Discover more from timo's substack
Using EventStorming when building internal data products
why data teams need to become the domain experts of all domains in a company
When I was 16 years old, I loved adventure games. And all my friends loved them too, and we spent afternoons discovering Monkey islands or Maniac Mansions.
But I had a problem. While my friends had no problem investing hours and hours in figuring out where to find this missing piece or the right words for a pirate sword contest, I didn’t have any patience for that.
Which was a pity because I was so much into the stories of these games, and I wanted to learn what would happen to Guybrush and Elaine, about Zack and the aliens, and what makes Edna tick in her mansion.
My solution? Cheating.
I let my friends tell me the instructions. And I used walk-throughs from magazines (yes, that was pre-internet as we know it). Was that bad? My joy came from expiring the game’s journey, not solving the puzzle.
If I built a trillion-dollar app today, it would be a walk-through for start-ups. You would buy it, follow the setups, and enjoy the journey, the fame, and the fireworks exit. Yeah, that would be great. But stop dreaming; I don’t have this app for startups 😱😢.
But I have it for data teams who want to build internal data products. And I am giving it away for free—here and today.
Let’s unpack it.
What you can get as a data team is a detailed map that shows where you can find your impact treasures. Clear in the open, to surface with a bit of work.
So where can you get this treasure map?
You provide the canvas and let your internal customers paint it.
Let’s dive into it.
The good news is that a very simple workshop format will help you map out how a team in your company works.
Why are we interested in how a team works?
In data, you will often hear: “try to learn about the problems the team wants to solve and base your work around it.” But problems are problematic. They often include aspects that can’t be controlled easily. And they tend to have too many input variables and complex interconnections. And by this, they can quickly become hard to solve and will eat your resources for breakfast.
Focusing on the functions of a team is much more straightforward. First, it is much easier to map and understand the function (this is what we will do with Event storming). And it is a lot easier to help to improve functions. It’s just optimization. And data teams are extremely good at optimizing things.
What is EventStorming
It is a specific workshop format to make actions, events, actors, and more visible in a particular domain. Alberto invented it in the context of Domain Driven Design. But I find it extremely useful in all different areas where you must figure out how things work together.
In an EventStorming workshop, a group of people with domain knowledge map out (or storm out) all events from a starting point to an end state.
They start with the events that are happening along the way on a timeline. Then extend these events with specific actions that trigger the event, systems involved in the events, what kind of data is needed, and where open questions and challenges are.
The process can take a while. 2-3h or longer sessions are not rare depending on the scope of the analysis.
The outcome is a massive map with all events, actions, actors, systems, and data covering a specific function of a domain.
The workshop can be done in person, using a huge whiteboard or wall to map things. Everyone gets post-its that represent the different assets:
- 🟧 Orange: Events
- 🟦 Blue: Actions/Command
- 🟨 Yellow: Actor
- 🟪 Purple: Business Rules
- 🎟️ Pink: External System
- 🟩 Green: Data needed
- 🟥 Red: Errors, Challenges
But it also works fine in a remote environment using tools like Miro, Whimsical, or others.
Sounds good so far? Let’s show it in an example in the next step. But before some links to watch some videos and find templates:
- Miro Template: [https://miro.com/miroverse/event-storming/]
- Website: [https://www.eventstorming.com/]
- 50.000 orange stickies later: [
- EventStroming for fun and profit: [https://speakerdeck.com/tastapod/event-storming-for-fun-and-profit]
If you want to see it in action: Watch my free course for EventStorming for Tracking Design (just ⏰ 30m).
Example EventStorming sessions for data teams to understand how other teams are working
Product - How does a feature lifecycle work.
Understanding how the product team and the product engineers work on and release features is a powerful asset. Data can significantly help product and engineering teams to save time and learn about future features. But it is crucial to know which data and where to apply it.
You invite a product team into a workshop. This should include all roles, from feature ideation to deployment and analysis.
In the session, let all persons map out all the required steps until a feature is released.
Listen carefully for these things:
- Where is uncertainty - where are multiple back-and-forths? You usually hear when people describe situations where they are not sure.
- Ask for times between different events - go deeper on the ones that take longer. Ask the usual plenty of whys to understand why it takes so long
- Pay attention to the data needs. These sometimes come hidden, with sentences like - “we would need to know.”
- How do they follow up tests and early releases - what can be exciting for them when a feature gets released (and usually gets a lot of attention across the company) - learn how you can help them to shine (it will shine back on you)
Growth - How to run experiments
Usually, growth teams work around experiments. If not, it would be good to understand their work and map their approach to growth activities.
The experimental approach is powerful since it requires good data to move quickly and with solid insights.
Listen carefully for these things:
- How do they design experiments? What kind of data do they take into account for the design
- How long do the experiments run, and how does it take to set them up - can you help them to speed things up? With different models to analyze the variant data?
- How do they analyze the performance? Locally for the experiment but also globally - can you help to develop some templates that can easily be applied to new experiments
There are plenty of more examples. Just talk initially to different teams and ask them about their primary functions. If they struggle to tell, you can do a storming session and map out what the team did in the last 30 days or three months.
Takeaway: Are you an internal consultant now?
Yes, you are like an internal consultant. As a data team, you are, in 95% of all cases, dependent on other teams that implement your insights or put your data into workflows.
Therefore your first task is to understand how the different work and function. These maps of their ways of working will be precious for all discussions you will have in the future.
Use them in catch-up meetings and update them when something has changed.
Use them in feature meetings, asking where in the process the requested data or feature can help the team and how. Even this small thing will get exciting answers and usually leads to different implementations than the usual dashboard no one is looking at.
Tell me how it went when you did your first storming session.
And don’t forget to subscribe to get my next post on how to build internal data products.