Before building the first version of a product, talk to at least 10 people who genuinely experience the problem you want to solve. The goal is not to pitch your idea or collect compliments; it is to understand how people currently handle the problem, what frustrates them, what they already pay for, and what they would actually need from a solution.
Use these conversations to design the initial product specifications with real users, then document every useful contact, insight, objection, and follow-up opportunity. Those people can become your earliest testers, customers, referral sources, or advisors when the product moves from an idea to something people can use.
Why 10 Conversations Can Change Your Product Direction
A product idea can look compelling from the founder’s perspective because the founder already understands the problem and has imagined a solution. Potential users see something different. They may describe the problem differently, solve it with an unexpected workaround, or consider a feature essential that the builder never considered.
Ten conversations create enough qualitative evidence to reveal recurring patterns without turning early discovery into an expensive research project. You are looking for repetition: the same pain points, similar workflows, common objections, recurring language, and consistent outcomes people want.
The objective is not statistical certainty. Early customer discovery is about reducing the risk of building something technically impressive that solves a problem people do not consider important enough to change their behavior for.
Who You Should Talk To
The quality of your conversations depends heavily on who you choose. Ten random people are less useful than ten people who regularly encounter the problem your product is designed to address.
Prioritize people who are close to the problem:
- Current users of competing solutions: They can explain what works, what does not, and what they wish existed.
- People using manual workarounds: Their spreadsheets, notebooks, messages, and improvised processes can reveal unmet needs.
- People who recently experienced the problem: Their memory of the situation is usually more concrete than hypothetical opinions.
- Potential buyers or decision-makers: If someone else will pay for the product, you need to understand their criteria as well as the end user’s needs.
- Experienced practitioners: They can expose edge cases and requirements that beginners may overlook.
Avoid relying exclusively on friends, family, or people who already want to encourage you. Supportive feedback can feel useful while providing very little evidence of genuine demand.
What to Learn From Each Conversation
A productive conversation should uncover behavior rather than simply opinions. Asking, “Would you use an app that does this?” invites speculation. Asking, “How did you handle the last time this happened?” gives you evidence.
Focus your questions on the person’s existing reality:
| Discovery area | What to investigate | Why it matters |
|---|---|---|
| Problem | What happened and how often? | Establishes whether the problem is real and recurring |
| Current solution | How do they solve it today? | Reveals existing alternatives and competitors |
| Friction | What is slow, expensive, confusing, or frustrating? | Identifies opportunities for improvement |
| Consequences | What happens when the problem is not solved? | Measures practical importance |
| Prior attempts | What products or methods have they tried? | Shows what has already failed or succeeded |
| Desired outcome | What would a better solution accomplish? | Defines the result users actually value |
| Constraints | What would prevent adoption? | Exposes technical, financial, operational, or behavioral barriers |
| Buying behavior | Who chooses and pays for solutions? | Helps shape the business model and sales strategy |
Ask About What People Have Done, Not What They Say They Would Do
Hypothetical questions are one of the biggest weaknesses in early product research. Someone may enthusiastically say they would download, recommend, or pay for a product without ever taking that action.
Past behavior is stronger evidence.
Instead of asking, “Would you use a tool that automatically manages this?” ask, “What did you do the last time you had to manage this?” Follow that answer with questions about time, cost, frequency, frustrations, and alternatives.
If someone says they would pay $20 a month, ask what they currently spend to solve the problem. If they say the problem is urgent, ask when it last caused a meaningful consequence. The purpose is not to challenge the person; it is to distinguish genuine pain from polite enthusiasm.
Turn Conversations Into Initial Product Specifications
Do not let interviews become a collection of interesting anecdotes. Translate recurring findings into concrete product requirements.
For example, if several people repeatedly describe manually transferring information between two systems, the specification might include an integration or import workflow. If they consistently say they need approval before an action occurs, the product may require permissions and review controls rather than full automation.
A useful specification should connect each major feature to a demonstrated user need:
User problem → observed behavior → desired outcome → product requirement → success measure
This approach prevents the feature list from becoming a collection of assumptions.
Separate Must-Haves From Nice-to-Haves
Not every request deserves a place in the first version. Users will often suggest features that sound valuable but are unrelated to the central problem.
Group findings into three categories:
- Essential: Without it, the core problem remains unsolved.
- Useful: It improves the experience but is not necessary for the initial solution.
- Later: It may become valuable after the core product proves demand.
This creates a smaller initial specification and gives you a defensible reason to say no to distracting feature requests.
Keep a Contact and Insight Log
The contact list is not administrative clutter. It is part of your product-development infrastructure.
Record each person’s name, role, relevant experience, date of conversation, key problems discussed, important quotes or observations, product suggestions, objections, and whether they agreed to future contact. Also note whether they appear suitable as an early tester, customer, expert adviser, or referral source.
Keep the information organized and permission-based. Do not collect unnecessary personal information, and do not assume that agreeing to an interview means someone has agreed to receive marketing messages.
A simple discovery record might look like this:
| Contact | Problem observed | Current workaround | Key requirement | Follow-up |
|---|---|---|---|---|
| User A | Repetitive manual task | Spreadsheet | Automated workflow | Prototype test |
| User B | Difficult information retrieval | Messaging colleagues | Searchable records | Interview again |
| User C | High error rate | Manual checking | Validation | Early-access invite |
| User D | Slow approval process | Approval workflow | Prototype feedback |
Look for Patterns Across the 10 Conversations
One person’s suggestion is an observation. A repeated pattern deserves more attention.
After every few conversations, review your notes and identify recurring themes. You might discover that eight people struggle with the same task, six use a similar workaround, five mention the same competitor, and four describe the same consequence when the problem goes unsolved.
Those patterns should influence the next version of your specifications.
However, repetition alone is not enough. A frequently mentioned problem may still be too minor to motivate adoption. Give greater weight to problems that are frequent, costly, frustrating, time-consuming, risky, or currently underserved.
Bring Users Into the Specification Process Without Letting Them Build the Product
“Design the product with users” does not mean allowing every interviewee to dictate the roadmap. Your responsibility is to synthesize what you learn.
Users are experts in their experiences. You are responsible for turning those experiences into a coherent product.
Ask them to react to workflows, prototypes, priorities, and outcomes rather than simply asking them to invent features. This makes the conversation more concrete and helps reveal whether the proposed solution actually fits their behavior.
The same principle becomes increasingly important as software becomes more autonomous. When products involve AI agents that can take actions rather than merely provide information, understanding exactly what users expect the system to do—and what they expect it never to do—becomes part of the specification. The discussion of AI agents gaining access to real systems and creating a new security front line illustrates why capabilities, permissions, and boundaries need to be considered early.
Treat Safety, Trust, and Control as Product Requirements
Some products need more than functional requirements. If your solution handles sensitive information, makes recommendations, connects to external systems, or acts autonomously, trust requirements should be discovered alongside user needs.
Ask questions such as: What would you allow the system to do automatically? What actions should require confirmation? What information should it never access? What would make you stop using it? How would you want mistakes to be detected and reversed?
These questions can materially change the initial architecture. They also matter as AI systems increasingly operate as active participants online rather than remaining passive software tools; understanding how AI agents are evolving into internet actors provides useful context for why autonomy changes the product-design equation.
Keep the 10 People Close to the Product
The strongest outcome of customer discovery is not simply a better specification. It is the beginning of a relationship with people who have a reason to care about whether the product succeeds.
When you have a prototype, invite relevant contacts to test it. When you change a workflow, ask the people who originally described the problem whether the new approach makes sense. When you reach an important milestone, reconnect with the people who gave you early insight.
Not everyone will become a customer, and not everyone needs to remain involved. But the people who consistently provide thoughtful feedback can become a valuable early-user group.
Use the Conversations to Decide What Not to Build
Customer discovery should eliminate ideas as well as create them.
If repeated conversations reveal that a proposed feature is rarely needed, difficult to explain, or disconnected from the main pain point, remove it from the initial specification. If users consistently solve a problem adequately with an existing tool, investigate whether your product offers a sufficiently meaningful improvement before investing heavily.
This discipline is especially important when the technology itself is exciting. A technically possible feature is not automatically a valuable feature.
Repeat the Process After the First Prototype
Ten conversations should be the beginning of the discovery cycle, not the end.
Once people can interact with an early prototype, their feedback becomes more concrete. They can identify confusing screens, missing workflows, incorrect assumptions, unnecessary steps, and trust barriers that are difficult to uncover in conversation alone.
The cycle becomes:
Talk → document → identify patterns → define requirements → prototype → observe usage → revise → talk again.
That feedback loop turns customer discovery from a one-time validation exercise into an ongoing product-development system.
The Real Value of Your First 10 Conversations
The first ten people do more than help you improve a feature list. They can expose whether the problem is significant, reveal the language customers use to describe it, identify existing alternatives, clarify what the first version must accomplish, and show you where your assumptions are wrong.
Most importantly, documenting those relationships gives you a living network to return to as the product evolves. The people who helped shape the initial specifications can become the first people you ask to test the prototype, challenge the next version, and tell you whether you are solving the problem you originally set out to solve.
For products involving autonomous systems, that discipline becomes even more important because product decisions can extend beyond convenience into security and societal consequences. Exploring what researchers mean by existential AI risk and potential humanity-level consequences can help founders place those design decisions within a broader risk conversation.