What a Job to Be Done Actually Means
The central insight of JTBD is deceptively simple: people do not buy products, they hire them to do a job. When someone downloads a task manager, the job might not be to manage tasks at all. It might be to feel in control of an overwhelming workload, or to signal to a manager that they are organised. Understanding the real job changes everything about what you build. A job has three components. The functional job is the practical task: I need to transcribe this meeting. The emotional job is the internal feeling desired: I want to stop worrying about missing action points. The social job is the external perception: I want my team to see me as thorough. A product that addresses only the functional job often loses to one that addresses all three. For AI products specifically, this distinction matters enormously. An AI meeting summariser competes on functional job with a dozen similar tools. One that gives teams a single organised view and eliminates the anxiety of forgotten follow-ups is solving a broader job, and that is harder to replace.
How JTBD Differs from Personas
Most product teams are taught to build personas: fictional composites of their target users, complete with names, ages, and motivations. Personas have real value for communication, but they are a poor tool for product decisions because they describe who the customer is, not what situation triggers them to seek a solution. JTBD focuses on the situation and the trigger. Two people with completely different demographic profiles, job titles, and psychographics might hire the same product for the same reason in the same situation. A solo founder and a procurement director might both hire a contract management tool in the same moment: just after a deal nearly fell through because nobody was tracking the renewal date. The trigger and the job are the same. Persona-based design would have built two different products for them. JTBD points you to the same core solution. This is especially relevant for early-stage AI MVPs where the target user base is often broader than it first appears, and where narrowing scope based on persona assumptions can exclude high-value segments.
Running JTBD Interviews
JTBD research is interview-driven, and the interviews are structured differently from standard user research. The goal is to reconstruct the timeline of a purchase or adoption decision, working backwards from the moment the customer switched to a new product or hired something new. The key questions are not about the product itself. You ask: what was happening in your life when you first started looking for a solution? What did you try before? What made you finally make a change? What were you hoping would be different? These questions surface the real job because they reveal the triggering situation, the previous solutions that failed, and the emotional stakes involved. For a UK AI startup building in the fintech space, a JTBD interview with a finance director might reveal that the real trigger was an FCA audit question they could not answer, not the general pain of slow reporting. That is the job to address in the MVP. SpeedMVPs runs a compressed JTBD discovery session during our project scoping phase to extract these insights before development begins.
JTBD for MVP Feature Prioritisation
Once you understand the primary job your product is hired to do, you can apply JTBD to prioritise which features belong in the MVP and which do not. The rule is straightforward: if a feature directly enables the customer to complete the core job better than they can without it, it belongs in the MVP. If it addresses a secondary job or a nice-to-have, it can wait. This prevents the common mistake of building a feature-rich MVP that does many things adequately but nothing exceptionally. For AI products, this matters because AI features have non-trivial development cost. Every RAG pipeline, every fine-tuning run, every agentic workflow adds scope. JTBD discipline helps teams decide which of these is essential to the job and which is gold-plating. A legal AI product whose core job is helping solicitors find precedent faster does not need a document generation feature in version one. The job is search, not drafting. Keep the scope tight around the job.
JTBD and Positioning for AI Products
JTBD has a second application beyond product scoping: it drives better positioning. When you know the specific situation and trigger that causes someone to hire your product, you can write copy that speaks directly to that moment. Instead of describing your AI as an intelligent document processor, you describe it as the tool that gives you an answer before the client emails again. That specificity resonates because it mirrors the exact situation your customer was in when they started looking. For AI products in regulated sectors, JTBD also helps identify the emotional jobs that feature prominently but rarely get acknowledged in marketing. A healthcare AI might be hired not just because it processes data faster, but because it gives a clinical team confidence they are not missing something in a patient record. That emotional job, the reduction of clinical anxiety, is a legitimate product outcome and a powerful message. Naming it in positioning separates you from competitors talking only about accuracy percentages.
Applying JTBD at SpeedMVPs
At SpeedMVPs, JTBD shapes the scoping conversations we have with founders before we begin development. We ask about the situation the user is in when they need the product most, what they are currently doing instead, and what a successful outcome looks and feels like from the user's perspective. This takes roughly half a day and changes the specification materially in most cases. Founders often arrive with a list of features they want built. JTBD interviews with their early users regularly reveal that two or three of those features address jobs nobody has, while a completely different capability they had not considered addresses the primary job precisely. The result is a tighter, faster-to-build MVP that delivers more value on launch day. If you are approaching an AI MVP and want to make sure you are building for a real job, a scoping conversation with our team is the right starting point.