Building the Right Thing vs Building the Thing Right

What Building the Right Thing Means

Building the right thing is product strategy. It is answering whether you should build something at all, who it’s for, and why they’d pay for it.

This is the discovery phase. You are validating assumptions about the problem, the market, and the user before you write code or design screens. You are talking to real people, watching how they work today, and testing whether your proposed solution fits their workflow.

Building the right thing requires staying in the problem space long enough to understand what people need, testing demand signals before you commit budget, and being willing to kill ideas that do not pass the evidence bar.

I worked with a scale-up who spent six weeks in discovery and ended up scrapping a third of their planned features before a wireframe was drawn. They shipped the remaining features, had 40 paying customers within the first three months, and broke even by six months.

What Building the Thing Right Means

Building the thing right is execution. It answers: can we build this well, ship it reliably, and maintain it without breaking?

This is the delivery phase. You are writing clean code, designing intuitive interfaces, setting up CI/CD pipelines, and ensuring the product performs under load. This is where engineering excellence lives.

The trap is that building the thing right feels productive. You can see progress. Tickets move across the board. Demos look impressive. Leadership sees activity.

If you are building the wrong thing, all that execution discipline just gets you to failure faster.

I have reviewed dozens of internal start-up teams where the tech leads were outstanding. They had automated tests, documentation, design systems, and proper staging environments. The products still failed because nobody had validated whether users would adopt them.

Why Teams Default to Execution Over Discovery

Discovery feels slow and uncertain. You are asking questions, not shipping features. It is harder to show progress in a sprint review. Delivery has clear metrics: velocity, burn-down charts, feature completion rates. Comparatively, speaking to 12 users and learning your core assumption is wrong does not fit neatly into a roadmap. Telling a senior developer to spend two weeks doing user research instead of coding feels like a waste of their skills.

The result? Teams skip straight to delivery, assume they have validated the idea because someone senior said it was important, and treat any user feedback post-launch as a feature request rather than a signal they might have built the wrong thing.

The Cost of Getting the Order Wrong

When you build before you have validated it, three things happen.

First, you waste money. The budget the founder spent on the whole project could have been smaller and split across three prototypes tested with real users. The evidence would have shown the idea did not work before serious budget was committed.

Second, you waste time. A six-month build cycle for a product nobody wants is six months you cannot get back. Competitors move. Market conditions shift. Your team burns out.

And last, you lose credibility. When you launch something that flops, the organisation loses trust in the product function. Future pitches get harder. Budget gets tighter. Good ideas get killed because the last one did not work.

I worked with an innovation team inside a financial services company. They had built and launched four products in 18 months. None had more than 200 users. All were technically solid. The problem? They had never validated demand before committing to builds. By the time I was brought in, the board was questioning whether the innovation unit should exist at all.

How to Know If You Are Building the Right Thing

Before you write a single line of production code, answer these:

• Who is this for? Not 'SMEs' or 'operations teams'. A specific person in a specific context doing a specific job.
• What problem does this solve for them? In their words, not yours. If you cannot repeat back the problem in the language they use, you do not understand it yet.
• How do they solve this today? Spreadsheets, emails, manual processes, a competitor product. If they are not solving it at all, ask why.
• Why would they switch to your solution? Better how? Faster? Cheaper? Less risky? What is the tangible benefit that justifies the cost of change?
• What evidence do you have that they will pay for this? Actual behavioural signals: they have a budget, they are already paying for a partial solution, they have tried to build it themselves.

If you cannot answer these with specifics, you are not ready to build.

One founder I worked with wanted to build an AI-powered scheduling tool for barbers and freelancers. In discovery, we found that most barbers and freelancers do not have a scheduling problem. The ones who did were already using Calendly and were not looking to switch. We killed the idea in week two. It saved four months and a lot of money: £60,000.

When to Shift from Discovery to Delivery

You do not stay in discovery forever. At some point, you have to build.

The shift happens when you have evidence (not assumptions) that the problem is real and painful enough that people will pay to fix it, your proposed solution is believably better than what exists today, and you can reach the target users who are ready to adopt something new.

This does not mean certainty. Product work is never certain. The balance of evidence should suggest you are solving a problem that matters for people who will use what you build.

Once you have that, execution discipline becomes essential. You need to build the thing right: test coverage, performance, security, maintainability. If you have validated demand and then ship a buggy, unreliable product, you will lose the users you worked hard to find.

The sequence matters. Discovery first, then delivery.

What This Looks Like in Practice

A health tech scale-up came to me with an idea for a patient engagement platform. They wanted to start building immediately. They had wireframes, a technical spec, and a three-month delivery plan.

We paused and spent four weeks in discovery, talking to 18 clinicians and 12 patients. We tested three different problem framings and learned that the original concept solved a problem the organisation cared about but patients did not.

We pivoted, focusing on a smaller, adjacent workflow that patients were already trying to solve with workarounds. We built a prototype in two weeks using no-code tools, tested it with five users, iterated, and tested again.

By the time we committed to a full build, we had 30 patients on a waitlist and three clinics ready to pilot. The product launched six weeks later. Adoption in month one was 78 per cent. Retention at month three was 65 per cent.

That only happened because we refused to jump straight to delivery.

The Harsh Truth About Discovery

Discovery is not popular. It does not generate the dopamine hit of shipping features, and it forces you to confront the uncomfortable truth that maybe your idea is not as good as you thought. It might be that the market is not ready. It might be that you are solving a problem that does not exist.

Most teams avoid discovery because they are afraid of what they will find.

Here is the alternative: you spend six months building the thing right, launch it, and discover the market does not care. Now you are out of time, out of budget, and out of credibility.

Discovery does not guarantee success. Nothing does. It dramatically improves your odds by ensuring you are aiming at the right target before you pull the trigger.

Validate demand before you commit budget. Stay in the problem space long enough to understand what people need. Test assumptions with real users, not hypothetical personas. Only then shift to execution.

If you are a founder, scale-up, or internal team struggling to figure out whether you are building the right thing, book an MVP Clarity Session. We will spend 90 minutes challenging your assumptions, clarifying your concept, and working out what you should actually build first.