Product Discovery & Customer Research: Finding Out Before You Build

You describe your idea to ten friends. Nine say it sounds great, one asks when it will be ready. You build it for six months, launch, and almost nobody uses it. Nobody lied on purpose. Your friends were being kind, answering a question about a future they could not picture, about a product that did not yet exist, to someone they like.

Teams that ship things people keep using do something earlier and less glamorous. Before they commit to building, they find out whether a real person has the problem, how badly, what they do about it today and what would make them change. That work is product discovery. It borrows from ethnography, interaction design, psychology and statistics, and it is mostly a set of habits for not fooling yourself.

This piece describes methods that practitioners use; the interactives use invented products and invented numbers, labelled as such.

Talk about their life, not your idea

Rob Fitzpatrick's short book The Mom Test (2013) starts from a joke: even your mother will say your business idea is good, because she loves you. The fix is not a cleverer way to ask "do you like it?". It is to stop asking that kind of question. His rules, in plain words: talk about their life instead of your idea; ask about specifics in the past instead of generics or opinions about the future; and talk less and listen more.

Why the past? People are poor at predicting what they will do, and often poor at explaining why they did what they did: the psychologists Richard Nisbett and Timothy Wilson reviewed this in a well-known 1977 paper, "Telling more than we can know". "Would you use this?" asks for a prediction and a compliment at once. "Tell me about the last time you did this" asks for a memory, which has details you can check: when, with whom, what they tried, what it cost, what went wrong.

A good interview also listens for what people do rather than what they say. Someone who has already paid for a workaround, built a spreadsheet, or asked a colleague for help has shown you the problem is real. Someone who says "that would be great" has shown you they are polite. Fitzpatrick calls compliments, vague promises and unprompted feature requests noise to be deflected, and treats a real commitment (time, an introduction, money) as the signal.

Without JavaScript, the pairs are: "Would you use an app to split bills?" becomes "Tell me about the last time you shared a bill: what happened?"; "Would you pay $10 a month?" becomes "Have you paid for anything to solve this before, and what did it cost?"; "I'd definitely buy that!" becomes a request for a next step, such as an introduction or a trial.

Jobs to be done: people hire products to make progress

The jobs-to-be-done idea says customers do not buy a product for its features; they "hire" it to make progress in a particular situation. Clayton Christensen and colleagues popularised the framing in the early 2000s and set it out for managers in Competing Against Luck (2016) and a September 2016 Harvard Business Review article, "Know Your Customers' 'Jobs to Be Done'". Anthony Ulwick developed a related but different method, outcome-driven innovation, which lists the measures by which customers judge success at a job and rates each for importance and satisfaction; he described it in HBR in 2002. The two camps disagree about how to define a job and how to measure it, and both have critics who find the idea hard to apply without a lot of interpretation. As a discovery habit it is useful regardless: ask what the person was trying to get done, not who they are.

A job has a situation ("when I land late in a city I do not know"), a motivation ("I want to reach the hotel without being cheated") and an outcome ("so I can sleep"). Notice what is missing: age, income and hobbies. Two people with different demographics can have the same job, and one person has different jobs on different days. Interviewers using this approach (Bob Moesta and Chris Spiek teach one in Demand-Side Sales 101, 2020) rebuild the switching story: the first thought that something was wrong, the searching, the deciding, and the moment they changed. They look at four forces: the push of the old situation, the pull of the new idea, the anxiety about the new thing and the habit of the old one.

A real example of a job found by watching use rather than by planning: in October 2005 Safaricom and Vodafone began a pilot of M-PESA in Kenya, funded in part by a UK Department for International Development challenge fund, with microfinance loan repayment in mind. Customers also used it in other ways, and after complications with the microfinance partner the service was refocused on sending money and making payments before its commercial launch in March 2007. What people were actually hiring it for shaped the product.

Without JavaScript: with push 6 and pull 5 against anxiety 4 and habit 6, forces for change total 11 and forces against total 10, so the customer is only just ahead. This is a thinking aid with equal weights, not a measured model.

