I thought I understood Jobs-to-be-Done


Hi Reader,

Have you ever heard of the Jobs-to-be-Done framework?

You probably did. And like you, I have heard of the interpretations of it, and I thought I got it. It's an easy concept.

But with the new small internal tool I am building, I have decided to actually implement it, and see if it could help me organize messy requirements into a clear picture.

So if you are currently managing a product, and need some ability to actually map out what it's meant for, this newsletter is for you!

P.S. It is much more powerful than I realized before.

Today in 10 minutes you will:

  • Learn the JTBD vocabulary in plain English, on a real example
  • See the full Jobs-to-be-Done needs framework, piece by piece
  • Watch me apply it to an internal reporting tool I'm building
  • Hear my biggest takeaways from applying it
    ​

Why PMs should care?

The primary focus of the Jobs-to-be-Done framework is to help you define the market and opportunities, so that you can bring in disruptive innovation with your product.

For internal product managers though, it carries another advantage: it actually forces us to think about our end user.

Internal products often get built from a list of requests. Someone senior asks for a dashboard, we build the dashboard.

JTBD makes you ask what that dashboard is supposed to help them get done.

My use case

I am building a reporting tool for marketing (media) teams that are tracking different media performance KPIs.

The whole media organization has multiple levels of hierarchy. They are using a number of tools, depending on where their media campaign is hosted. They can be using Instagram to post some stuff, they could be using TV.

Every time someone from the top of the hierarchy needs to see the performance of the media campaigns, they go to the lower level and ask for it.

Then the lower level gets all their tools out, copy-pastes all the numbers from different tools, puts them in an Excel, does some extra calculations sprinkled on top and voilà.

The problem is, the next day the data is outdated. And one week later you definitely need to redo this exercise again.

So I (as a product manager of media reporting solutions) need to solve this problem.

From a technology standpoint, all is clear: an automated reporting tool is the goal.

But from the business perspective:

→ What's the right level of detail?

→ What's the right level of KPIs?

→ What's the right frequency?

That's the stuff I need to think of.

Btw, I am also competing with the current way of doing things. Why would users not go do the thing the old way, even if they have an automated report?

In JTBD terms, the Excel copy-paste routine isn't "nothing." It's the solution people currently use to get the job done.

My tool only wins if it gets that job done better.

Let's get the vocabulary first

Tony Ulwick, who developed the framework, starts with a simple truth:

People buy products and/or services to get a job done.

They don't buy a product because it's nice. They buy it to do something with it. And if it's nice, that's a good addition.

What is a job?

What someone is trying to accomplish, independent of any tool they use for it.

In my case, the marketing director's job isn't "look at a report." It's deciding where to invest the media budget to get the best performance over cost.

Excel, Instagram analytics, my future reporting tool: those are just tools for that job.

Tools change. The job stays the same.

What is a market?

A group of people trying to get a specific job done.

So my market isn't "Excel users" or "dashboard users." That's the solution space. It's everyone trying to decide where the media budget should go.

What is a need?

A measurable outcome people want to achieve when getting their job done.

According to Strategyn, a single job usually has 50 to 150 of them.

A need never mentions a tool. It follows a specific format: direction + metric + object + context. For example:

"Minimize the likelihood of making an investment decision based on outdated data"

No "dashboard." No "export button." That's the point.

What is an unmet need?

An important need that current solutions don't satisfy well.

To find them, users rate each need on importance and satisfaction (0 to 10). Then:

Opportunity = Importance + max(0, Importance - Satisfaction)

In plain words: importance plus the gap. If satisfaction is higher than importance, the gap counts as zero.

Say directors rate "outdated data" 9 for importance and 3 for satisfaction (just an example). That's 9 + (9 - 3) = 15.

Anything above 10 is underserved. That's where to focus.

What is a segment?

A subset of people in a market, each with a different set of unmet needs.

Not demographics. Not job titles.

Two marketing directors can have the same title and still struggle with completely different parts of the job. One with comparing TV against Instagram, another with data being outdated.

Btw, if you are not fully getting my explanations, take a look at this video from Tony Ulwick himself.

video preview​

The framework

Source: Strategyn, Jobs-to-be-Done Needs Framework

It looks like a lot. But each ring answers one question:

→ Job executor: who is getting the job done?

→ Core functional job: what are they trying to get done?

→ Job steps: the 8 universal steps of any job: Define, Locate, Prepare, Confirm, Execute, Monitor, Modify, Conclude.

