Jobs-To-Be-Done (JTBD) vs Minimum Viable Product (MVP)

Definition

Jobs-To-Be-Done is a framework that says customers don't buy products — they 'hire' products to do a job in their life. A customer doesn't buy a drill because they want a drill; they want a hole in the wall. They don't even want the hole — they want to hang a picture to make their home feel like theirs. Understanding the REAL job reveals competitors you never considered and opportunities you never imagined. McDonald's milkshakes compete with bananas and bagels (the 'morning commute companion' job), not just other milkshakes. Intercom adopted JTBD and restructured their entire product around customer jobs instead of features — driving a 3x improvement in activation rates.

Common trap

The trap is defining jobs too narrowly (feature-level) or too broadly (life-level). 'I need a spreadsheet' is a feature request, not a job. 'I need to feel successful at work' is too abstract to design for. The right level is: 'I need to track monthly expenses across 3 teams and present a consolidated view to the CFO by the 5th of each month.' This gives you the functional job (track + consolidate), the emotional job (look competent to the CFO), and the constraints (monthly, 3 teams, by the 5th). Another trap: assuming you know the job without talking to customers. Your guesses about why people use your product are wrong 60-70% of the time.

Practical use

Conduct 10 Switch Interviews (a JTBD technique) with recent customers. Ask: (1) 'What were you using before us?' (reveals the competitor you're really replacing). (2) 'What was the specific moment you decided to look for a solution?' (reveals the struggling moment). (3) 'What would you go back to if our product disappeared?' (reveals the real alternative). Map the responses into Job Statements: 'When [situation], I want to [motivation], so I can [expected outcome].' Identify the top 3 jobs and redesign your landing page, onboarding, and feature roadmap around them.

Formula

Definition

An MVP is the smallest version of your product that delivers real value to early users and generates validated learning. The goal isn't a 'crappy first version' — it's the fastest path to proving whether customers will pay for your solution. 74% of startups fail because they build something nobody wants.

Common trap

The trap is building too much. Founders spend 6-12 months building a 'complete' product before showing it to a single customer. By then, they've burned through runway and assumptions. Dropbox's MVP was a 3-minute demo video — it validated demand before writing a single line of code.

Practical use

Define the ONE core problem you solve. Build only the features needed to test if users will pay for that solution. Launch within 4-6 weeks. Your MVP should be embarrassingly simple — if you're not embarrassed by v1, you launched too late.

Formula