Jobs to be Done (JTBD)
// Definition
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.
// 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.
North Star metric
A North Star metric is the single number that best captures the core value a product delivers to customers — the one that, if it grows sustainably, predicts long-term business health. Spotify's was time-in-app; Airbnb's was nights booked. The North Star sits above vanity metrics (page views, sign-ups) and below revenue — it measures the value exchange, not the financial outcome. Choosing the wrong metric drives the wrong behaviour at scale: an engagement metric optimised without guardrails can increase usage while eroding user wellbeing. Supplement the North Star with counter-metrics to prevent gaming. For testers becoming PMs, this is a genuine mindset shift: QA thinks pass/fail (binary, per-release, reversible), while product thinks directional (continuous, long-horizon, probabilistic). Learning to act confidently on a trend rather than a verdict is the core adjustment.
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.