You Solved the Right Problem. But Did You Solve It Well?
- Chris Burgess
- Jul 18, 2024
- 5 min read
Updated: Oct 13
A practical guide for founders, startup teams, and product leaders who discovered the problem but want to get the right thing into users’ hands faster.
Building software is risky. The best way to reduce that risk is to keep learning after you’ve started building. Once you know who your users are and what problem you’re solving, the next challenge is figuring out how well your product actually solves it.
If you’ve ever launched something that users said they wanted but still didn’t adopt, you already know how important this step is. Product discovery at this stage isn’t about choosing what to build, it’s about learning whether what you built delivers on its promise.
If you’re a founder, PM, or early team member, product discovery helps you test your assumptions, measure how well your solution solves the problem, and adjust before you scale.
Customer Discovery vs. Product Discovery
People often use these terms interchangeably, but they’re actually different stages of learning.
Customer discovery is about who you’re building for and why they care. It’s about validating the problem, not the product. You’re asking questions like:
Who is my target user?
What problem are they really trying to solve?
Is this problem painful enough that they’d pay for a solution?
Product discovery, on the other hand, starts once you’re confident about the problem and audience. It’s about how to solve it, exploring what the right solution might look like, how it should work, and what value it creates.
A simple way to think about it:
Customer discovery validates the problem.
Product discovery validates the solution.
If you skip customer discovery, you risk building a great product that nobody needs. If you skip product discovery, you risk building the wrong version of the right idea.
Three Ways to Learn How Well You’ve Solved the Problem
When you’re past customer discovery and moving into product discovery, I’ve seen teams approach learning in three main ways:
Share a prototype
Run a beta
Go straight to general availability (GA)
Each approach offers a different level of feedback, realism, and risk.
1. Prototype: Learn Fast, Guide Closely
A prototype is an early, rough version of your product that helps you test the concept before you build for real. It’s not about UX polish or performance; it’s about learning if your idea makes sense to users.
Because prototypes aren’t fully functional, users usually need more hand-holding. You’ll spend more time explaining context and observing how they interpret what they see. Their confusion is valuable because it helps you understand whether your concept is clear.
Why it works:
You get early feedback before writing serious code.
You validate ideas cheaply and quickly.
Watch out for:
It requires more facilitation. Users might struggle without context.
You won’t learn much about real-world UX yet. That comes later.
Prototypes are for validating clarity, not usability. Keep them light, focused, and fast.
2. Beta: Test the Experience, Not Just the Idea
A beta is your chance to see how users engage with a nearly complete version of your product. At this stage, you’re not validating the problem anymore, you’re learning how people use your solution.
Closed beta: You handpick users who fit your target audience. This lets you observe behavior directly, ideally without giving instructions. The goal is to see where users struggle or succeed on their own.
Open beta: Anyone can sign up. This gives you a wider range of feedback, but it’s harder to manage and can produce noisy data.
Why it works:
You see how users behave in realistic settings.
You start gathering genuine UX and engagement insights.
Watch out for:
Closed betas can bias behavior if you guide users too much.
Open betas can overwhelm you with feedback that’s inconsistent or irrelevant.
Betas are about observation and learning, not direction. Let people explore as that’s where real insight lives.
3. General Availability (GA): Launch and Listen
General availability means your product is live for everyone. It’s the full release, but it doesn’t mean you stop learning, and it doesn't mean development stops.
At this stage, you often get the least direct feedback. Users don’t schedule calls to tell you what’s wrong, they just leave or churn quietly. That’s why instrumenting analytics, usage tracking, and lightweight feedback loops is so important.
Why it works:
You get real-world usage data at scale.
You move fast and can find product-market fit sooner.
Watch out for:
Bugs or friction can hurt your reputation fast.
Without active feedback loops, you may fly blind.
GA isn’t the end of discovery. It’s the point where user behavior replaces user interviews as your feedback engine.
My Take: Go Live Early, But Stay Disciplined
I’m a big believer in the Minimum Viable Product (MVP) approach, but I’ve learned that the discipline around discovery matters more than the framework itself.
Here’s my playbook:
Prototype: Build it fast. Spend no more than two person weeks creating it, and give yourself no more than two weeks to test it. At this stage, your goal is to validate the concept, not polish the UX. Keep it scrappy, focused, and decisive. If you’re still tweaking after two weeks, you’re overthinking it.
Closed beta: Only run one if you can get at least ten customers to participate, and make sure the testing and feedback cycle is complete within two weeks. Closed betas are great for direct observation, but the value disappears if they drag on or lack structure.
Open beta: Do it only if you can guarantee a feedback loop. Set clear deadlines and expectations for users. An open beta without structured feedback is just a soft launch with no learning.
Now, about general availability (GA). I love it because it forces progress. It gets things shipped. But it can also be emotionally tough when feedback dries up. That’s why doing your customer discovery first is critical. If you already know you are solving a real problem, the lack of noise after launch will not shake your confidence, just track the data. And remember, just because it is GA does not mean you cannot still invite users into your office to observe how they use it. Watching people interact with your live product often reveals things analytics cannot.
At that point, the question shifts from “Does this solve a problem?” to “How well does it solve it?” and “Do we communicate that clearly enough to make people care?”
That is the heart of product discovery: balancing speed, structure, and empathy for the people you are building for.
Final Thought
Discovery isn’t a step you do before “real” work starts. It’s a mindset you keep all the way through.
Whether you’re sketching a prototype, running a beta, or launching your first version to the world, the goal is the same: learn how well your product solves the problem — and keep improving until it does.
Product discovery is hard to get right, but when you do, it changes everything about how you build and learn.
If you want help strengthening your discovery process or validating your next release, contact me at info@crwburgess.com
Comments