→ Related jobs: what else do they do before, during, or after it?

→ Emotional jobs: how do they want to feel? How do they want to be seen?

→ Purchase decision maker: who pays for it, and on which numbers?

→ Product lifecycle support team: who sets it up, maintains, and retires it?

Applying it to my reporting tool

Let's apply it to the main job executor.

I am skipping the lifecycle support team and purchase decision maker today, that would blow up the newsletter. If you are curious, check out this article from Tony Ulwick.

Job executor: Marketing director

Core functional job:

Decide the investment strategy of the brand into media, optimize performance over cost, and ultimately increase the revenue of the brand through marketing.

Job steps:

→ Define: decide which campaigns, channels, and KPIs to review, and against which targets

→ Locate: get performance data from every channel, from Instagram to TV

→ Prepare: bring the numbers into one comparable view (same KPIs, same time period)

→ Confirm: check that the numbers are complete and up to date before making a call

→ Execute: decide where to put (or pull) the media investment

→ Monitor: track whether the new spend is performing over cost

→ Modify: adjust the investment when a campaign under- or over-performs

→ Conclude: report results and learnings to the rest of the organization

Outcomes:

→ Minimize the time it takes to get performance data from all channels into one view

→ Minimize the likelihood of making an investment decision based on outdated data

→ Minimize the number of people involved in answering a performance question

→ Minimize the likelihood of KPIs being calculated differently across teams

→ Minimize the time between a change in campaign performance and seeing it in the report

Emotional jobs:

→ Feel confident when defending the media budget to leadership

→ Be seen as someone who makes data-driven decisions

None of these say "dashboard." But they answer my open questions:

→ Level of KPIs: from Define. Which targets does the director steer on?

→ Level of detail: from Prepare. What must be comparable, and at which level?

→ Frequency: from Monitor and Modify. How often do they change investment?

My biggest takeaways

As I went through the exercise, I realized that the Locate and Prepare steps are actually executed for the marketing directors, not by them. They are executed by the people who work for them.

Yes, automation and productivity savings are big motivators (and one of the outcomes the director wants). But another big motivator is meeting the unmet needs of the directors themselves.

Monitor (comparing new investments against old ones) could be step-changed with live tracking. Same with Modify, because you would spot what needs changing earlier.

And maybe not in the first version, but down the roadmap, there could be a feature that uses AI to summarize the current standing and what has changed. That would simplify reporting of learnings.

Now this, I can see the marketing leadership getting behind.

So to me, the biggest takeaway of the JTBD framework is not only phrasing the jobs of users and stepping into their shoes.

It's actually using that to evaluate what we are doing today, and how we can step-change the jobs of our users.

​
​

What do you think?

Did this newsletter help you make sense of Jobs-to-be-Done a bit?

Hit reply and let me know — do you love it, hate it, want more of something else?

Talk to you next week,

Maria

Frankfurt am Main, 60311, Germany
​Unsubscribe · Preferences​

Maria Korteleva

Hi, I’m Maria. For the past 7 years, I’ve been building internal products across FMCG and tech companies.Now, I share everything I’ve learned to help junior PMs master delivery from technical skills to stakeholder communication. Join 200+ Internal PMs who get weekly insights from the Build Internal Products newsletter.

Read more from Maria Korteleva

Hi Reader, You know that feeling of “you don’t know what you don’t know”? You get it always when you start building a new system or a complex feature. And you’re just thinking: how are we supposed to know how to build this if we’ve never built it before? As someone who likes to control things (yes, that’s me), I tried my best to find an answer. Of course, very predictably, there is no answer. We can’t predict many of the technical issues that will come our way. But that doesn’t mean we should...

Hi Reader, Have you ever felt lost while asking your engineers if they have already pulled, pushed, or merged their code? I have 🙋🏻♀️ What if I tell you that learning this once and for all will take you only 20 mins? And much more confidence going forward. If you like that, today's issue is for you. Today in 20 minutes you will: Why code repositories matter to PMs (even if you never write code) What Git and GitHub are (and why they're not the same thing) The 9 words your developers use every...

Hi Reader, Building apps has never been easier. I can prove it. I built a working app for the hands-on API workshop I held two weeks ago. Took me 3 hours, spread across 4 rounds of getting it right. If you've ever wanted to do a quick, scrappy first build and actually put it in front of other people, this one's for you. Today in 10 minutes you will: See why I built my own app instead of grabbing something off the shelf Get the process I actually followed, from idea to a public link See the...