We spend a lot of time talking to and coaching people in product. Very often these people feel like they do not have enough autonomy to influence where the product is heading. Instead, leadership is dictating what they should build or sales or other parts of the organization hands them requirements. A few days before writing this article a seasoned PM with 10+ years of product management experience told us: "I've worked with Product Management in a handful of companies and it's all the time top-down. Crazy top-down, 9/10 PMs just get told what to build!" - just one example out 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 to 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 important move a product organization can make - for individual PMs, for the companies they work for, and ultimately for the users they serve.
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. This is as they are not really 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 make sure that the product is successful.
But actually doing the job of making the product successful means being involved across the whole product management process, shown below:
In the ideal situation, the PM has either a leading role or at least a highly engaged role across the whole process, giving a sense of autonomy and of being able to actually 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. Oftentimes leadership 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 different superficial reasons for 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.
If the lack of trust stems from the relationship, then a good place to start is the trust equation.
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.
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.
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.
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).
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.
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.
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 have a good solution for working with opportunity solution trees.
But we want to nail it! To do that we must learn even more about what stops PMs from getting started with opportunity solution trees, and what prevents them from working smoothly with the full outcome-opportunity-solution-experiment chain once they are up and running.
So, help us help PMs level up in the ladder of autonomy. Join our beta and put the theory of opportunity solution trees into practice with Delibr.