The toy is honest about what it is: invented scores on a made-up scale, with equal weights. Its point is practical. If a customer is not switching, you can lower anxiety (a free trial, an import tool) as well as raise pull (more features), and the cheaper lever is often anxiety or habit.

The opportunity solution tree: from outcome to experiment

Interviews produce a flood of stories. Teresa Torres, in Continuous Discovery Habits (2021), proposes a way to keep them organised: the opportunity solution tree, which she has taught since 2016. At the top is one outcome, the business need your team can move (for instance, more new customers still active after a month). Below it are opportunities: customer needs, pain points and desires you heard about, which would drive that outcome. Below each opportunity are several candidate solutions, and below each solution the assumption tests that would show whether it deserves to be built.

The tree enforces two disciplines. First, you choose which opportunity to pursue before you fall for a solution, so you do not tie every customer complaint to your pet feature. Second, each opportunity gets several candidate solutions to compare, so the first idea does not win by default. A tree also gives you a visible record of what you chose not to pursue. Torres suggests that the product trio (a product manager, a designer and an engineer) build and revise it together, and that it is revisited as interviews continue.

Without JavaScript, the example tree is: outcome "More new users still active after 30 days"; opportunity "I can't tell which plan fits me", with solutions "Plan quiz" and "Side-by-side comparison"; opportunity "I forgot why I signed up".

Assumptions: what must be true, and how little we know

Every idea rests on assumptions. Marty Cagan's list of product risks is a handy sorter: will anyone want it (value), can they use it (usability), can we build it (feasibility), and does it work for the business (viability)? Other authors group the same questions as desirability, feasibility and viability, which is the form David Bland and Alexander Osterwalder use in Testing Business Ideas (2019). Assumption mapping plots each assumption on two axes: how important it is (if false, the idea fails) and how much evidence you have. The top-left corner, important and with little evidence, is where to test first.

Teams often do the reverse: they test what is easy, such as whether a page loads, and avoid what is frightening, such as whether strangers will lend a power tool to someone they met online. The map makes that visible.

Without JavaScript: of the nine invented assumptions, four are important with little evidence (lending to a stranger, a deposit, enough tools nearby at launch, and a cheap way to insure damage), so those are tested first.

Cheap tests: paper, wizards and fake doors

Once you know what to test, pick the cheapest test that could prove you wrong. A rough ladder, from cheapest: a paper sketch or clickable mock-up (tests whether people understand it); a concierge test, where you deliver the service by hand to a few customers; a Wizard of Oz test, where the interface looks real but a person behind it does the work (the researcher John F. Kelley named the method in the early 1980s while working on natural-language interfaces); a landing page or fake door, a button for a feature that does not exist yet, which measures clicks; and finally a thin real build. The further down, the more it costs and the closer to behaviour you get.

Fake doors carry ethical limits. Clicking a button is a weak commitment, so a click rate shows interest, not demand. Taking payment, or collecting more personal data than you need, for something you cannot deliver crosses from testing into misleading people. Good practice is to tell people straight away that the feature is not ready, offer to notify them, and keep only what you need. Data-protection law applies to test participants too: the EU's GDPR (in force since 25 May 2018) and Brazil's LGPD, among others, require a lawful basis for collecting personal data, and recording an interview is collecting it, so ask first.

Small numbers mislead. If 3 of 40 visitors click, the rate is 7.5%, but the true rate could plausibly be anywhere from about 3% to 20%. The toy below shows a 95% Wilson interval, a standard way to put a range on a proportion.

Without JavaScript: 12 clicks from 200 visitors is 6.0%, with a 95% interval from about 3.5% to 10.2%; 3 clicks from 40 gives about 2.6% to 19.9%.

Synthesis: how many interviews, and what to do with them

After a round of interviews you have notes, quotes and surprises. Synthesis means finding patterns: write each observed behaviour or quote on its own note, group notes that belong together (the affinity method that Jiro Kawakita popularised in Japan in the 1960s as the KJ method), and name each group by the need underneath it, not by the feature people asked for. Keep a record of what people did and said, apart from your interpretation, so a colleague can disagree with you.

