Product discovery
// Definition
Product discovery is the work that happens before a single line of code is written: identifying real user problems, validating that they are worth solving, and shaping a solution hypothesis. It involves interviews, observation, prototype testing, and quantitative analysis — the goal is to collapse uncertainty before committing engineering effort. Discovery is never "done"; product teams run it in parallel with delivery to stay ahead of the build queue. The common trap is confusing discovery with research reports that nobody reads; discovery output is a decision: build this, not that, and here is the evidence. For QA engineers moving into product, discovery is where the instinct for "what could go wrong" is most valuable — testing a problem statement or a prototype applies the same rigour as testing a feature, just earlier and cheaper.
// Related terms
Jobs to be Done (JTBD)
Jobs to be Done is a framework for understanding why customers hire a product. A "job" is the underlying progress a person is trying to make in a specific situation — not demographics ("35-year-old manager") but motivation ("help me give stakeholders confidence the release is safe"). Clayton Christensen popularised the idea; Tony Ulwick operationalised it into Outcome-Driven Innovation. JTBD interviews focus on the purchase story: what triggered the search, what alternatives were considered, and what caused the switch. The insight is that competitors are not always obvious — a spreadsheet competes with a project management tool if the job is "stay in control of my team." For QA-to-PM transitioners, JTBD reframes users from "people who file bugs" to "people trying to ship confidently" — a small shift with large consequences for what you build.
User research
User research is the practice of systematically learning how people think, feel, and behave in relation to a product or problem. Methods split into generative (discovery-oriented: interviews, contextual inquiry, diary studies) and evaluative (testing a solution: usability tests, A/B tests, surveys). The most common mistake is treating research as a one-time gate rather than a continuous discipline. A 30-minute user interview per week, compounded over a quarter, builds pattern recognition that transforms product intuition. Recruiting bias — talking only to power users or company friends — corrupts findings badly. QA engineers have a natural head start: writing a test case requires modelling user behaviour under adverse conditions, which is essentially the same cognitive work as a usability test. The gap is comfort with ambiguous, open-ended questions rather than pass/fail verdicts.
Problem validation
Problem validation is the practice of confirming that a problem is real, significant, and widespread before building a solution. The tool set includes user interviews (direct evidence), support ticket analysis (indirect signal), usage data (quantitative), and competitor research (market signal). Validation fails in two directions: false positive (you believe the problem is real because your most vocal customers have it, but most users don't) and false negative (you discount a real problem because it is hard to articulate in interviews). The lean loop — problem hypothesis → smallest experiment → decision — applies directly. For QA engineers moving into product, the "what could go wrong" instinct maps cleanly onto validation: both disciplines search for failure modes in a hypothesis. The shift is running that search before code exists, on assumptions rather than implementations.
Product-market fit
Product-market fit is the degree to which a product satisfies strong market demand — a state where users acquire, retain, and refer at rates that sustain growth without heavy marketing spend. Marc Andreessen defined it as "being in a good market with a product that can satisfy that market." Sean Ellis's heuristic: if more than 40% of surveyed users would be "very disappointed" if the product disappeared, PMF is likely. Before PMF, optimise for learning, not efficiency — every process and metric should target understanding what the market actually wants. After PMF, optimise for growth. For QA engineers pivoting to product, PMF reframes the entire quality conversation: before PMF you are validating the concept, not production polish; after PMF, reliability and quality become competitive differentiators that directly affect retention.