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

Honest Take — Before You Begin

Honest Take — Module 1: Continuous Discovery — How to Stop Guessing #

Torres' Continuous Discovery Habits will feel academic the first time through. You will read the opportunity-solution-tree chapter and think "this is overengineered for my scale." Hold that judgment for two weeks. The book reads as overhead because Torres is teaching a habit, and habits read as overhead until you've installed them. The operationalization at solo scale is much smaller than the book makes it look — one user conversation per week, one OST sketch per active product, one explicit assumption-test per cycle. That's the whole thing. The 280 pages exist because Torres is also teaching product trios at SaaS companies, and the trio version needs more scaffolding than yours does.

The two earlier drafts of this module made different predictions about where your resistance will show up, and I think both were right, because it's the same resistance at two checkpoints. One draft said the resistance arrives before the first conversation: you'll find a hundred reasons to defer emailing your waitlist or your users — the email needs another draft, the questions aren't ready, you should re-read The Mom Test once more. None of those reasons are false; all of them are evasion dressed as preparation. The other draft said the resistance arrives at the third conversation, once the novelty has burned off: "I already know what they'll say," "the waitlist isn't representative yet," "I'll do it next week when the new mockups are ready." Same resistance, different costume. Schedule the conversation anyway. What users say in a real conversation diverges from what you predicted they'd say in roughly 30-40% of substantive points, and the divergence is exactly the discovery.

Here is the truth the formal module can't quite say at full volume: continuous discovery is genuinely harder for engineers than for non-engineers, and the difficulty has nothing to do with the framework. It requires sustained attention to humans rather than to code, and the engineer brain finds code-attention easier and human-attention more depleting. Twenty minutes debugging a flaky spec feels easier than twenty minutes on a video call asking a stranger to describe their last working morning. The asymmetry is the diagnostic — if user conversations feel easy and code feels hard, you've already internalized the discipline; if it's the reverse, you're where most engineer-founders live, which is where I predict you are.

And one technical note from observed first interviews: you will talk too much. You'll explain your product's context before asking questions, because you want the interviewee to "have context" — which is backwards; they're supposed to give you context about their problem. Count your words against theirs. The first interview you'll be at 40/60. By the fifth you should be at 15/85. The improvement is the skill.

Two warnings about artifacts. First, the waitlist: if you have one, it is a comfort, and it means less than it feels like it means. Take the worked example — ClearCal's ~140 signups. People sign up for waitlists for products they will never use, because signing up is free and "interest" is a low bar. The interviews tell you the difference between the people who have the problem painfully and the people who liked the landing page; the two groups look identical on the list and completely different on a call. Second, the OST: you will, at first, draw a beautiful tree, screenshot it, and never look at it again. That's deliverable mode. Working-artifact mode is uglier — a markdown file with bullet-nested opportunities, edited weekly, half-deleted, never finished. The ugly version does the work; the pretty version is procrastination dressed as artifact creation.

Last: do not jump from raw transcripts to product changes. You will hear one person say "I wish it had X" and want to build X that evening. The pattern across five interviews is the signal; the single quote is noise; M2 turns the conversations into demand evidence and M3 turns the evidence into a position. The discipline of not building yet is part of this module. I cannot run the conversations for you — the interviewer's presence is part of the data — and I cannot tell you what your users actually want, because you mostly haven't asked them, which is itself the diagnostic.

Conclusion #

Continuous discovery is observability for product decisions and the weekly user-touch is the instrumentation. Torres reads academic until the habit installs; install it by running it small. The resistance will arrive before the first conversation and again at the third, wearing reasonable clothes both times. The conversations will surprise you in roughly the same shape every time — the user is solving a job adjacent to the one you assumed — and that surprise is the value no certificate ever delivered.

Predictions #

  • You will defer the first conversation by at least a week beyond when you intended. The deferral will feel like preparation. It is avoidance.
  • The first conversation will feel awkward and run 22-28 minutes; the third will feel competent and run 35-45 because you'll have learned to follow rather than lead.
  • Your talk-time ratio in interview one will be around 40%. By interview five it will be under 20%, if you record and count — and if you don't record, it won't improve.
  • At least one waitlist signer or user will turn out to have signed up for a reason adjacent to, not identical to, what you've been building. The adjacency is the discovery, not a problem.
  • You'll skip the weekly user-touch in week two because the day job eats the slot. Resume in week three; do not restart the count.
  • The OST will be ugly. The ugliness is correct; resist beautifying it before the practice has stabilized.
  • One conversation in the first six will reveal something you'd been quietly avoiding knowing — usually that the product you're building is not the product the list wants. That conversation is the most valuable one. Take notes; resist defending.