How many interviews are enough? There is no single number. In a well-known 2006 study in Field Methods, Greg Guest, Arwen Bunce and Laura Johnson coded 60 interviews with women in West Africa and found that new themes had mostly stopped appearing after 12, with most of the main ones visible after six, in a fairly uniform group asked about one topic. Later work on more varied, cross-cultural samples suggested larger numbers (20 to 40) were needed, so treat 12 as a starting point for one segment. Each segment you care about needs its own round.

A simple model shows the logic. If a fraction p of your customers have a problem, and you interview n of them chosen without bias, the chance of hearing about it at least once is 1 − (1 − p)ⁿ. A problem shared by 30% of customers is heard in five interviews 83% of the time; a problem shared by 5% will usually be missed, which is a reason to follow interviews with a survey or usage data once you know what to count (see 36/98).

Without JavaScript: at a 20% share, five interviews hear the problem at least once with probability 67%, and about 11 interviews are needed for 90%.

The model assumes the people you reach are like the people you do not. They rarely are: those who answer a cold email tend to be keener than average. That is why discovery sampling matters as much as sample size.

A weekly habit, and a template to start with

Torres's central argument is about rhythm: teams that interview customers only at the start of a project learn once, while teams that talk to a customer every week keep their picture current and make smaller bets. Her book recommends weekly touchpoints by the team that is building the product, with small research activities fitting into the week. The alternative, a large research project that finishes after the decisions are made, is common and costly.

Not every context suits the same habit. Business-to-business products may have few customers and long sales cycles. Hardware has long lead times, so tests use prototypes. In regions where many customers are not online or do not speak the team's language, discovery may mean field visits, local-language interviews and a researcher from the community. Teams in São Paulo, Nairobi or Jakarta build for different payment methods, phones and trust, so imported assumptions need testing before they are believed.

Without JavaScript, copy the template's headings by hand: learning goal, who, opening, past-behaviour questions, commitment ask, and a grid of who / what they did / job or need / surprise.

What a graduate just sees

• "Would you use this?" asks for a compliment and a prediction; "tell me about the last time" asks for a memory.
• What someone has already paid, built or worked around is stronger evidence than what they say they would do.
• Customers hire products for jobs in situations; demographics describe people, not what they are trying to do.
• If someone is not switching, look at anxiety and habit as well as at missing features.
• Choose the opportunity before the solution, and compare several solutions for it.
• Test the assumption that is both important and unproven, not the one that is easy.
• A click is a weak commitment, and a small sample gives a wide range.
• Twelve interviews are a start for one uniform segment, not a law; each segment and each context needs its own.

Where it shows up next

• Product Strategy, Roadmaps & Prioritization (36/97): the opportunities you find here are what the roadmap chooses among, and your confidence scores should come from evidence like this.
• Product Metrics & Experimentation (36/98): a fake door and an interview tell you what to measure, and an A/B test settles it at scale.
• UI & UX Design (36/75): once a solution is chosen, usability tests on a prototype find where people get stuck.
• Marketing Research & Analytics (34/59) and Product Innovation & Go-to-Market (34/63): surveys, segmentation and why good products still fail.
• In the world: a payments team in Nairobi watching how people send money, a founder asking a shopkeeper about the last week's stock-outs, a hospital app team shadowing a nurse.

If you want to go deeper

• 📘 Textbooks. Teresa Torres, Continuous Discovery Habits (Product Talk, 2021), the standard practitioner text on weekly interviews and opportunity trees; and Erika Hall, Just Enough Research (A Book Apart, 2nd edition, 2019), on research methods for people who are not researchers.
• 📘 Gentler. Rob Fitzpatrick, The Mom Test (2013), a short book on the interview rules in this piece; and Christensen, Hall, Dillon and Duncan, Competing Against Luck (2016), for jobs to be done.
• 🌐 Free resources. User Interviews 101 (Nielsen Norman Group); Product Talk on opportunity solution trees; and IDEO.org's Field Guide to Human-Centered Design (free PDF).