Product discovery for a small team building with AI agents

Product discovery is the work of finding out what is worth building, and whether it will work, before you commit to building it.

TL;DR

• When agents build fast, being wrong gets cheaper to ship and no cheaper to carry. Discovery is where you avoid that.
• Talk to a customer every week about what they did, not what they would like. Keep the quote.
• Test the riskiest guess first, then rank what survives against your bets.

When to use it: before any job that takes more than an afternoon, and whenever you are guessing at why a customer wants something. When not: skip a full discovery pass for a bug, a small fix or a change a customer has already described in detail.

What is product discovery?

Marty Cagan, who writes at SVPG, prefers "product discovery" to "requirements and design" because it names two things you must learn: whether real users want the product, and whether you can find an answer that is usable, useful and feasible. He calls it a creative process, "more art than science."

Teresa Torres, who wrote Continuous Discovery Habits, puts it simply: if you are continuously making decisions about what to build, you need to stay continuously connected to your customers.

For the short definitions, see product discovery and continuous discovery.

Why does discovery matter more when AI agents do the building?

Because the cost that fell is the cost of building. The cost of being wrong did not.

• A wrong feature still has to be carried. It stays in the codebase, in the docs, in support and in every later change.
• Speed multiplies the error. You can be faster at building the wrong thing, and ship three of them before a customer replies to the first.
• Customers did not get faster. A useful conversation takes the same hour it did before coding agents. See customer interview.

So the constraint moves. The question stops being "can we build it" and becomes "should we, and for whom."

What does a discovery loop look like for a small team?

Five steps, once a week. It does not need a team of specialists.

1. Talk to one customer. Ask about the last time they hit the problem. See the script below.
2. Write down what happened. The exact words, the account, the date. Not your summary.
3. Look for the pattern. Is this the third account to describe it? Group matching requests. Do not count one loud user as a trend.
4. Name the riskiest guess. What must be true for this to work?
5. Test it cheaply. Ask five more customers, show a sketch, or have an agent build a rough prototype behind a flag. Then decide.

Which risks should I test first?

Cagan lists four risks in his article on the four big risks:

With coding agents, feasibility is the cheapest to test. Start with value. Most wasted work was built well for a problem nobody had.

How do I run a good customer conversation?

• Ask about the past. "Tell me about the last time you did this" gives you evidence. "Would you use a feature that did this?" gives you a polite guess.
• Listen for stories. Torres calls her version an interview snapshot: a week-by-week record of one specific customer story, rather than direct questions like "what do you want?"
• Do not pitch. Rob Fitzpatrick's The Mom Test is about asking questions that give you real information rather than encouragement, even when people are not fully honest with you.
• Look for what they already do. A workaround, a spreadsheet or money spent shows the problem is real.
• End with who else. "Who else has this problem?" is the cheapest way to find the next conversation.

How does discovery turn into a decision?

Discovery gives you evidence. A decision is still yours. Put the evidence on the row, then rank it. Use this order inside your bets: what is broken, then what customers asked for, then ideas. See prioritization frameworks and idea management software.

If you have no customers yet to ask, use the same loop with people who have the problem: the founders in your community, a past colleague, someone who answered your post.

A customer interview script

Use this script. Keep it open while you talk and fill in the notes straight after.

Discovery conversation (30 minutes)

Before: write the one thing you want to learn. [e.g. How do they decide what to build next?]

1. Open (2 min)
   "Thanks for the time. I am not selling anything. I want to hear how you work."

2. Their context (5 min)
   - What do you do, and what are you trying to get done this quarter?
   - Which tools do you use for it today?

3. A specific story (15 min)
   - Tell me about the last time you [did the thing].
   - What happened first? What happened next?
   - What was hard? What did you try?
   - What did it cost you: time, money, a customer?
   - What do you do about it now?

4. Dig on the strong parts
   - You said [their words]. Can you say more?
   - Have you looked for something to fix this? What did you find?

5. Close (3 min)
   - Who else has this problem?
   - Can I come back to you when I have something to show?

Do not ask: "Would you use this?" "Do you like the idea?" "How much would you pay?"

After the call (5 min), write down:
   Name and account:
   Date:
   Their exact words (3 quotes):
   What they did, not what they said they would do:
   What they already pay or work around:
   How strong, 1-3 (1 = polite, 3 = they asked to hear when it exists):
   Riskiest guess this changes:
   Next step:

Send yourself the notes the same day. A conversation not written down is gone by Friday.

How does Annsa do it?

Annsa is AI agent management, and the source of direction for your agents. A person makes the call.

• Evidence comes in from Slack, Intercom, call transcripts, surveys (six templates), CSV and Google Sheets imports, GitHub, typed by hand and an API. Each request keeps the customer behind it, their exact words, the account and its revenue.
• Matching requests are grouped, so you can see the third account saying the same thing.
• Priorities are ranked within your bets, in your order. What a person marked broken comes first, then what customers asked for, then ideas.
• Each priority has a spec: the why, the evidence and Done When lines. Your agent, or Ask, writes it. Claude Code, Cursor, Codex and Grok read it over MCP, so what you learned in discovery reaches the agent building the work.
• When a job ships, Annsa drafts a note to each person who asked. You send it.

Annsa does not run your interviews. It keeps what you learn attached to the work. See Choose what to build and feedback.

Sources

• Marty Cagan, Product Discovery and Four Big Risks, Silicon Valley Product Group.
• Teresa Torres, Continuous Discovery and Continuous Discovery Habits, Product Talk.
• Rob Fitzpatrick, The Mom Test.