Luke Moody
Get in touch
InsightsProduct
Product

Your MVP is not your product strategy

Luke Moody5 March 20266 min

There's a mistake that happens consistently with first products, and it's understandable enough that it's worth naming clearly.

A founder builds an MVP. It gets some traction. People sign up, maybe pay, and the founder takes that signal as confirmation that they've found the thing — the product, the market, the direction. They accelerate. They build more features. They double down on everything that exists.

Months later, growth has stalled. The product has become harder to explain. The users who stayed are using it differently than intended, and the ones who left left quietly without saying why.

The mistake wasn't building the MVP. The mistake was treating it as a strategy.

What an MVP is actually for

A minimum viable product answers one specific question: is this problem real enough, and is this solution credible enough, that people will take an action to engage with it?

That's it. It doesn't tell you who your best users are. It doesn't tell you which feature drove retention. It doesn't tell you whether the positioning is right or whether you're in the right market. It tells you that something is worth exploring further.

The MVP is the start of the learning process, not the end of it.

The moment strategy actually begins

Strategy starts after contact with real users. Not hypothetical users. Not friends who were polite about the demo. Users who found the product independently, chose to use it, and then either stayed or left.

That cohort tells you things the MVP never could:

Where the friction actually is. Not where you assumed it would be. The things users struggle with are rarely the things founders worried about while building.

What they ignore. The features you were proud of that nobody uses are data. They're telling you something about the gap between what you built and what users actually need.

What they come back for. The part of the product that creates a return visit is almost always the seed of the real product strategy. Whatever that is, it deserves more investment. Everything else deserves scrutiny.

How they describe it. Listen to how users explain your product to others. If their language is different from yours, their version is probably more accurate. It's closer to the problem as they actually experience it.

Why founders skip this step

Building feels like progress. Gathering signal feels like pausing.

There's also a psychological dimension: looking closely at how users actually behave means confronting the gap between what you imagined and what you built. That gap is always uncomfortable. It's easier to add the next feature than to sit with the evidence that the last one didn't land the way you expected.

But the founders who skip the signal-gathering phase pay for it later. They build products that are coherent in a pitch and confusing in reality. They optimise for metrics that don't connect to retention. They build for the user they imagined rather than the user they have.

What to do after the MVP

The work after an MVP is investigation before acceleration. Specifically:

Talk to the users who stayed. Not a survey — a conversation. Why did they come back? What problem does this solve for them, in their words? What would they miss if it went away tomorrow? These conversations are worth more than any analytics dashboard.

Look at behaviour, not just outcomes. Signups and revenue are outcome metrics. Behaviour metrics — where users go, what they click, where they stop — tell you why those outcomes are happening. Both matter.

Identify the smallest version of the real product. Based on what you've learned, what is the most valuable thing you could build right now? Not the most ambitious. The most valuable. That becomes the next version — built from evidence, not assumption.

Cut what the evidence doesn't support. This is the hardest part. Features that took weeks to build and that nobody uses are still candidates for removal. A focused product is easier to explain, easier to maintain, and easier to sell than a complete one.

The strategy question the MVP can't answer

There's a question that every product eventually has to answer: who is this for, really?

The MVP might give you a hint. But it won't give you a definitive answer, because MVPs attract early adopters — a group that is systematically different from the mainstream users who will determine whether the product reaches scale.

Early adopters tolerate rough edges. They fill in gaps with imagination. They use products that aren't finished yet because they want what the product might become, not what it currently is.

Building a strategy around early adopter behaviour is a trap. What keeps an early adopter engaged is often different from what will attract and retain the user you actually need to build a sustainable business.

The MVP validates the problem space. Strategy requires understanding the specific users you can serve best — and being willing to be honest when those users aren't who you initially imagined.

The version of this that applies to Clubase

I built Clubase because I watched my son's football coach managing everything through WhatsApp and a folder of handwritten notes. That was the problem I understood.

The MVP answered the narrow question: would grassroots football coaches use a tool built for them? Some would.

But the strategy — who specifically, what they need most, what keeps them paying — that came from the coaches who stayed. The ones who came back. The ones who contacted me to ask for a specific feature, or to tell me something wasn't working.

The MVP didn't give me Clubase's product strategy. The users did.

That's how it works.

Build the MVP. Then stop and look.

There's a rhythm to building well: build something, release it, gather signal, interpret it honestly, then decide what to build next. Each cycle should produce a more accurate understanding of the product and the people it serves.

Skip the middle step — the gathering and interpreting — and you're just building on top of assumptions. Some of those assumptions will be right. Many won't. And by the time you find out which is which, you'll have spent months building in a direction that the evidence never actually supported.

Your MVP is the first word. Not the whole sentence.

Work with me

Got something worth building?

I take on a small number of React / Next.js projects each year. If it's interesting, let's talk.
Luke Moody
Luke MoodySenior React / Next.js engineer. Building @Clubase_ and @PostHackerio. Manchester.
Keep readingMore from the same thread.A couple more pieces on product, engineering, and the work that starts after the prototype.
10 Mar 2026 · Product

Vibe coding got you an MVP. Now what?

What happens after Cursor or Bolt builds your first version — and why the real work starts here.

Read
8 Mar 2026 · Product

Building in public needs systems, not motivation

Shipping side projects consistently has less to do with hype and more to do with having a repeatable way to make progress. Here's what actually works.

Read