Product Discovery & User Research
Problem framing, interview technique, jobs-to-be-done, opportunity sizing
Last reviewed
Recommended
Product Discovery & User Research — Timed Test 2 (10 questions)
No account needed. Answers and explanations arrive when you submit.
What this topic tests
The mix every Product Discovery & User Research set is built to, and the questions published against it so far. Nothing here is hidden before you start.
| Level | Target share | Published |
|---|---|---|
| Easy | 40% | 16 |
| Medium | 40% | 16 |
| Hard | 20% | 8 |
| Total | 40 |
Product Discovery & User Research — the theory
Discovery Answers Two Questions, Not One
Product discovery is usually described as "talking to users", which collapses two jobs into one. Marty Cagan splits them. First, you need to discover whether there are real users out there that want this product. That is the first. And Second, you need to discover a product solution to this problem that is usable, useful, and feasible. That is the second. A team can finish the second and fail the first, and the result is a well-built answer to a problem nobody has.
The Four Risks Every Idea Carries
Cagan names four, and they are the vocabulary most product interviews assume you already have. Value risk asks whether customers will buy it or users will choose to use it. Usability risk asks whether users can figure out how to use it. Feasibility risk asks whether our engineers can build what we need with the time, skills and technology we have. Business viability risk asks whether this solution also works for the various aspects of our business — legal, sales, support, finance, brand.
The four are independent. Evidence that settles one says nothing about the other three.
What to Answer Before the Work Starts
Cagan's opportunity assessment is a short list of questions asked before a team commits, and it doubles as a structure for the "how would you evaluate this idea?" interview prompt:
- Exactly what problem will this solve? (value proposition)
- For whom do we solve that problem? (target market)
- How big is the opportunity? (market size)
- What alternatives are out there? (competitive landscape)
- Why now? (market window)
- How will we measure success/make money from this product? (metrics/revenue strategy)
Two things are easy to miss. The list demands answers before the effort rather than after it, and it treats Why now? (market window) as first-class — an idea can be right and three years early.
A Worked Pass: One Idea Through Both Filters
A team building invoicing software for freelancers proposes in-app chat with clients. Run the four risks first. A usability session shows every participant finding and sending a message without help, so the usability risk looks answered — and nothing else does. Value is untouched: nobody has shown a freelancer would choose it over the email thread they have. Feasibility is untouched: no engineer has costed message retention or search. Viability is untouched: support has not said who answers a client's complaint sent through your product at 2am.
Now the assessment. The team can answer the problem and the target market. It cannot answer why now, and it cannot say how success would be measured. Two of six unanswered is not a verdict, but it is the honest state of the idea.
Opportunities Are Needs, Not Features
Teresa Torres's opportunity solution tree is the most reproduced artefact in modern discovery, and the term it defines is the one teams get wrong. In this context, an opportunity is an unmet customer need, pain point, or desire. It is not a feature request. The tree is Opportunity solution trees are a simple way of visually representing the paths you might take to reach a desired outcome. The desired outcome sits at the top; beneath it sit the opportunities, which are These are the customer needs, pain points, and desires that, if addressed, will drive your desired outcome.; solutions hang off those. You do not start from a backlog and reverse-engineer a need to justify it.
Who Does Discovery
Torres's answer is the product trio. A product trio is typically comprised of a product manager, a designer, and a software engineer. The point is not headcount. When a product trio works together to develop a shared understanding of their customer, they are in a much better position to create products that customers love. The shared understanding is the deliverable, and it is the thing a circulated research report cannot produce.
Interviews About Last Tuesday
The most useful interview technique is also the easiest to state. Keep the interview grounded in specific instances of past behavior. Torres's own opening is Tell me about the last time you watched Netflix. — not "do you watch Netflix?", and certainly not "would you use a feature that…".
A question about the future returns a prediction, and predictions about your own behaviour are cheap. A question about last Tuesday returns a story, with the context, the constraints and the workaround still attached.
Test the Assumption, Not the Idea
When a prototype of a whole concept fails, a team learns that something is wrong. It rarely learns what. Torres's alternative is deliberately narrower: Assumption testing makes it clear that we’re testing a single assumption and not the whole idea. The payoff is diagnostic — When an assumption test fails, we know exactly what needs to change. A test that can only return "the idea did not land" leaves you nowhere in the morning.
Five Users, and What That Finding Actually Says
Almost every product manager can quote this one and almost nobody quotes both halves of it. The Nielsen Norman Group result is that The best results come from testing no more than 5 users and running as many small tests as you can afford. The advice that travels with it is that it is better to distribute your budget for user testing across many small tests instead of blowing everything on a single, elaborate study
The number is only defensible with the second half attached. Quoted alone, "five users is enough" becomes a licence to test once and stop — the opposite of what the finding says.
The Job, Not the Customer
Jobs to Be Done is a lens, not a segmentation scheme. The Christensen Institute defines it as Jobs to Be Done is a lens that reveals the circumstances—or forces—that drive people and organizations toward and away from decisions. Its central claim is that People don’t simply buy or pick products or services; they pull them into their lives to make progress.
The practical consequence is what you segment by. Two people of the same age, income and job title, in different circumstances are not the same customer.
Needs, and the Things That Only Look Like Needs
The UK Government's Service Manual is unusually blunt about evidence, and its definitions travel well beyond government. ‘User needs’ are the needs that a user has of a service, and which that service must satisfy for the user to get the right outcome for them. Note what that excludes: a need is a need of the service, not a wish in general, and it is tied to an outcome the user is trying to reach.
Then the sentence that settles most stakeholder arguments: Treat any opinions or suggestions that do not come from users as assumptions that have to be proven by doing research. An executive's strongly held suggestion is not a requirement. It is a hypothesis with a sponsor, and it enters the backlog on the same evidence as anything else.
Research Is a Habit, Not a Phase
The same manual is equally direct about scheduling. This means doing small batches of user research in every iteration of each development phase - starting in discovery and continuing throughout live. And the number teams flinch at: All team members should watch real users interacting with your service and talking about it - ideally for at least 2 hours every 6 weeks.
Who you research with is not a detail either. For your research to be effective, your participants must be actual or likely users of your service. — a colleague's opinion of a screen is not a finding. Avoid using your own staff for research into the public facing parts of your service., because Their knowledge and experience can mean they will use the service in a very different way. And screening deserves care for a reason that is easy to miss: Some people with access needs do not identify as having a disability and it is important to be aware of this in the screening process.
Sources
Marty Cagan / Silicon Valley Product Group · Teresa Torres / Product Talk · Nielsen Norman Group · the Clayton Christensen Institute · the UK Government Digital Service's Service Standard and Service Manual · the 2020 Scrum Guide. Every quotation above is verbatim, machine-verified against the live pages on 2026-08-24.
Sample questions
Three questions from this topic, with the answer and the reasoning shown.
Q1EasyA director sends the team a list of changes he is certain users want. Under the Service Manual, what is that list?
- A set of requirements, because of the seniority of the person sending it
- A set of needs, once the team has agreed the changes make sense
- A set of assumptions, to be proven by doing researchCorrect
- A set of findings, equal in weight to what the analytics reports
Explanation
The principle — what an input counts as depends on where it came from, not on how sure its author is.
Why the key is correct — the instruction is to Treat any opinions or suggestions that do not come from users as assumptions that have to be proven by doing research. A director is not a user, so the list is hypotheses. Not a dismissal: many may be right, and research finds out which.
Why the others are wrong — seniority changes who must be persuaded, not what was claimed. Team agreement converts nothing: the standard names research, not consensus. And a record of what people did is different evidence from a prediction.
Remember this — if it did not come from a user, it is an assumption with a sponsor.
Sources — the UK Government Digital Service Manual on learning about users and their needs.
Q2EasyAmong Cagan's four big risks, which question does value risk ask?
- Whether the product can be built and sold at an acceptable margin
- Whether the evidence so far has raised the team's overall confidence
- Whether customers will buy it or users will choose to use itCorrect
- Whether users can figure out how to use it
Explanation
The principle — each of the four risks asks one question, and value asks about choice.
Why the key is correct — Cagan's value risk is whether customers will buy it or users will choose to use it It is about the decision a person makes when nothing compels them to make it.
Why the others are wrong — margin belongs to business viability, which Cagan keeps separate. General confidence is not a risk at all; naming four questions is what replaces it. And whether someone can work out the interface is usability, which is answered by watching them try, whereas value is answered by watching them decide.
Remember this — value is about choosing, not about understanding, affording or building.
Sources — Marty Cagan on the four big risks, Silicon Valley Product Group.
Q3EasyCagan's opportunity assessment is a short list of questions a team answers before it commits to building. Which pair opens it?
- What problem this solves, and who has already agreed to buy it
- What problem this solves, and for whom that problem is solvedCorrect
- What the team built, and what it learned once the thing had shipped
- What problem this solves, and what the launch metrics later showed
Explanation
The principle — the assessment is a set of questions asked before effort is spent, not a report written after it.
Why the key is correct — Cagan's list opens with Exactly what problem will this solve? (value proposition) and For whom do we solve that problem? (target market) A team that cannot say what problem it is solving, and for whom, has nothing the rest of the list can build on.
Why the others are wrong — a signed-up buyer is a later commercial fact. Describing what was built turns the exercise into a retrospective, which is the one thing it is not. And launch metrics arrive after the decision the assessment exists to inform.
Remember this — the problem and the person come first, and both are answerable before anything is built.
Sources — Marty Cagan on assessing product opportunities, Silicon Valley Product Group.
Practise all 40 questions
Every published question in Product Discovery & User Research, with its answer and explanation.
- A director sends the team a list of changes he is certain users want. Under the Service Manual, what is that list?easy
- Among Cagan's four big risks, which question does value risk ask?easy
- Cagan's opportunity assessment is a short list of questions a team answers before it commits to building. Which pair opens it?easy
- Cagan's second discovery finding concerns the solution itself. Which three properties does he require it to have?easy
- In Torres's account of assumption testing, what does one test isolate?easy
- Marty Cagan describes product discovery as producing two separate findings rather than one verdict. What is the first of them?easy
- On Teresa Torres's opportunity solution tree, what is an opportunity?easy
- One of the questions in Cagan's opportunity assessment is why now. What is it asking a team to establish?easy
- Teresa Torres uses the term product trio. Who is typically in one?easy
- The Christensen Institute describes Jobs to Be Done as a lens. What does that lens reveal?easy
- The Nielsen Norman Group's finding about testing with five users has two halves. What are they?easy
- The Service Manual defines a user need. What does its definition tie a need to?easy
- The Service Manual sets one condition on who takes part in your research. What is it?easy
- What does Cagan's feasibility risk ask about?easy
- What does Teresa Torres's story-based interviewing keep the conversation anchored to?easy
- Where does the Service Manual put user research in a team's delivery cycle?easy
- A delivery team books a six-week research phase before the build starts and plans nothing after it. The researcher will run the sessions alone and present findings at the end. Which two things does the Service Manual ask for that this plan misses?medium
- A one-page proposal names the problem crisply and names the segment that has it. Asked why the company should build this year rather than three years ago, the author says the problem has always been there. Which of the assessment's questions is unanswered?medium
- A proposal claims there is no competition, because no company sells anything like what is being described. In research, the people with the problem are handling it today with a spreadsheet and a weekly calendar reminder. How does the assessment treat that?medium
- A team can describe in detail what it intends to build and why the design is elegant. Asked who the users are and what they need from the service, the room goes quiet. What does the Service Standard say about that position?medium
- A team can say what problem the feature solves, who has it, how big that group is and what those people use today. Nobody can say what would have to be true in six months for the feature to count as having worked. Which question is open?medium
- A team has a prototype that every tester navigates without help, and engineering has costed the build and signed it off. Nobody on the team can point to evidence that a person outside the company wants the thing. Which of Cagan's two discovery findings is still open?medium
- A team is drawing an opportunity solution tree for the first time. What belongs at the top, and what do the branches immediately beneath it hold?medium
- A team tests one assumption on its own and it fails. What does that give them that a failed prototype of the entire concept would not have?medium
- An organisation runs discovery by having a researcher interview customers alone and circulate a written summary to the product manager, the designer and the engineer. On Torres's account of the trio, what is missing?medium
- Customers in research are enthusiastic about a shared inbox for client messages. Support says it would make them accountable for disputes they cannot see, and legal flags the retention rules it would trigger. Which of Cagan's risks is this?medium
- Three things land in one week. A customer in a research session describes giving up on finding her renewal date and phoning instead. The head of sales says customers want a dashboard. Analytics shows two in five sessions ending on the account page. Which is a user need as the Service Manual defines it?medium
- Twelve of twelve participants complete your new sign-up flow in a usability session without hesitating once. Two weeks after launch, almost nobody starts it. What had the session actually established?medium
- Two ways of grouping the same customers are on the table: by company size and industry, or by what was happening in their work on the day they signed up. Which grouping does a jobs lens call for?medium
- You have an hour with a customer and two candidate openings: would you use a feature that summarised your week, or tell me about the last time you tried to work out what happened last week. Which does story-based interviewing call for, and why?medium
- You have budget for fifteen usability sessions on one product this quarter, and you can spend it however you like. What does the Nielsen Norman Group's advice point to?medium
- Your engineers report that the personalised feed would need a response time the current data pipeline cannot reach, and that rebuilding the pipeline is two quarters of work. Which risk has that answered, and what does it say about the rest?medium
- A team brings three things to a review: a usability session in which every participant completed the task, an engineering spike showing the work fits one quarter with existing tooling, and written sign-off from legal, finance and support. Which of the four risks is still open, and what would close it?hard
- A team builds a clickable prototype of an entire new onboarding concept, puts it in front of fifteen people, and eight abandon it partway through. In the debrief nobody can agree on why. Judged against Torres's account of assumption testing, what went wrong with the test design?hard
- A team presents a tree with ship the referral programme written at the top, and three branches beneath it: invite by email, invite by link, and reward tiers. Each branch is labelled an opportunity. In Torres's terms, what has gone wrong, and what would repair it?hard
- A two-page brief states the problem, names the segment that has it, asserts a large and fast-growing market, says there is nothing else like it, and closes with an engineering estimate. Judged against Cagan's opportunity assessment, what is the honest state of it?hard
- Churn has risen among customers who look identical on every attribute you record. Interviews surface two groups: teams that grew past the point where a single shared inbox worked, and sole traders whose accountant began asking for exports the product cannot produce. What does a jobs lens make of this?hard
- You are handed three things and asked which may be treated as established. In a research session a customer says she gave up looking for her renewal date and phoned instead. An executive says the product needs a dashboard. Analytics shows two in five sessions ending on the account page. How should each be classified?hard
- You are recruiting for research on a public-facing benefits checker. The delivery manager offers to fill the sessions from your own support team, who use the tool every day, and suggests screening by asking each participant whether they have a disability. What does the Service Manual say about the two proposals?hard
- You read back a transcript and every answer is a generalisation: I usually check on Mondays, I would probably use it for invoices, we tend to reconcile at month end. Judged against story-based interviewing, what has happened here, and what changes in the next session?hard
Frequently asked
What people ask about product discovery & user research.