1 - Micromanagement
Some product owners - and even Scrum teams - feel that all decisions about the Product, including features, UI and UX must be made by the Product Owner.( Let us ignore for a second the fact that this is turning developers into mindless drones, because Software development is exclusively about decision making - the "implementation" is the easy part, finding out how to do it best is the hard - and fun - part. )
This implies that the Product Owner must be available whenever a decision is being made.
Also, that the Product Owner would need to understand the intricacies of UI, UX, SEO, SMO etc. (which would make the PO quite a jack-of-all-trades) - it means that the PO is considering the Product on a very base level.
The Product Owner should be more concerned with strategic propositions of the Product - such as which customer segment to target, what value proposition to offer - and how to turn a more or less clearly understood market need into a feasible backlog item.
2 - Being a designer
Some go as far as having the PO explicitly define all Acceptance Criteria and spoonfeed them to the team. There are two problems in this:- This forces the Product Owner to spend a significant amount of time with intricate details of the "How" in implementation.
- The product design is biased around the Product Owner's understanding of technology.
Let us consider a Site Landing, for example: "As a customer, I want to register so that I can use subscription services".
The Product Owner proceeds to design the Wireframe including all form fields and buttons, defines the events and hands that to the team. But that is bad for the product. Why?
Because the solution was pre-empted: Point in case - customers DON'T want to fill in registration forms. (just consider yourself: When was the last time you enjoyed that process?) Customers want to use services. Registration is the standard way of making subscription services available. But there may be different ways of identifying subscribers, such as - referring to an existing Google / Facebook accounts, etc. - you might even want to use facial or fingerprint recognition. That's easier for the user and serves the same business purpose. And users don't end up with the umpteenth password to remember.
3 - Being a Scrum Master
While the Product Owner is responsible for the success of the product, they are not responsible for enabling the team to work un-impedited. Scrum clearly discriminates the Product Owner and Scrum Master roles, for multiple reasons.One of these reasons is, of course, that the Product Owner wants maximum value in the shortest possible time - while the Scrum Master might have to shoo back the Product Owner on decisions affecting technology that might compromize sustainability of the Product. The most common decision (un-enlightened) Product Owners make is to cut short the testing in order to speed up delivery. In these cases, a Scrum Master must intervene.
If the Product Owner perceives the urge to go about educating others about Scrum and resolving team impediments, this means that the Scrum Master isn't doing their job. No accusation to the Scrum Master - maybe that's an organizational issue. But if the Product Owner does the job of the Scrum Master, then the team remains in dysfunction: Not only does the burden on the PO increase, the key impediment does not get resolved.
It is better for the Product Owner to step back, sit with the team and Scrum Master - and find a solution for this issue than for the PO to sprint into action.
Summary
Being a good Product Owner may - occasionally - imply doing something that is definitely outside the sphere of your core responsibility, i.e. envisioning and packaging a great product. However, if you see that you are spending a significant amount of time with stuff that should be done by others, ask yourself "What am I doing here?" - give it to the team, and refocus.You will only succeed as a Product Owner if you do what a PO should do best - not when you do what others should be able to do better.
No comments:
Post a Comment