User research
// Definition
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.
// 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.
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.
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.
User story
A user story is a short, human-centred description of a feature: "As a [type of user], I want [some goal] so that [some reason]." The format forces scope discipline — if you can't complete the sentence, the story is not well understood. Stories are units of conversation, not specification; the real value is the discussion they trigger between PM, designer, and engineer. Story splitting is a core skill: a story that takes more than one sprint to deliver is almost certainly two or three stories in disguise. For QA engineers moving into product, user stories feel immediately familiar — acceptance criteria are test conditions expressed in business language. The adjustment is writing stories before knowing how they will be implemented, living with ambiguity in the what while the team works out the how.