You need to sign in or sign up before continuing.
Reflection — An Honest Take 8 min

Honest Take — Before You Begin

Honest Take — Module 2: Jobs-to-be-Done — Interviews That Reveal Real Demand #

The five JTBD interviews are the deliverable you will most want to skip, and I want to name that explicitly because the wanting-to-skip will feel reasonable in the moment — too busy, the day job is heavy this month, the waitlist is too small, the interviews can wait. None of those reasons survive contact with the math. Five interviews is roughly five hours of call time plus four hours of synthesis. Nine hours of work, spread across three weeks, against the alternative of building features for nine more months toward a job nobody is hiring your product to do. The interviews are the cheap version of the lesson. The other version costs 9-12 months and ends in a dead product. If you run the worked example in your head — ClearCal, 140 waitlist signups, never launched — the nine hours are what stands between "validation by waitlist" and actual demand evidence.

The contrarian frame here is load-bearing and I want to underscore why. "Would you use this?" produces useless data, because people say yes politely. "Would you pay for this?" produces noise too — stated willingness to pay over-predicts actual willingness by 2-3x in most consumer-software studies. The discipline JTBD trains is asking "what are you currently doing about this problem?" Past behavior is signal. Stated future intent is noise. Most of the questions you have asked your users or waitlist in passing — and most informal user questions engineers ask anywhere — fall into the noise category.

The five interviews are the corrective, and the question stems exist precisely because the natural questions are the wrong ones.

Here is the prediction I want on the page so you can check me later. At least one of the five interviews will reveal that what your product does — at least as you've been describing it — is not what the interviewee thought they were signing up for. They signed up because the landing page promised something adjacent. The adjacency is your data, and there are exactly two responses to it. The wrong response is to defend the original vision and dismiss the user as confused. The right response is to write down what they actually wanted, ask the next four interviewees about that thing, and let the interviews tell you what product they're hiring you to build. Which response you choose is the entire signal of whether M2 installed. It is uncomfortable. It is also the most valuable possible outcome of the module.

Let me say the thing the formal curriculum says more quietly: most engineer-founders never run a real user interview in the JTBD register. They run informal chats, demo calls, friend-feedback sessions — useful for some things, useless for the demand question — and their products fail by exactly that gap. Christensen's research base, Klement's case studies, Moesta's demand-side work all point at the same pattern: the interview discipline is rare, and the rarity is why most products miss demand. You are not unusual here, and seniority does not protect you. If anything, a decade of shipping makes you more vulnerable, because you have built so many things that working without explicit demand-evidence has become normal. "I can just build it" is precisely the capability that lets you skip validation indefinitely. M2 makes the skipping abnormal.

I can hold the question stems, predict where you'll flinch, and template the synthesis. I cannot do the interviews, because the interviewer's presence is part of the data the interviewee responds to, and the discipline only installs when you sit on the call yourself. One logistical note so the response rate doesn't discourage you: warm-ish interview asks for indie products land at roughly 30-50%. Send 12-15 asks to get your 5 yeses, and don't take the silence personally.

Conclusion #

JTBD interviews are adversarial input testing for product hypotheses. Five interviews, nine hours, against the 9-12 month alternative. At least one will reveal demand-adjacency rather than demand-confirmation, and the adjacency is the most useful possible signal — provided you treat it as data rather than as a threat to defend against. The synthesis feeds M3 directly: you cannot position a product until you know what job anyone would hire it for. Engineers who skip this discipline ship products with confident interfaces and no buyers.

Predictions #

  • You'll schedule the first interview within a week of starting M2. Interviews 2-3 will slip by 4-7 days each because the calendar fights back. Push through.
  • One of the five interviews will run 60+ minutes because the interviewee starts telling you something useful and you finally stop interrupting. That interview is the one to reread.
  • At least one person will simply not respond to your interview ask. The hit rate is 30-50%; send 12-15 asks for 5 interviews.
  • The synthesis document will be harder to write than the interviews were to conduct, because synthesis forces a stance and conducting allows ambiguity. Write the stance.
  • You'll be tempted, during interview 3 or 4, to start pitching your product's current scope. The interview frame collapses the moment you pitch. Resist; sales calls are a different instrument.
  • The "what would have to be true" pre-mortem will surface at least one assumption you didn't know you were making — usually about the user's existing tooling or workflow. That assumption is the first thing M3 has to reckon with.