A typical MVP design sprint is a five-day process consisting of a two-day workshop and a few days to design, build, and test the prototype. This article is the first in a series where we share a breakdown of how we run our MVP (Maximum Value Product) Design Sprints. We have based our process on Jake Knapp’s Sprint, utilizing most of the techniques he created. Here we will give an overview of our process and how we use it to bring our client’s ideas to life.
(Keep an eye out for upcoming articles in which I will take you through the steps and exercises in more detail. Not sure if a Sprint would help your business? Read this article first)
We spend the first two days of our MVP design sprints in person with the client. Participants include major stakeholders of the team: for example, the CEO, COO, head of design, marketing, and the product owner. We also include representatives from specific business lines. For example, if we’re ideating a product for the customer support team, we’d include someone from customer support.
Regardless of who we include, we want the people representing the business to play a role in designing the end product.
Before the sprint begins, I’ll interview members of their team to get an idea of individual perspectives and insights; typically, this consists of anyone that understands the overall business and specifically anyone responsible for solving the problem at hand.
To kick things off, we review expectations and guidelines, so everyone is on the same page. Jake Knapp was sure to include principles to abide by in the process & they make the time more productive than a typical brainstorming session. One that is particularly useful is “Working Together Alone.” This allows everyone to put their head down and think about the question being asked without feeling pressured to contribute or speak up at the moment. I know I am not the only person who gets nervous & overthinks in these situations but personally, I appreciate this tactic.
Working “Together Alone,” we workshop the major challenges and goals of the business. We want to understand how the business is operating today, where the client needs to business to grow & the hurdles between those two spaces. There are a few different exercises to get those answers, but they all have the same goal of putting the ideas on paper and finding cohesion points among the group.
When everyone’s contributions are organized and placed on the wall to review, something sort of magical happens. Typically it becomes clear that the team agrees on more than they might have thought. They may even realize that collectively they feel strongly about an idea or value that can serve as a guiding point.
We once ran a sprint for a client who needed to create a user portal. The team had a good idea of the functions they needed and wanted, but by working through this process, they identified a key value everyone shared. Every person wrote something about how important it was to build & maintain the trust of their clients. Every design, feature, and rollout decision was guided by the simple question, “Are the decisions we’re making on the product contributing to or continuing to build trust with our customers?” It served as the North Star and aligned the entire team’s expectations.
By the end of day one, we’ve identified and prioritized the most important challenges to solve and the goals we are working towards. We know the questions we will answer when testing our prototype later in the week. Using the example from above, a question to answer might be, “Can we automate the experience for our clients without losing their trust?” Last, we will have ideated and created multiple solutions to review the next day.
Day Two is about choosing the most impactful solutions and understanding how to test them. Everyone has come up with & drawn out a concept they think will solve the problem best. The concepts are voted on, and the “Decider” of the group makes the final call on which idea to expand on and test out.
Every MVP sprint has a decider, usually the CEO or business owner, who can approve the solutions. This is important because you need a person who can approve (or veto) the ideas in the sprint to prevent any roadblocks afterward.
The ideas presented but not chosen are not a loss. One benefit of this process is that we have valuable ideas for future product iterations.
With the chosen concept, we work together to build a user test flow with a clear beginning and end point, which we will turn into a storyboard. This is essentially the sketch of what our prototype will look like, how it will function, and what we will test on our target audience.
The clients have done their part & it is time to design our product. The next few days involve designing a low-fidelity prototype, gathering users, and preparing for user testing. The idea is to build out the feel and function of the end product. It’s usually five or six screens, but it’s enough to present to sample users in our target demographic, and it represents a bulk of what our MVP build will be.
The purpose of user testing is to identify if our target audience will find the product to be of value as well as validate the proposed solutions before spending the time and money building it out with an engineering team. During a user test, we have our participants interact with the prototype as if it is a real product. We ask them to complete specific tasks & to report their experience along the way. This will help us assess how well the design works and if it solves the problem we need it to. We can also discover valuable insight from our users about the product or service by asking open questions about their experience & pain points.
Once the user tests are complete, we can synthesize the results to identify common trends.
The feedback we hope to deliver to our clients might be, “The users really liked that they can upload photos to their profile and said they would only use the platform if that function is available.”
It’s never quite that simple, but it is typically information we can use to inform our next steps.
By the end of the week, we should understand which features our test users like and which they’d use. Next, we will decide what is most important to build and in what order.
Many firms offer design and research services but don’t build the software. They may provide the client with a prototype, test results, and recommendations, but they might not have a good understanding of what it would take to build the product. This comes back to the cathedral analogy we used in the last article; it’s great to have beautiful features, but if the budget or time frame doesn’t allow for building them, it doesn’t matter.
We take the sprint one step further & bridge the gap by involving engineers who can map out the technical feasibility of the app early on. This helps to create realistic expectations and align priorities.
We have internal conversations between design and engineering team members that give better context when choosing where to focus. We ask, “How badly do we need this feature compared to what it’ll take to build it?” Then we can give the client the ability to measure the impact compared to the effort.
In the end, the result of our process is a product roadmap that yields the highest impact to users that requires the lowest possible effort; the maximum value. Testing the lo-fi prototype helps us determine if the juice is worth the squeeze.
MVP design sprints allow you to accomplish more in just five days than you’d think. These short strategic sprints allow you to identify the key challenges you’re facing and the goals you want to accomplish. They also provide the creative framework to brainstorm the most impactful solutions to said challenges. Most importantly, they provide real data from real users that tested your product. Using this information is the most realistic approach to prioritizing features and devising a plan to build them without investing time and money you don't need to.
