What happens after the design sprint finishes?
Design Sprints look great but do they actually deliver anything tangible except a sea of post-it notes? What are you left with?
Jake Knapp’s excellent book ‘Sprint’ has propelled design sprints into the limelight. If you don’t know what a design sprint is, here’s a 90 second video explanation from the author himself.
Now, I love sprints – but what happens after they end? Having run a sprint myself, I can now reflect on the aftermath. I’m hoping my thoughts might help you if:
- You’re considering running a sprint yourself
- You’ve been invited to participate in one
The latest iteration of the sprint adds up to 4 days of intense work. So, what can you expect after it’s ended? How can you maintain that momentum?
In another great book, The Jelly Effect by Andy Bounds (a book more about business communication than sprints), the author describes what he calls ‘The AFTERs’. Here’s a quote that says it all…
“Audiences don’t care about what you say. They only care about what they are left with AFTER you’ve said it.”
So in the spirit of that book, I want to talk about what happened AFTER our very own sprint.
First of all, a tiny rewind…
- The book that started it all
In a LinkedIn post back in November, I talked about running a design sprint. The team and I designed, prototyped and tested a brand new product in 4 days.
What were we left with? I think we found a really engaging process that produced a good prototype. Our client was excited about what we made. But, after all the post-its were posted, wipeboards covered in pen and mock-ups made… it all went a bit quiet.
Immediately after the sprint
So now firmly out of sprint mode, we collated the research feedback, then we tweaked the prototype.
We then made a video showing a tour of the product to demo the main features. So we could show the investors how the product would work and how it might be marketed.
We spent time modelling the numbers to show how much it would cost to launch the product, the right channels and how many users we could expect to recruit.
We pulled this together neatly into an investor deck that – at time of writing – is ready to do the rounds.
We also hunted around for potential dev partners. At this point, we still hadn’t decided if it’s an app, website or Chat solution. Truthfully, I think this was an oversight on our behalves… not lining up a dev partner was a mistake (as you’ll see below).
My thoughts: how to improve on sprints
On reflection, my criticism is of our process. It was a bit fast-slow.
Well actually, it was more fast-stop.
Immediate response is integral to sprints
What I mean by that is… during the sprint, the team is together and able to make fast decisions. There is focus, energy and collaboration.
With consensus in the room, thinking is challenged and differing points of view can be exchanged and resolved quickly. It’s all exciting stuff and we got to a solution that we had validated in the user tests.
To get to where we got to WITHOUT a sprint would have taken weeks if not months. Of that I’m certain.
But, as soon as the sprint finished and everyone returned to the ‘real world’, we lost that dynamism. I know that’s obvious but it is an immense come-down.
Hello darkness, my old friend
The end of the sprint reminded me of going to a conference. You hear and see amazing people speak. You learn and feed-off their energy.
Your mind starts firing about how you can use what you’ve learned to solve that problem you’re working on…
Next day, reality returns and that energy disappears. The conference and speakers fade into memory. Your inspiration goes cold turkey. I don’t think we mean to let it happen, it’s just that life takes over.
I’ve heard from others who don’t go to conferences say ‘what will I walk away with?’ ‘What will I learn” So the AFTERs mentioned above in The Jelly Effect really resonate here.
Sprints hog time
In hindsight, should we have run another sprint to iterate the product and do all the numbers? A sprint on-top of a sprint?
Perhaps. But those jobs need intense time spent creating spreadsheets and designing interfaces. They tend to be done solo, not as a group. They don’t feel sprinty (made-up word).
There’s no doubt: sprints demand commitment and discipline. And that’s not always possible for all the people involved. The practicalities of getting the team together again are tricky because we all have other things to do as well as sprints.
… Unless your name is Ross Chapman. He does this sprint thing for a living.
What does it take to become a Sprint champion?
Ross is Head of Design Sprints at Etch. He knows a lot about the process and I was intrigued to read that he’d hit this type of post-sprint problem before.
Here’s a post by Ross that explains more. Ross describes what he calls ‘iteration sprints’…
“….what is less well documented is the Iteration Sprint, which happens the week after. This is where the team iterate based on the feedback from the previous week and get ready to handover to the next team, likely being a digital production team.”
So by the looks of it, the Iteration Sprint is what we should’ve done. Or at least we should do next time around. The only snag is… we don’t always have a production team to handover to. Mainly because our client often won’t have got that far.
As a team, we tend to sprint very early in the overall process. Which ain’t a bad thing in my opinion.
But, maybe we can line-up a development or production partner when we’re planning the next sprint? Or, at least someone or something to handover to before the countdown to the sprint starts ticking.
I’m now thinking of it as sprint succession-planning!
It looks and feels like this could be a good way of keeping that dynamism and energy flowing and avoiding the cliff edge. So that’s what we’re working on for now: how to avoid going from Fast > slow > stop!
In summary: sprints are part of a bigger picture
What I’ve found is that design sprints are just the beginning. They can kick-start the problem-solving but they aren’t always the definitive solution. Nor should they be. Any idea needs to evolve and change. So the sprint is not a ‘magic bullet’.
Are sprints worth it?
One of the reasons I wanted to write this post is to help those NOT familiar with the sprint to see them as the start of something.
It’s fair to say that in some quarters, sprints are seen as “fads” – I can understand that point of view. If a sprint’s pitched as the end solution, it’s doomed from the start and the expectations won’t be met.
How to manage a sprint effectively
Clients/product owners will want to know what they’ll get from a process so you need to manage that expectation too. Human beings want certainty. Or at least the illusion of some linear process that leads somewhere. Whilst that’s kind of contrary to the sprint ethos, you don’t need to be too descriptive of what stage 2 will look like but you do need somewhere else to head to.