One of the first things you should do when you become a Product Owner for a new product is sit through the training class and all of the training videos, even if you are intimately familiar with the product.
When you watch an instructor teach a class on your product, it should become very obvious where the product is confusing or difficult to use. If the instructor is having to bounce through multiple screens to show off a feature or is pointing out settings that should always be configured a certain way, you have areas for instant improvement.
I was watching a training video on setting up a product to run as a service. The instructor pointed out multiple settings for the product workflow, that if turned on would cause the product to halt because user intervention would be required but could not be performed. Why were these settings available if there was never a case where they could work? Lazy programming? Give the admin enough rope to hang themselves? But what if someone wants that setting for a use case we didn’t consider?
NO! NO! NO! – Don’t make this mistake. If something can cause this much trouble, spend the time discussing and designing it so that it will work properly.
On a separate training video I saw an instructor configuring statistic collection for the product. He let you know how useful the statistics could be, but also warned you not to leave them turn them on because they would have adverse affects. GREAT, you have this really useful feature that I can’t or shouldn’t use because no one took the time to think it through. Statistics do not have to be resource hogs. They do not need to be something you only turn on occasionally. It is very possible to collect meaningful statistics all the time, without adversely affecting the system and without eating tons of storage, but it requires thinking about how to design it, what needs to be collected, what should be stored, where, and for how long.
In a training class I attended, the instructor was teaching us how to debug a data collection by tweaking a parameter. You could tell that the default value for this parameter was chosen arbitrarily by a developer and never thought about again. Except of course for the poor trainer and professional services team who actually had to make the product work in the real world. I had to wonder how many times the instructor recommended changing the default to the dev team and was ignored. Or did they even bother because so many of their other suggestions had fallen on deaf ears.