Rebuilding Jobs to Be Done (JTBD) with AI: The Innovation Operating System

By Colin Duff, Mosaic

August 18, 2026

Colin Duff is CEO of Mosaic Innovation and the creator of the most-used Jobs to Be Done template on Miroverse. He has rebuilt it around Miro AI Flows so that customer interviews turn into structured, traceable evidence while the research is still running. Here is how it works, and the template to try it yourself.

Last year, I built a Miro template to make Jobs to Be Done easier to apply. It became the number one JTBD template on Miroverse – 8,000 users, and the most viewed, copied and liked template of summer 2025.

It also had a hole in the middle of it, and I knew exactly where.

A quick primer: What is Jobs to Be Done (JTBD) and where is it useful

Let’s start with some context in case the framework is new to you. Jobs to Be Done starts from a simple idea: people don’t buy products, they hire them to get a job done.

Jobs to Be Done splits into two approaches, and this template is built on the harder one – Outcome-Driven Innovation (ODI). ODI translates customer needs into precise desired outcome statements, then pinpoints where the outcomes that matter most are served worst.

Instead of stopping at “customers want faster checkouts,” ODI breaks the job itself into steps (the Job Map), interviews the people doing that job (Job Executors) about specific times they did it, and turns what they say into precise, measurable desired outcome statements – things like “minimise the time it takes to confirm an order,” rather than a vague pain point.

It works best once a job is stable enough to describe: people can name the steps, and say what “done well” looks like. That’s usually a job someone is already doing, in some form, whether or not your product exists yet. If the job itself is still undefined, or the market is too new to have settled criteria for success, ODI isn’t the right starting point – more on that later.

That precision is what makes ODI worth doing where it fits. It’s also why it’s hard to run: every piece of evidence has to stay connected to the step, the person and the words it came from, and there can be a lot of it. Here’s where that got difficult.

The part that always broke

ODI was always a nightmare in physical workshops. A job map runs to dozens of steps. A single target job can generate more than a hundred desired outcome statements. All of it has to stay connected – every statement traceable back to a step, a circumstance and a participant’s actual words. Projects ran for days, which meant holding the same room and the same wall for the duration while steps moved and evidence chased them around.

The original template walks through four stages: scoping the job, mapping it into steps, investigating it through interviews, then capturing outcomes. The first template solved the front half – scoping and mapping – well.

Teams could agree the Job Executor, settle the target job, and build the job map together in one shared space. We used it with clients dozens of times.

Then came the investigate phase – the interviews – and it fell apart.

We would take the transcripts away, analyse them offline or through separate AI tools, and carry the findings back into Miro by hand. One interview could produce dozens of outcome hypotheses, each tied to a particular job step and circumstance. Rebuilding that in Miro meant unwieldy tables, evidence copied between tools, and a steady loss of the link between what the customer said and what we concluded.

So we usually gave up and made slides. Easier – and it changed how the room behaved. The moment something looks finished, people review it instead of arguing with it.

Worse, it meant waiting. We would sit on the analysis until it was nearly complete, which is precisely when it is too late to change what you ask in the next interview.

Why generic AI analysis wasn’t going to work

When Miro shipped AI Flows, transcript analysis was the obvious thing to point it at. I did not expect it to hold up.

Ordinary voice-of-customer analysis can afford to be broad. Summarise the pain points, group the themes, cluster the customers. ODI cannot work that way. Every observation has to carry four things with it: who was performing the job, which step of it they were on, what circumstance was shaping their priorities, and what success criterion the evidence actually implies.

Take the Uber example that runs through the template. A conventional analysis would file this under “unreliable pickups”.

ODI needs it broken out:

Evidence: “I kept checking outside because I didn’t know whether the car was actually coming.”
Job step: Confirm the arranged vehicle will arrive.
Circumstance: Travelling to an appointment with little tolerance for delay.
Outcome hypothesis: Minimise the likelihood that the arranged vehicle fails to arrive at the agreed collection point.

Collapse that into a theme and you have thrown away everything that makes it actionable. What I needed from the AI was not a summary. It was a structure that was well-preserved.

