Your team is about to build a new feature. How much are you betting without knowing if anyone will use it? We see it every day: startups burning budget on unvalidated features, with the accountant crying (and we know that because we come from accounting).
We, at Meteora Web, learned the hard way: when you build software for real clients, every unvalidated line of code is a cost that doesn't come back. That's why product discovery is not a luxury for agile gurus: it's the first tool to keep your company's finances healthy.
In this operational guide we go straight to the core of discovery: user research through interviews and how to turn results into a problem statement that drives decisions. No abstract theory – only what works in real projects (and that we've tested with clients from retail to B2B).
Why most interviews fail (and how to avoid it)
The most common mistake: treating the interview like a survey. You ask: "Would you like a feature that does X?" The answer is almost always yes, but it means nothing. People want to be polite, and their intentions don't match behaviors.
The approach we use: contextual interviews based on past experiences. Ask not what they would like, but what they actually did. Example: instead of "Would you like a system that alerts you when a product drops in price?", ask: "Tell me about the last time you looked for a discounted product. How did you do it? How much time did you spend? What made you give up?"
This type of question yields real data, not opinions. And real data is what we need to calculate the ROI of product decisions.
The 3 rules for interviews that work
- Don't talk about your product. Ever. The interview explores the problem, not the solution. If you mention your idea, you'll bias the answer.
- Ask for stories, not hypotheticals. "Tell me about the last time you…" triggers specific memories with behavioral and contextual details.
- Be silent. After a question, wait. Most people need a few seconds to organize their thoughts. If you interrupt, you lose depth.
We applied these rules in a project for a fashion e-commerce startup (remember? we managed the ERP of a clothing store). Interviews with buyers revealed that their real problem was not "finding new suppliers" but "evaluating sample quality within tight deadlines." That discovery completely changed the roadmap and saved months of development.
User research interview template (copy and use)
Here's a basic script we use. Customize it for your context, but keep the structure.
# Discovery interview script (15-20 min)
1. Introduction: "Thank you for your time. The goal is to understand how you experience [problem area]. There are no right or wrong answers."
2. Opening question: "Tell me about your role and what you do every day." (builds context)
3. Specific experience: "Tell me about the last time you faced [problem situation]."
4. Details: "What exactly did you do? How long did it take? What worked and what didn't?"
5. Emotions: "How did you feel during that process?"
6. Alternatives: "What else have you tried to solve this problem?"
7. Closing: "Is there anything I didn't ask that you think is important?"From interview chaos to the Problem Statement
After 10-15 interviews you have mountains of notes, audio, transcripts. How do you extract a problem statement worth developing? Here our accounting background kicks in: you need to quantify.
An effective problem statement answers three questions:
- Who is the target user? (not demographic, but behavioral: "the fashion buyer who needs to evaluate 10 samples per week")
- What specific problem do they face? (not "bad experience", but "they don't have a fast way to compare quality and price across physical samples")
- What impact does this problem have? (costs, lost time, missed opportunities – with real numbers if possible)
Example of a well-written problem statement:
"Fashion buyers managing multiple suppliers spend on average 4 hours per week comparing physical samples, with a 15% error rate in qualitative assessments. This delays purchasing decisions and costs the company approximately €12,000 per season in missed opportunities."
See the difference? It's not vague. It's measurable. And because it's measurable, you can decide if solving it is worth the investment. We always do this: before developing anything, we calculate the cost of the problem for the client. If it doesn't exceed the development threshold, the problem is not a priority.
How to build your problem statement (step by step)
- Collect all interview notes and look for recurring patterns. Use a spreadsheet or a tool like Miro (but pen and paper work too).
- Identify the most frequent context: in what situation does the problem manifest? E.g., "during pre-season sample selection."
- Quantify frequency and impact: how many people, how many times, how much time/cost? Use the stories you collected: if 8 out of 10 interviewees mentioned the same delay, you have a data point.
- Write the problem statement in one sentence following the structure: [User] has [problem] causing [impact].
- Validate it with a couple of interviewees: "We understood your problem is this, correct?" If they nod, you're on the right track.
Common mistakes in product discovery (and how to avoid them)
After over 8 years on projects, we've seen the same mistakes repeat. Here are three that cause the most damage.
Interviewing only enthusiastic early adopters
If you only talk to people who already love your product, you'll only find out how to improve it, not whether the broader market wants it. We always aim to include at least 30% non-users or ex-users. They tell you why they left.
Stopping after 3-4 interviews
A typical mistake for startups with tight budgets. A few interviews can give false confidence. Saturation – when no new patterns emerge – usually occurs between 10 and 15 interviews. We aim for at least 12.
Turning the problem statement into a solution
"The problem is they don't have an app to compare samples." No. The problem is that manual comparison takes too long. The app is just one possible solution. If you start with the solution already in mind, you close the door to better ideas. We've seen it happen: a client wanted to build a B2B portal, but after interviews the real need turned out to be a simple digital checklist on WhatsApp. They saved 6 months of development.
Practical tools for discovery
You don't need a big-tech budget. Here's what we use daily:
- Audio/video recording: Otter.ai or simply Zoom recording (with consent). Listening to pauses and tones is often more important than words.
- Automatic transcription: Whisper (open source) or services like Rev. Transcripts allow you to search for keywords and patterns.
- Affinity map: Miro or a physical whiteboard. Group emerging themes and look for connections.
- Problem statement template: we created a simple Google Doc with the structure: "For [user] who [context], the [problem] is important because [impact]." Use it and share it with your team.
In summary – what to do now
- Plan 12 interviews with real users (including non-customers). Use the script template above.
- Conduct the interviews without ever talking about your solution. Listen for stories, not opinions.
- Analyze the patterns and write a quantified problem statement for the most recurring problem.
- Validate it with at least 2 interviewees.
- Decide if the problem is worth investing in. If yes, move to solution definition. If no, go back to discovery.
We, at Meteora Web, use this process every time we start a new project – for an e-commerce, a proprietary platform, or a simple brochure site. The right product is built first in the interviews, then in the code. And code costs money, so better get it right the first time.
For more on how product management methodologies connect to digital strategy, check out our article on Meta's AI customer agent used to hack Instagram accounts – an example of how unvalidated problems lead to security risks. If you want to understand how to protect your stack while building your product, read the attack on GitHub repos to steal AI developer passwords.
Sponsored Protocol
