Owning a product sounds great. But what does it mean? How can we test if an individual or team owns a product?
An individual or team truly owns a product if the person or group has the right to say no. Don’t get me wrong. I don’t want to promote a negative mind-set or can’t-do attitude. But as Steve Jobs said: “Innovation is not about saying yes to everything. It’s about saying no to all but the most crucial features.” If we take on every idea or feature request, we are likely to end up with a bloated product that is expensive to develop and that provides a poor user experience.
In a cyclic process such as Scrum, feedback from stakeholders is regularly used to understand if the right product is developed, as the following picture shows:
In the picture above, the team creates a product increment guided by the overarching vision. Feedback is then obtained by exposing the increment to the right people. These include users and customers as well as internal stakeholders such as representatives from marketing and sales. Demoing or releasing the increment results in new ideas or requirements. Sometimes powerful stakeholders such as a management sponsor or customer request new features based on what they have seen.
Any constructive feedback is good feedback and should be welcome, but not all feedback is helpful and relevant. It’s the job of the people creating the product to analyse the feedback and to decide which pieces are and which aren’t relevant. Feedback is irrelevant when the data quality is poor, for instance, if a piece of information is unclear or ambiguous, or if the feedback is not helpful to reach the vision or release goal.
The relevant feedback is used to change the product backlog or product canvas thereby shaping the next product increment and progressing the product further. But any irrelevant data should be disregarded, symbolised by putting it in the trashcan in the picture above.
Disregarding feedback implies the right to say no. It may mean telling a customer that a feature request will not be fulfilled, at least not in the near future. Being empowered to push back, to filter and select, puts the people creating the product in control. It allows them to move fast, to try out new ideas, and to decide what the product should look like and do. But it also implies being responsible for making the product a success: developing a product that does a great job for its users and the company.
To find out if you truly own your product, ask yourself: Am I empowered to disregard feedback and reject requests? Can I say no, even to powerful stakeholders? Exercising agile product ownership requires a positive answer to both questions.
You can learn more about product ownership and the product owner role by attending my Certified Scrum Product Owner training course.