Validating Product Ideas

What Do People Need?

Needs are the ground floor of a product, and the worst way to learn them is to ask people what they want. People cannot reliably describe a need for something that does not exist yet, and they answer to be helpful rather than accurate.

Experience sampling

The method that works is experience sampling: prompt real people, repeatedly and at random moments over days, to log what they are doing, feeling, and struggling with right then. Captured in the moment, needs surface as they actually occur, not as someone reconstructs them later in an interview.

Because the data is collected in context and over time, it catches the frustrations and small unmet needs people forget by the time you sit them down. It trades one tidy interview for many honest fragments of real life.

For a product manager, the reframing is to stop mining opinions in a conference room and start capturing needs in the wild. A need someone reports in the moment it bites is worth far more than a wish list they generate on the spot when you ask.

Who Are the Users?

Most teams already have personas, and most of those personas are fiction, built from assumptions, stereotypes, and wishful thinking. Sharon bluntly calls the starting version a BS persona: a hypothesis, not a fact.

From assumption to evidence

The fix is cheap. Write down your assumption personas honestly, then run around ten in-person interviews with real people in the target group. Use what you hear to confirm, correct, or delete each assumption, until the persona reflects actual behavior and motivation rather than what you hoped.

Ten conversations sounds small, but patterns repeat quickly, and the goal is not statistical proof. It is to stop designing for an imaginary person and start designing for one you have actually met.

For a PM, the discipline is to treat every persona as a claim that must survive contact with real users. Before a roadmap leans on a segment, ask whether anyone has actually interviewed ten of them, or whether the segment is a story the team told itself.

How Do People Currently Solve a Problem?

Before you design a solution, understand the one people already use, because they are always solving the problem somehow, even if badly. That current workaround is the real competition.

Watch, do not just ask

The reliable method here is observation: watch roughly eight people tackle the problem in their natural setting, and document the routines, shortcuts, and workarounds they never think to mention. What people say they do and what they actually do routinely diverge, and only watching closes the gap.

Synthesize across sessions with affinity diagramming, clustering the raw observations into themes, so patterns emerge from many small notes rather than from one memorable anecdote.

For a PM, the lesson is to fall in love with the problem, not your solution, and to go see the problem being solved today. The clumsy spreadsheet or the sticky note on a monitor is telling you exactly which job your product has to beat.

What Is the User's Workflow?

A feature rarely lives alone; it sits inside a longer sequence of things a person does to get a job done. Miss the surrounding workflow and you can build a good feature that fails because it does not fit the flow around it.

Diary studies

Diary studies map that sequence: participants log their relevant activities over days or weeks, then sit for a concluding interview. From the entries you reconstruct the real, step-by-step workflow, including the parts that happen away from your product entirely.

The value is seeing the handoffs and gaps, the moment before your product enters and the moment after it exits, where much of the friction actually lives.

For a PM, this argues for designing the whole path, not the isolated screen. Knowing the three steps before and after your feature often reveals that the real improvement is smoothing a handoff, not polishing the moment your product owns.

Do People Want the Product?

Wanting is different from needing, and you can test it before building. Surveys are useless here, because people cannot judge their appetite for something that does not exist, so you measure behavior instead.

Concierge and fake doors

Two experiments do the work. A concierge MVP delivers the value by hand to a few real customers, the way Zappos founders first bought shoes in stores and shipped them to prove people would buy shoes online. A fake-door test puts up a button or page for a feature that does not exist yet and measures how many people try to walk through it.

The discipline that makes these valid is setting a pass/fail threshold in advance. Decide what click-through or conversion would count as real demand before you run the test, so you cannot rationalize the result afterward.

For a PM, this is permission to answer the scariest question, will anyone want this, for the price of a landing page. Run the smoke test with a number decided up front, and let behavior, not the loudest stakeholder, greenlight the build.

Can People Use the Product?

A product people want can still fail if they cannot use it. Usability testing answers whether real people can complete real tasks, and it does not require a lab or a big sample.

The rainbow spreadsheet

Recruit a handful of representative users, give them realistic tasks, and watch where they stumble. A small group exposes most of the serious problems. To analyze fast, Sharon uses a rainbow spreadsheet: a shared sheet where each observer is a color and findings are logged live as sessions run, so patterns are visible immediately.

