Problem validation
// Definition
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.
// Related terms
Product discovery
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.
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.
Minimum Viable Product (MVP)
Minimum Viable Product is the smallest version of a product that lets you test a core assumption with real users and generate validated learning. The word "minimum" does not mean low quality — it means minimum scope. An MVP can be polished; it is simply not feature-complete. The concept is widely abused to justify shipping half-finished work under the banner of "we'll iterate," which is a delivery failure dressed up as product thinking. Eric Ries's original definition centres on learning, not launching: an MVP is an experiment, not a release. QA engineers often recoil at MVPs because the scope looks under-tested. The reframe: an MVP is tested deeply for the one assumption it exists to validate, not for completeness. Coverage is deliberately narrow and intentional — a different discipline from full-release testing, not an absence of discipline.
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.