Two Experiments to Scale up the Product Owner/II

In our previous post "Challenges Adapting Product Roles when Growing" about that topic we have discussed common challenges of adapting the product roles and strategies during different stages of a company with the example of mySugr.

This post covers two experiments and some metrics that we have used to address the adaptation of the product role.

Main Drivers

The general idea we are following is to align product roles with fields within the drivers of the business model and unbundle the layered structure into vertical teams. The main drivers are customer segments and partners which each require a very different approach to managing the product. Each team will own end-to-end business objectives, e.g. making an impact for a specific segment on the customer side, growing key partners with device integration or enabling medical experts to connect with patients. We expect that this will result in improved business-level agility by shortening the feedback cycles, more focus and a clearer purpose for the teams doing the right thing, and motivation by creating a higher level of autonomy.

To test our hypothesis we will launch two experiments. First we will launch a small, autonomous team that explores a new segment using a lean approach with customer and product discovery tools. Second we will integrate the B2B business developer role as PO within a dedicated, cross-functional team bypassing the PO - business stakeholder man in the middle.

How do we Measure Success?

We’ve created a baseline using a quick questionnaire that assesses the status for the following health factors for lean and agile product management:

  • Ownership of product strategy

  • Relationship to the development team

  • Customer and market focus

  • Use of product metrics and innovation accounting

  • Lean and agile process

  • Workload and mastery level

  • Level of trust in and around the role of product

and we expect that within the two experiments we will see at least the aspects of ownership of product strategy, relationship to the development team and customer focus will improve.

Lessons Learned

There are no perfect answers to the question of how to organize. When scaling an organization new patterns will emerge inevitably and what worked in the past of a company may not work in the future. Having a continuous adaptation process in place is more important than trying to find the perfect structure. This makes the capability of experimenting even more important than striving for the perfect solution.

The structure of the product organization needs to match business objectives. Good products create value for customers and the business model of the company. Deciding the tradeoffs that need to be made and navigating the tension between the two perspectives is an essential part of the product process. The product organization needs to be designed to support this decision-making process.

We have observed the pattern of a centralized PO role in many cases and if this creates the described problems to us the solution is clear: level up the skillset and empower the product owner role so that the product decisions are made within a context of small autonomous teams having the maximum of knowledge available. Plus having a flight level 3 product Kanban system and product OKR in place to provide an inspect and adapt loop for the whole product group will be a topic for an upcoming post. Photo Credit: Erich Ferdinand, Flickr Creative Commons (https://creativecommons.org/licenses/by/2.0/)

Previous
Previous

#PoDojo Talks: Building Machine Learning Products: Lessons learned while building a machine learning product from scratch

Next
Next

Challenges Adapting Product Roles when Growing/I