From Brainstorm to Blueprint: A 2-Day Problem-Solving Workshop (Part 1)
Have you ever had a problem that needed solving but didn’t want to spend weeks lost in endless discussions, alignment meetings, and half-baked Slack threads? Same.
In my last role as a Data Product Manager, my team faced an ongoing challenge: centralizing data alerts so all Engineering teams could access them in one place and take action. As the company grew, managing and communicating these alerts became increasingly complex. We had explored the issue multiple times, but we hadn’t quite landed on a clear path forward.
So, I asked myself: How do we go from endless brainstorming to actual planning in a matter of days—or even hours?
Enter: The 2-day workshop.
This two-part series breaks down the workshop I designed to take my team from problem definition to solution exploration. Could I have crammed everything into one day? Sure. But Facilitation 101—if you want your team to engage and not fake a Wi-Fi outage mid-session- is: don’t overpack your sessions.
Let’s dive in.
(Note: Images are purely for visual effect—actual content has been redacted.)
DAY 1: DEFINING THE PROBLEM SPACE
First, we needed to fully understand the challenges at hand. Sure, we had talked about them before, but this time, we were going to document them properly so we could actually build on them.
Exercise 1: Long Term Goal
Kicking things off with a Long-Term Goal sets the tone and gives everyone a sense of direction. We spent five minutes brainstorming, then voted on the top goal. Encourage each participant to come up with a few statements. Once you have your top goal, if needed, reword it slightly and then write it in BIG BOLD LETTERS on a blank sheet or whiteboard. This will serve as your guiding light throughout the sprint.
Brainstorm: 5 mins
Vote: 1 min
Exercise 2: Note-N-Vote- Mapping the Current Experience
I wanted every engineer to map out their personal experience of resolving an alert when something went wrong. This wasn’t just for individual reflection—it was a chance for the team to see different workflows, identify gaps, and catch nuances they hadn’t noticed before.
Each engineer mapped out their process in three parts:
Actor (who’s involved?)
Steps (what happens?)
Outcome (how does it resolve?)
(Pro tip: Always start with the first step and the outcome—it makes filling in the middle much easier.)
Mapping: 15 mins
Presenting: 5 mins per person
Voting on key steps: 2 mins (4 votes per person)
Give them a few guidelines like below:
The output should look something like this:
To keep discussions focused, we used pink sticky notes for questions. As each engineer presented, others wrote their questions silently and stuck them under the relevant step. This avoided interruptions and let the presenter address everything at the end.
Once all maps were shared, the team voted on the most critical steps—the ones that stood out across multiple maps. These would become the key problem areas our solution needed to address.
Exercise 3: Main Story Map- Bringing It All Together
Next, we combined the highest-voted steps from all individual maps into a single, consolidated Story Map—our core artifact for the rest of the sprint.
No need to create new steps. Just take the voted steps, arrange them in order, and boom—you’ve got a structured view of the problem.
(Pro tip: Try to create buckets to group the steps in the journey together. This is very useful to quickly understand which part of the user journey deserves the most attention.)
Create the Map: 20 mins
Vote: 2 mins (3 votes per person)
To further refine, we did another quick round of voting. This two-step mapping process (individual first, then collective) was a game-changer. It was fast, efficient, and avoided groupthink.
Think about it: If we had done this through an open discussion, we would’ve spent an hour (at least) listening to four engineers share their workflows, debating details, and figuring out key areas. Instead, we nailed it in under 25 minutes. That’s the power of a well-structured workshop.
Exercise 4: How Might We- Framing the Challenge
To wrap up Day 1, we ran a How Might We (HMW) exercise—essentially a way to reframe our challenges as opportunities.
By pulling the most critical step from our Story Map, we could craft a focused, actionable HMW statement to guide the next day’s ideation. This kept us from spiraling into vague or overly broad problem-solving territory.
And just like that, we had clearly defined our problem in a matter of hours, not weeks.
In Part 2, I’ll break down how we tackled the Solution Space on Day 2—stay tuned!