Product Discovery

Discovery is a toolkit of techniques, each answering a different type of question. Customer interviews (for understanding problems and motivations): 60-minute one-on-one conversations focused on the customer's current workflow — not feature feedback. The interviewer asks the customer to walk through how they accomplish a specific task today, probing for pain points, workarounds, and the moments of confusion or frustration. Optimal cadence: each PM conducts 2–4 interviews per week on a rolling continuous basis. Usability testing (for validating designs): observe 5–8 participants attempting to complete a specific task using a prototype or live product — the test surfaces usability problems that analytics cannot detect (users who know "something is wrong" but can't articulate what). Concept testing (for validating solutions before building): present a written or mockup representation of a proposed solution to 10–15 customers and measure their comprehension, desirability, and predicted behavior change. Prototype testing: build the minimum-fidelity prototype that allows testing the riskiest assumption, and observe real users interacting with it. Fake door tests: create a UI element (button, menu item) for a feature that doesn't exist yet, measure click rate, and collect emails from interested users — proves demand before any development effort.

Continuous discovery, popularized by Teresa Torres, is the practice of conducting small, frequent discovery activities on an ongoing basis — rather than large periodic research phases with long gaps between. The traditional model: a product team pauses all development for a 4–6 week "discovery phase," conducts extensive research, presents findings, and then enters an extended delivery period with no new discovery. The problem: the world changes, customer priorities shift, and the assumptions from the discovery phase go stale during the long delivery period. Continuous discovery substitutes weekly or bi-weekly small-scope discovery activities for quarterly big-bang research: each PM conducts 2 customer interviews per week, every week, not as a project but as a professional rhythm like their weekly planning meeting. The insights from these regular touchpoints are logged in the team's research repository (Dovetail, Notion), and patterns emerge organically without requiring a formal synthesis phase. Teams operating with continuous discovery consistently make better product decisions because they have current, specific customer context rather than research insights that are 3–6 months old.

Assumption mapping is a structured technique for identifying and prioritizing the beliefs underlying a product decision, then designing the minimum experiments required to validate or invalidate the riskiest assumptions before development commitment. The process: for any significant product initiative, the team lists all the assumptions the initiative requires to be true for it to succeed. Example assumptions for a new onboarding flow: "New users are confused by the current setup wizard" (is this actually true, and is confusion the primary cause of low activation?); "A guided tour format reduces activation time" (have we tested guided tours vs. the current wizard?); "Users who activate in week 1 have higher 6-month retention" (is there actually a causal relationship, not just correlation?). Each assumption is then plotted on a 2×2 matrix: axis 1 is certainty (how confident are we this assumption is true?); axis 2 is importance (how critical is this assumption being true for the initiative to succeed?). High-importance + low-certainty assumptions are the discovery priorities — the team designs the minimum test (user interview, prototype test, or fake door) that will move the assumption from low certainty to high certainty before committing to full development.