Jobs to be done for founders

Jobs to be done for founders is a way to describe the progress someone wants in a situation, not a list of features or a demographic label. You use it to sharpen discovery before you commit months to a build.

Jobs to be done for founders, in one sentence

Someone “hires” a product when it helps them make progress on a job: get a report out before the board meeting, stop chasing suppliers on Friday afternoon, feel confident they chose the right therapist. The method asks what that progress is, what they used last time, and what almost stopped them from switching. It does not tell you whether they will pay you, how big the market is, or whether your stack is the right answer.

This piece is for a founder with an idea or pre-seed traction who keeps explaining the solution instead of the struggle. If you already have paying customers and a repeatable channel, you need iteration metrics more than a fresh framework. If you only want a workshop slide, skip the exercises below and talk to people instead.

The next step after language is evidence. How to validate a startup idea ties jobs to interviews, landing tests, and what to measure before engineering weeks.

Job

The progress the buyer wants in a specific circumstance, not a user type.

Hire

They choose your offer (or a spreadsheet) for that progress.

Fire

They stop using the old way because it failed them often enough.

Job story

A short line: when … I want to … so I can …

What JTBD is good for before an MVP

Founders often open with “we are building an app that…”. Buyers rarely wake up wanting an app. They want an outcome with less risk or less hassle. JTBD gives you a disciplined way to capture that outcome in words you can test.

It improves customer interviews because you ask about the last time the problem showed up, what they did, and what they wished had been easier. It improves scope because you can mark features as “only if this job is real”. It improves positioning because you describe the before and after of progress, not a technology stack.

It pairs naturally with problem validation: you are not proving the job exists because you wrote a clever sentence. You still need conversations, and often a small experiment, before you treat the job as confirmed.

1. Write the struggling moment

   One situation, present tense. “When a guest asks for a wine we thought we had…” beats “restaurants need inventory software”.

2. Name the old hire

   Spreadsheet, WhatsApp group, pen and paper, a human assistant. Ask what broke last time.

3. List anxieties

   What makes switching feel risky: cost, looking foolish, training staff, losing data.

4. Turn lines into interview prompts

   Ask for a story, not a verdict on your mock-up.

What jobs to be done does not prove

A crisp job story is not revenue. Two teams can agree on the same job and still lose to an incumbent, a regulation change, or a channel you cannot afford.

JTBD does not replace market sizing. “Parents want calm bedtimes” does not tell you how many will pay CHF 15 per month in Switzerland. It does not prove your solution is technically feasible at a price that works. It does not prove you can reach buyers without burning cash on ads that never convert.

It also does not protect the idea. Under Swiss practice, ideas as such are not protectable; execution, brand, and contracts are. Treat the job map as input to validation, not as intellectual property.

A made-up example: from features to a Friday job

A made-up example: a solo founder targets independent restaurants in Zurich. The first pitch was “digital stock and supplier orders in one app”. After three interviews described as polite nods, she rewrote the job: “When service is about to start and the walk-in fridge is wrong, I want to know what is missing without leaving the floor, so I do not disappoint guests or rush a supplier call mid-shift.”

The old hire was a head chef texting photos to a supplier and a notebook by the pass. The anxiety was staff ignoring a new tool during rush hour. The MVP scope shrank to a phone-friendly checklist tied to one supplier, not a full ERP. That shift is what JTBD is for. Whether guests would pay, or whether ads could reach enough kitchens, still needed a separate test.

Who should skip the workshop version

Skip a formal JTBD sprint if you already see repeat purchases or signed pilots tied to a clear pain. Your job is to remove friction and measure retention, not to rediscover language.

Skip it if you cannot reach the buyer at all. A beautiful job map for hospital procurement without access to a single stakeholder is theatre.

Skip it if you are building only for yourself and do not intend a business. The framework still helps you think, but it will not replace a market.

Frequently asked questions

Is jobs to be done the same as user personas?

Personas describe who someone is. JTBD describes what they are trying to get done in a moment. You can keep a persona for messaging, but interviews should anchor on situations and past behaviour.

How many job stories do I need?

Enough that the same struggle appears in unrelated interviews. One story is a hypothesis. Three similar stories from different people is a signal to design a test, not proof of a market.

When a job is sharp enough to test with a real build, landing page, and measurement, the MVP validation package is the studio path that connects discovery to shipped software and a Go, Pivot, or Stop read-out.