Outcome driven roadmaps

Most product roadmaps are feature based. They define what features to build by when - driven by a prioritisation process.

The problem with the approach is it can lead to a “feature factory” - a team continually adding new features without understanding what the aim is - making it hard to connect to the overall business strategy (OKRs, KPIs etc).

Another downside of feature roadmaps is they can easily turn into sales roadmaps - building features designed to make a product easier to sell - not better for the user.

A final problem is the measurement of feature driven roadmaps. Success is simply implementing a feature - regardless of the impact it has had on the success of the product. This leads teams to be out of alignment with the overall strategy as you as measuring teams based on their output not any business success metrics, so a teams incentive is simply to ship more.

Outcome driven roadmaps specify outcomes, and metrics to measure those outcomes (e.g. the KR in OKR) but they do not tell you specifically how to do it. Your team looks at the outcome, devises solutions, implements them and check the metrics. If they pass then they move on to the next outcome, if not they continue to innovate.

An example of an outcome driven roadmap is “improve the onboarding-to-signup flow by 10% by Q1.” There is no mention of specific features, just a metric to be achieved and a date.

This is similar to 4DX and the Wildly Important Goal.