Introducing: The MVP Track

Over the course of two years, we've run over 50+ design sprints with clients in various industries; from healthcare and insurance to e-commerce, logistics and media. Yet, the question that keeps coming up after a design sprint is what happens after. After the user testing has ended, the sprint report wrapped up, backlogs filled, where do we go from there?

Fair question. After having gained so many insights during the sprint and now (hopefully) knowing which direction to head in, how do we make these insights actionable? How do we get this project off the ground for real, in a way that we keep the momentum as high as during the four-day design sprint? We kept getting this question over and over again and we couldn't agree more that a design sprint shouldn't be a one-off event where everyone could just go home after high-fiving on Friday night. We've come up with an approach that fits our believes best. We call it the MVP Track, which consists of 4 pieces. And, for the record, MVP meaning "Minimum Viable Product".

• A Decision Dash to prioritize company challenges. Here you can learn more about our Decision Dash.
• A Design Sprint to quickly validate solutions and ideas in one week with a tangible prototype. More info on our approach can be found here.
• A Sprint Cycle is a 6-week program ultimately yielding your first MVP.

Is it really that straightforward?

A Sprint cycle to build a functional MVP

‍

Essentially, the cycle is a 6-week agile development flow (Scrum or Kanban, whatever suits your needs best) during which we build our first MVP. We're taking the feedback from end-users to create an early version of the product and launch it to, once again, learn as much new things as possible. This is something that is called validated learning, or learning based on real data gathering rather than guesses about what the future could hold. An MVP should always be treated as an experiment that is there to learn, not to scale. This is basically what we did for Dreamland, a Belgium-based retailer specializing in toys, gifts, multimedia, and other seasonal products. In only 8 weeks, we went from defining a challenge using a Decision Dash to creating a high-fidelity prototype during the Design Sprint and finally launching a fully functional MVP of the solution in 6 weeks of agile development. Here's the case study, if you're interested.

That 8 weeks process gives you 2 crucial feedback points, after the design sprint, and after the MVP launch. Based on those insights, you can continue iterating. After each cycle there's time to reflect and set up plans for the next cycle, during another design sprint or a more specialized sprint focused on growth or engagement. Interested in how we tackle those specific topics? We'll have more information on that on our website soon so stick around.

6 weeks, each with their own focal point.

Here's an example of how the first 6 weeks of the sprint track look like.

Week 1 - Kickstart Sprint: set up the core of the project, make sure we can rapidly implement, test and release new features. Focus on the core flows as this will shape your end result the most. Refine the prototype from the design sprint ran prior to this sprint, and start understanding and prioritizing all the potential things we could do in this cycle. The first week we also focus on potential risks that could create immense delays. You should be aware of all of these risks in the first week and spend some time with it to see whether the risk factor can be removed to avoid losing too much time when you're really building it.

Week 2-5 - Execution Sprints: The team has an idea of the direction they're going to take and every week we decide what we should focus on. You want to avoid overspending on certain topics. That's why a check-in every week is the absolute minimum. During this check-in you discuss progress, re-evaluate the chances of shipping a good result after 6 weeks and either pivot or nullify certain features if needed. A perfect product doesn't exist, a product that's good enough and ships on time is always more valuable this early in the process. That doesn't mean you should ship a bugged product or introduce work-arounds, but choose to implement a simpler feature to solve the same problem. Towards the second part of the track, your team should really be picking up some speed

Week 6 - Launch sprint: When you're nearing the end of the cycle, your team should start preparing for launch. Focus on bugs, polish and Product Marketing. You don't want to launch a product that will frustrate users, or worse, won't even notice. And even worse, you don't want to stay in the void on the feedback and usage of your users. We see Product Marketing as a crucial part that should be controlled by the team. If you need experts on this in the team, involve them soon enough, Product Marketing really is just one of the responsibilities of the team and you want to make them accountable for it.

To keep track of this process, Basecamp introduced Hill charts, which nicely visualises the feeling during a Sprint Track. We're not using the Hill chart, but this really maps well on our approach during the 6 weeks.

Eric Ries: "In today's marketplace of uncertainty, whoever learns fastest wins"

Focus on outcome, not output

We can't stress this enough. A product should always aim to solve a problem; it needs to scratch a certain itch. The way your product impacts the behavior and how your users interact with it, is far more important than the potential output the team could deliver during an MVP cycle. Typical roadmaps often focus on what features will be launched, when you should really only be focusing on the outcome. If your outcome is reached with a minimal set of features, you're achieving this by investing in simplicity and user experience. Most successful product teams have become so efficient because of this approach.

That's why it's really hard to plan what the final output of your team pas 6-week-cycle is gonna be like. After having launched your first MVP you gather enough data to plan for the next 6 weeks which will then create a brand-new MVP, and the cycle begins anew. We don't like to spend too much time beyond this timeframe but focus solely on gaining the best results on the proposed outcome. Beyond that, we only talk potential focus areas, but those will only become clearer after each launch.

Janna Bastow from Prodpad wrote about this on Twitter and it really hit a nerve in the Product community. Try explaining your roadmap like this, the next time someone asks you to present your roadmap and see what happens!

This is the first article of our Trust the process series, where we explain our way of working. Follow us on linkedin, Facebook or Twitter to see updates or join or mailing list!

‍