How To Support Your Minimum Viable Product With No Tech
Don’t doom your MVP with a bad first impression
A lot of MVP failures have nothing 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 most common mistakes that I’ve seen ultimately doom an MVP:
- The company can’t onboard customers properly or quickly.
- The user experience isn’t defined.
- The customer experience isn’t executed according to plan.
- One or more outliers grow unchecked until the product falls over.
- The front line of support doesn’t know how to solve or escalate problems.
None of those mistakes are rooted in the core product itself. In fact, in all those cases, the core product never got a chance to live or die on its own, because the first impression of that core product got botched right out of the gate.
The Problem: MVP delivery, execution, an support are usually afterthoughts
Customers will actually accept a new product that doesn’t work 100% as expected the first time and every time. What they won’t accept is having to jump through a bunch of broken hoops to purchase, receive, use, and manage the product. Delivery, execution, and support are concepts that have all been set in stone for a while now, and no one wants those things reinvented.
But there are a bunch of reasons why those concepts get overlooked:
Misunderstanding: Some entrepreneurs mistakenly believe an MVP is an excuse to require extra effort from the customer.
Excitement: We’ve built this awesome, game-changing MVP and the world needs it right now.
Pressure: Money or time is crunched, and it’s now or never.
Cost and complexity: It’s expensive and time consuming to build out proper delivery, execution, and support for an MVP.
The Solution: A simple playbook
An MVP playbook is a living document that defines and dictates how the product is delivered, executed, and supported. It’s sole purpose is to remove customer friction at every step, by providing information, instructions, and feedback mechanisms to everyone at the company involved in customer interaction.
The playbook serves as sort of minimum viable delivery system. Thus, the playbook has to be as simple and flexible as the MVP itself.
And you can build one with a slide deck. That’s right, we’re finally going to put Powerpoint to good use.
Actually it doesn’t matter what tool you use, as long as:
- It’s simple to review and navigate.
- It supports links and images.
- It can be easily and quickly updated.
- Most importantly, it can be shared.
Google Slides is the very definition of those attributes, which makes it a ridiculously simple way to get a handle on delivery, execution, and support without the investment and learning curve of a new tool.
The slide deck should be available to view by everyone in your company involved with the product. One person needs to own the editing, but everyone should be allowed input via comments. Everyone knows how to use a slide deck, so no training necessary.
The first slide of your deck should be a table of contents, with links to other slides. The next slide should explain, briefly, how customers discover and purchase the product, which is how they enter the system.
Now let’s take a look at each of the points of failure I’ve listed above and use the playbook to create the solution for each problem.
The company can’t onboard customers properly or quickly
Acquiring customers is difficult, but keeping them from churning is a constant struggle. That struggle begins with nailing the onboarding process — getting new customers engaged and leading them to value.
Entrepreneurs go into an MVP launch with assumptions about what information their customers will need in order to become engaged. But the product doesn’t always fill every onboarding information gap, especially at the MVP phase.
Thus, the next few slides of the playbook deck should cover:
- How the customer receives the product, what can go wrong during fulfillment, and how we fix it.
- What information the customer needs from us during onboarding, how they get it, and when they should get it.
- What information we need from the customer during onboarding, how we get it, and when we should have it.
- How we determine whether or not a customer is engaged, and when we proactively reach out when they aren’t.
- What we need from the customer when we reach out.
Good onboarding can create a smooth user experience and drastically minimize the need for support. The playbook deck should ensure that the onboarding is executed properly, systematically, and consistently.
The user experience isn’t defined
Entrepreneurs also go into an MVP launch with assumptions about how their customers will use the product. Sometimes, these assumptions are way too simple. Other times, these assumptions are just plain wrong. But almost all the time, customers will find workarounds and shortcuts that the startup wasn’t intending to support.
The next few slides of the deck should define the user experience. You don’t have to drill down into too much detail for the playbook deck, but 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).
UX isn’t going to be set in stone during an MVP, but the only way to determine which parts of the UX are working and which need tweaking is to deliver a consistent UX every time. That consistency should be documented in the playbook deck.
The customer experience isn’t executed according to plan
It’s not just your customers who will have different interpretations of your product, your own team might have different levels of understanding as to what your MVP should do.
So go back through the deck, and at every UX anchor point, add information for the internal team:
- Rules for what the product should and should not do at each anchor point.
- Highlights of known weaknesses, specific instructions at points where things are most likely to go wrong.
- Messaging for instructions and explanations to the customer.
With consistent onboarding, a consistent UX, and a consistent customer experience, we’ve pretty much set up the stage for the core product to prove itself.
Now let’s make sure it does.
One or more outliers grow unchecked until the product falls over
MVPs are designed to fail at the margins. The problem is that the makers of the product usually believe they know what “normal use” means, but the customers will always determine what “normal use” means. And when the customer definition slips closer and closer to a scenario the makers weren’t prepared for, you get an ugly surprise.
When bad things happen, no matter how big or how small, the team needs to document what happened, how it happened, and if possible why it happened. So the playbook should also contain links, at every functional anchor point, to whatever system you’re using to track issues and bugs, even if that that system is just another document.
Now you have an early warning system, consistently threaded through your delivery, execution, and support processes.
The front line of support doesn’t know how to solve or escalate problems
Support always seems to be an afterthought with an MVP. But even when a support plan is created, the problems that we anticipate and assume before launch are nothing like the problems that happen after launch.
When new problems appear out of nowhere, your front line support can hit a brick wall and leave a customer hanging — once. When it happens twice, your odds of losing that customer skyrocket. Your playbook has to be easily editable, so you can communicate new answers to new problems on the fly.
The last side of your playbook deck should be an escalation path, complete with clickable email addresses and phone numbers for people who can solve new problems as close to right away as possible. This way, when your support team doesn’t know what to do, they’ll at least know where to go.
You don’t have to build a slide deck as your playbook. A deck is just a dead-simple way of making sure that delivery, execution, and support are part of your plan. It’s better than nothing, and it actually works until the system outgrows it. By that time, the strategy should be baked in, and you won’t have to worry about shitty delivery, execution, and support killing your MVP.
Hey! If you found this post actionable or insightful, please consider signing up for my weekly newsletter at joeprocopio.com so you don’t miss any new posts. It’s short and to the point.