Skip to main content

Collective product ownership

5 min read

Often, (locally) new concepts* are born when a more or less complex task has to be accomplished. Same applies here.

The story

Right on the halfway to an MVP I’m having a two months paternity leave. Good news for my little son, bad news for the project? Nobody likes bad news...

The task

Eliminate the single point of failure of the product ownership and establish a collective product ownership. This concept is inspired by collective (code) ownership in XP [1] which, however, only affects the development team. On the other hand collective product ownership is an holistic approach which, consequently, affects the whole team. Both are democratic, though. This concept looks so promising that I tend to introduce it as a common agile practice and not only using collective product ownership in exceptional situations.


Generally spoken collective product ownership means a masterless product ownership. I.e. there is not a single team member (traditionally the product owner) who feels strong empathy for the product’s success - this empathy is spread across the whole team. Consequently, the product vision as well as the product roadmap are virtually joint artifacts.
Product ownership has different facets, e.g. financial, legal, organisational, empathic / emotional ones. Collective product ownership targets the empathic / emotional level.


There are three main benefits:

  1. Be more efficient and effective by using swarm / collective intelligence. The more complex the task is the bigger the benefit of swarm / collective intelligence is.
  2. Be more efficient and effective by enforcing universal motivation. The more complex the task is the bigger the benefit of universal motivation is.
  3. Be more secure by eliminating a single point of failure in a crucial job (like you do in software architecture and often neglect in organisations).

The role of the product owner

Collective product ownership doesn’t exclude the product owner (as a role assigned to a specific person). In my opinion, it is (still) naive to believe that the large majority of medium and large enterprises allows fully self sufficient product teams. From my experience, enterprises still need accountables (according to RACI [2]) to meet the requirements of their organisational structure. The concept of primus inter pares [3] seems to be a solution, a bridge, to connect collectivity with the requirement of having one accountable. I.e. from the external perspective the product owner is accountable for his product and responsible for the product vision, backlog and roadmap while internally creating and refining the vision, backlog and roadmap are collective tasks. As the primus inter pares the product owner has the right of a double voting on these topics e.g. if discussions are stuck. The product owner puts (creating) the product vision on the agenda, provides drafts of the product roadmap and backlog, leads the backlog refinements in Scrum. He is the driving force behind the product mission.

How to establish collective product ownership?

The crucial task is that every team member internalizes what the product to build is about; what the value of the product is (from the customer / user perspective). It’s about the big picture, not the details which are constantly discussed during the journey. The concept of Self-contained systems (SCS) [4] is beneficial here as a system in the SCS approach is reduced to only a few, or even only one, domain specific job(s). 

From my experience I consider the following actions effective:

  1. Schedule a minimum of one week before starting the iteration 0 (sprint 0 in Scrum) to draft, discuss, refine, and sharpen the product vision, the initial version of the roadmap as well as the architecture of the product to build. You may find the mind map for digital products inspiring and useful [5].
  2. Formalize and record the results together in iteration 0.
    1. E.g. use Roman Pichler’s “The Product Vision Board” [6] for the product vision.
    2. Create the initial prioritized set of epics and backlog items (stories in Scrum) which are subject of the following backlog refinements.
  3. Create the initial set of metrics and KPIs together: How do you objectively check if your product is moving right against the stakeholder’s objectives? You may find my template for application metrics helpful [7] (find a further read in [8]).
  4. Create the DoR and DoD as joint artifacts in iteration 0.
  5. Use the backlog refinements to check periodically how you are proceeding towards the product vision. Does the generated knowledge during implementation require corrections? Always remind the big picture and don’t lose yourself in the details.

Remember: It’s plausible and perfectly compliant to the idea of collective product ownership that the product owner creates the initial drafts and drives the discussions.

The action part is a field for discussion and learning. The verification of the hypothesis is still running. I’m really curious about the result when I return in the middle of September.

* After doing some research on the web I found an “experience report” [9] from 2006 which is about “Ript: Innovation and Collective Product Ownership” [9]. Some slides are available for free [10].

References, links