Design sprint prototype to real world MVP

You may have read my previous blog post about the first design sprint we ran at accuRx. This post follows on from that and covers our steps from design sprint prototype to MVP in the hands of 12 users.

Unlike when setting out on the design sprint, the internet wasn’t quite awash with as many blogs/videos on how to keep up the momentum to turn your high fidelity prototype into a production reality. So this is how we approached it.

The Design Sprint

We came out of our design sprint with a high level of confidence in our messaging prototype. We tested with 7 users and there were clear recurring themes about how the product could improve their ways of working and add immediate value. Particularly around saving time. Which we know is a huge delighter for healthcare teams.

However, we still had a number of unanswered questions that the design sprint either didn’t help with, or that the choices we made to limit the scope of our sprint meant we hadn’t had an opportunity to test. The questions / challenges were:

• Our prototype only covered half of our expected user journey, given we were planning to take on email, how would we identify what a realistic MVP was for the whole journey.

(note: all images are of dummy patients)

Original sprint prototype finished on the send confirmation screen.

• How do we keep getting iterative feedback on the product we are building
• How do we keep up the great momentum we got from the design sprint

Divide and Conquer

One of the things that we really enjoyed about the sprint process was all being in a room together and working on the same problem. However, we all agreed that to turn our prototype into a real world product we couldn’t keep working like that.

We divided up the work to make the most of the skills in the team. This fell into two broad categories:

• Development: There were a lot of ‘knowns’ about what we wanted to build, even if we hadn’t been able to test the whole journey. So as soon as the design sprint had finished the engineers started on building out the basics. Given we were using email as our core functionality there was lots we could do to get going without worrying too much about how it would work or look for the user.
• Product: The focus was on testing ideas for the rest of the journey and analysing the outcomes from research to identify what the MVP could be. We re-used parts of the sprint process, particularly the sketching and dotmocracy sessions, to move us forward quickly and keep us focused. Given that we were extending our Figma prototype to show the rest of the journey we benefited a lot from components we could re use.

We also made a decision to reduce the level of personalisation in our prototype. Whilst this had been really important in our design sprint and helped gather reliable feedback from users, we now had other demands on our time and decided to sacrifice this.

Always be testing

Once we had a full journey we got back in touch with the participants from the design sprint as well as those who had expressed an interest in testing but were unable to. Going back to these users had a lot of added benefits:

• It reduced the recruitment time as we knew people were already interested and we didn’t have to start with cold emails etc.
• It allowed us to take people on a journey by showing them our iterative improvements and the completion of the journey.
• It gave us a group of users who were really brought in to the product and were interested in what shape it would take.

Set a realistic MVP

One of the best things about testing with users who we had already shown the finished product was that we felt really comfortable showing them a very basic MVP. I wanted to get something in the hands of users ASAP so we went with the minimum thing which we thought could add value. That meant the MVP didn’t let you add attachments, delete messages or even put them in a separate folder but the integration with the patient record meant it had enough value for people to start using it.

A fair question is: Why ship a product when you know that users will want the things that are missing?

The simple answer is to learn more. We know that users want those key features and we are working on them so releasing without them is an interesting test. If we get asked for those features we can say they are coming soon, but what if there is something else we haven’t thought of that people ask for more or that the data tells us is missing? In research people have a natural tendency to please, so what if people were being nice to us and our idea wasn’t actually very good. Why pass up the opportunity to learn about what you don’t know rather than wait and get more validation on what you already do know.

So has it worked?

I think so. We released just before Christmas, which we were worried would slow down our momentum, but a practice contacted us on Christmas eve to turn it on for all their users.

We’re seeing it being used for real communication with pharmacies and consultants and responses are coming back in. Which is great, because it meant that releasing the MVP early was the right call. We’ve since had feedback about other features that would be useful for people which is insight we wouldn’t have otherwise gained.

Next steps

Build out the the features that we know / believe we need to build. We’ll do this iteratively so that we can keep a close eye on the value we are adding and the problems we are helping to solve. I’ll post again when we take our next big scale up step and let you know how that goes.

If you worked in a similar way, or did something completely different, I’d love to know how it went. Do get in touch.

Thanks

Matt