I’ve observed numerous occasions where product managers say they want to build a Minimum Viable Product (MVP) but end up delivering a MAXIMUM Loosely Viable Product (MLVP).

At a fundamental level, I consider a Minimum Viable Product as a way to validate or invalidate a hypothesis. That is, what is the least I can do to learn enough to decide on my next step.

“What if we found ourselves building something that nobody wanted?” Eric Ries, Lean Startup

Yet, I often see the MVP get warped when teams get mired in thinking about all the nebulous and tangential cases that may come up. It’s easy for product managers to engage in these discussions cause, after all, “we’re solving problems for our users.” Unfortunately, this behavior tends to lead to a quick progression toward bloat, and by the time you realize it, you’re past the point of diminishing returns.

To guard against this, product managers need to stay vigilant and step back often to reassess whether they’re doing too much. It’s easier said than done, though, but here are some smells to help you identify and some tactics you can use to help re-orient yourself and, by extension, the team.

Some smells

1. The team wants integrations into existing systems to handle the potential “flood” of new users.
2. You’re catering to your largest customer(s) and infrequent user(s).

Examples

We need to integrate our CRM, Customer Support System, before launching!

While thinking of examples like Groupon sending out coupons via Apple Mail at the beginning or Paul Graham talking about doing things that don’t scale can be effective, they don’t necessarily resonate because the lessons aren’t considered applicable.

Instead, try using a basic illustration shown below that helps provide some perspective. Highlight that there are zero users and zero revenue, and doing integration work will cost $x. Equating actual dollar value seems to help.

X feature must be there because Mr. Power User from Bigly Big Corporation, who used to do that job, said it would be nice to have.

Remember, even if Mr. Power User is your target user, it’s one data point. To bring perspective, ask if additional data points can support the need for the particular feature in the MVP.

In an established business, getting your teammates to think about what is most important is challenging but critical. Asking your team if they would still do the feature now if they were in a startup and running out of money can give the team pause, especially when showing that the top reasons that startups fail are that there was no market need to run out of money.

These examples may seem obvious, but when you’re in the day-to-day, your blinders may be on. Build the discipline to step back to assess whether you’re correctly prioritizing and course-correct where appropriate. If you don’t, you’ll likely end up burning a lot of money on a Maximum Loosely Viable Product (MLVP) that doesn’t fit anyone’s needs very well.