As the minimum viable product idea becomes mainstream, I’m starting to hear “MVP” used to justify any minimal effort. It’s great that people want to benefit from being lean and agile, but it’s also absolutely vital that an MVP answers your important questions. There are many kinds of MVPs and most of them are anything but minimal effort. Thinking of an MVP as minimal effort risks wasting the effort completely.
Finding the Sweet Spot
In software we often balance competing goals. I’m going to deconstruct the MVP as tension between three different kinds of questions. Thinking this way helps you prioritize what you want out of your MVPs. It’s more useful than trying to find the sweet spot on a Venn diagram of potential products. Read more on Minimum Viable Product: Pick Any Two…
Update February 2015:Tickets for the event are now on sale! Early bird tickets are available through mid-February; standard tickets will be available after that. Please visit the Balanced Team 2015 Grand Rapids website for more information. We’re excited you’ll be joining us. See you soon!
Many teams and organizations struggle with the question, “How can creative teams work together to produce valuable, validated outcomes in an environment of extreme uncertainty?” This is a tough question — and surely has no single answer — but it’s one that the Balanced Team group has been addressing head-on since 2009 through meetups, mailing lists, and conference presentations.
“…a version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.”
An MVP usually targets early adopters and includes only the minimum amount of features to validate your value proposition hypotheses.
The practice of starting with an MVP is a lean startup tactic. To execute an MVP well, I suggest you study the principles behind it and the Lean Startup Methodology as a whole. Understanding Lean Startup principles will also be a great help as you build your company.
When Less Is More
Through years of experience helping clients build products with Atomic Object, I’ve found most product managers and entrepreneurs tend to overbuild their first product release. This is often comes from a fear of underbuilding – they want to know that they’re product is compelling enough for their users, and they don’t want to give competitors a chance to leap-frog them. I also believe overbuilding can be partially motived from another fear — a subconscious desire to put off the release and the prospect that your idea might fail.
Atomic Object has helped many companies design and implement new software products. I’ve noticed different environments at companies that are primed for innovation and companies that are not.
Roger Martin’s knowledge funnel concept describes how business practices become more algorithmic as organizations scale and strive for efficiency. As companies scale, their technology departments develop an operational mindset and become more focused on efficiency and stability than on creating opportunity.
Sometimes, though, a Minimal Viable Product turns into a Mediocre Value Proposition. A company might introduce a product in the marketplace. A few customers find it interesting (you can always find a few customers). Results fall short of expectations, but the company says, “Well, it’s just a minimal viable product for learning.” The company makes a few tweaks, scales up spending . . . and falls flat on its face.
On Friday night, Justin, Paul, Scott, and I joined the Ghost in A Box team. Ghost in A Box is the brainchild of Melissa Price. The concept was simple, users buy a ghost online and receive a package containing their new resident. Once customers receive their ghost, they can go online and learn their ghost’s story.
The challenge in front of our team was to refine, define, design, build and deploy in 1 day. Luckily, we had a small head start. Melissa had a strong concept for her product and she had already created the visual style. Even with these components in place it was still a daunting task to create a soup to nuts product in one day. Read more on Building a Product in 20 Hours – Startup Weekend Detroit Story…