How Product Managers can climb the Ladder of Autonomy

At Delibr we spend a lot of time talking to, and coaching, people in product. These people often feel like they do not have enough autonomy to influence where the product is heading. Instead, leadership is administering what they should build, or sales or other parts of the organization hand them requirements.

A few days before writing this article a seasoned PM with 10+ years of product management experience told us: "I've worked as a Product Manager in a handful of companies and all the time it's top-down. Crazy top-down, 9 our of 10 PMs just get told what to build!". This is just one example of many.

Product Managers want autonomy, but most feel that they lack it. Trust is the main driver of autonomy. That's why we would like to present the Ladder of Autonomy for PMs and discuss ways to build trust, climb the ladder, and adopt a more outcome-driven product management style. We believe that the move towards being more outcome-driven is the single most essential move a product organization can make - for individual PMs, the companies they work for, and ultimately the users they serve.

We regularly hold training programs with Product Managers on the topic of becoming more autonomous and outcome-driven. If you like what's in this article, make sure to check out when the next training program begins at the Delibr Academy.

Product managers want autonomy to work across their entire process

Everyone wants autonomy. Autonomy is one of the three main drivers of motivation, together with mastery and purpose, as laid out in the book Drive by Daniel Pink.

And product managers crave autonomy more than most because they are not individual contributors but rely on others to "do the real work". Developers write code, and designers craft designs, but the job of a PM is supposed to be to ensure that the product is successful.

But doing the job of making the product successful means being involved across the whole product management process, as shown below:

In the ideal situation, the PM has either a leading role or at least a highly committed role across the whole process, giving a sense of autonomy and of being able to influence whether the product is successful.

‍

Product managers lack autonomy due to limited trust

Most product managers lack autonomy

Unfortunately, the ideal situation is not as common as it should be. Leadership often tells PMs what features build or even hands over requirements based on input from sales or other parts of the organization.

As a result, many PMs feel demoralized. Some feel like "requirements gatherers" or even just "spec writers". Some suffer from imposter syndrome, as they know they are supposed to make the product successful, but don't feel that they are actually able to influence the success of the product.

Marty Cagan also describes this situation in his article "The Best vs. The Rest".

Lack of trust is the main underlying problem

There are often many distinctive superficial reasons why product managers are not given full autonomy, but as Paul Adams says on Melissa Perri's podcast: "The underlying problem is almost always trust".

The lack of trust in this situation is sometimes about the relationship or competence, but it is most often about alignment.

The relationship

If the lack of trust stems from the relationship, then a good place to start is the trust equation.

Competence

If the lack of trust stems from hesitancy regarding competence, then it can be good to go through a PM skills competency matrix with leadership to see the expectations they have across different types of skills and what skills could be improved to increase autonomy.

Alignment

However, most often, a lack of trust stems from leadership not feeling that there is enough alignment. As a response, and to avoid chaos and inefficiency, leadership gets involved in the details, thereby reducing autonomy. Henrik Kniberg has a great illustration of this.

‍

To climb the ladder of autonomy, PMs must build trust over time

Product managers must build trust to expand their role and achieve autonomy across the entire product management process. They can do this and climb the ladder of autonomy by building trust over time.

Modus operandi

PMs at this stage are often handed partially defined features to refine and hand over to the development team. In the case with the least autonomy, the PM is handed a set of requirements, and their job is then to translate them into a specification together with the development team.

When the product manager (PM) and product owner (PO) are split into two roles, this becomes the job of the PO. Some PMs/POs do a good job at this part, e.g. with strong cross-functional facilitation of decision-making and user story mapping sessions. Nonetheless, the fact that they are being told what features to build does detract from their feeling of autonomy.

The PM is confined to only part of the process, and from the point of view of the PM, the process looks something like the below. Notable in this description is that the PM lacks both strategic context and contact with actual users.

Example feature - Single Sign-On

For PMs and POs who receive feature requirements that they need to specify with their team, it's very common that the conversation around the "why" is nowhere to be seen. There's simply no reasoning around the underlying customer problem(s), main user types, how to measure if the feature is successful, etc. In the context of writing a Product Requirements Document (PRD), this often shows because the entire "problem"-section is missing, and we jump directly to the solution.

