Post Traumatic Design Sprint Disorder

What happens after the design sprint, and how can you transfer the inspiration and the high pace into a more production oriented phase where stuff will actually be built. For real. I have some ideas.

Design sprint done — You did it! 🙌

So you just came out of the last day of the design sprint. You’re exhausted but also all bubbly and excited over how much this small team could accomplish in just a week. The facilitator of the sprint was so awesome and inspiring. And the ideas you came up with! Top class super innovative ideas that will change the world. Your test users all loved the service and they are already asking for the release date.

High fives around the table. This will be great! What now?!

Fast forward 2 months. At most companies one of the following things has happened:

1. Nothing. This was just a fun exercise to bring some energy to the team. A theatre. A show.
2. Management asks what they always do. What will it cost? And so starts the cumbersome task of writing specifications along with detailed cost estimations of all the things in the prototype the sprint didn’t handle or just took for granted. CRM system integrations. GDPR issues, legal texts, translations, market rollout. You name it. When specification is finally done and an investment cost is calculated the project is put on ice because bad ROI, too expensive or any other money or resource related reason.
3. You don’t have the internal resources or competence in place to take this any further.

Bubbly feeling gone. Shiny prototype forgotten. Train gone. Curtains close.

You are experiencing the Post Traumatic Design Sprint Disorder. And it’s not fun.

I’ve seen it happen a lot of times since I started using the design sprint process. It’s not the design sprints fault. It’s just that you’ve now moved beyond the responsibility of the design sprint and find yourself in the vacuum between innovation and execution. And there is no predefined process on how to proceed. Some advice you to go into an iteration sprint and then hand over to production. But since the concept of handovers gives me a rash I’d like to propose another way. So let me try here.

High speed execution in a complex environment 🚀

Let’s get some things straight first. Many times after a design sprint you end up in a situation where you will need to pivot or iterate your idea , change the prototype or even do another design sprint. I will not focus on those cases here. This article focuses on the times where the outcome of the design sprint is an advice to actually build something. A product or a service that requires a team with a skillset in the digital product building area.

Keeping the speed up 🏃🏽‍♀️

One thing the design sprint is really good at is to get a bunch of people in deep focus mode. That makes the high speed possible and this, I have seen, is extremely inspiring to people. It makes work fun again. Therefore I highly believe that it’s very important to keep up the speed and momentum when moving into execution mode. Or week 2 as we sometimes call it. To do this a few things need to happen fast:

1. MVP definition. Many projects fail because you want it all done at once. Having the same brutal way of handling time as in the design sprint is crucial. You will need to prioritise hard. Real hard. And then keep on prioritising in every iteration of the product. At any point in time you should always focus on what’s needed. So as a first step I often bring in more experts on the specific service area, sit down together and do an MVP definition of what is needed to move from prototype to a releasable product. Here you could for example use tools like the Value vs Complexity matrix. Don’t overdo it. Start small and iterate only when you have proved value. Doing this right will mean that the effort to start a first iteration will be manageable, even to the people deciding on money. Which means you have a better chance of actually moving into first stage of execution.
2. Set a team. Gather a small team of experts. It’s important that the team have full autonomy to make quick decisions and always move forward. All the competences you will need to move forward and take decisions has to be either directly in or highly available to the team. I would also suggest trying something like the team canvas to get everyone on the same page and working towards the same goals.
3. Start building. I tend to propose working in 2 week sprints and aim at having something releasable already in the first or second sprint. Yes, that means you need to have a production environment up and running on day one of the first sprint. If that’s not possible, your requirements are wrong and need to be revisited or you need better tools and processes for CI/CD etc.

Autonomous teams & serverless architecture ⛅️The key for a successful team is autonomy. The freedom to choose tools, architecture, programming language cloud services etc. In my experience there is right now no faster way to build a digital product than basing it on a serverless architecture in one of the cloud vendors ecosystem, AWS, Google Cloud or Azure. Working with a serverless microservice backend and a progressive frontend framework (like React or Angular) you will have all you need to get going. And by utilising the great ci/cd tools from any of the clouds you will also make sure you have an instant production environment up and running in no time.With an approach like this your organisation will have the bandwidth to launch 10–20 products per year instead of the 0 you are doing now.So feel free to use these things to get your a head start on your competitors. It’s never too late. And I would love to get your feedback and ideas on anything related to this article and topic. Contact information below.Now go build something! You rock(et).Epilogue / CommercialWait what!? Almost at the end and no quote? Well ok, here’s one. From me. That I just made up. Use it.How to launch a new service or product? Easy! Team up with great people, let the cloud be your launchpad and serverless your rocket fuel. Liftoff!
- Johan Uddståhl 2020Oh, and by the way, wouldn’t it be great if there was a company that were experts at running design sprints AND had the people, tools and processes to get things out in the real world? Sounds very unicorny right?Well, tell you what!
We were very early in adopting the design sprint as a great tool in our way of working, but where other companies leave you with a clickable prototype in Invision (to be filed away and forgotten) we make sure you get a product on the market.At Humblebee we have delivered several products with this approach. You can read all about them at our work pageIf you are interested I would love to speak to you about your challenges. Ping me on LinkedIn or contact me at johan.uddstahl@humblebee.se