In her song “Hurts so good”, Astrid S describes a complex and confusing love affair. The contradictory feeling is in many ways recognizable for designers working in teams using an MVP approach.

Merging design and MVPs

The Minimum Viable Product (MVP) approach is all about building to learn. You strive to build something that gives some value to users as quickly and efficiently as possible so you can learn and evolve the product. Build, measure, learn, repeat. It is a process of many iterations.

The benefits are many:

• Development goes faster
• Users get value earlier (more and more features over time instead of nothing until the product is done)
• Risk per release is reduced
• The team is more flexible to fix bugs or change course

So, only good stuff here. But what happens when you combine an MVP approach with design methodology?

As a designer I am all about user-centered problem solving. To be able to do my job I need to empathize with and understand the users and their needs. I also need to understand the context, ideate, test my hypothesis, and sketch (amongst other things). All time-consuming activities. Time which we in the digital product development world don’t have. I’m currently working in a team where we have just launched an MVP and are now continuously working to improve our product and find out what our next step should be. We are in the beginning stages of our project and we aim to go fast. Learn fast and build fast. Which brings me to why it hurts.

Speed vs. quality

When development speed increases, the designer has less time to design. There is no time to squeeze in a double diamond between each release. You do not have time to do the testing you would like, or gather the desired user insight. Without this insight and understanding, you feel like you will crumble on the first release. Releasing something that maybe only half done (or less) really, truly hurts. Oh my god. It hurts.

However, as soon as the first release is out you immediately have real users, and get real data. The learning begins. You learn from actual use of the MVP. User insight expires quickly, as our users are evolving in line with the digital development. Having short feedback loops results in current and continuous user insight. In addition, small releases leads to more accurate insight from tracking, testing and interviews because the changes between releases are smaller. So, on the good side, if your half-finished work was a total disaster you will see it real quick. PLUS, you will most likely know exactly what needs to be done to fix it.

Flexibility and immediate value

In digital development it is important to be able to adjust course quickly. Working with MVPs encourages short-term planning. By focusing on the next iteration, and not planning half a year in advance, allows the team to be flexible for changes and fixes. So your half finished work from before can be edited quickly. But, designing for the short term can result in a fragmented solution. It is therefore important to balance between quick and small iterations, and look up and ahead from time to time. When working in the digital world we not only have the possibility to be flexible, but also have the opportunity to create immediate value for the user. The MVP will not be exactly what the users wanted, but it will bring them one step closer to solving their problem. Instead of waiting a long time for the potentially perfect solution, you create small bits of help along the way to the full product.

So, let us head back to my project. My team and I are working on a possible digital service in relation to a physical product. We already have a digital product for the same target group. Our first step was defining our MVP. What would create user value and give us real feedback? Well, maybe informing our users about this physical product existence, and describe how it works. Just adding text in our digital product. Super easy and low effort, and enables us to track the effect this information has on the use of the real product. It is not even close to the digital service we might end up with - but, at this point we do not know if it is a digital service we should be making either!

…

Many designers are afraid their work will fall apart when forced into an MVP approach. But done right I believe your work as a designer can flourish and become more accurate. However, creating an MVP is not always the correct approach in digital product development. My point here is that even if such an approach may conflict with design methodology, it is not necessarily wrong. As designers we need to adapt our workflow and methods to the increasing speed of the digital world. Even though it hurts to release something that your gut tells you is not ready, it might be the best thing to do for the product and your users. We learn and grow the most when we go out of our comfort zone, so the pain is not necessarily bad, even though it hurts (so good).

So, let us sum this up:

• You will have to feel the pain of letting go of something that is not even half of what it should have been.
• You have to think short-term, day-to-day in some cases, even when your brain is screaming “IT’S ALL CONNECTED! I CAN’T BREAK IT INTO BITS AND PIECES!”
  

… but on the other hand

• You will always have up-to-date user insight
• You will have more granular knowledge about the use of your product
• You will be able to make changes fast (fix bugs, tweaks ect.)
• You will create value for your user earlier..
  

And, before you throw yourself out there. Here are some must haves when working with MVPs

• A team who values user centered development
• Logging: Tracking is key to learn as much as possible. Know your products numbers.
• Iterations: Anyone on board in this process need to understand that there will be rapid iterations. Without iterations, logging and a user-centered approach your product will stand alone as a far from finished and not an MVP.
• Do a more qualitative, thorough research from time to time. It helps on the holistic evaluation of the product, and trigger the long perspective.

A big thank you to Ola, Jens Andreas and Sonja for help along the way!