After four weeks of building the wrong thing, the Greenbox team knows they need a different approach. Lee’s advice was clear: get the domain out of Maya’s head and into shared understanding before anyone writes another line of code.
The technique Lee recommends is Event Storming. It was created by Alberto Brandolini, and the premise is disarmingly simple: get everyone in a room, cover a wall in sticky notes, and map out how things actually work as a series of events.
No code. No architecture diagrams. No user stories yet. Just: what happens, in what order, and where are the hard parts?
It sounds almost too simple to be useful. That’s what Tom thinks when Maya suggests it. “We’re going to spend three hours sticking notes on a wall?” But the simplicity is the point. The sticky notes are a constraint that forces everyone to express ideas in small, concrete units. You can’t hide behind vague hand-waving when you have to write a specific event on a specific note.
What you need
Event Storming doesn’t require fancy tools or expensive facilitators. You need:
- A long wall (or a very long roll of paper stuck to a wall)
- Sticky notes in four colours (orange, blue, yellow, pink – Lee will explain what each means)
- Markers (one per person – thick ones so you can read the notes from a distance)
- Everyone who matters in the room: developers, domain experts, product people, operations
- Two to four hours of uninterrupted time
Setting up
Maya books the meeting room with the biggest wall. She grabs sticky notes from Officeworks – four packs, one of each colour. She invites the whole team: Tom, Priya, Jas, Sam. She also invites two of her farming contacts, Dave and Rachel, who she hopes will eventually supply Greenbox. They know the supply side in ways the team doesn’t.
Dave Morrison arrives ten minutes early. He’s been to “workshops” before – the last one was run by a government agricultural adviser and produced a glossy brochure that nobody ever opened. He’s here because Maya asked personally, and because she grew up on a farm, and because that counts for something. He shakes Lee’s hand and eyes the wall of blank paper with the expression of a man who has seen a lot of fences built in the wrong paddock.
Rachel, who runs a smaller mixed farm nearby, mentions her “dodgy broadband” when Lee hands her a marker. “Took me twenty minutes to load the map to get here,” she says. “Satellite internet. Works when it feels like it.” Nobody thinks much of it at the time.
Seven people. One wall. Three hours blocked out on a Tuesday morning.
Lee offered to facilitate, which helps enormously. The facilitator’s job isn’t to have domain knowledge – it’s to keep things moving, ask awkward questions, and make sure the quiet people get heard. You can run a session without a dedicated facilitator, but it’s harder. Someone inevitably gets sucked into the content and stops managing the process. If you can borrow someone who’s done it before, do.
Phase one: chaos
Lee starts by explaining the format. He holds up the four colours of sticky note and runs through them quickly:
- Orange – things that happen, written in past tense. “Payment Submitted.” “Box Packed.” “Farm Confirmed Availability.” These are the backbone – the story of how the business works, told as a sequence of things that already happened. (Lee calls them “domain events,” but at this point nobody cares about the jargon. They’re just things that happen.)
- Blue – decisions or actions that make those things happen. “Submit Payment.” “Pack Box.” Someone or something chose to do this. If orange is “what happened,” blue is “what triggered it.”
- Yellow – who or what is involved. A customer clicking a button. A farmer calling with availability. A scheduled job that runs overnight. The people and systems in the story.
- Pink – problems, questions, disagreements. Anything that makes someone say “wait, how does that work?” or “I thought it worked differently.” “These are the gold dust,” Lee says. “When you spot something that doesn’t make sense, or that two people disagree about, slap a pink note on it. Don’t try to resolve it now. Just mark it. We’ll get to pink notes later in the session – for now I just want you to know they exist.”
“We’ll start with just orange,” Lee says. “Only events. Write each one in past tense on an orange note. Don’t worry about order. Don’t worry about getting it right. Just get everything out of your heads and onto the wall. Keep the pink notes in your pocket for now – we’ll come back to them.”
He gives one important instruction: no talking during this phase. Just write and stick. Conversation comes later.
He sets a timer for twenty minutes and says go.
What follows is beautifully chaotic. Everyone grabs orange sticky notes and starts writing. Maya is writing rapidly – “Farm Listed Produce,” “Box Packed,” “Subscription Created,” “Weekly Menu Decided.” Tom writes “Payment Processed,” “Account Created,” “Subscription Cancelled.” Priya writes “Inventory Updated” and “Farm Onboarded.” Jas writes “Customer Signed Up” and “Box Previewed.” Sam writes “Delivery Scheduled” and “Customer Complained” (Sam always thinks about the operational realities).
Dave, one of the farmers, writes “Harvest Confirmed,” “Surplus Reported,” and “Growing Schedule Committed.” Rachel hesitates over her next note, then writes “Crop Failed” quickly and sticks it on the wall without looking at it. She’s thinking about the 2019 frost that wiped out Dave’s entire tomato crop. Dave sees it go up and his jaw tightens, but he says nothing. Rachel also writes “Delivery Window Missed” and “Price Renegotiated.” These are events the team hadn’t considered at all. Nobody on the Greenbox team had thought about what happens on the farm before produce arrives at the packing facility.
Priya notices Rachel writing “Crop Failed” and reaches for a pink note – she has questions. Lee catches her eye and taps his watch. “Good instinct. Hold that thought for the pink notes phase. Right now, just orange.” Priya nods and puts the pink note back, but she doesn’t forget the question.
Within twenty minutes, there are about sixty orange sticky notes scattered across the wall in no particular order. Some are duplicates. Some contradict each other. “Payment Processed” and “Payment Confirmed” might be the same event, or they might not. “Customer Signed Up” and “Account Created” look like duplicates. That’s fine. That’s the point. The goal of this phase is volume, not precision.
Phase two: the timeline
Lee gets everyone to step back and look at the wall. “Now let’s put these in order. Left to right, earliest to latest. Talk to each other. If you disagree about where something goes, that’s interesting – stick a pink note on it and we’ll come back to it.”
This is where the real conversations start.
Maya picks up “Farm Listed Produce” and puts it early on the timeline. Tom picks up “Customer Signed Up” and puts it at the start. Priya asks, “Which comes first – do we need farms onboarded before customers can sign up, or can customers sign up before we have supply?”
Maya pauses. “Good question. We need to know we can fulfil before we take subscriptions. So farm onboarding is first.”
Tom didn’t know that. He’d been building the subscription system in isolation, assuming customers came first. One sticky note conversation, and an assumption is surfaced and resolved.
But Lee notices a pattern forming. Maya is the one placing notes with confidence. Everyone else is asking, deferring, moving on. The pink notes – the disagreements – aren’t appearing.
This is exactly what Event Storming is supposed to prevent. If one person places all the notes and nobody disagrees, you haven’t built shared understanding – you’ve just transferred one person’s mental model onto a wall. The whole point of getting everyone in the room is to surface the places where people see the domain differently. No pink notes doesn’t mean there are no disagreements. It means the disagreements are hidden – buried under politeness, deference, or the assumption that the founder must be right. Those hidden disagreements don’t go away. They become bugs, missed requirements, and late-night arguments in sprint three.
He tries a direct prompt. “Tom, challenge one of these. Is there a note that might be in the wrong place?”
Tom glances at the wall. “Looks right to me. Maya knows the farming side better than I do.”
Lee changes tactic. He walks over to Dave. “Walk the supply side of this timeline with Tom. Tell him what actually happens on a farm between committing produce and it arriving at the packing facility.”
Dave pulls “Farm Listed Produce” off the wall and holds it at arm’s length. “This makes it sound like I sit down on a Monday and know what I’ve got. I don’t. I can tell you what I’ll probably have. But the weather, the pests, the truck – anything changes it between now and Thursday.”
Tom stares at the note. “So the data model can’t treat supply as definite. It’s more like a forecast?”
“Now you’re talking,” Dave says. And now there are pink notes.
There’s a brief tangent about whether “Payment Submitted” and “Payment Confirmed” are the same event. Tom explains they’re not – one is the customer clicking “pay,” the other is Stripe confirming the charge went through. A payment can be submitted and then fail. Maya hadn’t thought about that. Priya makes a note that they’ll need to handle failed payments – another pink note for the wall.
The duplicates get merged. “Customer Signed Up” and “Account Created” collapse into a single event. “Growing Schedule Committed” gets moved to a parallel swim lane because it happens on a different timeline to the customer flow. The wall starts to take shape.
The team works through the timeline together. After thirty minutes of shuffling, arguing, and clarifying, a rough sequence emerges:
Eighteen events across four clusters. That’s the core of Greenbox, from farm onboarding to customer feedback. It took the group about an hour to get here, and already the room feels different. Everyone can see the same picture.
Notice the structure that’s emerged. The one-time events – farm onboarding, customer signup, payment – are the scaffolding. They happen once and create the conditions for everything else. The recurring events – weekly supply matching, packing, delivery – are the business. They repeat every week for as long as farms supply and customers stay subscribed. Tom is already thinking about how this affects the data model.
Phase three: commands and actors
Lee hands out blue and yellow sticky notes. “For each event, let’s figure out what triggers it. Write the command on a blue note, and who or what performs the command on a yellow note.”
This phase goes faster because the timeline provides structure. But it surfaces new questions.
“Who decides substitutions?” Jas asks, placing a blue “Decide Substitution” note next to “Substitution Decided.”
“I do,” Maya says. “For now, anyway. Eventually maybe an algorithm, but right now it’s judgement. You need to know the produce – you can’t just swap beetroot for lettuce.”
Tom had assumed substitutions would be automatic. He was planning a simple algorithm: if item A is unavailable, pick the next cheapest item in the same category. Maya is telling him that’s not how it works at all. The substitution logic is a core part of the value proposition, and it requires domain expertise.
Pink sticky note goes on the wall: “Substitution policy – who decides, and how?”
Sam asks another question: “Who dispatches the boxes? Us, or a courier?”
Maya says, “We’ll use a local courier for now, but eventually I want our own drivers. The delivery experience matters.”
Sam writes a pink note: “Delivery logistics – own drivers vs courier, and when do we switch?”
The actor layer reveals something interesting about “Supply Aggregated.” Who does the aggregating? Right now it would be Maya, manually checking what each farm has submitted. But with ten farms, that’s manageable. With fifty, it’s a full-time job. The yellow note says “Maya” but really it should say “System” – eventually. Another pink note: “When does supply aggregation need to be automated?”
Priya points to the bracket the team added during the ordering phase – the one marking where the weekly cycle starts. “Every actor from here onwards is doing something every week,” she says. “But the yellow notes don’t show that. Maya doesn’t aggregate supply once. She does it every Wednesday, for every box.” The actor layer makes the repeating workload visible in a way the event timeline alone didn’t – and with it, the bottlenecks. If one person’s name appears on five weekly events, that’s a scaling problem waiting to happen.
Phase four: hotspots
By now the wall is covered. Orange notes tracing what happens, in order. Blue notes beneath them showing what triggers each step. Yellow notes above showing who’s involved. And scattered across the whole thing, pink notes marking every question, disagreement, and “wait, how does that actually work?”
Lee gathers everyone around the hotspots. “These pink notes are the most valuable thing on the wall. Every one of them is a misunderstanding you caught before it became a bug, a wrong assumption, or a wasted sprint.”
The team counts twelve pink notes. The four biggest clusters:
Supply shortfalls. What happens when total farm supply doesn’t cover subscriber demand for the week? Rachel explains that this is completely normal in farming – “You think you’ll have twenty crates of zucchini, then the slugs get in.” Dave adds that some farms will over-promise because they don’t want to lose the contract. “We’ve all done it,” he says. “You say yes and hope the crop comes through. Sometimes it doesn’t.”
The team needs a process for handling shortfalls, and it needs to be baked into the weekly cycle, not treated as an exception. This is a design decision that affects everything: the commitment deadline for farms, the buffer stock policy, the customer communication if a box has fewer items than expected.
Substitution policy. This one sparks the longest argument of the session. Tom thought boxes had fixed contents – the same items every week, based on what the customer selected at signup. Jas thought customers picked individual items each week, like a supermarket order. Maya says neither is right. The box contents change weekly based on what’s available, and the curation is Greenbox’s differentiator. The customer doesn’t choose. They trust Greenbox to choose well.
Three people, three completely different mental models. If the team had kept building without this conversation, they’d have shipped three different products.
Delivery logistics. Sam raises the practical questions nobody else had thought about. What’s the delivery window? What happens if nobody’s home? Who handles complaints about damaged produce? Can customers change their delivery day? Is there a minimum order density per area to make delivery economical? None of these have answers yet, and every one of them affects the software.
Seasonal availability gaps. Rachel explains something the team hadn’t considered at all. In Western Australia, summer is abundant, but late winter is lean – fewer varieties, smaller yields, and some crops just don’t grow. What does Greenbox do during those weeks? Pause subscriptions? Source from further afield and compromise on the local promise? Offer a reduced box at a lower price? This is a business model question disguised as a supply chain problem.
The remaining hotspots are smaller but still important: how do farms get paid, what happens when a customer wants to skip a week, how is feedback collected and acted on, what are the deadlines for each step in the weekly cycle. None of them are show-stoppers individually, but together they represent the operational complexity that nobody had mapped before today.
The arguments are the point
About ninety minutes into the session, Tom and Maya have a proper disagreement. Tom is placing the “Supply Matched to Demand” event and says, “So the system automatically allocates produce to boxes based on the subscription sizes?”
Maya shakes her head. “No. I look at what’s come in from the farms, I think about what makes a good combination, and I decide what goes in each box size. It’s not just weight and price matching. A box needs to make sense as a meal plan for the week.”
Tom looks frustrated. He’s been building things for twelve years. He can hear the problem being described, and his instinct is to solve it with code – that’s what he does, that’s who he is. Being told that the answer is “Maya decides” feels like being told the problem isn’t worth solving properly. “So there’s no algorithm? You just… decide?”
“For now, yes. The algorithm is my brain.” Tom says nothing, but the thought flickers: the substitution logic “could be automated eventually.” Maya catches his expression. “Eventually,” she says, with a weight that closes the topic for now.
Lee steps in. “This is great. Put a pink note on it. The question is: can this scale? And if not, what does the handover from Maya-decides to system-decides look like?”
This is exactly the kind of conversation that Event Storming is designed to provoke. The argument isn’t a problem – it’s the discovery working. Tom now understands that the matching process is far more nuanced than he assumed. Maya now understands that if they want to scale, they’ll eventually need to codify her decision-making process. Both of those insights are worth the entire session.
Priya has been staring at the timeline. She traces it with her finger: “Supply Matched to Demand” on Tuesday, then “Box Contents Decided,” then “Box Packed,” then – she stops. “Where does payment happen?”
Tom points to the left end of the wall. “Payment Submitted” is near “Customer Signed Up,” right at the beginning. That’s how he built it – charge on signup.
Priya shakes her head slowly. “But the box contents change every week. The cost depends on what’s in the box, and we don’t know what’s in the box until Tuesday evening when Maya finishes the matching. If we charge at signup, we’re charging for a box whose contents aren’t known yet.”
The room goes quiet. Tom stares at the wall. She’s right. The entire payment flow he built assumes a fixed price at a fixed time. But the timeline on the wall makes it obvious: billing can’t happen until after supply matching. The data model, the Stripe integration, the receipt emails – all of it is in the wrong place.
Pink sticky note: “Billing point – must be after supply matching, not at signup.”
It’s one of those moments where the wall shows you something that no amount of code review would have caught. The billing architecture isn’t a technical decision. It’s a domain decision, visible only when you see the full sequence of events.
There’s a quieter but equally important moment when Jas admits she’d been designing the customer experience around item selection. “I thought the whole point was letting customers choose,” she says. “Like a farmers’ market online.” Maya gently corrects her: the point is the opposite of choosing. Customers are busy. They don’t want to browse and pick. They want to open their door and find a box of good stuff.
Jas pauses. She’s been designing the wrong product for four weeks and nobody told her. She can feel the heat rising in her face. Then something clicks. “That actually changes everything about the landing page. The value proposition isn’t choice – it’s trust.”
Nobody told Jas she was wrong at any point during her first two weeks. She’d been designing in good faith based on an assumption that nobody thought to challenge. Event Storming created the space for that challenge to happen naturally, without blame.
What emerged
By the end of three hours, the wall tells a story that nobody in the room could have told alone. Maya knew the farming side but hadn’t thought through the software implications. Tom and Priya understood the technical constraints but had wrong assumptions about the domain. Jas had been designing for a product that doesn’t exist. Sam had operational questions that nobody else had considered.
| Before the session | After three hours on the wall |
|---|---|
| The domain lived in Maya’s head – nobody else could build without asking her | 18 domain events on the wall, visible to everyone. The team shares one picture instead of five different guesses. |
| Tom assumed box contents were fixed. Jas assumed customers chose items. Neither knew they were wrong. | Three fundamental misunderstandings surfaced and resolved: box contents vary weekly, customers don’t choose, farm onboarding comes before subscriptions. |
| Priya had a list of unanswered questions about the farm portal and no way to get them answered | 12 pink hotspot notes – each one a question the team caught before it became a bug or a wasted sprint. Priya’s questions are now on the wall where everyone can see them. |
| Jas had designed a customisation interface for a product that doesn’t work that way | The value proposition is trust, not choice. Jas now knows what to design for. |
| Sam’s operational concerns – delivery logistics, courier contracts, customer complaints – hadn’t been heard by the developers | Sam’s events are on the wall alongside Tom’s and Priya’s. Operations is part of the domain, not an afterthought. |
The key insight
The session resolved in three hours what would have taken weeks to discover through code. Every one of those twelve hotspots was a potential sprint of wasted work. The fundamental disagreement about box contents alone would have caused a full rewrite if discovered in production.
And it’s not just about avoiding waste. Tom now knows the subscription model needs variable weekly contents. Priya knows about commitment deadlines and shortfall reporting. Jas is designing for trust, not choice. Sam has a list of logistics questions that need answers. Everyone is building toward the same product because they all stood in front of the same wall.
Facilitation matters
A few things Lee did that made the session work:
He enforced the no-talking rule in phase one. When people talk too early, the loudest voices dominate and the quieter participants defer. The silent writing phase gives everyone equal weight. Dave and Rachel, who might have felt like outsiders in a tech team’s meeting, produced some of the most important events because they were writing, not competing for airtime.
He kept asking “what happens next?” and “what could go wrong?” These two questions drive the entire session. “What happens next?” extends the timeline. “What could go wrong?” generates hotspots. The second question is the more valuable one, because it forces the group to think about the unhappy paths – and that’s where most of the domain complexity lives.
He didn’t let anyone open a laptop. The moment someone starts Googling or checking Slack, they’re mentally out of the room. Event Storming works because everyone is physically engaged with the wall, moving sticky notes, pointing, arguing. Screens kill that energy.
He adjusted when his first approach didn’t work. When Lee tried to get Tom to challenge the timeline directly, Tom deferred to Maya. So Lee paired Dave with Tom instead – putting a domain expert next to a developer and asking them to find contradictions. The best facilitation is adaptive, not scripted.
He time-boxed ruthlessly. Three hours is enough for a first pass. After three hours people are tired and the returns diminish. Better to photograph the wall, take a break, and come back for a deeper session on the hotspots if needed. The wall isn’t going anywhere.
When to use Event Storming
- You’re entering an unfamiliar domain. If your team doesn’t deeply understand the business process, you need to surface that understanding before you build. Most domains are more complex than they first appear, and the complexity hides in the parts you don’t think to ask about.
- You’re kicking off a new project. Even if individual team members understand parts of the domain, they probably don’t share a mental model. Event Storming builds that shared model explicitly.
- You have access to domain experts. The technique depends on having people in the room who know how things actually work. Dave and Rachel’s farming knowledge was essential to the Greenbox session.
When not to use it
- The feature is small and well-understood. Adding a password reset flow doesn’t need a three-hour workshop.
- You don’t have the right people available. Running Event Storming without domain experts is just developers guessing together. That’s worse than useless – it creates false confidence.
- The team already shares a strong mental model. If everyone genuinely agrees on how things work, Event Storming will confirm what you know without adding much. The danger is that “we all understand it” is often an untested assumption – but sometimes it’s genuinely true.
What happens next
Maya photographs the wall – five panoramic shots that she’ll have laminated the following week. Sam volunteers to transcribe the events and hotspots into a shared document. Tom, who was sceptical about spending three hours not coding, admits he’s glad they did it. “I would have spent a week building automated substitution logic. That would have been completely wrong.”
Lee and Dave walk to the car park together. Dave pulls his keys out of a jacket that’s seen a decade of Margaret River weather. “That wasn’t as bad as I expected.”
“High praise from a farmer.”
Dave pauses by his ute. “The thing about crop failures. That’s not a what-if for us. That’s a Tuesday.”
“I know,” Lee says. “That’s why you needed to be in the room.”
Back inside, the team stands in front of the wall, arms folded. Twelve hotspots, eighteen core events, dozens of questions. Tom’s face says where do we even start? Priya is reading the pink notes methodically. Sam is counting them.
“Pick the one that scares you most,” Lee says.
Maya doesn’t hesitate. She reaches for the pink note from the substitution cluster. Substitution policy – who decides, and how? The question that cost Tom two rewrites in week one. The question that sits at the heart of what makes Greenbox different from a supermarket delivery.
“Good,” Lee says. “Now let’s make it concrete. Rules. Examples. Edge cases. Twenty-five minutes and four colours of card.”
Tom groans. “More sticky notes?”
“Cards, actually.” Lee is already pulling a fresh pack from his bag.
After the session, Jas catches Maya in the kitchen. She’s been on a two-day-a-week contract – Maya’s “we don’t need a designer yet” arrangement – and she’s supposed to be in again on Thursday and then gone until next week.
“I don’t want to do two days anymore,” Jas says.
Maya’s face falls. She’s already thinking about finding another designer, about the landing page redesign, about all the trust-not-choice work that just landed on the wall.
“I want to do five,” Jas says.
Maya is quiet for a moment. The seed money landed a few weeks ago – Angela’s first tranche, $75K – and it’s already stretched across Priya’s salary, Sam’s reduced-but-no-longer-catastrophic pay, and the cafe-office lease. Tom is on equity and a token wage. The budget doesn’t have a full-time designer in it. But it also didn’t have a two-day-a-week contractor in it until Sam talked her into it, and she found the money for that.
“I can’t match your contract rate,” Maya says. “Not even close. I can do a salary – startup salary, which means it’ll be less per week than you’re making now for two days. But I can offer equity. A small stake, vesting over two years. If this works, it’s worth something. If it doesn’t, you’ve taken a pay cut for a startup that folded.”
Jas has done the maths already. She was doing it during the session, while the sticky notes were going up and the arguments were flying. Two days a week at contractor rates is safe money. Five days a week at a startup salary is less money and more risk. But she’s twenty-six, her rent in Leederville is manageable, she doesn’t have a mortgage, and she’s just spent three hours in a room where she understood for the first time what she’d actually be designing.
“I want the equity in writing,” Jas says. “And I want to be in the room for product decisions. Not briefed after.”
“That’s fair,” Maya says. “I should have had you in the room from the start.”
They shake on it in the kitchen of a cafe-office in Fremantle, next to a kettle that takes four minutes to boil and a jar of instant coffee that nobody likes but everybody drinks.
Jas goes home to her Leederville flat that evening and opens her Moleskine to the page where she’d been sketching the customisation flow – the dead one, the one nobody told her about. She turns to a fresh page and writes trust, not choice at the top. Underneath, she starts sketching a landing page that sells the feeling of opening your front door and finding dinner sorted. Her grandmother’s market garden in the Adelaide Hills. Grow what they actually want.
She fills three pages before she looks up.
Lee calls the technique Example Mapping. Twenty-five minutes, four colours of card, and a vague story becomes something you can actually build.