Therefore, PRDs at this stage often look something like the below screenshot.

To improve the PRD, the PM needs to add a good Problem section, and to do that they need better as insights into strategic context and input from actual users.

The next step

PMs that operate at this stage often feel like they are lacking autonomy and are simply being handed features to develop. I've seen this many times with the PMs I've coached. But at this point, it is worthwhile stepping into the shoes of leadership. I'll say it plainly: It is not reasonable for leadership to give a PM that does not understand the strategic context and that has hardly spoken with users the free reign to decide what features to build.

So, to PMs in this situation, I say: Start earning the trust you will need if you want to eventually transition to a more outcome-driven way of working.

There are two simple things that a PM can do to move to the next stage: engaging in feature definition through PRD writing and building understanding by talking to users.

Engaging in feature definition through PRD writing

By writing Product Requirements Documents/PRDs (or whatever you call the main document that describes the why, what and how of the feature). Doing this means engaging in the definition of features. This will build trust in that you understand the context for features.

Most often it is appreciated if you just step up and do the work of creating a PRD. In most situations, people appreciate leadership. If somebody else is writing the PRDs, it can be a good idea to ask them to involve you. As you are let into the process, first aim to prove helpful to them by saving them time, and then over time try to make the case that they should delegate writing the PRD to you.

A strong argument for PRD-writing is "I just want to understand why we are building this, it helps me build a better feature". Stepping up in this way, showing that you want to understand and be helpful is a good way to build trust.

When writing PRDs, and building the trust needed for the next step, it is important to think through and cover the relevant aspects for each particular feature. This can vary a bit depending on the feature, but often includes thinking about:

• Why should we build this feature? For which type of users?
• What kind of feedback have we heard to make us think this is good idea to invest time on?
• How will we measure if we are successful or not?
• Which potential solutions could solve the problem/need?
• What use cases and flows do we need to cover?
• What assumptions have we made, and which ones are most risky?
• How can this feature be sliced into the smallest release that is still valuable?
• What must the rollout plan cover to ensure it gets all the way into hands of users?

To make it easier to cover the right topics for any feature, it can be helpful to start from a PRD template.

Building understanding by talking to users

In order to understand the problem/opportunity space, it is critical to establish a process of regularly talking to users.

Being engaged in the definition of new features can help you make the case for talking with users, as it gives you a perspective on the number of user insights behind new features. When a new feature is pushed for with barely anecdotal evidence from users, it is often a good idea to suggest talking a bit to the users.

Building understanding is a strong argument also for talking to users: "I just want to understand, and hearing from users the problems they have and how this would benefit them will help me build a better feature". Showing that you want to understand and be helpful goes a long way in building trust.

Based on knowledge gained through talking with users, it will be much easier to understand how and evaluate whether suggested features will actually help them, and to challenge when they don't make sense to build. As it becomes clear that talking with users leads to valuable insights, the case for conducting such interviews becomes stronger. Before you know it you are regularly talking to users.

Leveling up

At this point, you should be able to start the transition to a different modus operandi where you move from receiving requirements to getting higher-level feature ideas. Leadership is rarely stupid, and they can save a lot of time by making this move, and so most of the time it is just a matter of building the trust needed, and then having a dialogue. (Unless you are a PO working in a SAFe setting, then you are eternally condemned - or at least face an even more uphill battle).

Modus operandi

At this stage, PMs receive higher-level feature ideas from leadership and other stakeholders and are expected to then figure out whether and how to build those features by taking both strategic context and insights from talking with users into account, as well as by working closely with their team.

The PM has a larger influence on what parts of a feature to actually build, how to do it, and can also to some extent highlight problems with solutions and suggest alternative ones. The PM aims to take responsibility for the developed features, setting and coming back to a measure of success, as well as getting involved in the rollout plan. From the point of the PM at this stage, the PM process looks like this.

Example feature - Single Sign-On

As you build a better and better understanding of the context for what you build, and express those in the PRD as e.g. formulation of the problem to solve, received feedback, and measure of success, you can start to poke at the feature idea itself.

