Minimum Viable Product
A lot of MVP failures don’t have anything to do with the viability of the core product itself. In fact, in over 20 years of building, delivering, and studying both successful and failed products. These are the first common mistakes that I’ve seen ultimately doom an Minimum Viable Product:
- The company can’t onboard customers quickly or adequately.
- The user experience isn’t defined.
- The customer experience isn’t executed consistently with the plan.
- One or more outliers grow unchecked until the merchandise falls over.
- The battlefront of support doesn’t have the skills to unravel or escalate problems.
None of these mistakes are rooted in the core product itself. Altogether those cases, the core product never got an opportunity to scale or die on its own because the primary impression of that core product got botched right out of the gate.
The Problem: MVP delivery, execution, support are usually afterthoughts
The Solution: an easy playbook
An MVP playbook may be a living document that defines and dictates how the product is delivered, executed, and supported. The playbook is a kind of minimum viable delivery system. Thus, it has got to be as versatile and straightforward because of the MVP itself.
And you’ll build one with a slide deck. That’s right. We’re finally getting to put Powerpoint to good use. The slide deck should be available to look at by everyone in your company involved with the product.
- The first slide of your deck should be a table of contents, with links to other slides.
- The subsequent slide should explain, briefly, how customers discover and buy the merchandise, which is how they enter the system.
Now let’s take a glance at each of the points of failure I’ve listed above and use the playbook to make the answer for every problem.
1. The company can’t onboard customers quickly or adequately
Acquiring customers is difficult, but keeping them from churning may be a constant struggle. That struggle begins with nailing the onboarding process — getting new customers engaged and leading them to value.
2. The user experience isn’t defined
Entrepreneurs also enter an MVP launch with assumptions about how their customers will use the merchandise. The next few slides of the deck should define the user experience. You don’t need to drill down into an excessive amount of detail for the playbook deck. Still, it should have anchor points, sections if you will, describing functionality with images for visual reference and links to internal product documentation and third-party apps (like Salesforce or Hubspot, for example).
3. The customer experience isn’t executed consistent with the plan
It’s not just your customers who will have different interpretations of your product. Your team may need different levels of understanding of what your Minimum Viable Product should do. So return through the deck, and at every UX anchor point, add information for the internal team:
- Rules for what the merchandise should and will not do at each anchor point.
- Highlights of known weaknesses, specific instructions at points where things are presumably to travel wrong.
- Messaging for instructions and explanations to the customer.
4. One or more outliers grow unchecked until the merchandise falls over
When bad things happen, regardless of how big or how small, the team must document what happened, how it happened, and, if possible, why it happened. Therefore the playbook should also contain links, at every functional anchor point, to whatever system you’re using to trace issues and bugs, albeit that that system is simply another document.
5. The battlefront of support doesn’t skills to unravel or escalate problems
Support always seems to be an afterthought with an MVP. But even when a support plan is made, the issues that we anticipate and assume before launch are nothing just like the problems that happen after launch.
The far side of your playbook deck should be an escalation path, complete with clickable email addresses and phone numbers for people that can solve new problems as on the brink of directly as possible. This way, when your support team doesn’t know what to do, they’ll know where to go.