Often we find at the core of a great product is a great Product Owner (PO). The Product Owner holds the vision for the product and prioritizes the work to be done. They steer the team to create the product. If the product they define is not ultimately what the customer wants then no matter how well it is built all bets are off. Here are seven strategies for effective Product Owner.
1. Be the SME
The PO must have a deep understanding of what the product is to be. They must spend time visualizing the system before it is built so they understand it as much as possible. They must be a subject-matter expert (SME) in the domain they are working in as well as being able to communicate to the developers what needs to be built.
2. Use development for discovery
While the PO must hold the product vision they must also keep an open mind to discovering better solutions in the process of building it. Iterative development provides many opportunities for feedback and the PO should take these opportunities to get features in the process of being built in the hands of users to make sure development is on track and to find out if there are usability questions.
3. Help developers understand why and for whom
Understanding why a feature is being requested and whom it is for gives developers a context for what is being requested and can often come up with better, more maintainable implementations that get the same job done but is also more generalized, flexible, and extendable.
4. Describe what you want not how to get it
One of the many benefits of stories over specifications or uses cases is the focus on what to build and not how to build it. Developers often interpret specifications or use case descriptions literally into code, making it difficult to generalize a solution later. POs must be careful not to tell developers how to do something and instead focus on what they want done. This can give developers the freedom to come up solutions that are more maintainable.
5. Answer questions quickly
How can a single-sentence story replace a specification? It can’t. Stories are a “promise for a conversation” between the PO and the developer. The PO must be always available to answer questions that come up throughout development. Often, answering developer questions becomes the bottleneck during development and when the PO is not available development slows down and developers must make assumptions that may turn out not to be true.
6. Remove dependencies
POs typically don’t code but they can help the team by working with other teams they depend on to ensure the dependencies don’t hold anyone up. They order the backlog and must ensure that any dependencies across teams have enough lead time.
7. Support refactoring
It is the POs job to request features but they must also be sensitive to the quality of the code being produced so it remains maintainable and extendable. This often means supporting the team when they feel that refactoring can help. Technical debt can accumulate, even when developers are doing small refactoring as they go. Sometimes a larger refactoring can become advantageous before adding more features to a system and the PO should know when to support this.
The Product Owner is a critical role in driving product development with Scrum. It is not a technical role but it requires great talent and communication skill. The PO must have a deep understanding of what is to be built and be able to answer developer questions that come up in the process of building features. When a PO is available to the team to quickly answer questions and provide direction then software development can rapidly move forward.
Previous Post: « Seven Strategies for Getting Support from Management
Next Post: Seven Strategies for ScrumMasters »