How we conducted 5 simultaneous workshops during a strategy meeting for a 200+ software house.
During my whole career as a market researcher-turned UX PM, and later: a manager and board member, I have been looking for effective and satisfying ways of generating great ideas. At first, my efforts focused mainly on fine-tuning ideation workshops for our clients who reached out to us asking for help in developing new product and services ideas. Then, a couple of years ago, my role changed and I became more responsible for the growth of our company, Divante. In those days, I often struggled with the nightmare of all managers: long, unfruitful, unactionable meetings that were aimed at finding new ways of developing the company, but failed miserably in most cases.
True story
As I was not alone with this feeling, I knew that something had to be done to improve things. So it happened that, for some time already, me and my Product Design team had been exploring Design Sprints as a possible solution for our clients, both external and internal (Divante develops their own products, Open Loyalty and Vue Storefront). We got trained and certified and so we’ve learned about Lightning Decision Jam. It seemed to be the best solution to our problem as it combined creative thinking with rigorous discipline and time-keeping, providing a stack of methods and tools for coming up with an actionable plan at the end. Perfect!
We started small, by conducting a Jam for our HR department to help them solve some of the issues that bothered them. The results were promising, as the team came away with many actionable insights on how to operate more effectively.
Having fun during workshops is a side effect, but the one we are ready to accept :)
Thus, I decided to use the method during the next strategy meeting we hold in Divante regularly, to keep all the managers up to date with our strategy and to find the best ways of executing it.
The challenge I faced though was that the group attending the meeting was quite big (more than 20 people) and their backgrounds were very diverse: from HR to Finance to Software Development to Sales. Therefore, one could predict that the problems to be solved will be as diverse, and there will be an issue of deciding which one to focus on. As we couldn’t have many separate meetings (one has to work sometimes ;)), I decided to go for a scaled version of Lightning Decision Jam, with a couple of groups working simultaneously. We weren’t sure if this approach was right but decided to give it a try.
Scaled version of Lightning Decision Jam
Here you have a description of the process we followed. In general, it based on the agenda settled by Jonathan Courtney, but with some twists:
1. Start with problems
During the preliminary discussion on our strategy and implementation, we came up with some problems that were blocking us. At the beginning of the workshop session, we completed the list with other issues during a short discussion. As a moderator, I kept it short, giving people approx. 10 min to complete the problem list.
Problems, problems everywhere
2. Present problems
When all problems were collected on post-its and stuck to a wall, I went quickly through the list, to make sure that we had a mutual understanding of each of them.
3. Select problems to solve
The first round of voting began. Each participant had two votes to promote problems which were, in their opinion, worth pursuing. As settled by the method, one could use both votes for one problem or give two problems one vote each.
When the exercise was finished, I ranged the problems by number of votes. We had one clear ‘winner’, with 6 votes and 5 others with 5 votes. The rest gathered up to 3 votes and we decided to discard them.
Now came the moment when we had to move away a little from the standard process – we had to decide how many problems we tackle during the session and who’ll join which group. This is when we fumbled a bit, as there were many ideas on how to solve it, but finally we did it in a very simple way: I put a problem on one of five tables we had in the room and people just joined the one they liked the most. Then we made some adjustments, to have more multidisciplinary teams, as it should help in bringing more diverse solutions.
4. Reframe problems as standardised challenges
It’s important to have the problems reframed to standardised How Might We’s, as it allows for more creativity during the next step. This one went quite quickly and smoothly, as some of the problems were already written down that way.
5. Produce solutions
This is when the magic happened :) I really like the idea of working on the solutions the way this method suggests: not by an unstructured and quasi-creative way of throwing random ideas at each other, but by working quietly on your own, producing as many solution for the problem chosen by the group as possible. I have to say that all participants went for this approach without any difficulties. I gave them 10 minutes to write their ideas on separate post-its and then stick them to a wall under the bigger post-it with the problem written down.
No discussions. No faked creativity. Pure effectiveness and focus – love it :)
6. Vote on solutions
The next round of voting had to be longer than the first, as it took time to read all the ideas and have a short explanation whenever needed. The room exploded with lots of voices but it wasn’t a problem – we worked in quite a big conference room so the groups had enough space to gather and not to interrupt each other. This part took another 10 minutes, until all of us had given their 6 votes on the solutions they liked the most.
Some of us had a very neat approach to sticking post-its…
7. Prioritize solutions
The votes allowed us to range the solutions. I moved from group to group and helped people arrange post-its by number of votes. This is when I discovered that some solutions became a group of similar ideas – the participants had seen some patterns in their proposals and grouped them accordingly. In my opinion, this was a very good side effect, as the solutions became more versatile that way.
He really liked it, believe me ;)
8. Decide what to execute on
Each group was given their own effort/impact scale and started to position their highest voted solutions along the axis. My role as a moderator was to help them start with the first one, by showing them how they should move the post-it up and down, left and right, to decide on which quadrant it should be stuck to.
An example of one of the effort/impact scales
During this step, I added another custom part: when all post-its were allocated, each team presented their work to others. I thought it would be good to share the outcomes across the whole team; moreover, it provided the presenting group with additional ideas and points of view. On the downside, this part became quite long (approx. an hour) and we lost the dynamics of the workshop somewhere between the 3rd and 4th presentation. That’s why I decided to have a short break and some energetic music played to bring the power back ;)
9. Turn solutions into actionable tasks
The last task was to choose the solutions located in the sweet spot of the scale (high impact/low effort) and change them into action plan, with clear steps for the person responsible for executing the solution. This step also included some discussions but very effective ones, as people had a clear vision of the problem and solution, so there were no problems with coming up with the plan for them.
With this activity, we finished the workshop. We had a short wrapping-up discussion, during which I collected feedback on the method. I’d like to share it with you, in case you plan to follow our steps in scaling the Lightning Decision Jam.
Feedback on scaled Lightning Decision Jam
What went well?
The most important thing is that we now know that it’s possible to have couple of sessions going simultaneously. It didn’t affect the performance of each group and there is an added value of exchanging the results between teams.
All of the participants agreed that LDJ is a very good method for problem identification and solving. People liked the time discipline, the quiet moment of concentration during the ideation part, the way their discussion became very focused and effective. By the end of the day, we had come up with five sets of solutions and action plans, packed with easy to follow next steps – something we’ve never achieved before.
What went not so well?
This was the first time I conducted a simultaneous ideation workshop and of course there are some things that need improving next time. First of all, the allocation to groups took too much time and discussion; we’ve agreed that maybe drawing for groups will be better next time.
People also complained that they didn’t have a possibility to work on other problems as well; I’m considering adding some rotation next time, to allow for that, although this can be tricky when you want to keep time discipline of the workshop.
An additional insight: while having couple of groups working at the same time, the moderator has to behave a bit like a sergeant ;) There were moments when I had to be very strict and determined while cutting the discussions and having all the people come back to the tables for the next task.
Free your inner sergeant. A bit
Will we continue doing Lightning Decision Jams?
Of course! Me and the PD team have already have a couple of other internal workshops queued, as all of our managers saw the benefits of such an approach. This will lead us to become a truly Design-driven organization in the future :)
We are also conducting such workshops for our clients with similarly appealing results. After this one, we know that it’s not only effective but also scalable, so can be used by companies of all shapes and sizes.
If you are interested in learning more on how we conduct our workshops or how we can help you tackle your problems that way, just contact us and we’ll be more than happy to discuss it with you.
Published March 14, 2019
