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


A template for application metrics

1 min read

I love patterns and templates. I love them even more if they are proven in practice. In the context of metrics my template for application metrics is a really useful little helper. IMO it is not only a product owner’s artefact but also a valuable medium when discussing the overall nature of a digital product with the development team. Consequently it is a plus when a product owner has created a sufficient collection of application metrics and provides further information as given in the template before any code is written and the whole team is shaping the vision and the architecture of their digital product.

An important component of the template is the second part where it’s about business value, targets and business impact on target violation. In my observation this is often a neglected aspect.

Find the template including an example metric on Google Docs: Various formats are provided for download. Any feedback is appreciated!

The template is licensed under Creative Commons BY 4.0.

A classification of application metrics

6 min read

When you're a product guy you love monitoring your metrics, don't you? How, otherwise, could you develop your product purposefully?

In the last weeks I was musing on a classification of application metrics for back-end data systems which do not provide interaction with (end) users / customers. I.e. classic and well known e-commerce metrics like average order value, conversion rate, etc. are absent. This is how I have come so far:

What is a metric?

My ultra short (Twitter compatible) and simple definition is:

A metric is a quantitative information which enables conclusion about quality.

Application metrics need a connection to business objectives to make an interpretation possible (positive? negative?). See Kaushik for a well defined drill down [1].
KPIs are a subset of metrics which - according to Kaushik - "helps you understand how you are doing against your objectives" [2]. Full ack.

Why metrics are important?

Metrics are essential for product managers to drive their products against the business objectives. Furthermore metrics are indispensable for efficient communication between the product division and the company management. Why? They are basic common sense and act like wormholes between these two worlds of mostly divergent thinking, acting, and talking.

The popular Lean Startup movement has even established the Build - Measure - Learn cycle as an axiomatic premise for building successful products.


The scope of this blog post comprises business data systems / services without direct interaction with (end) users / customers. Systems that collect or produce, transform, store, and provide e.g. product or customer data via APIs. True back-end.

Ensuring data integrity is a crucial requirement especially in distributed and / or microservice environments. Example: Receiving five new object events via the input stream must generate five new object events on the output stream regardless of complexity and distribution level of the process chain.

The metrics in question focus the application layer which is following (i.e. is above) the infrastructure layer. Therefore I call these metrics application metrics. The application layer is the layer where business logic resides. Datadog’s Alexis Lê-Quôc has also published a classification of metrics (which has inspired me) where he has identified "work metrics" [3] which look similar to what I refer to as application metrics.


The following classification of application metrics helps organizing your metrics as well as identifying your KPIs, and thus remembers you what kind of metrics is worth to have a look at.

Class: Integrity

Description: Covers metrics that indicate if processing the business objects along the process chain is successful or not. As integrity - especially in distributed and/or microservice environments - is crucial, metrics from this class should be casted to KPIs.

A process chain

  1. Import customer data from a message queue
  2. Transform customer data
  3. Save customer data in database
  4. Provide transformed customer data via RESTful API

Example values:
Calculate ratios

  • "No. of new customers imported per day" / "No. of new customers saved in database per day" = 1
  • ...
  • "No. of new customers saved in database per day" / "No. of new customers provided via API per day" = 1,25

The resulting ratios are metrics. A ratio = 1 indicates processing is successful; i.e. integrity is ensured. If ratios are != 1 errors must have occurred.

Of course, atomic "No. of new customers imported per day" is a metric, too. It is a quantitative information about the quality of efforts to generate new customers. However, the product owner of the business data system which processes, saves, and provides customer data to other internal systems has no influence on this metric. Therefore it cannot be one of his KPIs. It is a minor quantitative information (see next class).


Class: (Minor) Quantities

Description: Covers metrics of less interest the product owner cannot influence

A process chain

  1. Import customer data from a message queue
  2. Transform customer data
  3. Save customer data in database
  4. Provide transformed customer data via RESTful API

Example value: No. of unique customers in database


Class: Performance

Description: Self-explanatory. Performance metrics are fundamental indicators how an application is doing against its non-functional objectives. Therefore performance metrics should be casted to KPIs.

A process chain

  1. Import customer data from a message queue
  2. Transform customer data
  3. Save customer data in database
  4. Provide transformed customer data via RESTful API

Example value: 90th percentile end to end processing time of customer data (“a customer”) in seconds per day: 1.2

Class: Errors

Description: Self-explanatory. Error metrics could be casted to KPIs because errors indicate that an application is not meeting its objectives.

A process chain

  1. Import customer data from a message queue
  2. Transform customer data
  3. Save customer data in database
  4. Provide transformed customer data via RESTful API

Example value: No. of HTTP 500 per day: 2


Class: API analytics

Description: Covers metrics to analyse client server interaction

A process chain

  1. Import customer data from a message queue
  2. Transform customer data
  3. Save customer data in database
  4. Provide transformed customer data via RESTful API

Example value: No. of requests responded with HTTP 200 on resource /customers/city/Berlin


In the context of metrics some specific actions are relevant which are sometimes confused IMHO.

  • Logging: The act of producing raw data e.g. by Syslog to enable the generation of metrics (e.g. a count of specific log entries).
  • Monitoring: The act of watching metrics constantly; performed by a human or a computer (program).
  • Notifying: The act of notifying a specific person or a specific group of persons when a specific event in the context of metrics happens, e.g. the occurrence of an HTTP 500.
  • Analyzing: Best see

The support dimension

Some last words are dedicated to the support people doing a great job often 27/4. When collecting raw data for your metrics in class Error collect as much information as possible. "What good data looks like" in [3] is a great inspiration on this topic. Focus on these two objectives: A) identify the problem asap, b) fix the problem asap. And don’t forget to measure the total time an incident needs to be solved.




(Digital) product owners, beware of the iceberg!

2 min read

The mind map below was posted on Twitter months ago. However Twitter's limitation to 140 characters didn't allow further words about my motivation. This is the addendum.

Building digital web products from scratch the agile way including continuous delivery or even continuous deployment requires "operations thinking" right up from start. A common mistake (IMHO) I have seen several times is that many product owners almost exclusively care about user interaction - the visible part of the product - and most effort is spent on UX. This is an important aspect, of course. However, this is just the top of the iceberg. I guess nobody wants to ship a product which breaks on increasing traffic, which is not prepared for handling data loss or which misses a proven backup and recovery process. I.e. - from an operations perspective - I guess nobody wants to ship just a prototype while the company expects stable software up running. 

But isn't this the team's job? Well, let's sharpen the role of a product owner. In this case this is perfectly illustrated by the difference between responsabilty and accountability as defined in RACI. The team is responsible writing and shipping and maybe even running the software while the product owner is accountable for the whole product. Therefore a product owner has to care about performance, backup and recovery, monitoring, SLAs, security, etc., etc. A product owner is responsible (!) to create, refine and prioritize backlog items which cover the operations aspects of his product (the what). It is a native product owner task. It is not expected that a product owner has the know how to answer all these questions and presenting perfect user stories of operations epics passing the backlog refinements without any question. Providing the how is in the team's realm. Of course, any input from the team on the what is appreciated. But managing the discussion, asking the right questions, asking for yet another load test, etc. is in the product owner's task portfolio. He's got the active role here.

The following mind map helps me to remember all facets of a digital web product. It serves as a boilerplate for the collection of epics especially when I have to create the initial backlog. It is a life saver.

Mind map creating digital product

If you think something is missing please drop me a line. Any input is welcome.

A comprehensive collection of monitoring tools and services: