What Does It Mean to Build the Right Product?

I've reviewed about 40 MVPs in the last year. Maybe 8 of them were actually solving problems people had explicitly asked for. The rest were clever solutions to problems the founder assumed existed.

This revealed something to me - not everyone knows why you should build products, and there’s a huge gap in that knowledge.

Building the right product means solving a problem that real people will pay to have solved, in a way they can adopt.

Most teams confuse ‘building the right product’ with ‘building the product right’. They're not the same thing.

Building the Product Right vs Building the Right Product

Building the product right is about execution. Clean code, good UX, reliable infrastructure, hitting deadlines. It's craft. It's important.

Building the right product is about direction. Are you solving a problem worth solving? For people who will actually use and pay for it? In a way that fits how they work?

You can build the product right and still fail completely. I've seen it dozens of times. Beautiful apps with zero users. Elegant platforms that nobody needed. Three months of perfect sprints pointed in the wrong direction.

The craft matters. But only after you've figured out where you're going.

The Three Questions Most Teams Skip

When I sit down with a founder or product team, I ask three questions. If they can't answer them clearly, they're not ready to build yet.

1. What specific problem are you solving?

The answer to this isn’t that ‘people need better project management’ or ‘teams struggle with collaboration’. That’s too broad. What exact moment of friction, frustration or cost are you removing?

The teams who can answer this question well usually describe a scene. For instance: “A product manager spends two hours a week chasing developers for status updates because Jira doesn't surface blockers automatically." That's a problem worth building for.

2. Who has this problem badly enough to pay for a solution?

Lots of people have minor annoyances, few people have problems painful enough to change their behaviour or spend money.

You need to find the people for whom this problem is in their top three. Not something that would be nice to fix. It needs to cost them time, money, opportunity or sanity.

If you haven't spoken to at least 10 people who've tried to solve this problem already (even badly), you don't know if it's real.

3. Why will they actually use what you build?

This is the adoption question. It's not enough to solve the problem. Your solution has to fit into how people already work.

I once watched a startup build a brilliant AI tool for compliance teams. The problem was real, the solution worked, but it required uploading sensitive documents to a third-party platform. The compliance teams wouldn't touch it for fear of data breaches.

They’d built the product right and validated the problem existed, but they hadn’t considered the ways of working and limitations of their audience.

Why ‘Just Ship It’ Advice Misses the Point

There's a lot of Silicon Valley advice about bias towards action. Ship fast. Iterate. Learn by doing.

It's not wrong, but it's incomplete.

Shipping fast only works if you're pointed in roughly the right direction. If your core assumption is wrong — the problem isn't real, the audience won't pay or your solution doesn't fit their workflow — you'll just iterate your way into a better version of something nobody wants.

I've seen founders ship three separate iterations of a product and still have zero traction. While they took the ‘ship and iterate’ advice literally, they forgot to speak to their users first.

The right sequence is validating the problem, testing the solution concept, then build and ship. Not build first and hope.

What Good Problem Validation Looks Like

You might be thinking that with all this talk of user validation, you need a six-month discovery phase or formal research. That’s not true either - you need structured conversations with people who have the problem you’re aiming to fix.

Here's what I look for:

• Specific stories. This needs to be more than a statement that something is hard. Look for real anecdotes that show the impact this problem has. For example: "Last Tuesday I spent 40 minutes trying to figure out why a feature was delayed because three people had different versions of the truth."
• Current workarounds. If they're not already trying to solve this, even in a rudimentary way, it's not painful enough.
• Willingness to change. Would they actually pay to switch tools and processes, or is this just something they complain about but live with? If the appetite to change isn’t present on an individual or systemic level, you’re unlikely to gain traction no matter how appealing your solution is.

If you can get 10 people to describe the same problem in their own words and at least half of them say they'd be willing to pay for a solution that worked, you're onto something.

If you can't, you're guessing.

The MVP Test: Could You Build This in Four Weeks?

Once you've validated the problem, the next question is scope.

I use a simple test: if you couldn't build a testable version of this in four weeks (or less), your scope is too big.

That doesn't mean ship a half-broken product. It means ruthlessly cut everything except the core problem and the simplest possible solution.

Most founding teams add features because they're worried the product won't be "good enough" without them. The opposite is true. Every feature you add before you've validated the core makes it harder to learn what's actually working.

Build the smallest thing that solves the problem in a way someone would pay for. Test it. Then decide what to add next based on what you learn.

When to Kill an Idea (And Why That's Success, Not Failure)

Here's the thing nobody will say out loud: building the right product sometimes means not building at all.

In the last six months, I've told three founders not to build their idea. Their ideas weren’t bad, but the evidence said the problems weren’t painful enough.

They didn't like hearing it, but in each case killing the idea early saved them three to six months and tens of thousands of pounds they would have wasted building something nobody wanted.

That's what building the right product actually looks like. It's making the hard call based on evidence, not hope.

TL;DR

Building the right product means solving a real problem, for people who will actually pay for it, in a way they can adopt. Most teams skip the validation, ship fast and wonder why nobody cares.

The teams that succeed ask three questions before they build: What specific problem are we solving? Who has it badly enough to pay? How will they adopt the solution?

If you can't answer those, you're not ready to build yet. And that's fine. Figuring out the right direction is faster and cheaper than building the wrong thing beautifully.

Want to test if your product idea is actually solving the right problem? Grab the MVP Cost Clarity Toolkit — it walks you through the exact validation questions I use with founders before we start any build.