How To Identify A Weak Product Organization
By: Iris Bröse
Tags: Organizational Culture, Product Management, Agile, Organization, Product Development

Do you want to have a strong product organization?

After reading “Inspired” by Marty Cagan I have had this eye-opener: if you really want agile to fulfill its potential, you need to put a focus on a strong product organization, too. These two decisions have to go hand in hand and the implications need to be discussed!

I want to share an example of an organization that decided to “become agile” but didn’t want a strong product organization.

3 symptoms of a weak product organization

When working with the product teams, the majority reported versions of these three points in their Retrospectives:

Lack of prioritization and planning: new topics coming “out of nowhere” mid-sprint and needed to be put on top of everything else. In other words, there was no real planning beyond a two-week horizon for development teams. Control down to sprint level: pre-sprint planning meetings with top management (!) to plan the next sprint of a team. In other words, the team was not able to say “no” to anything because it was already decided what goes into their sprint. Lack of clarity and direction: the dev teams didn’t know why they had to do certain things a certain way. They didn’t know the company strategy or goals, they didn’t understand their stakeholders’ or users’ needs. In other words, the team was completely removed (or rather kept away) from the bigger picture.

Why would they even need clarity on where things were going strategically? — They were a service team! They were busy fulfilling urgent requests and plans that someone else made in a pre-meeting before the actual planning.

Interestingly enough, there was little talk about the Product Owner at all. And why would there have been — they obviously had not much say. The real business decisions were made elsewhere.

We, the team of Scrum Masters, therefore wanted to understand what led to this setup and under-valuing of the Product Owner in the organization. We set out to discuss the Delegation Matrix with Product Owners and stakeholders.

Hypotheses about the WHY

The hypotheses we had to the “why” of things were the following:

The Product Owner role is not understood There’s a lack of trust in Product Owners and teams to deliver the right “what” The organization thinks in functional silos, not in cross-functional product teams

Weak or strong product organization?

In the end, we only tested the first hypothesis we had about the organization. Through the conversations, though, the other two were also touched.

From the conversations about the role and own discussions on the organizational setup, we saw the following:

Stakeholders considered themselves to be accountable for a product because they have KPI goals they need to achieve. In order to achieve them, they need to tell the product teams what to do and when. In the past, Product Owners were only there to write things down for the development team and organize the nitty-gritty details of product delivery. With already decided solutions, constantly changing priorities and no idea about the stakeholder’s KPIs, Product Owners didn’t have the time nor the freedom to do discovery on their own. Product Owners didn’t understand the operational processes deeply and couldn’t have an eye-to-eye conversation with the stakeholders about their challenges. This led to the stakeholders’ belief that they need to give solutions and define the “what”. An eroded understanding of the Product Owner role was one of the results of this setup. On the other side, the organizational structure didn’t help either. Functionally organized, the product organization was reporting to the CMO. Marketing, also being a stakeholder for the website teams, was therefore very strongly represented on this side of all product teams. Scrum Masters were reporting to the CTO who wanted to create a stronger and agile product organization. However, since there was nobody representing “product” on a top-management level, the fight was a very difficult one to fight.

The organizational setup and past experiences led to an unclear understanding of the Product Owner’s accountabilities and responsibilities.

This, in turn, led to strong stakeholders and weak Product Owners — diminishing the product organization altogether in the eyes of upper management.

The decision to go for a strong and agile product organization was never consciously made and therefore it ended up becoming a weak product organization.

What about your organization: do you see similar structures and implicit assumptions? What else helps to identify a weak product organization? Feel free to leave some comments!