The Product Ownership Test

By Roman Pichler, 10th January 2013

Owning a product sounds great. But what does it mean? How can we test if an individual or team owns a product?
Read on to find out my answers to these questions.

An individual truly owns a product if the person 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 feature soup, 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.


Article Name
The Product Ownership Test
This blog posts explains that agile product ownership implies the right to say no, to disregard feedback and to reject requests for new features.
Pichler Consulting Limited

Learn More

You can learn more about porduct ownership and empowerment with the following:


RSS Feed

Tags related to this post:

Leave a Reply

Your email address will not be published. Required fields are marked *