How we decide what goes in v2, and what waits

Once an MVP actually launches and starts generating real user feedback, requests for new features start arriving quickly, from users, from the founding team's own evolving ideas, from competitors' latest moves. Deciding what genuinely belongs in v2, versus what should wait, or simply never get built at all, requires a different filter than the one we used to originally scope the MVP itself.

The MVP filter was essentially "what's the minimum needed to genuinely test our core assumption." The v2 filter is different: "what does the real data we now actually have tell us will move the metrics that genuinely matter most to the business at this specific stage." We help founders make this real shift deliberately, rather than letting the original MVP scoping habits simply persist by default into a phase where they no longer actually fit.

Pre-launch, every feature request is genuinely speculative, since there's no real usage data yet to actually inform it one way or another. Post-launch, real data exists: which features get used, where users genuinely get stuck, what they actually ask for repeatedly versus what a single vocal user happened to mention just once in passing.

We push founders to ground every v2 decision in this real, available data rather than in whoever happens to be the loudest or most persistent voice in the room at any given moment. A feature requested by one particularly vocal user carries very different weight than a friction point genuinely observed across a meaningful share of real, active users interacting with the product.

We score each real candidate feature against three specific questions: how many current users would this genuinely affect, how significantly would it move a metric the business actually cares about right now, and how much real effort would it take relative to that expected impact. This isn't a purely mechanical formula, but it forces a consistent, comparable, apples-to-apples conversation across genuinely different kinds of feature requests.

This scoring conversation regularly surfaces genuine disagreement about the underlying assumptions, which metric matters most right now, how many users a given feature would actually reach in practice, and that disagreement is valuable to have explicitly, out loud, rather than leaving it quietly unspoken and unresolved beneath a decision that seems to have been settled but actually hasn't been.

A single vocal user, often an early adopter genuinely enthusiastic about the product, can feel like a strong, urgent signal, and their specific request may not actually represent what the broader user base genuinely needs or wants overall. We ask founders to check any single loud request against real, aggregate usage data before treating it as a genuine, board-worthy priority signal on its own.

This doesn't mean ignoring vocal users entirely, their engagement is genuinely valuable and often worth real, deliberate attention. It means not letting volume or persistence of a single voice substitute for real, representative evidence about what the broader base of actual users genuinely needs from the product going forward.

Features that would meaningfully help a small, narrow segment of users but not the broader base usually wait, unless that specific narrow segment happens to represent a deliberate, strategic direction the business has already decided to actively pursue going forward. Features that are technically interesting to the founding team but don't clearly connect to any actual metric that currently matters also generally wait.

We keep an explicit, visible "good idea, not yet" list for exactly this purpose, similar in spirit to the pre-launch MVP list we described in an earlier post, so genuinely good ideas don't simply get lost or forgotten, they just get sequenced deliberately rather than pursued immediately without real, careful consideration.

Early post-launch, we prioritize features that improve genuine retention and core usage, since the immediate priority is usually proving the product is a real, durable habit rather than a one-time curiosity that users try once and never return to. Later, once retention is solid and reasonably well established, priorities can shift more toward growth-oriented and monetization-oriented features instead.

We revisit the actual prioritization framework itself periodically as a product genuinely matures, because the questions that mattered most at three months post-launch aren't necessarily the same questions that matter most at twelve months post-launch, even for the exact same underlying product.

Treating v2 as "everything we originally wanted to build but cut from v1" rather than as its own fresh, independent decision genuinely informed by real, current data. Some originally cut features turn out, once real usage data exists, to matter far less than they seemed to at the very start, and others that weren't even part of the original plan turn out to matter considerably more than anyone initially expected.

We treat the original MVP cut list as a starting point for the v2 conversation, not a fixed roadmap or binding commitment, and we're explicit about this distinction with founders from the very start, so nobody feels genuinely blindsided when a previously cut feature doesn't automatically make the actual cut for v2 either.

One founder we worked with was certain a specific advanced feature, cut from the original MVP, needed to be the centerpiece of v2 based on how strongly it had originally been requested before launch. Real usage data told a different story: the users most engaged with the actual product were struggling with a simpler, unglamorous onboarding issue that was quietly suppressing retention far more than the absence of that advanced feature ever was.

Fixing onboarding first, ahead of the originally planned centerpiece feature, produced a measurable retention improvement within weeks. The advanced feature eventually shipped later, to a considerably larger and more engaged user base than it would have reached had it launched first, exactly as the founder had originally, confidently planned before the real data actually came in.

The filter that helped you decide what to cut for launch isn't the same filter that should genuinely decide what to build next once real users and real data actually exist to inform that decision properly.

We help founders make this deliberate shift explicitly, from testing a core assumption to optimizing a real, living product based on real evidence, because conflating the two leads to a v2 that's either too conservative or too speculative relative to what the actual data is genuinely telling you at that specific stage.

This framework has helped multiple founders make faster, more confident v2 decisions, precisely because it replaces an open-ended, often anxious debate with a structured, evidence-based conversation grounded in real data rather than opinion or gut feeling alone.