5 ways to gain momentum and move from a design sprint to MVP.
Design Thinking has become an essential part of how innovation teams surface ideas.
One specific tool has been the design sprint - typically a 5 day exercise using user-centered design methodologies to quickly arrive at a potential solution to a problem.
It’s fantastic tool - one we use ourselves and teach to our clients. But coming out of them, there’s often the problem of what to do next.
In our conversations with innovation teams, its extremely common to run a bunch of design sprints, identify a bunch of potential solutions, but then get stuck.
In many cases, the rough prototype and the small sample size of customer feedback, even if positive, isn’t enough to earn the resources internally to move to an MVP build.
And so instead of a stack of ideas piling up, there’s now a stack of somewhat validated prototypes piling up instead. You’ve moved the ball forward, but not by much.
A great tool for summarizing a potential solution on a single sheet of paper is the Lean Canvas.
Underneath an idea is a set of assumptions:
Design sprints can help solve a subset of these, but obviously not all of them.
Assuming you are following the practices of user-centered design, you’ve done the work of validating stakeholders need before starting your design sprint. And through the sprint process you uncover at least to a degree that the solution could potentially solve the problem.
But just like a venture fund is unlikely to invest in a company on the basis of a clickable prototype and 6 conversations with end users, your growth board or other innovation governance team likely won’t consider that sufficient to green light the resources to build an MVP.
So how do you close that gap, improve your case and move the initiative forward? Here are 5 suggestions that have helped other clients break the logjam.
You make something quick and dirty to capture user feedback during the sprint. Now it’s time to create high fidelity versions of that prototype.
This doesn’t need to be working software. It can still leverage tools like Invision. But it should have the look and feel of a finished product.
With that in hand, go outside the conference room and show it to more users. Capture their feedback around willingness to use and if necessary willingness to pay.
Don’t be surprised when you get lukewarm feedback or objections. Use those to improve the prototype, and go back out there.
Getting more data points can help build your case. And interestingly, simply having a highly designed version of your prototype can increase internal momentum as well. It gives the impression that there’s a “there” there.
Showing pretty screens can often generate more enthusiasm than talking about an idea in the abstract (or even showing lower fidelity versions of an idea, which signal that it’s half baked.)
Assuming the solution is a piece of software, a fantastic next step is to turn the prototype into a functional spec document. This typically includes:
Doing this gives your internal team the data they need to make the case from a level of effort perspective, which is obviously an essential part of your case.
It also helps you craft the message in a way that increases the likelihood of success. Too often teams try to pitch the grand vision. They ask for the budget to create the product as it will ultimately be. But this increases your cost and risk, both perceived and actual.
Instead, identify the “core experience” that belongs in the MVP. Focus your effort on nailing the first time UX and the core experience. Defer the rest.
This is a good practice anyway, as simpler, tighter products tend to result in higher user satisfaction and limit the amount of behavior change needed to adopt.
Getting timeline and budget numbers also help you identify potential trade offs, shaping what that core experience includes and doesn’t include. It helps you make a more modest ask for MVP development, while providing visibility into the costs of the potential long term roadmap as well.
We typically recommend getting an estimate from an external vendor at this phase, even if your internal team plans to build. This addresses two potential issues:
We’ve talked in detail about how we use growth models to put realistic assumptions around getting traction. We’ve found it to be an invaluable tool for making the MVP case.
The model makes a series of detailed assumptions at every layer of the customer or stakeholder funnel:
These are obviously all assumptions. But they demonstrate to your team that you’ve given things way more thought. That you have a rational plan for how you will grow the product once it’s launched, and that your estimates for ROI are backed by a detailed breakdown of the levers that influence it.
To further validate some of the assumptions in your model, you can create a smoke test to test acquisition.
A smoke test can take many forms - often it looks like a landing page (with your pretty screens) with a call to action to sign up. Behind that is a page saying we’re not ready yet, asking for an email address to be notified when you launch. You supplement this with a tactical paid acquisition campaign to acquire potential customers.
This helps you validate a whole host of things:
As an optional intermediate step, you can even add a pricing page (if relevant) in between the landing page and email collection. This lets you test various pricing models as well.
Finally, when dealing with b2b solutions, we often advocate for taking that smoke test and supplementing it with an aggressive cold outreach campaign.
You want the landing page up because it gives the idea credibility. You supplement the landing page with email addresses and linked profiles of people who “work” there. You build a list of targeted potential customers, and you craft a multi-modal outreach campaign to generate potential leads (typically some combination of email, phone and social selling.)
This again forces you to get outside of the building and test for value prop - customer fit.
While we believe in doing stakeholder research in other ways at the front end (validating pain through problem interviews, etc.), we do believe there is value in trying to sell the solution at this stage.
Getting meetings with potential customers who think the solution exists in some form is helpful because they’re no longer just giving you advice. They’re being sold, which increases resistance. As a result you get a ton of new useful information:
Please, continue to do design sprints. We know of no better tool to quickly make progress on a concept for a solution.
But realize it’s not a magic bullet. You still have to do the work of building your case to earn the right to move forward with it.
You can fundamentally de-risk an idea and earn the resources to build an MVP, in very little time and with very low cost. Consider baking the tools above into your process to increase your velocity of tested ideas.
Manifold has done all of the above for clients many times. We’d be happy to help you execute on any of them. To learn more, contact us.