The collaborative sheet turns analysis from a lone researcher's report weeks later into a team activity finished the same week, which is what keeps the research lean.

For a PM, the takeaway is that usability feedback is cheap and fast enough to run continuously. Five users and a shared spreadsheet can de-risk a flow this sprint, so there is no excuse for shipping a confusing experience and calling the confusion a training problem.

Which Design Generates Better Results?

When two designs both seem reasonable, opinion should not decide; the users already visiting your product should. A/B testing serves each variant to a slice of real traffic and compares them on a metric that matters.

Decide the rules first

The rigor is in the setup, not the running. Define the metric, the minimum effect worth acting on, and the confidence level before you start, and let the test run long enough, ideally at least a week, to cover normal variation in behavior. Then read the result you agreed to read.

The common failure is peeking and stopping the moment a variant looks ahead, which manufactures false winners. Predefining the stopping rule is what separates a real experiment from a flattering coincidence.

For a PM, this is the guardrail on data-driven design. Agree on the metric and the stopping rule before the test goes live, so the outcome settles the debate instead of each side mining the dashboard for a number that supports the design they already preferred.

How Do People Find Stuff?

Users cannot use what they cannot find, so navigation and information architecture deserve their own tests, separate from how a page looks.

Tree testing and first click

Tree testing strips away visual design and asks people to locate items in a bare menu structure, isolating whether the structure itself works. First-click testing checks whether people's very first move heads the right way, since a wrong first click strongly predicts failure. A lostness metric quantifies how far they wander.

Because these run on the structure alone, they tell you whether a findability problem lives in the information architecture or in the visual design, two very different fixes.

For a PM, the practical move is to test the tree before the paint. If users fail on the bare structure, no amount of visual polish will save them, and you have learned that cheaply, before a single screen is designed.

How to Find Participants for Research?

Every method in the book depends on one unglamorous step that quietly sinks most research: finding the right people to study. Good participants are the difference between insight and noise.

Screeners and where people already are

The approach is systematic. Define the exact criteria for a qualified participant, build a short screener questionnaire that filters people in or out, and post it where your target users already gather, relevant groups, hashtags, and communities on social platforms. Then schedule the ones who qualify.

Treating recruiting as a repeatable pipeline, rather than a panic each time, is what lets a team actually sustain continuous research instead of doing it once and stopping.

For a PM, the insight is that research capacity is really recruiting capacity. Invest once in a screener and a list of where your users hang out, and every future study starts from a running start rather than from zero.

The Entire Book in One Framework

The book is a lookup table for uncertainty. Name the question you are actually stuck on, need, identity, current behavior, workflow, demand, usability, comparison, or findability, and each maps to one cheap method that answers it before you overbuild.

Underneath every chapter is the same conviction: watch what people do rather than trust what they say, decide your success measure before you look, and learn as early and as cheaply as possible. Research is not a phase before launch; it is how you retire risk one question at a time.

Lean user research is not about doing more studies. It is about matching the smallest possible study to the exact question blocking your decision, and letting behavior answer it before you build.

10 Most Important Takeaways

• Every product decision reduces to a specific question, and each question has a cheap method that answers it.
• Trust what people do over what they say; avoid surveys about products that do not exist yet.
• Learn what people need by experience sampling, capturing needs in the moment rather than in an interview.
• Turn assumption-based personas into real ones with about ten in-person interviews.
• Understand the current solution by observing people, not just asking, because workarounds go unmentioned.
• Map the full workflow with diary studies, since your feature lives inside a longer sequence.
• Test demand before building with a concierge or fake-door MVP and a pass/fail threshold set in advance.
• Five users and a rainbow spreadsheet expose most usability problems quickly and collaboratively.
• A/B test with the metric, effect size, and stopping rule decided before the test runs.
• Recruiting the right participants is the real bottleneck, so build a repeatable screener-based pipeline.

The deepest idea is that you almost never have to guess. Whatever you are unsure about, someone has already worked out a fast, inexpensive way to watch real people answer it, and the only question left is whether you will run the test before or after you have wasted the build.