Skip to main content

The Imperceptible Product Owner

April 19, 2018

This post was co-written by PSTs Sjoerd Kranendonk & Wilbert Seele.

In the Scrum Guide the following is written about the role of the PO: "The Product Owner is responsible for maximizing the value of the product and the work of the Development Team." For the Product Owner to succeed, the entire organization must respect his or her decisions. The Product Owner’s decisions are visible in the content and ordering of the Product Backlog. No one is allowed to tell the Development Team to work from a different set of requirements, and the Development Team isn’t allowed to act on what anyone else says.

In practice this often means the Product Owner starts acting like a gatekeeper of the Development Team. In the beginning, this might not even be bad in fact. Having all Stakeholder-Development Team communication go through the Product Owner allows the Development Team to focus on the work they intend to do in the Sprint. This can create a sense of calm if before the Development Team was often interrupted in their flow with new requests. But if left at this state, it can turn into something less helpful.

This is why we prefer the Product Owner to be less "visible", in a way. Not as in absent, but more that Stakeholder and Development Teams should directly interact, facilitated by the Product Owner. As Kniberg said in his amazing "Product Ownership in a Nutshell": The Product Owner enables communication between the Development Team and the Stakeholders.

Enabling communications between Development Team and Stakeholders means taking a page out of the Scrum Master's book. Trying to continuously relay communications or babysitting the Stakeholders when they consult with the team leads to Product Owner fatigue and a bottleneck in the flow of information. Instead of being needed for every communication, aim to facilitate. This means making sure 3 goals are reached concerning the communication:

1.    It happens when it's needed and on time (no blocking of development flow);

2.    Both sides of the communication understand their role & responsibility (clarity of accountability and its boundaries);

3.    The result is sufficient understanding to deliver a valuable product increment (shared understanding of item's goal).

A legendary Product Owner manages the delivery of value by decentralizing communications and decision making in as many areas as possible. They are not afraid to delegate authority to where the information is: let the the people involved decide what is important to reach the larger goal(s). As David L. Marquet wrote: "give control and create leaders".

Taking this approach to Product Ownership is valuable because:

There's No Single Point of Failure

  • You're the Product Owner for an important Product developed by your Enterprise. You've set yourself up to be the linchpin in the Value delivery process. You also forgot to look both ways when crossing the road and as a result, didn't see that bus coming. So now you're in the hospital for the next 6 weeks. What's going to happen to the Product now? Is the Vision on the Product alone enough to help the Development Team deliver for the next few Sprints? Especially if the Development Team isn't used to working closely together with its Stakeholders, or even speaking each other's language? Risky, right? However, if you had spent some time cultivating their relationship, then a clear understanding of the Product Vision might just be enough to keep things on course until you recover.

Continuous Team Growth

  • What are the career prospects of Development Team members? What are the career prospects for a Product Owner for that matter? Scrum really doesn't say all that much about it, save that the teams will mature, and the quality of what they deliver will mature with them. Maturity isn't just technical skill though, it's also taking more ownership through understanding the Product the Scrum Team as a whole is developing. Enabling Interactions between the Individuals of the Development Team and Stakeholders means you're free to spend more time working on the Vision of the Product, but also familiarizing yourself with the broader elements of Product Ownership, such as tracking Total Cost of Ownership and Return On Investment of your Sprints. This means you can grow into the Entrepreneurial Product Owner Scrum sees at the end of the maturity curve. But you can only do this if the rest of the Scrum Team matures with you, and that only happens if you get out of the way.

Enhances Team Understanding of Value

  • When a Backlog Item is not clear enough, an empowered Development Team will collaborate directly with the affected Stakeholder(s) to adapt the solution to their newly discovered insights. Working this way, team members can learn firsthand what is valuable to Stakeholders. In other words, by loosening control on the value steering and getting out of the way, the team is empowered to validate their assumptions with less handovers and less potential for confusion through multiple layers of interpretation. However, decentralized decision making will only generate mass benefits when all people involved are working on a shared Vision or Strategy. Without this clarity in the greater goals there is no alignment, leading to a chaotic approach: a lack of focus preventing the team to ‘move as one’. Another benefit is a less waiting time by cutting out the ‘middle man’. This frees up the Product Owner to invest their time in other activities, for instance working with multiple Development Teams on a larger Product development effort. Please note that while the Development team may do the work involved in Backlog management, the Product Owner remains Accountable!

So here's our gift to you, dear readers: the core take-away. If your ambition is to be a legendary Product Owner, don't block the interactions between the Development Team and the Stakeholders. Remember the Agile Manifesto: Individuals & Interactions OVER Processes & Tools. While being a link between Stakeholders and Development Team can be a great way to facilitate collaboration and shared understanding, especially at the start, if you remain the sole communicator this keeps a process in place that inhibits the interactions that are crucial to improve your Agility.

Product Ownership is serious business. So take it seriously; don’t do it alone.


What did you think about this post?

Comments (3)


Guilherme Krüger Romariz
09:15 pm April 23, 2018

Nice post, but there is one thing that can be a problem, the stakeholders. When you say that development team needs to be mature with you, I think we can say the same for the stakeholders.

Unfortunately, often the people who are the "customer
" end up losing the reference on what and when to deal with the development team. In practice, if the "customer" is not mature enough, this may compromise the speed of deliveries and generate breach of trust.

What you think guys?

Best regards,

Guilherme Romariz


Dinesh Chandran R
05:22 pm July 16, 2018

I agree with this. We can allow the direct interaction, when customers also understand the process of development. Most times, I as a product owner ends up taking all the pressure that the customer creates and allows the team to work on the free mindset to achieve the definition of Done. There is a high risk involved in the direct interactions that too with customers who are new to product development.

It is a gift if the customers have greater experience on product development and a benefit for product owner.


Rene de Ruyter
06:57 am April 12, 2019

True, it's all about maturity in the broadest sense. In a customer/supplier relationship is it fair to expect and demand the commercial customer to be truly mature working with Scrum teams? I don't think so!

The areas that the Development teams interact with Stakeholders must be concise and limited. So for example in the Refinement phase, cutting out the man in the middle and have the Dev team collaborate directly with Stakeholders is a good thing. Asking Stakeholders directly for clarification during the Sprint is also a good thing. But only if expectation and scope management is also in place. This is a commercial aspect that is something the Product Owner should have in its skills set. For Dev team members that is a desirable but optional skill.

What I have found during my many years working with Scrum teams, is that the demand on IT is much bigger than the capacity of those teams. That's one of the reasons why we prioritize. This is something best done by one accountable person. Remember what the Scrum guide says about this: "The Product Owner is one person, not a committee. ". Having the Dev team members involved in Stakeholder information gathering may lead to a feeling of a committee.

Also consider that Stakeholder management when done with the Dev team members consumes time the Dev team can not use to produce working software. Dev team members like to focus on the things they are doing and may find they can't focus on there work if they have to maintain an active relationship with Stakeholders.

Concluding: Yes, a warm and constructive relationship between Dev team members and Stakeholders is desirable. But care have to be given to expectation and scope management and 'burden' on the Dev team. The Sprint review is meant for exactly this. Have the Stakeholders involved in what is build and empirically go forward. Of course chances are that what is reviewed during Sprint Review will look more like what the Stakeholders envisioned when clarifications can be given along the production cycle. But a strong pull from Stakeholder side may impact the original Sprint goals and Vision as it is perceived by Dev team members. Role clarity is key for most people. Maturity of teams, organisations and Stakeholders may give room for broader fullfilments of those roles.

Be carefull!