Nortrup in Development

Outcome First Roadmaps

#Product Management | #Roadmap

I’m sure if you’ve talked to me recently you’ve heard my song and dance on outcomes based road mapping. As I’ve been talking about it over the past few weeks something really clicked for me on why it’s so important to identify the outcomes early in the definition of an idea.

When you are trying to get work prioritized and on the road map, it’s straightforward to start with a name for the solution that conveys meaning and then find supporters who also like the sound of the idea. An easy default is to talk about the solution you are proposing to fix a problem. They go together to help form a narrative story that works well in a meeting. We have this problem, and here is the solution!

While this is really appealing, it also leaves us some challenges on the backend. If we prioritize problems with a measurement of what we are going to achieve better alignment on why we are trying to solve this problem, and allow ourselves more freedom to discover the right solution.

Lack of precision

Words can be really precise, but the words that go on your road map as initiative titles usually aren’t. When I say “Universal Module Export” it means something to me, but probably means something different to someone else. By the time I get all of the required stakeholders on board I probably have 6 or 7 different ideas about the solution in people’s heads.

If I lead with “I want to increase workflow efficiency by allowing more users to export data without needing an admin to configure the export. I think we can achieve a 50% increase in the number of users who create or modify a connection.” Then we have a lot more clarity in the discussion about what we want to achieve, and we can talk about why that is or is not valuable for users or administrators, and how it fits with strategic priorities.

Starting with this clarity about how you are going to measure success will result in a conversation about how you’ve chosen to measure the problem and progress towards the solution.

You are pinned to a particular solution

It pins us to a solution early in the discovery process. What we really want is to solve the problem for our users, but now we are getting commitment to solve the problem using one specific solution. This probably takes good ideas off the table about how we want to solve the problem. If you are a PM you are probably not taking into account some amount of engineering, and design insight into the solution. If we lead with the outcome that we want, we can start generating and evaluating multiple ideas to get there.

If we start with a measurable outcome then we can get work collectively to outline the existing workflow, where problems are, what the value stream looks like, the relative difficulty of solutions. Product development is a team sport. Product Management does not need to be the hero of the story finding all of the solutions and delivering them to engineers.

The outcome might not work

The solution you picked early might not work. If completing the solution is the benchmark that you’ve set for yourself you are more likely to continue to build towards that benchmark. Then if you realize that your solution didn’t solve the problem you’ll have to come up with a next idea to solve it, and get commitment to build that, and hope it works.

If we lead with an outcome, we can measure progress towards that outcome while we are building and incrementally releasing, if we are not seeing progress with one approach, we can stop early and explore different solutions. Conversely, if we set a measurable target condition, we might achieve that goal after completing 20% of the planned solution; that allows us to move onto the next problem rather than building 80% more solution.

Outcomes are easier to describe

Outcomes are easier to describe on the road map to non-technical stakeholders (customers, marketing, sales, executives). Once you put a solution on the road map, you are going to start all discussions with the name of the solution, then backtrack to explain what the problem you are trying to solve, then you’ll move forward to discussing the solution you’ve selected.

Instead if you tell your customer that you are focused on increasing the productivity of their systems administrators by streamlining workflows for data export, they can immediately grasp the value of that. They don’t need to know anything about how the product works to know that they would like their staff to be more efficient. They also don’t need to spend time understanding your solution in order to decide if it is actually going to solve their problem.

If the stakeholder asks for details you can discuss the targets you’ve selected, why you chose that target over others, why you thought this was the most important problem. These discussions and their feedback will help draw out more information about the problem and improve your overall solution. Again, because you haven’t committed to a specific solution, you can integrate all of the feedback right away.

Stay light on your promises in progress

Once you start telling stakeholders that you are going to build a particular solution, they (reasonably) are going to start expecting that solution to materialize. They have their hopes up that you are going to get something to them, if you’ve really gotten out over your skis you might have also told them that you are going to get it to them by a certain date (for shame).

The best thing that can come out of that situation is that you have to explain to them that you changed priorities, or learned that you needed to take a different approach to the problem. In that case you are back tracking from the solution to the original problem (where we should have started). In the worst case, they signed a deal with you because you made the promise to build a particular solution. They (and your finance department) won’t be happy until they have it. Revenue recognition is a challenge.

There is still solution planning

None of this eliminates the detailed work of planning and designing solutions. Part of prioritization is that we should be evaluating impact and effort to solve problems. Once a problem is selected we are going to do multiple rounds of design, engineering and customer evaluation. We are going to talk to customers about the things we are building in order to get feedback. None of that goes away.

But when we are selecting things for our engineering teams to work on, we should be selecting the most important problems that we can solve, not a solution. We should defer and distribute detailed solution planning to the people who are going to be closest to solving the problem, and leave them as many options as possible to solve that problem.