The first, a bit more innocuous way to do it is to just add a section with "Alternative solutions", where you compare pros and cons for different solutions. Once you have done the work up to this point, with a clearly articulated problem to solve, it is often possible to ask a pointed question, for example: "How to reduce the friction of entering email & password?" (as in the first example below).

The next step (which is more of a middle-step to actually working with opportunity solution trees) is to make an opportunity solution tree for the epic you are working on (as in the second example below). By doing this, you can highlight not only the link to the outcome and that there may be different solutions to reach it, but also that there might even be different problems to solve to reach the outcome.

The next step

To fully move away from being a feature factory with limited autonomy you need to convince the leadership team to transition towards discussing goals and outcomes rather than prescribing features to build.

As you continue to talk with users, you become better and better at mapping suggested features as solutions to underlying opportunities. As you add stub opportunity trees to different features, a pattern will start to emerge. Typically, most features will be related to one or a couple of goals, and so you will be able to capture most of the features with one or a couple of opportunity solution trees

If you can bring these type of opportunity solution trees to your leadership, something nearly magical will happen, as you will be able to have a different kind of discussion with them. From this vantage point, it is clear, that the outcomes and the opportunities are more important to talk about that the individual solutions.

Leveling up

From here on, you should be able to start the transition to a different modus operandi

• Negotiate goal over time - if there are too many different goals to pursue at the same time, it should now be possible to have a discussion on limiting that to one or a couple per quarter (adopting OKRs  often goes a long way towards this).
• Opportunity solution tree at core - try to make a discussion of the status of the opportunity solution tree one of the first agenda points in talks with leadership.
• Generate multiple solutions for each opportunity - to further drive the point that feature ideas are not the most valuable input, generate multiple solutions for the prioritized opportunities.
• Conduct experiments to validate risks - alleviate the tension the above point creates by having a plan for testing and concluding which of the many solutions is the best.
• Validated solutions premiered during prio - fully drive the point home in the next feature prioritization meeting, by comparing the expected value of a validated solution from this process with another suggested feature.

Modus operandi

At this stage, PMs are involved in the whole chain from from outcome to opportunity to solutions validated in experiments. They negotiate the outcome with leadership at a low frequency (e.g. quarterly). Then over time, working towards their agreed outcome, they drive the work across the opportunity solution tree, and use the tree as an artefact to create alignment and trust that they focus is on the right things in discussions with leadership.

From the point of the PM at this stage, they are heavily involved throughout the product management process, and as a result, they experience a high degree of autonomy.

Example feature - Single Sign-On

What distinguishes this stage from the others is that many discussions with leadership happen with the opportunity solution tree as the starting point, with PRDs and other artefacts being pulled up to clarify any details.

You can see the opportunity solution tree below. Discussion starts from the top, and only once there is clarity on the problem space and what parts of it to explore does it make sense to jump in to discuss solutions. In discussion of solutions, there is an emphasis to look at several different solutions. Once discussion goes down to a single discussion, the PRD will play more or less the same role as before, but often with more clarity around the problem space, and a higher emphasis on risk validation, finding the most critical assumptions to test in experiments

The next step

Thus far we have talked about the stages as if a PM was entirely at one stage and then moved to the next one. This is not the case in the real world. A better way to look at it is split across approaches for developed features.

It is a huge win when the first feature is developed based on work ranging from outcome to opportunity to solution, and validated in an experiment. But from that point, the work continues to engage in a constructive dialogue with leadership to keep the trust earned, and to drive the share of development efforts done this way up over time.

In this territory you're in a very good position to start working with continuous discovery and opportunity solution trees through the entire process.

‍

Level up in the PM ladder of autonomy

In theory, this is pretty straight forward. But in practice, there are a lot of nitty-gritty details to get it right, and many teams want to but don't quite manage to get going.

At Delibr, we pride ourselves on being really good at helping PMs move from level 1 to level 2. But over time, we heard more and more different variations of PMs wanting to move to level 3. We dug into this with lots of interviews and prototyping, and now we have a good solution for working with opportunity solution trees that we are sharing in our training program. See you there?