What the AI Flows actually outputs

You drop the interview transcripts onto the board, and click Run.

Behind the button is a prompt that tells the Flow how to read an ODI interview, how to use the approved job map, and how to shape what comes out. It reads every transcript added so far and builds an editable evidence table, one row per distinct piece of evidence:

Participant and context
Job step
Evidence or quote
Outcome hypothesis
Circumstance or constraint

The speed was not the surprise. The surprise was that the relationships survived.

A quote stayed attached to the participant who said it, the circumstance they said it in, and the point on the job map it belonged to. The interpretation sat next to the original evidence instead of replacing it. That means anyone on the team can challenge a reading, go back to the participant’s own words, and see how the outcome was arrived at.

Reading the research while it’s still running

The change I did not anticipate is that synthesis no longer has to wait.

After two or three interviews you can run the Flow and look at what is forming. Several participants stalling at the same step. An outcome that matters enormously in one circumstance and barely registers in another. A step you were certain would be central that nobody mentions.

None of that is a conclusion. But making it visible early changes what the research can do. The team reads the evidence and decides what to push on in the next interview. You can see where the evidence is thin, where participants contradict each other, and where the job map itself needs revising.

Previously, all of that lived in the researcher’s head. Now it develops on the board, which gives the wider team something to hold onto while the researcher still owns the interpretation.

Frequency is the trap. An outcome mentioned once may be the most underserved need in the study. One mentioned in every interview may already be perfectly well served. The Flow counts nothing – and that is the point.

The human judgement doesn’t move

The Flow produces a structured first pass. It does not produce an outcomes library – the reviewed, finalised set of desired outcome statements a team scores and prioritises against.

Researchers still have to review every row against the transcript, rewrite weak statements, merge duplicates, and separate genuine desired outcomes from product complaints, emotional needs and feature requests dressed up as needs.

What the AI removes is the administration. It does not decide what the evidence means, and a workflow built as though it could would just be a faster route to bad research.

A few things to know before you try it

Update the prompt before first use. The Flow needs your target job, your Job Executor and your approved job map steps. Run it against the defaults and it will cheerfully map your evidence onto Uber’s job map.
One job map per run. The Flow analyses against a single approved map. If you are studying two Job Executors with materially different processes, that is two passes.
Transcript quality carries straight through. Interviews anchored to one specific, recent execution of the job produce clean rows. Interviews where the participant generalises produce rows you will spend longer fixing than writing.
Check every row. Misassigned job steps are the common failure, usually where two steps sit close together. Splitting a row that contains two ideas is quicker than untangling it later.
Strip personal and confidential information first, in line with your own policies.

Four stages, one board

1. Scoping – identify the Job Executor, define the target job, capture the circumstances and constraints and the related jobs around it.

2. Job mapping – break the target job into solution-free steps across the eight universal stages: Define, Locate, Prepare, Confirm, Execute, Monitor, Modify, Conclude.

3. Investigate needs – interview Job Executors about specific recent experiences, then use the Flow to turn transcripts into structured evidence.

4. Capture outcomes – translate evidence into precise desired outcome statements and build an outcomes library ready for prioritisation.

In a full ODI study, Job Executors then rate every outcome for importance and satisfaction – and Important and Poorly satisfied is where the opportunity is at. The board shows where that quantitative stage fits; Mosaic’s ODI Toolkit carries the survey design, scoring and interpretation behind it.

One board holds the job, the evidence and the outcomes together, and every conclusion on it can be traced back to a person’s words. That is what I mean by an operating system for innovation.

When this is the wrong tool

This is the condition I flagged earlier: ODI needs a stable job to measure. Participants have to be able to describe the job, the steps involved and the criteria they use to judge whether it was done well.

If the team cannot yet say whose outcomes matter most, if the job is still too broad or solution-led to measure, if the market is too new to have settled success criteria, or if the real question is why people switched, churned or stayed, then this is not the method to reach for. That is where the Switch approach and broader discovery work earn their place, and Mosaic’s toolkits cover both.