Topic 5 — Discovery — understanding users

Goal: Learn to find real problems worth solving before jumping to solutions.

Lesson 5.1 — Fall in love with the problem, not the solution

In a Monday standup, Lumi's CEO leans back and says, "We should add an AI assistant. Everyone's doing it." The room nods. Maya feels the pull to nod too, then catches herself with a quiet question she's been learning to ask first.

What problem would an AI assistant actually solve, and for whom?

Nobody in the room can answer cleanly. That gap is the whole point of Discovery — the stage of the product lifecycle from Topic 3 where you test an idea against reality before anyone builds it.

Most beginners fall for their first solution. "Let's add a chat feature!" feels like progress, so they run with it. But a wrong solution to a real problem is fixable. You ship it, watch users struggle, and adjust. A beautiful solution to a problem nobody has wastes everything: the months, the team, the goodwill. There's no fixing it, because there was no problem underneath.

So good PMs slow down at the start and get attached to the problem instead. The problem is the durable thing. The solution is a guess that will change.

Fall in love with the problem, not your solution.

Maya's first idea is always a guess. Discovery is how she finds out whether the guess is worth chasing.

Lesson 5.2 — How to actually talk to users

The most powerful discovery tool is also the cheapest: talking to users. Maya doesn't need a budget or a lab. She needs a few good conversations and a handful of rules, because most interviews go wrong in the same predictable ways.

• Ask about the past, not the future. "Tell me about the last time you tried to export your spending into a spreadsheet" reveals what someone really did. "Would you use an export feature?" invites a polite lie, because people are terrible at predicting their own behavior.
• Ask open questions, then go quiet. Silence feels awkward. Sit in it. People fill the gap by elaborating, and the second half of what they say is usually the honest half.
• Dig into the why. When someone mentions a frustration, ask why. Then ask why again. The real problem is usually a couple of layers below the first complaint.
• Don't pitch. Maya is there to learn, not to sell. The moment she starts defending her idea, the interview stops teaching her anything.

Five honest conversations will teach her more than a month of guessing in a meeting room.

Lesson 5.3 — The questions that lie to you

Maya tries out a question on a Lumi user: "Would a one-click export save you time?" The answer comes back warm and fast. "Sure, I guess." She writes it down, feeling validated.

She shouldn't.

That was a leading question — one that plants the answer she was hoping for. Almost nobody says "no, that sounds useless" to a friendly PM's face. So she walks away with confidence in an idea that no real behavior supports. False confidence is worse than no confidence, because it makes her build.

Watch the same curiosity asked two ways:

Leading	Neutral
"Would a one-click export save you time?"	"Walk me through the last time you needed to get data out of the tool. What did you do?"
"Sure, I guess."	Reveals what really happened, including whether export is even a real pain.

The fix is to anchor every question in real, specific, past behavior, and let the user's actual experience supply the signal instead of her hopes.

When a transcript comes back wall-to-wall "yes," get suspicious, not happy. Honest discovery kills ideas all the time, and that counts as a win. Killing a bad idea in a thirty-minute interview beats killing it after a three-month build.

Lesson 5.4 — What is the user actually hiring you to do?

People don't buy a quarter-inch drill because they want a drill.

They want a quarter-inch hole. And really, they want a shelf on the wall. The drill is just one way to get the shelf up. That little chain is the heart of Jobs to be Done (JTBD): people "hire" a product to get a job done in their life, and the job is the goal, not the feature.

Framing the job keeps Maya pointed at what the user is trying to accomplish rather than at the feature she happens to be excited about. It also surfaces competitors she'd never have listed. Think about a food-delivery app. Its real rivals aren't only other delivery apps. They include cooking, frozen meals, and the restaurant down the street, because all of those also do the job "feed me tonight without much effort." Name the job, and the better solutions and the real rivals come into focus.

Lesson 5.5 — Validate before you build

Everything in Discovery serves one goal: reduce the risk of building the wrong thing before Maya spends the team's real time and money. Interviews are one way to do that. There are cheaper ones too.

• Look at existing data. What are users already doing, or quietly abandoning? Lumi's slow loading screen showed up as a spike in drop-offs before a single person complained out loud.
• Run lightweight tests. A fake "coming soon" button that measures how many people click it. A rough prototype. A landing page describing a feature that doesn't exist yet. (These connect to experimentation in Topic 10.)
• Look for patterns across sources. One user's complaint is an anecdote. The same problem from many users, backed by data, is a signal worth acting on.

The discipline is gathering enough evidence that a problem is real and worth solving before committing the team to build. Maya will never reach perfect certainty. Discovery reduces risk; it doesn't erase it. But a PM who validates cheaply ships far fewer wasted features than one who builds on a hunch and hopes.

Worked example — Killing a beloved idea (and saving months)

Maya is convinced Lumi should add a "social feed" so users can compare budgets with friends. She loves the idea. She's already sketched it.

Before building, she runs discovery. She asks ten users to walk her through their last busy week of tracking spending — past behavior, no leading. Not one mentions wanting anything social. What they mention, again and again, is losing time hunting for old transactions and receipts. When Maya gently floats the social idea without pushing it, reactions are lukewarm at best.

The job users are hiring Lumi for isn't "connect with my friends." It's "help me find my stuff fast." So Maya drops the social feed and reframes the roadmap around search. Sam, the engineer who never moves on opinion alone, is sold the moment she shows him the pattern across all ten conversations.

Discovery just saved months of building something users didn't want, and pointed straight at something they did.