The Product SystemThe Vault
Customer Discovery for Product Managers: 5 Habits That Matter More Now Prototypes Are Cheap, the infographic in this PDF

Product management

Customer Discovery for Product Managers: 5 Habits That Matter More Now Prototypes Are Cheap

Five customer discovery habits for product managers, from the outcome sentence before you prototype to reading real sessions before you trust evals.

Want this as a PDF?

You'll also get The Product System, my weekly note on leading product in the AI era. Unsubscribe anytime, and I'll never sell your email. How I handle your details

1

The full infographic, as a PDF

The exact one from the post, sized to print or keep within reach.

2

A copy in your inbox

The download link lands in your email too, so it's there when you need it. No follow-up campaign.

3

The Product System, weekly

My note on leading product in the AI era. One idea a week that compounds. Unsubscribe anytime.

PMs avoid customer calls like kryptonite. AI just made that the most expensive habit.

I'd argue talking to customers matters more than ever now that prototypes are cheap. Building the thing used to be the slow, costly part. Now a working prototype can take an afternoon. The harder decision has moved. It is whether what you are building solves something customers care about.

Customer conversations give you the why. Prototypes can tell you the what, but they cannot tell you the why. A prototype shows you whether someone can use a thing. Only a conversation tells you whether they needed it in the first place.

And customer attention is finite. It is the one resource AI cannot give you more of. You can generate ten prototypes this week, but not ten more hours of a customer's time. So the craft of customer discovery is now the scarce skill, and it comes down to a handful of habits. Here are five, and what each one looks like in practice.

Write the outcome down before you prototype

Before you open any tool, write one sentence: what changes for the customer, and how you will see it.

The order matters. Once a prototype exists, it starts to argue for itself. It looks real, people react to it, and the conversation turns into feedback on the screen rather than the problem underneath. Writing the outcome first gives you something to hold the prototype against.

If you cannot write that sentence yet, you are not ready to prototype. That is not a failure. It is a signal that the next step is another customer conversation, not another build.

Find the pain before you copy a feature

AI makes copying a competitor easy. It does not make it the right thing to build.

A feature that works for someone else's customers solved someone else's problem. Before you copy it, find out whether your customers have that problem at all, and what it costs them.

The way in is to ask about the last time the customer faced the problem. Not what they would want, and not what they think of the competitor's version. Ask what they were trying to accomplish, and what they did instead. The workaround tells you how much the pain matters. If they shrugged and moved on, the feature is a nice idea. If they built a spreadsheet or lost an afternoon to it, you have found something worth solving.

Book two customer calls every week

Discovery that happens once a quarter is research. Discovery that happens every week is a habit, and the habit is what keeps your judgement current.

Two calls a week is a small, fixed number you can protect in a diary. In each one, ask about a recent time they faced the problem. What set the problem off? Where did they get stuck? What did they do instead?

Recent and specific beats general and hypothetical. A question about the future invites a guess. A question about last Tuesday gets you what happened.

The test is simple. A week with no customer calls is a week of building blind.

Write one line before every prototype test

Before every prototype test, finish this sentence: "If this fails, it's because ___."

That line forces you to name the assumption most likely to make the idea wrong. It might be that customers will not trust the output, or that their current workaround is good enough.

The reason to write it down first is what happens after a failed test. If the test fails and you do not know which assumption failed, you have not learned what to fix. You just know it did not work, and the next version is a guess. Naming the riskiest assumption up front turns a failed test into a clear next step.

Read real sessions before you trust an eval score

If you run an AI feature, the eval score is tempting. It is one number, and it fits on a slide. It also only measures what someone thought to test for.

So read the sessions. Pick 10 conversations people had with your AI feature this week. Mark where they got stuck, and whether their need was actually met.

You will see things no score shows you, like the point where someone gave up, or the answer that was technically correct and no help at all. When you find a failure no eval caught, write one that would. Each new eval keeps the suite tied to what customers experience, rather than to what the team expected.

Cheap prototypes raise the cost of skipping discovery

All five habits point the same way. They put the customer's why in front of the build, so the speed AI gives you goes somewhere useful.

AI made features easier to copy. It did not give customers more time or attention. That changes the maths of skipping discovery. When building was slow, a wrong idea took a long time to build, and that cost forced a pause to check. When building is fast, the pause disappears, and the wrong idea just ships sooner.

I'd argue the PM who skips discovery is not building more. They are just wrong faster.

The fix is not a big research programme. It is one sentence before the prototype, two calls a week, one line before each test, and ten sessions read before the dashboard. Pick one of the five and try it tomorrow.

Questions people ask

What is customer discovery for product managers?
Customer discovery is the work of finding out whether a problem is real and worth solving before you build for it. For a product manager, it means regular conversations with customers about specific, recent moments when they faced the problem, what they were trying to do, and what they did instead. It gives you the why behind a product decision, which a prototype alone cannot.
Why do product managers avoid customer calls?
Customer calls take time to book, and they can reveal that a favoured idea solves a problem nobody has. Building feels like progress, and talking can feel like delay, especially now that AI makes prototypes so fast. That makes skipping discovery an easy habit to slide into, and an expensive one to keep.
How often should a product manager talk to customers?
A practical baseline is two customer calls every week. A small, fixed number is easy to protect in a diary and keeps your judgement current, rather than relying on a research round once a quarter. In each call, ask about a recent time the customer faced the problem, what set it off, where they got stuck, and what they did instead.
Does AI prototyping replace customer discovery?
No. AI makes prototypes cheap, which raises the value of discovery rather than replacing it. A prototype can show whether someone can use a thing, but only a customer conversation tells you whether they needed it. Customer attention stays finite however fast you can build.
What should you write down before testing a prototype?
Write one line: "If this fails, it's because ___." Fill the blank with the assumption most likely to make the idea wrong. If the test then fails, you know which assumption to revisit, so a failed test becomes a clear next step instead of a guess.
Should you trust eval scores for an AI feature?
Treat an eval score as a partial view, because it only measures what someone thought to test for. Each week, read around 10 real conversations people had with the feature and mark where they got stuck and whether their need was met. When you find a failure no eval caught, write a new eval that would catch it.