Your Minimal Viable Product Rules Just Expired – Here’s What Nobody Tells You About Building With Real Users

Estimated reading time: 8 minutes

Three key takeaways

1. Minimum means something different on an established product, and viable isn’t the ceiling. It’s the smallest change that doesn’t damage what already works, ideally one users end up preferring rather than merely accepting.
2. Scope the Minimal Viable Product around contested functionality, and validate it with real users before you build. Talk to the people affected, test the direction manually where you can, and let usage rather than stated interest confirm you’re on the right track.
3. A redesign MVP needs an exit plan as much as a launch plan. Rollback thresholds should be agreed before the release, not during it.

Minimum Viable Products are not an exclusive tool used at the inception of a product idea, they’re there to test the validity of a product idea’s iterations. The only thing that has changed is the definition of minimum. With an established product, minimum can’t just mean the smallest feature set that proves a concept, it has to mean the smallest change that doesn’t erode what’s already working. Viable can’t just mean ‘good enough to learn from’, it has to mean ‘good enough that existing users don’t churn while you’re learning’. As your organisation evolves, so does the MVP.

Let’s get into it.

Define what you’re actually protecting

Before scoping any Minimum Viable Product redesign, get explicit about what’s untouchable in this phase and what’s genuinely up for testing. This is the redesign equivalent of identifying your riskiest assumption: instead of asking ‘will anyone want this’, you’re asking ‘what happens if this specific workflow changes’.

Map current functionality into three groups:

• Core and proven. Heavily used, well understood, low risk to change. Leave it alone unless there’s strong evidence otherwise.
• Contested. Used, but with visible friction, complaints or drop off in the data. This is where your redesign MVP should focus.
• Legacy and low value. Rarely used, kept out of habit rather than need. Usually safe to simplify or remove, but sense check with support or account teams first.

Scope the MVP around the contested group, not everything at once. It keeps the change small enough to test properly and gives you a cleaner signal on whether the redesign is actually working.

Before committing design or development time, talk to a meaningful sample of the users who touch that contested area, ten to fifteen is a reasonable working target for most B2B products. Focus those conversations on how they currently work around the problem, not on pitching your proposed fix.

Where possible, validate the new direction with something closer to a concierge test than a build: deliver the improved outcome manually for a small group first, even if that means a person doing by hand what the redesigned feature will eventually automate. Usage, not stated interest, is the signal that matters. Existing users are often too polite to say a change won’t work for them, they just quietly stop using it.

Aim for lovable, not just viable with your MVP

First things first, the “lovable” part doesn’t work for everyone. If you dear reader are on the product team for a tax software company, perhaps this isn’t for you. Can tax software be better and easier to use? Yes. Is the goal to be loveable? That is a steeeeeeep uphill battle and I commend you if that is your goal. In short, B2C can benefit from this philosophy more than a rigid B2B product. 

Every design that nudges users out of an existing established pattern is another reason to resent the disruption. This is where it’s worth borrowing from the idea of a minimum lovable product rather than a purely minimum viable one:  going beyond “just” solving a pain point but doing so with extra care and attention IF it fits. A redesign that trades a familiar annoyance for an unfamiliar one, without a genuine upgrade in return, is the fastest way to turn a careful MVP process into a churn event.

Run it inside your existing agile cadence, not around it

An Minimum Viable Product for an existing product works best when it’s absorbed into your normal sprint rhythm, not treated as a separate, parallel project. An MVP is meant to sit inside a team’s existing flow of epics and sprints, not run alongside it as a special case. Fencing a redesign into its own workstream tends to create a ‘big reveal’ moment not unlike a mini waterfall project, exactly the risk MVP thinking is meant to avoid, and exactly the kind of UX friction that shows up when a change lands on users all at once instead of in small, tested steps.

Structure the work as a sequence of small, reversible releases inside your existing sprints:

1. Ship the redesigned element behind a feature flag or to a small percentage of users.
2. Run it alongside the existing version rather than replacing it outright.
3. Compare behaviour, completion rates, support tickets and direct feedback between the two.
4. Expand the rollout only once the new version is holding its own, and roll back quickly if it isn’t.

This phased approach means a redesign MVP never puts the whole user base at risk at once, and it keeps stakeholders inside the same reporting cadence they already use for every other piece of agile work, which makes buy in far easier to get and keep.

Trello itself is a useful case study in both directions. Butler, its automation engine, started life as a paid, opt-in Power-Up rather than a core feature, giving Atlassian a live cohort of users who’d actively chosen it before deciding whether to fold it into the free, core product. It only became a built-in feature for all boards once that signal was clear. That’s the phased model working as intended: test with a self-selected group, expand once the value is proven.

Compare that to what happened when Atlassian skipped the same discipline. In May 2025, Trello shipped a full interface overhaul to its entire user base in one go, changing layout, fonts and button behaviour and removing some existing capabilities in the process. The backlash was significant enough that industry press compared it to some of the most criticised software updates in recent memory. Same company, same product, two very different approaches to rolling out change, and two very different outcomes.

Protect the exit, not just the entry

Most Minimum Viable Product advice focuses on how people arrive at a product. With an existing product, how people leave a broken transition matters just as much, not least because underperforming UX is already a known driver of customer churn even without a disruptive redesign layered on top. Build a rollback plan before you build the redesign itself: know exactly how you’ll revert if the new version underperforms, and set the threshold for that decision in advance, not in the middle of a bad week.

A quick MVP redesign checklist

• Have you separated core, contested and legacy functionality before deciding what to change?
• Have you talked to a real sample of the users affected, and tested the direction manually before building it?
• Is the change scoped to the contested area, and does it aim to be genuinely liked, not just tolerated?
• Is it shipping behind a flag or to a limited cohort first, inside your normal sprint cadence?
• Do you have a rollback plan and a clear threshold for using it?
• Have existing users been told what’s changing and why, before they encounter it?

FAQs

How is an MVP for an existing product different from a normal MVP? A standard MVP is tested against no prior experience, so users have low expectations and little to compare it to. An MVP for an existing product is tested directly against the version it’s replacing, so the bar for ‘viable’ is higher and the cost of getting it wrong includes losing trust with users who were already satisfied.

What should trigger a rollback during an MVP redesign? Agree this before launch rather than after. Common triggers include a drop in task completion, a rise in support tickets, or negative direct feedback that exceeds a threshold you’ve set in advance, so the decision to roll back is quick and not made under pressure.

Is a minimum lovable product different from a minimum viable product? A minimum viable product is judged on whether it works, a minimum lovable product is judged on whether people prefer it. For a redesign, viable is rarely enough on its own, existing users already have something that works, so the new version needs to offer a genuine improvement they notice, not just parity with extra risk attached.