JTBD: Outcome based Product Roadmapping

Have you ever experienced this question before:

Hey Product Manager.. got a tasty new assignment for you. Oh and I need a suggested MVP and 1 year roadmap by Monday!

Ok, so the question is usually a little more polite than this, but it’s genuinely something you’ll face many times in your product career as other teams such as tech or marketing need to plan their resources and activities well ahead.

Let me share this hack I recently used when dealing with this exact request at the South East Asian super app Gojek that stitches together a few well-known frameworks. It solves your immediate problems, forms a basis for a more robust validation later and becomes the single place for all big cross-team alignment.

Problem

I recently took over a large digital product and after a week got invited on the Friday to a Monday off site whereby we needed to present next year’s roadmap to 40 senior stakeholders who all had very strong opinions about what needed to be built.

I’d received many Slack messages beforehand with bold feature ideas. But I didn’t want to promise anything I just wasn’t sure about. So how to get them all aligned so quickly without freaking out our engineering teams?

After reading all our research slides and procrastinating for half a day, full on panic was setting in.

Ah hah moment

I decided to take a short walk that Sunday afternoon and an idea hit me. Why not take all the team’s ideas over the last 12 months and put them all on the table. But then express the pain points from the research using JTBD style outcome statements giving each one an opportunity score to enable feature ranking/excluding. Then the entire conversation can be filtered to customer pain, market size and engineering effort.

In just a few hours of intense focus, I had a defendable outcome based product roadmap showing:

1. What functional jobs we were solving for e.g. listen to music privately — turns out we had 5 jobs (♥️ by all as grounded our thinking going forward)
2. What were the pain points expressed as customer outcomes e.g. minimise the time it takes to start listening with associated opportunities scores so we could rank them (♥️ by research, design and product)
3. All feature ideas linked to above problem statements (♥️ by engineering who just hate waste)
4. An MVP cut of features followed by subsequent packages of suggested releases over the year, each with a clearly defined needs based proposition and associated market size (♥️ by engineering and marketing)

It worked.. the next day in a short 20 min presentation followed by Q&A, we managed to get everyone to the same place whilst shutting down many of the bigger ideas that either weren’t solving high priority problems or giving us any any scale — and at Gojek we only solve for scale!

We were now ready to begin design and setup tech resourcing whilst our research team hungrily validated my qualitative based assumptions with a quantitative survey whilst marketing got busy with GTM plans and engineering began t-shirt sizing.

Step by step guide

As per my other blogs on JTBD, I’ll use the following job to help provide a clear example of the framework:

Listen to music privately

Here is the final output in Google Sheets if you want to skip ahead.

Listening to music privately is our core example job

Step 1: Define the job

Define the functional job your product is trying to solve for. Could be multiple and can use this blog to help you. Put this/these into column A. Every pain point and feature will be anchored to a core job from now on.

Step 2: List outcome statements and rank for importance & satisfaction

In column B, list all outcome statements customer is trying to achieve as they execute the job in column A. These are the core needs you might address. Use this blog to help pull these from any qual research you may have done.

In column D, put which step of the job the customer is at when they need this outcome to give you more context. I use 4 simples steps here to bucket them:

1. Setup: Before listening e.g. finding listening device, connecting wires
2. Execute: The moment you play e.g. initial volume, wrong device
3. Monitor: While listening, how to monitor and adjust e.g. volume, track
4. Conclude: When you want to stop listening e.g. stop music, put away

Finally (fun part), for each outcome statement, add a score out of 10 for how important your think this is for your average user and how satisfied they currently are with their solution. I’ve written a post on this part here for you. Call out that these numbers need to be validated as a next step, but that doesn’t stop you filling them in right now to get you to a draft roadmap.

The opportunity scores will appear with a higher number being something you should probably try and solve for with your features and a lower one maybe not important. If importance and satisfaction are both above 6, the tool marks it as hygiene i.e. you just got to do this to even play the game.

Give each outcome an Importance and Satisfaction score to get your opportunity score

Step 3: List all features and do MoSCoW assessment per outcome

In the top row, list all the big features you’ve heard from customers, founders, team members (big believer that ideas should come from everywhere in innovation). This makes everyone feel heard.

Everyone gets a say in JTBD, but be sure to keep it high level for this exercise

Don’t go too low level here. You want everything on a single screen otherwise you will lose your audience and they won’t use the tool going forward. Remember this is a stakeholder communication and alignment tool.

Next, for each outcome statement, mark the feature using MoSCoW method of prioritization as follows:

• Must: If we don’t do this feature we CAN NOT solve the pain point
• Should: Unless we are strapped for time, we really should also do this
• Could: Would be nice to have but really not essential to solve pain
• Won’t: What won’t we do to solve this pain point (important to call out)

Easily see what features we should focus on for each pain point

Step 4: Select your MVP and write market value proposition

Ok, so we can now clearly see what features are solving what pain points. Now for a bit of validation, ask yourself 2 questions:

1. Do we have features that cover all the hygiene pain points for this job?
2. If a pain point doesn’t have any Must features, why is that? Have we forgotten a feature? Or maybe it just isn’t important enough? That’s where marketing sizing can help which we will discuss next.

The next step is to package releases by selecting what must have features we want to build to solve what pain points in the market. I had Timo our marketing guru on a Slack between his Sunday family time to help me understand the market size for those pain points.

We probably don’t want to select features that solve pain points that fit only 20% of total addressable market cares about e.g. noise cancellation. We probably do want to package features that together hit 60% of the market’s pain points and really differentiate us e.g. just let me start listening quickly. This is an art more than a science so be ready for bit of back and forth here.

Package the features into releases that solve for large pain points not forgetting hygiene factors

The value proposition is so so easy once you have identified the biggest market pains you will solve. For example, above I crossed checked my suggested release 1 with Apple’s actual market value proposition and was pretty spot on:

Simply take them out and they’re ready to use with all your devices. Put them in your ears and they connect immediately, immersing you in rich, high-quality sound.

Their wireless H1 chip for seamlessly connecting between all your Apple devices clearly solved the pain point around time spent to start listening.

I might wait for release 2 to solve more niche pain points like noise cancellation as the engineering team may need more time to figure this out and pending quant I’ll assume less people care about that so it’s more incremental. The fiddly job of ensuring a smooth fit in anyones ear when they do exercise sounds like a smaller market too so will also hold on that.

Next steps

Now everyone is nicely aligned, go do your quant survey to validate the assumptions on market size for these pain points. With a good research team this takes 2–4 weeks if you are good. Once back, you will likely adjust your opportunity scores, which could change your product roadmap. Same applies to engineering estimates.

The think I love the most about the survey is that if you go big, you get to play around with the results to group people based how much pain they feel for different outcomes. These become needs based segments that you may want to give slightly different messaging to. More details in this post, but as an example, you may discover 2 groups:

• People who get frustrated at setup time and need the wireless feature also happen to love exercising
• People who get really frustrated as they switch devices a lot are office workers who constantly move between conference calls and music and may mistakenly have loud music streaming from the player they aren’t actually connected to.

Can imagine an instagram ad having very different messaging for these groups.

Finally

I really hope this framework helps anyone who finds themselves in the same position as I often have.

Would love to hear any feedback so can continuously improve as have used on 3 products so far and works great for me and my teams, but doesn’t solve everything i.e. can we quickly factor in effort into the equation somehow earlier.

Note: Original JTBD framework and ideas are a mix of Clayton Christensen and Tony Ulwich and highly recommend reading Innovator's Solution and checking out Strategyn for more detailed info from these 2 brilliant people.