Beyond the MVP: how to think about v1, v2, and what comes after

There's a moment in almost every founder conversation where someone says: "Let's just build the MVP and see what happens." And honestly? That instinct isn't wrong. Getting something into the hands of real users is one of the smartest things you can do early on. But "see what happens" isn't a strategy - it's a coin toss. And when the MVP lands and the feedback starts rolling in, founders who haven't thought even loosely about what comes next tend to freeze, scramble, or worse, rebuild things they just built.

So here's the uncomfortable truth we share with nearly every founder we work with: what you leave out of your MVP matters as much as what you put in. And you can only make good exclusions if you've thought - even roughly - about the sequence that follows.

Your MVP isn't v1. It's v0.

Let's reframe things a bit. Most people treat the MVP as the first version of their product. It's not. It's the version before the first version - the one designed to test whether your core assumption holds up in the real world. Will people actually use this? Will they pay for it? Does the problem you're solving hurt enough that someone will change their behaviour to fix it?

That's all your MVP needs to answer. Nothing more.

V1, then, is what you build once you've got those answers. It's the version where you take everything you learned from the MVP - the features people ignored, the ones they begged for, the workflow that made no sense to anyone but you - and you respond. V1 isn't a guess. It's an informed bet. And v2? That's where you start to scale what's working and cut what isn't.

V1 is about learning. V2 is about responding to what you learned. If you skip the thinking between those stages, you end up rebuilding instead of building.

"But isn't planning ahead the opposite of being lean?"

We hear this a lot. There's a widespread belief - partly thanks to how Lean Startup ideas get compressed into soundbites - that any forward planning is waterfall thinking in disguise. That you should only ever focus on what's directly in front of you. But there's a difference between planning your next twelve sprints in granular detail (don't do that) and having a loose sense of direction for where the product is headed.

Put another way: you don't need a Gantt chart. You need a logic. A sense of if this, then that. If the MVP validates demand, what's the first thing we'd add? If users love feature A but ignore feature B, what does that tell us about v1? If we know we'll eventually need integrations with third-party tools, how do we build the MVP so we're not ripping out plumbing later?

This is what we mean by strategic sequencing. It's not a twelve-month roadmap pinned to a wall. It's a set of intentional decisions about what comes first, what comes later, and - critically - what you're deliberately parking for now.

The real cost of not thinking ahead

Here's where it gets practical. When founders build an MVP with zero thought about what follows, a few things tend to happen:

1. Technical debt stacks up fast. Shortcuts that made sense for a quick test become load-bearing walls you can't easily knock down. We've seen teams spend months unpicking decisions that took a week to make, simply because nobody asked "and what if this works?" before they started building.
2. You end up rebuilding, not iterating. There's a big difference between adding to something and starting again. If your MVP architecture can't support the features your users are asking for, you're not moving to v1 - you're back at square one with better data and less runway.
3. Momentum stalls, and the energy that carried you through launch starts to drain. Founders who don't know what comes next tend to either over-react to every piece of feedback or freeze entirely. Neither is helpful. A rough sequence gives you a framework for deciding what to act on and what to note for later.

None of this means you need everything figured out. You don't. But a bit of forethought - even a couple of hours sketching out the "if/then" logic of your next two stages - can save you weeks of rework and a significant chunk of budget.

So what does good sequencing actually look like?

It's simpler than you'd think. When we work with founders at Rise, we usually map out three horizons before a single line of code gets written. Not detailed specs - just intentions. Horizon one: what's the minimum we need to learn whether this idea has legs? Horizon two: assuming it does, what's the first version that people would genuinely pay for and use regularly? Horizon three: what does this product look like when it's working well and growing?

Each horizon informs the one before it. Knowing roughly what v2 looks like helps you make smarter choices in v1. And knowing what v1 needs helps you strip the MVP down to its essentials without accidentally cutting something you'll desperately need later.

It's not about committing to a plan. It's about making intentional exclusions rather than accidental ones.

Start with the sequence, not just the sprint

If you're about to build your MVP - or you've already built one and you're wondering what on earth comes next - it's worth stepping back before you step forward. Not to plan everything. Just to think about the logic of what follows, so the decisions you make now don't box you in later.

We do this with founders all the time, and it usually starts with a 30-minute conversation. No obligation, no sales pitch - just an honest look at where your idea is, where it could go, and what sequence makes sense to get there. Book a discovery call with Rise and come away with a clearer picture, whether you work with us or not.