What we can still learn from ‘minimum viable product’ practices

French novelist Antoine de Saint Exupéry wrote that “perfection is attained not when there is nothing more to add, but when there is nothing more to remove.”

That high-minded virtue has become best practice in early business planning, from software and hardware through to an event or service. The art of product development is to start with a product that has very little art. That philosophy has emerged as low-cost tools such as coding “copilots,” website builders and 3D printing have proliferated.

“The building is getting easier,” Aaron Mulder told me. “Agreeing on what to build is not so easy.”

Mulder is an old hand in software building and now chief technology officer at Chariot Solutions, a software consulting firm based in suburban Philadelphia. (Fun fact, 15 years ago, Chariot was the first company to ever buy advertising on Technical.ly.)

Most of us do tend to over-build. Why? For one, we’re naturally more creative than scientific: it’s easier to generate ideas than it is to test if any of them are any good. We also crave consensus, so when a coworker has just one more suggestion, it feels rude to shoot it down.

Software building has gifted us jargon to describe this. In 2001, Frank Robinson, the CEO of California management consulting firm SyncDev, coined the term “minimum viable product” — or MVP in the lingo, which has become both a staple of the Silicon Valley consensus and a warning for those of us who tend to over-build.

Many projects have been so overloaded with pet features and distracting widgets that no one could determine what was effective and what wasn’t — assuming the project launched at all. It’s a common trap for teams of any size.

“For a startup, you think you know what you need to offer, but you really don’t until someone has used it,” Mulder said. Big, established teams experience misaligned expectations between their existing offerings and any new ones they want to test. Mulder draws a bright line between an MVP and your “first release.”

“Your MVP should be a fact-finding mission,” he said. Look at Journal My Health, an app launched in 2021 by longtime Chariot exec Tracey Welson-Rossman. Research shows that regular journaling improves health outcomes, especially for those with chronic conditions, but as most of us know, sticking to a journaling routine is a challenge. The app aims to improve follow-through. Its MVP tested assumptions about its effectiveness — but didn’t include cloud-sync across devices or login features that are common among established apps.

In other projects, Mulder has confronted real disagreement between product leaders with lots of feature requests and engineers who want to only build what is necessary.

“I don’t want to go to a product team and say ‘you’re wrong,’” Mulder said. “But I am willing to say, ‘Let’s put this in front of customers and see how it goes.’”

This exposes a fundamental weakness of most creative endeavors, not just software. We latch onto an idea of ours and resist giving it up. Remember: Obsess over a problem rather than one particular solution. An MVP is a necessary test of your assumptions.

“Write down what you want to learn,” Mulder said. “Then go learn it as efficiently as you can.”