Reverse engineering outcomes from outputs
Roadmaps are best created using deductive reasoning, starting with the end in mind, and with the outcomes and opportunities for achieving them. There’s lots written about outcome-based roadmaps and how to create good ones.
But, often, instead of outcome-based roadmaps, which as good as are for product managers require a certain amount of familiarity to make sense of, many organisations have feature-based roadmaps or project delivery plans that are called roadmaps.
Of course, product managers can help others to understand the benefits of outcome-based roadmap but that might take some time.
But maybe there’s another way.
Maybe there’s a way to take the outputs expressed in those plans and translate them into outcomes.
Starting with outputs
Let’s start with a website, like the one you’re on now. And a random list of changes that I could do:
- Add a chatbot trained on all the content on the website.
- Redesign the home page.
- Change the menu, e.g., include weeknotes and resources.
- Add a wiki on a subdomain.
- Reorganise the Projects section.
- Write more blog posts.
These are all outputs. Not an outcome in sight. And no prioritisation either. This could be any website, any product or project. So, what’s a product manager to do?
To get to outcomes, we need to group them by what they seem like they are trying to achieve. As we’ve said, if we were starting with what we know we want to achieve, we’d be creating an outcomes-based roadmap, but instead we need to make some assumptions about those outputs which we can test later.
Assuming outcomes
It seems to me that most of the things on that list are about organising stuff on the website; changing the menu, reorganising content, providing a different way of interacting with info on the site. So, we’ll want an outcome that includes all of those. The one that doesn’t quite fit is writing blog posts. That isn’t about organising stuff. Maybe it’s about getting people to the website.
Now, as we’re talking about outcomes, we’re talking about changing user behaviour, so let’s express our outcomes as:
- Get more people to visit the website.
- Make it easier for people to find information on the website.
Then I can group the outputs together by which outcome they seem most likely to achieve.
| Outcomes | Outputs |
|---|---|
| Get more people to visit the website. | Write more blog posts. |
| Make it easier for people to find information on the website | Add a chatbot trained on all the content on the website. Redesign the home page. Change the menu, e.g., include weeknotes and resources. Reorganise the Projects section. Add a wiki on a subdomain. |
Testing assumptions
So, we’ve taken a list of random ideas, made some assumptions about what those things are trying to achieve and grouped them, and phrased an outcome for them. Now we’re ready to test our assumptions. This is important. The difference between a guess and an assumption is that assumptions are called out and tested to try to figure out if they are true. Guesses aren’t, they stay as guesses. Product managers, in their attempts to bring order to chaos and empirical rigor to the messy real world, test their assumptions.
We can ask the people that contributed to the list of outputs whether they agree that those outcomes are really what they are trying to achieve. If they say yes, then our assumptions are validated and hopefully we’ve been able to have a helpful conversation about outcomes. If not, perhaps those people can help create new assumptions about what to achieve and how to group them, and we still get to talk about outcomes.
Prioritising outcomes
You’ll notice that one of our outcome has only one output, and the other has lots (almost like I planned it). So, to get more people to visit the website we can get on with writing more blog posts, that’s obvious. But to make it easier for people to find information on the website, there are lots of thongs that we could do, so we need to choose between them.
Ideally, we’d be able to work on both outcomes at the same time, but if we have to choose between them then we should choose by which provides the most value to the user. In this case, that’s probably writing more blog posts to get more people to the website. How do we know this? Analytics are a product manager’s best friend, and our analytics tell us that the majority of traffic comes from search engines and goes directly to blog posts. Therefore, more blog posts helps more people get to the website.
We also know that the average page view is 1.3, which tells us people aren’t navigating around the site, which back-ups the need for the second outcome and gives us a measure.
Measuring outcomes
For a product manager, just delivering those outputs isn’t enough. That’s fine for project managers but product managers need to know if those outputs are achieving the outcomes.
Measuring whether writing more blog posts correlates with getting more people to visit the website (the outcome) is a far more useful indictor of success than just how many blog posts were written (the output).
This is where we get to the ‘but why’ of outcomes. If one output doesn’t achieve the outcome, then maybe the next one will. The outcome is still worth pursuing because it is closely tied to value. If writing more blog posts doesn’t achieve the outcome of getting more people to the website, we can think of other things that might. Maybe posting on social media or starting a newsletter. Outcomes are more long-standing, and open to new opportunities of outputs being added over time to try to achieve it.
More outputs
If, tomorrow, someone comes up with another great idea, it can be tested against the existing outcomes to see where it fits. If the output they suggest doesn’t help to achieve the current outcomes, then it’s a far easier conversation to explain why it shouldn’t be worked on. And if it doesn’t fit, then we’ve made it easier for people to bring ideas without having to do the product thinking of starting with outcomes.