The Design Sprint is a process that radically changes the way that you work for a week to be more effective than you’ve ever been. Everyone we’ve worked with that goes through this process loves the change of pace and the quality of the work that comes out of it, but there’s still a mental barrier to placing a bet on 4 to 5 days for a lot of folk. A company that I personally follow closely is AJ&Smart and they have curated an exercise called the “Lightning Decision Jam” (LDJ) to give you a taste of what a Design Sprint is like. I want to share with you the first time I ran the LDJ internally with the technical team here at thestartupfactory.tech.
What is the Lightning Decision Jam?
The Lightning Decision Jam is a way for you to get a group of people all on the same page, identify problems from all angles, generate solutions and create action points to test out in the next week. It’s great to use when:
- There are many issues or problems.
- Team morale is low.
- You need to take action, fast.
It only takes 30-60 minutes, depending on how many problems and solutions you can generate, and is a fantastic way to prevent endless discussions and finally take some action. Below is a video if you want to learn more how to run the Classic version. Below that is the UPDATED version that AJ&Smart released just last week!
Updated LDJ: LDJ 2.0 via Youtube.
If you’re not so much of a visual learner and want to read about it instead, you can check out the (original?) blog post about the LDJ here:
Our LDJ: Step-by-step
Before we begin I always like to brief the entire team on what to expect, how long it’ll take approximately and the mindset we need to get into. This is super important, because the best results come when you have the right mindset and attitude. It broadly boils down to:
- No wrong answers– anything goes.
- Taking action > endless discussion.
- Decide on action points we can try in the next week.
Step 1: Generate Problems
We decided to set a general theme around “technical challenges” that we have been encountering at TSF.tech, and used 7 minutes to generate as many issues as possible independently. We really did strive for an “anything goes” attitude as one of the post-its states that “Chuck is not a developer” as a technical issue, and it wasn’t me that wrote it. Which is true, I do still end up writing code from time to time when the need arises!
Step 2 and 3: Present and Vote on Problems
Step 2 is straightforward– take 4 minutes each to present the problems we’ve identified to the rest of the group. Afterwards, we get 6 minutes to place 2 dot stickers each on the problem(s) we want to focus on. Any post-it, doesn’t matter if it’s yours. Just vote!
Step 4 and 5: Prioritise, and Reframe as “How Might We”
This is my favourite step, and I think the team enjoyed it too. Organise the problems based on their votes and pick the most popular one. Got a tie-breaker? Pick the left one. Brilliant! The post-it we went ahead with simply stated “boiler plate”.
Reframe these as a How Might We question, or HMW for short. This feels unnecessary to the untrained eye but this helps act as a connector between selecting the problem we want to focus on, and creating a consistent and concise understanding with which to generate solutions from. I’ve found that having the same format in my independent work has always paid dividends downstream in my workflow.
Step 6: Generate Solutions
Very similar to when we generated problems, but this time the focus is on generating solutions. I love this part of the workshop because by this stage everyone seems to be in a creative and engaged mood and the outcomes are brilliant. I think even though we could do some sort of “priming” when generating problems at the beginning, 9 times out of 10 the group already has a set of problems in mind they want to discuss and solve. Solving the issues we’re worried about already as a team is more important than solving the the “hidden” issues.
Step 7 and 8: Vote on Solutions and Prioritise
As before, but this time we have 6 (yes, six) dot stickers to distribute on our favourite solutions*. After everyone has cast their vote, order them as normal and keep all of the post-its with votes this time as we’ll need it in the penultimate step.
* N.B. taking action is more important than endless discussion.
Step 9: Decide what to Execute
This is probably my second favourite step in the process, which is to place the solutions with votes on an effort/impact matrix. There are other scales you could use such as the ICE method (Impact, Confidence, Effort) from the Growth Hacking community, but for something that’s only meant to take a week I’m satisfied that this is sufficient enough to make an educated guess. Perhaps my opinion will change after running many more of these.
Step 10: Craft Actionable Tasks
You only need to spend 5 minutes on this last part, as the timeline is already set at 1 week’s worth of effort. It doesn’t seem like a lot, but that’s all you need to come up with some effective takeaway tasks after working through all the previous steps. What we could have done better at this stage was assign an accountable person, but with the technical team as nimble as we are I think we could (just) get away with it this time. I would definitely strive to have an accountable person together with a time frame assigned for the tasks we’ve put together.
What did the team think?
As much as I enjoy the process and believe that we came to some really effective action points based on some real issues the technical team is worried about, the most important thing is what the team thought. At this point it’s critical to have a quick debrief with the team, ask how it compares to what we would have done otherwise, and check in on team morale. Perhaps I’m slightly biased but I think it did recharge us all a little bit, even if after the workshop I was ready to take a long coffee break and stretch my legs.
What about the outcomes and action points? Well, it’s up to the team to hold themselves accountable. As long as we’ve made more than no progress, then I’m happy to declare this LDJ a success. We’ll have to check in this Friday, as we aimed to give ourselves about a week and planned to commit our R&D time this coming Friday on one of these action points.
Similarities to the Design Sprint
There are a set of principles from the Design Sprint that are very similar to how a LDJ is run, and I think it’s a great way to give people a taster in a short period of time before making the commitment to try out a full sprint.
- Get everyone on the same page. This is critical because typical ways of working has everyone disjointed and coming in from different angles at different times. By purposefully having a shared “brain” i.e. the whiteboard for all of us to work against gets us to work together.
- Work alone, together. All of the problems and solutions are original thoughts from each of the participants. This helps to avoid biased groupthink and allows us to highlight and share our genuine concerns.
- Divergent and Convergent thinking. Most UXers or Designers will refer to the “Double Diamond” way of thinking. In this short period of time we take the participants along two sets of divergent thinking (unlimited possibilities) and convergent thinking (narrowing down to a choice) paths, common in creative circles.
I hope you got a good look inside not just what the Lightning Decision Jam is as an exercise, but got a taste of what the Design Sprint might be like, and got to see what it’s like to work with thestartupfactory.tech.
You can always get in touch with us via the usual channels, or join my Meetup group to learn more about Design Sprints and participate in one of the free LDJ workshops: Design Sprint Forum MCR.