continuous discovery

why

an assumption validated after the build is the most expensive way to learn it was wrong: no significant build starts before its question survives the cheapest probe that can falsify it. discovery as a front-loaded phase decays into opinion between projects; as a weekly habit it keeps real-visitor evidence flowing into prioritization. a one-hour probe routinely saves weeks of unwanted build.

rule

discovery is not a phase before building; it is a small continuous activity beside delivery. every week answers at least one open product question through the cheapest probe that can answer it. a question answered after a launch is an expensive answer.

probe menu, cheapest first

probe	answers
one conversation with a real visitor	does the problem exist, in their words, at what frequency and cost.
live manual run (concierge)	does the solution shape work for one person end-to-end.
clickable sketch / static mock	which surface communicates the value.
fake door / button that measures	would people go here if it existed.
smallest real capability flagged off	does usage repeat when it is real.

escalate probe cost only when the cheaper probe cannot discriminate. the FVM defined in onboarding is the reference point probes test against.

interview discipline

ask about past behavior and current pain, never hypothetical willingness ("would you use...").
record answers in the visitor's words; translate into feature names only with the question set open.
one probe, one question; do not bundle.

do not

validate a finished build; validate the question before and the change after.
treat internal opinion as a substitute for contact with a real visitor.
run a probe whose result cannot change the next decision.
stockpile discovery insights in a doc nobody rereads; feed them to prioritization weekly.

verification

review the last month: at least one probe per week (or the cadence the product stage warrants), each probe's question and answer written, at least one prioritization decision citing a probe. a calendar with no contact is the failure mode this file exists to prevent.

good and bad

bad

assumption: power users will compete on workflow speed.
decision: build a live leaderboard feature (6 weeks).
result shipped: leaderboard shows; 0.3% of users ever visit it.
post-mortem: "users don't care about competition."
cost: 240 person-hours for a feature nobody wanted.

validated after six weeks of work. a one-hour conversation with three power users would have surfaced the truth: they don't want public comparison; they want to improve their own workflows.

good

hypothesis: power users might engage more if they see others' speeds.
probe: one conversation with three active power users.
  "would you compete on workflow speed? why or why not?"
  answers: all three said no. they prefer private improvement metrics.
result: hypothesis false.
next: instead, test private performance tracking against public.
cost: 1 hour + insight, no wasted build time.

the cheap probe falsified the assumption before building; the same hour surfaced private performance tracking as the next iteration's higher-confidence item.