How to Know What Product to Build Before You Start Building
Most product failures don't happen because the technology was bad. They happen because the team built something customers didn't need, didn't understand, or weren't willing to pay for.
The most expensive product decision is not how you build it. It's deciding what to build in the first place.
Start With the Problem, Not the Product
A common mistake is starting with a solution. Someone has an idea for an app, SaaS platform, marketplace or AI product and immediately starts thinking about features, technology and design.
Instead, start by understanding the problem. A strong product usually solves a problem that is frequent, painful, expensive or difficult to solve with existing solutions.
5 Questions to Answer Before Building
Who has the problem?
Define the specific customer. Avoid targeting "everyone." Understand who experiences the problem most frequently and who is actually responsible for solving it.
What problem are they actually facing?
Don't describe the problem as a feature request. Understand what is currently slow, expensive, frustrating, manual or unreliable for the customer.
How are they solving it today?
Your biggest competitor isn't always another software product. It could be spreadsheets, WhatsApp, email, manual processes, outsourced teams or simply doing nothing.
How important is the problem?
A problem can be real without being important enough to pay for. Find out how much time, money or opportunity the problem currently costs the customer.
Why would they choose your solution?
You need a clear reason for customers to switch from their existing solution. Better speed, lower cost, easier workflows, better outcomes or a completely new capability can create that reason.
Talk to Customers Before Writing Code
Customer conversations are one of the fastest ways to test whether your assumptions are actually true.
Instead of asking: "Would you use this product?" ask about their current behaviour.
- How do you solve this problem today?
- What is the most frustrating part of the process?
- How often does this happen?
- What does this problem cost you?
- Have you already tried solving it?
- What would make you change your current process?
Validate the Business Model Too
A product can solve a genuine problem and still fail as a business. Before building, understand who pays, what they are paying for and whether the economics can work at scale.
Your early validation should therefore cover both product desirability and business viability.
Don't ask only, "Can we build it?" Ask, "Should we build it, who needs it, and why would they pay for it?"
Define the MVP Around the Core Problem
Once the problem is validated, resist the temptation to build everything. Your first version should solve the core problem as simply as possible.
An MVP is not a smaller version of your final product. It is the fastest version that allows you to test whether your fundamental product assumption is correct.
Build With Evidence, Not Assumptions
The best product decisions come from combining customer research, business goals, market understanding and technical feasibility.
Before development starts, you should be able to clearly explain:
- Who the product is for
- What problem it solves
- Why the problem matters
- How customers solve it today
- Why your solution is different
- What the first version needs to prove
- How success will be measured
The Goal Isn't to Build Faster
Building faster doesn't help if you're building the wrong thing. The real advantage comes from reducing uncertainty before investing heavily in design, development and infrastructure.
Good product strategy creates clarity before execution begins. It helps teams spend less time building features and more time creating something customers actually value.
Have a product idea but don't know where to start?
We help businesses validate ideas, define product strategy, structure MVPs and turn business problems into technology products.
Talk to Odylabs →
