Outcome Based Roadmaps : From Theory to Practice

A practical framework to roadmapping which we undertook at India’s largest Health-tech platform

Business asks, mission critical features, tech debts, bug fixes, customer asks, data insights, market & competition developments, CXOs focus areas, founder’s dreams, board commitments……sounds familiar ?This is something which thousands of PMs world over (hope my guesstimate of number of PMs worldwide is correct :)) would be going through day-in & day out !

Now imagine a mid stage startup, with young blood & roaring ambitions with a mission to revolutionise health-tech in India-multiply the complexity of prioritisation & managing expectations by 10X !

Below is a journey we undertook at PharmEasy, & hope this framework is of help to other fellow PMs.

Classical Roadmap

Sample extract of CX roadmap at Pharmeasy

Above is how a classical roadmap would typically look like in most setups. It’s a Waterfall/Scrum- fall approach with a list of features + delivery timeline.

The problem with this….

1. The entire focus is on Dates & features (outputs). TLDR- the roadmap blurs into a Release plan!
2. Teams are stuck in a feature factory, just building stuff/churning out features, trying to manage expectations often forgetting about the end customer.

“Stakeholders care about results & so do your customers”

There is a better way…

From Outputs to Outcomes

First things first, product teams would have to elevate from looking at outputs to outcomes . There is a fundamental difference between these 2 terms. Let’s understand these in context of roadmaps ….

Output — a feature is an Output

Outcome — It’s a Measurable Change in Customer’s Behavior

(source: Jason doherthy)

Let’s break down the above phrase | Customer is the user of your product-could be the end consumer, internal customer or a B2B client in case of an ERP product | Behavior — The way your customer acts or reacts, their habit | Change is something positive + net new|& lastly Measurable meaning there should be a way to measure the change either quantitatively or qualitatively

Thus the goal of any feature (output)should be to change the customer’s behavior in a measurable & positive way

Outcome based Roadmap

Next comes actually redoing the roadmap in the outcome based framework.

Step 0: A solid — groomed backlog (assuming this step is the same & forms the backbone, will talk about this later)

Step 1: Understand Strategic business objectives, spend some time on the AOP. Sit with your business teams for goals

Step 2: Work customer backwards & understand their need states. Marry these with your goals to come up with outcomes.

Step 3: Further breakdown outcomes into initiatives (epics/stories/tasks). Which initiative is alligned with the specific outcome.

Step 4: Line up initiatives basis prioritisation from respective backlog (ref step 0)

Step 5 : Last but the most important — plan for the right measurement framework!

Reorganised — OBR for CX (support cost)

By fixating on end results instead of specific deliverables, life no longer becomes all about how much gets shipped and how fast a widget reaches the market, but whether or not outcomes are being achieved.

• What the outcome-driven mindset also does is it gets you thinking beyond product/feature development and delivery. It means you’re also thinking about product marketing, including GTM (go-to-market) and customer feedback and preparing to iterate towards the desired outcome.
• Visibility while enabling the team to prioritize and plan based on value
• Clarity and alignment between sponsors, stakeholders and the product team
• Autonomy and empowerment for product teams to solve problems, rather than implement solutions.

Sounds simple right ??

From theory to practise

Things start getting complex when there are several such goals & workstreams running in parallel. So given multiple push-pulls how do you now go about implementing this & leveraging the goodness of the above framework?

Step 1: Have a outcome based roadmap for your respective workstreams

recap of the restructured CX- OBR

Step 2: Take the immediate Org goals & priorities into consideration

Key focus areas of one of the sample quarters

This would now mean not all of the cost workstream would get funding in the quarter since there are other workstreams tying into other goals as well.

Step 3: Superimpose the Org Goals on the OBR

Hybrid Grid with Qtrly Goals superimposed on the OBR

NET NET in terms of outcomes — this may mean just a 10% reduction in Costs for AMJ. But then there’s always the next quarter :)

Few pointers

1. Irrespective of the framework used, the starting point of having a good roadmap is a solid backlog.
2. Measuring outcomes is extremely important.
3. Prioritisation is important for any stage startup
4. Roadmap should be easy to comprehend & implement

Wrapping up.

At Pharmeasy Technology one of our core values is “Act Fail fast -Learn” . Am glad we took this paradigm shift with this framework & kudos to the PMs here to inculcate this — It has helped us sharpen our focus. While we are constantly learning & evolving this framework, would love to hear your thoughts & experience with roadmaps.

“Stop building stuff and start solving problems!!”

Refs

• The Build Trap by Melissa Perri
• Elena Sviridenko: Outcome Driven Roadmaps

Spl thanks to Chaitali Mehendale for helping vet the content.