What Is 'Build the Right Thing' in Product Management?

Most product failures are not because code is bad or a design is ugly. They happen because the team built something nobody wanted.

The phrase 'build the right thing' describes the strategic, discovery-led phase of product work. It is the part where you figure out what problem you are solving, for whom, and why it matters. It comes before you write a single line of code or draw a single wireframe.

This is not about shipping faster or executing better. Those things matter, but they only matter once you know you are building something worth building. 'Build the right thing' is the filter. It is the hard work of asking questions, testing assumptions, and being willing to hear uncomfortable answers.

I have worked with founders and internal teams for over 20 years. The pattern is consistent: teams that skip this step waste months building features nobody asked for. Teams that do it well ship less, but what they ship lands.

The Difference Between Build the Right Thing and Build the Thing Right

These two phrases sound similar, but they describe completely different phases of product work.

'Build the right thing' is about strategy and discovery. It is problem-led. You are asking: what problem are we solving? Who has this problem? How do they solve it today? What would make them change? What evidence do we have that this is worth solving?

'Build the thing right' is about execution and delivery. It is solution-led. You are asking: how do we architect this? What technology should we use? How do we design the interface? How do we ship this quickly and reliably?

Most teams are good at the second part. Developers know how to write code. Designers know how to create interfaces. Product managers know how to write user stories and run sprints.

The first part is harder. It requires you to slow down before you speed up. It means talking to users before you build for them. It means being willing to kill ideas that do not hold up under scrutiny.

Here is the test: if you removed the product and asked whether the underlying problem would still exist, what is the answer? If the problem disappears without your solution, you are probably solving a technology problem, not a user problem.

Why Teams Skip This Step

I see three recurring reasons why teams jump straight to building without doing the discovery work first.

The first is pressure. Founders have raised money and need to show progress. Internal teams have been given a brief and a deadline. There is a board meeting coming up or a pitch to a big client. Shipping something feels like progress. Sitting in a room asking questions does not.

The second is confidence. Someone senior has decided this is the right thing to build. They have domain expertise or industry experience. They have seen the problem themselves. The team assumes the discovery has been done when it hasn’t even begun.

The third is impatience. Discovery feels slow. Talking to users, mapping workflows, testing assumptions — none of this produces a tangible artefact you can demo. Building does. So teams skip ahead to the part that feels productive.

The irony is that skipping discovery makes everything slower. You build the wrong thing, launch it, get no traction, add more features, still get no traction, then either pivot or give up. I have watched this cycle play out dozens of times.

The teams that do discovery first might ship later, but at least they ship things that work.

What 'Build the Right Thing' Involves

There is a clear process, and it does not take months. Start with the problem, in one sentence. Then ask: who has this problem? How often do they encounter it? What do they do about it today? If the answer is 'nothing', you need to understand why. Apathy is a bigger competitor than any other product.

Talk to real people who experience the pain you want to solve. Ask them to show you how they handle it today. Listen for the language they use to describe the problem.

Most problems do not exist in isolation. They sit inside a process or a job to be done, so map those too. If you do not understand the surrounding context, you will build something that solves one small part of the problem and creates three new ones.

Test your assumptions before you build. You don’t need a working product — you can use prototypes, landing pages, or even simple explainer videos. The goal is to find out whether people would use what you are planning to build.

Define what success looks like. Not revenue or user numbers — those are outcomes. Define the behaviour change you expect to see.

How Do You Know If You're Building the Right Thing?

There is no single test, but there are clear signals:

• Users can articulate the problem without prompting. If you have to explain the problem to them, they do not have it. Real problems are obvious to the people who experience them.
• People are already trying to solve it. Look for workarounds, spreadsheets, manual processes, or clunky tools they have cobbled together. These are evidence that the problem is real and painful enough to warrant effort.
• Your solution maps cleanly to an existing workflow. You are not asking people to change their entire process. You are slotting into something they already do and making one part of it easier.
• Early users come back. Not because you are chasing them, but because they have integrated your product into their routine. Retention is the clearest indicator that you have built something people need.

If you do not have these signals, you are probably building the wrong thing. Most first ideas are wrong. The question is whether you are willing to acknowledge it and adjust before you have spent six months and tens of thousands of pounds building something nobody wants.

When 'Build the Right Thing' Gets Ignored

I worked with a founder last year who had built a scheduling tool for consultants. He had spent four months building it. The interface was clean. The code was solid. He launched it on Product Hunt and got 200 sign-ups. Within two weeks, 190 of them had churned.

When we unpacked it, the problem was obvious. He had built a solution for a problem he thought consultants had, not one they told him they had. He assumed they needed better scheduling because his own calendar was a mess. What he discovered — too late — was that most consultants were happy with their existing tools. They were not looking for a replacement.

He had skipped discovery. He had not talked to users before building. He had not tested the concept. He had built the thing right, but he had not built the right thing.

The same pattern shows up in internal teams. A product manager gets a brief from leadership to build a feature. They do not challenge the brief. They do not talk to users. They just execute. Six months later, the feature ships. Nobody uses it. The PM is frustrated because they delivered what was asked for, but nobody asked whether the brief was right in the first place.

How to Introduce This Thinking to Your Team

If you are working in an organisation that does not do discovery, you cannot change everything overnight. Start small.

The next time you get a feature request, ask three questions before you write a user story: What problem does this solve? Who has this problem? How do we know?

If the answers are vague, push back gently. Suggest talking to five users before scoping the work. Frame it as de-risking the build, not slowing things down.

If you are a founder, block out two weeks before you start building. Use that time to talk to potential users, map their workflows, and test your assumptions. It will feel slow. It will feel unproductive. Do it anyway.

If you are hiring a product person or a fractional leader, look for someone who asks uncomfortable questions. The best product people are not the ones who ship the fastest. They are the ones who stop you building the wrong thing in the first place.

Want help figuring out what to build before you start building it? Download the MVP Cost Clarity Toolkit to get a structured framework for scoping your first version without wasting time or money.