Product roadmaps provide a way to understand where a product is headed, but the information provided on most of them doesn’t help to clear the clouds of confusion about whether the product is heading in the right direction; even after viewing product roadmaps, customers can still be confused about whether future releases are valuable and relevant to their needs. When I think back on the roadmaps for products I worked on many years ago, I see the same symptoms that I see in many products today: they expressed a timeline of features and related work that did not clearly express the value the customer would realize from those releases.
Features are a convenient short-hand for expressing something that a team is working on.They tell someone what is being developed, but not why. Product roadmaps expressed in terms of features suffer the same problem: they show that the team(s) developing the product are busy doing work, but they don’t always make it easy to understand why that work is important.
An alternative is to express product roadmaps in terms of goals that the release aims to achieve. Those goals are best described in terms of customer outcomes, or something that the customer will be able to achieve that they were not able to achieve before the release. The advantage of using outcomes as a kind of lingua franca for product releases is that they are easily understood by people removed from the product development process such as customers and stakeholders.
If features are described in terms of outcomes, then traditional roadmaps will be outcome-focused with a customer centricity. Often, features are an internal shorthand used by an organization to talk about the work that is being done, but these features usually talk about what the work is, not why the work might be perceived to be valuable from a customer’s perspective.
Consider the following fairly typical product roadmaps for a fictitious smart home energy management system:
Features described in a roadmap are expressed in the way the developers think about it - as tasks they need to complete. This short-hand makes sense to them, but not usually to people other than those working on the product.
What would an outcome-focused roadmap look like? Consider this different version of the same example:
Now the roadmap expresses the benefits that the customer will experience. Expressed this way, product release roadmaps can stimulate meaningful conversations about value and whether the outcomes expressed in the roadmap are the right things to be delivering, in the right order, to bring the greatest value to customers. They can also be more useful to the developers of the product by giving them greater insight into why they are developing particular features.
Meaningful discussions about value are often hard to have using feature-based roadmaps because they require customers and other stakeholders to translate what the feature would mean to them. Feature descriptions are often vague and internally focused, so it’s hard to understand the benefit of the feature, which is why feature-based roadmaps are often met with blank stares and silence when presented to customers.
Outcome-focused roadmaps stimulate deeper conversations about value that can lead to better understanding of customer needs. Product roadmaps are more than simply ways of documenting product plans. The real value of product roadmaps is to expose misconceptions about customer needs and explore better ways of meeting those needs, and in turn to improve products so that they better meet customer needs by facilitating open and direct communication that stimulates valuable feedback.
Outcome-focused roadmaps also sharpen focus by maintaining attention on why work is being done. When everyone is focused on features, they sometimes forget the results that they are hope that work will achieve; the work becomes an end unto itself. Focusing on outcomes helps to keep the why in everyone’s minds.