Outcome-based roadmaps over feature lists
Your top priority may be, as the first agile principle says, to satisfy the customer through early and continuous delivery of value, but to deliver value you must first understand what value really means; in the past, delivering more value might have been achieved by just getting more stuff done, but in a modern software-driven world, this particular crank no longer makes sense, as a lot of features can be delivered and “work perfectly” but still don’t deliver any real value.
Although impact / high aspirational goals (like increasing revenues, decreasing costs, or increasing market share) are very important, they are often too big for any one group to target, and so, need to be broken down into smaller, actionable parts: outcomes, changes in human behaviors that drive results / business impact (as they are things people do, they’re both observable and measurable).
If you are a manager, you can manage your team by telling them what to make: that’s called managing outputs and it may be a problem because, as said before, features don’t always deliver value and are hard to prioritize (how can you figure out what features are important if you aren’t sure which features will deliver value?); on the other hand, you can manage your team by asking them to create some high-level value, like growing revenue: that’s called managing impact, but it’s a problem too, because it’s not specific enough; what you really want is to manage with outcomes: ask your team to create a specific customer behavior that drives business results. This approach creates a more customer-centric way of working and unlocks teams creativity, as they will work to find the best solution to the problem at hand to create the outcomes they seek. The less certain you are that your outputs will deliver the results you seek, the more it makes sense to plan in terms of outcomes; there are many ways to identify them, one is through the customer journey technique: draw a diagram that describes what people are doing (their “journey”) when they interact with your product, think about which of their behaviors you want to encourage (boosters) and which to eliminate (blockers), and finally build the roadmap around hypotheses that link question and potential answer together. Example:
We believe that if we….
(Outcome → )…increase the rate at which buyers and sellers meet early in the process…
(Impact → ) …it will lead to more successful transactions (as measured by X) and higher user satisfaction (as measured by NPS.)
(Outputs →) We think we can increase the rate of early meetings [with this idea] and [with this idea] and [with this idea.]”.
In order to test these hypothesis and see whether your assumptions are right or wrong, run experiments; try something (MVP), see if it works, and if it does, then invest in the approach. Of course, managing this way is not all rosy, as stakeholders may feel that they “lose” the “certainty” of the plans and it is difficult to admit that the answer to “when the work will be done” may seem subjective: “we stop working on something when we have progressed enough to feel satisfied”; to have these conversations successfully, people need to trust each other before.
It’s hard to shift thinking from the concrete world of features to the abstract world of outcomes, but you may start asking stakeholders to talk about what they are worried about, and what critical metrics they are watching, instead of asking for features; by doing this and shifting the focus, you will be able to step back from output conversations, understand the business problems you need to solve and then the outcomes you need to create.
If you want to go deeper into this topic, you can read the book on which this post was based: “Outcomes over output” by Josh Seiden
