Value Stream Mapping: Finding Where to Focus

After Event Storming, the GreenBox team has a wall covered in sticky notes. Domain events, commands, aggregates, hotspots. They can see the shape of their business for the first time. Everyone – Maya, Tom, Priya, Jas, Sam – shares the same mental model.

But shared understanding isn’t a plan. They know what happens in their domain – or at least what they want to happen, which is fine too. They don’t yet know where to start building.

That’s what Value Stream Mapping is for.

What is Value Stream Mapping?

Value Stream Mapping comes from lean manufacturing. Toyota used it to trace the flow of materials through a factory, measuring how long each step took and where things got stuck. The insight was powerful and counterintuitive: most of the time a product spends in a factory, it isn’t being worked on. It’s waiting. Sitting in a queue. Waiting for a handoff. Waiting for a decision. Waiting for someone to notice it’s there.

A car might take 20 hours to assemble, but spend 6 weeks in the factory. The assembly is the value. The 6 weeks minus 20 hours is waste.

Business processes work the same way. A customer might spend thirty minutes signing up for a produce box, but wait ten days before anything arrives. Value flows from a customer’s request to something that fulfils it. Along the way, it passes through steps – some that add value, some that don’t. A Value Stream Map makes this visible.

The mechanics are simple:

1. Pick a value stream – the journey from a trigger (“customer wants a produce box”) to an outcome (“customer receives a produce box”).
2. Map every step in that journey, left to right, in order.
3. For each step, record two numbers: processing time (how long the work actually takes) and wait time (how long before the next step starts).
4. Look at the ratio. If total wait time dwarfs total processing time, you’ve found where the waste lives.

You don’t need special tools. A whiteboard and markers work fine. Sticky notes if you want to rearrange things. The output is a simple diagram with numbers – nothing fancy, but brutally revealing.

Setting up the session

The GreenBox team gathers around a whiteboard the morning after their Event Storming session. The sticky notes from yesterday are still on the wall behind them – a useful reference.

Maya arrives with two coffees and a thought. “Nadia said something last night. She said, ‘Why don’t you just ask the customers what takes too long?’ She’s not wrong – but we don’t have enough customers to ask yet. What we can do is trace the journey ourselves and see where the time goes.”

Sam pulls up a spreadsheet on his laptop. He’s been tracking the pilot deliveries informally – how long each step takes, where things stall. Nobody asked him to. He just does this. “I’ve got real numbers for some of this,” he says. “Not precise, but better than guessing.”

Lee asks a useful question before they start: “Which flows matter most? You can’t map everything.”

The team looks at the Event Storming wall from yesterday. The domain naturally splits into two flows: the customer’s journey (discovering GreenBox through to receiving a box) and the supply side (farms committing produce through to boxes being packed). These are the two flows where the hotspots clustered – and they’re the two flows the business can’t exist without.

That’s the general principle: your Event Storm tells you which value streams to map. Look for where the hotspots cluster, where the most uncertainty lives, or where the biggest risk to the business sits. You don’t map everything – you map the flows that matter.

Maya draws a long horizontal line across the whiteboard and says, “Let’s start with the customer’s journey from hearing about us to getting their first box. Then we’ll do the supply side.”

She writes two rules at the top of the board:

• Be honest about the times. Don’t guess optimistically. Use what you actually know or can estimate from similar businesses. If Maya’s been running pilot deliveries, use those real numbers.
• Every step goes on the board, even the boring ones. Especially the boring ones. That’s where waste hides.

Priya asks, “How granular should the steps be?” Maya’s answer: “If someone different does it, or if there’s a handoff, it’s a separate step. If the work stops and waits for something, that’s a separate step too.”

Tom raises a fair point: “We haven’t built anything yet. We don’t have real data. Are we just guessing?”

Maya shakes her head. “Not guessing. Estimating. I’ve been running pilot deliveries for three months – I know how long packing takes, how long the courier needs, when farms can commit supply. The supply-side numbers are real.” Sam adds: “And for the customer side, I’ve looked at how similar subscription services work – sign-up flows, payment processing times, delivery windows. We’re not pulling numbers from thin air.”

Lee frames it: “You’re right that these are estimates, not measurements. But the point of VSM isn’t decimal-point accuracy. It’s finding the orders-of-magnitude gaps – the step that takes minutes versus the step that takes days. You don’t need precise numbers to spot those.”

The team grabs markers. Time to map.

The customer value stream

They start with the customer’s journey. What does a customer experience from the moment they hear about GreenBox to the moment they receive their first box?

Sam takes the lead here – he’s closest to the customer side of the business. He writes each step on a sticky note, places them left to right across the whiteboard, and adds the numbers underneath: processing time (how long someone is actively doing something) and wait time (how long nothing happens).

1. Discovers GreenBox 5 min
2. →
3. Browses Site 10 min
4. →
5. Signs Up 3 min
6. →
7. Chooses Box Size 2 min
8. →
9. Pays 2 min
10. →
11. Waits for First Box 3--10 days wait
12. →
13. Receives Box 5 min
14. →
15. Gives Feedback 5 min

Total processing time: about 32 minutes. Total wait time: 3 to 10 days.

Read those numbers again. Thirty-two minutes of active engagement from the customer. Up to ten days of silence.

Sam spots it immediately. “The customer does everything we need in half an hour. Then they sit there for up to ten days wondering if they’ve been scammed.”

He’s not wrong. Sam grabs a red marker and circles “Waits for First Box” on the whiteboard. That gap is the bottleneck.

1. Discovers GreenBox 5 min
2. →
3. Browses Site 10 min
4. →
5. Signs Up 3 min
6. →
7. Chooses Box Size 2 min
8. →
9. Pays 2 min
10. →
11. Waits for First Box 3--10 days wait BOTTLENECK
12. →
13. Receives Box 5 min
14. →
15. Gives Feedback 5 min

It’s not processing time – nobody’s doing anything wrong. It’s structural wait time. The customer has done everything right. They’ve committed. They’ve paid. And now… silence.

This is the most dangerous part of the customer experience. It’s where trust erodes. It’s where people check their bank statement, see the charge, and wonder if the whole thing is legitimate. It’s where cancellations happen before the first box even ships.

Jas adds: “We need something in that gap. A confirmation email immediately. Then maybe a preview of what’s coming a few days before delivery. An email introducing the farms. Something that makes the wait feel intentional rather than neglectful.”

Tom nods. “Even a simple ‘Your first box is being prepared’ email three days before delivery would help.”

Maya agrees but redirects: “All true. But look at this map. The wait is a real problem – but it’s a problem that only exists after someone subscribes and pays. Right now, nobody can do that. There’s no subscription system. There’s no payment flow. Without paying customers, this entire value stream doesn’t exist. We need to build the bit that creates subscribers before we worry about what happens while they’re waiting.”

This is an important VSM insight. The bottleneck isn’t always the thing to fix first. Sometimes the value stream doesn’t flow at all yet, and the priority is making it flow end to end – even imperfectly – before optimising any individual step.

The supply value stream

Next, the supply side. This is where Maya’s domain expertise really matters. What happens from the moment a farm has produce available to the moment a box lands on a customer’s doorstep?

Maya takes the marker this time. She’s done this process dozens of times during the pilot phase. She knows where the time goes.

1. Farm Assesses Availability 2 hrs
2. →
3. Lists Produce 30 min + 1--2 days wait
4. →
5. GreenBox Aggregates 1 hr
6. →
7. Matches to Demand 2--3 hrs
8. →
9. Identifies Shortfalls 1 hr
10. →
11. Decides Substitutions 1--2 hrs
12. →
13. Finalises Contents 1 hr
14. →
15. Packs Boxes 3 hrs
16. →
17. Dispatches 1 hr
18. →
19. Delivers 4 hrs

The team stares at the board. The numbers are all over the place. Packing takes 3 hours. Delivery takes 4 hours. Matching, shortfalls, and substitutions together take 4 to 6 hours. Those are all big chunks of time.

Tom asks the obvious question: “So what’s actually the bottleneck? Packing and delivery are the biggest individual steps.”

Lee steps in. “Look at it differently. Packing and delivery scale predictably – more boxes, more time, but you can hire packers and add drivers. They’re operational steps that grow linearly. Now look at the middle three steps. Who does those?”

Everyone looks at Maya.

“Right,” Lee says. “Matching, shortfalls, and substitutions are 4 to 6 hours every week, and they all require Maya’s domain knowledge. Which farms are reliable. Which substitutions customers will accept. How seasons affect availability. That’s not a time problem – it’s a dependency problem. Maya is a single point of failure.”

Maya goes quiet. She’s staring at the board, and what she sees is her name at every red-marked step. Matching – Maya. Shortfalls – Maya. Substitutions – Maya. Her father was the same on their farm. The one person who knew how everything worked. And when he sold, the knowledge left with him. She can feel the shape of that pattern repeating, and she doesn’t like it.

1. Farm Assesses Availability 2 hrs
2. →
3. Lists Produce 30 min + 1--2 days wait
4. →
5. GreenBox Aggregates 1 hr
6. →
7. Matches to Demand 2--3 hrs BOTTLENECK
8. →
9. Identifies Shortfalls 1 hr BOTTLENECK
10. →
11. Decides Substitutions 1--2 hrs BOTTLENECK
12. →
13. Finalises Contents 1 hr
14. →
15. Packs Boxes 3 hrs
16. →
17. Dispatches 1 hr
18. →
19. Delivers 4 hrs

Tom nods slowly. “So the matching problem is basically Maya doing a giant puzzle every week by hand?”

“Yes,” Maya says. “I compare what farms have available against how many subscribers we have for each box size. When there’s not enough of something, I decide what to substitute. Zucchini instead of cucumbers. Extra carrots if there’s no beetroot. It depends on the season, the farms, and what I think customers will accept.”

This is the hotspot they identified during Event Storming. Now they can see exactly how much time it eats – and more importantly, who it depends on.

But the linear diagram is hiding something. Rachel, one of the farmers on the call, points it out: “What happens when I phone Maya on Wednesday afternoon and say we’ve lost half the tomato crop to blight?”

Maya sighs. “I redo the matching. The supply numbers change, so the shortfalls change, so the substitutions change. Sometimes I’ve already finalised the box contents and I have to go back and redo that too.”

Lee grabs the marker. “Let’s draw what actually happens.” He adds loops to the board:

Those dotted loops are rework – pure waste. Every time a farm updates their availability after the initial listing, the aggregation, matching, and substitution steps potentially need to run again. Maya estimates this happens two or three times a week during the pilot. Each loop costs an hour or more of her time.

Sam adds another: “And what about when a customer subscribes mid-week? Does that change the box allocations?”

“It shouldn’t,” Maya says. Then she pauses. “Actually, it does. If we go from twelve small boxes to thirteen, the supply allocation changes. I usually just absorb it, but yes, technically I’m re-matching.”

The map now shows three sources of rework feeding back into the bottleneck: late farm changes, last-minute customer sign-ups, and (occasionally) farms that don’t submit at all and need chasing. Each one multiplies the time Maya spends in those red steps.

Priya raises another concern: “What about the wait time between farms listing and us aggregating? That’s 1–2 days where supply data is just sitting there getting stale.”

Maya explains: “Farms assess their stock early in the week. Some are quick to list, some take a day or two. We can’t aggregate until most of them have submitted. That wait is partly structural – we’re waiting for multiple farms to respond – but partly waste. If we had a better way to collect availability, maybe a simple form with a deadline, we could compress it.”

Another insight from the map. The wait time isn’t inevitable. Some of it is just friction in the process. And the rework loops make the bottleneck even worse than the straight-line numbers suggest.

Value-adding vs waste

Not every step in a value stream adds value. In lean thinking, there are three categories:

Value-adding: Steps the customer would pay for. Curating box contents, packing, delivering – these directly create the thing the customer wants.

Necessary waste: Steps that don’t add value but can’t be eliminated yet. Aggregating supply data, identifying shortfalls – the customer doesn’t care about these, but you can’t skip them.

Pure waste: Waiting, rework, unnecessary handoffs. The 1–2 day wait for farms to list produce. Any time Maya spends re-doing the matching because a farm updated their availability at the last minute. Any duplicate communication – Sam emailing a farm to chase their listing, then Maya phoning the same farm an hour later.

The GreenBox team marks each step on their board with a V (value-adding), N (necessary waste), or W (pure waste).

Customer journey:

1. Discovers GreenBox 5 min VALUE
2. →
3. Browses Site 10 min VALUE
4. →
5. Signs Up 3 min VALUE
6. →
7. Chooses Box Size 2 min VALUE
8. →
9. Pays 2 min VALUE
10. →
11. Waits for First Box 3--10 days wait WASTE
12. →
13. Receives Box 5 min VALUE
14. →
15. Gives Feedback 5 min VALUE

Almost entirely value-adding – until the wait, which is pure waste.

Supply journey:

Necessary waste dominates the first half. Value-adding steps only start once box contents are finalised. And the rework loops – those dotted lines feeding back into the matching steps – are pure waste that multiplies the cost of the bottleneck.

The goal isn’t to eliminate all waste immediately. It’s to see it clearly so you can make informed decisions about what to tackle first. Some necessary waste will become value-adding once you build software around it. Some pure waste will disappear entirely once you have the right process.

The decisions that fall out

The team steps back and looks at both value streams side by side. Three things become obvious.

1. Build subscription and payment first.

Without a way for customers to sign up and pay, there is no value stream. There are no subscribers to match against supply. There’s no revenue. Everything else depends on this.

Tom had started building this in week one, but on wrong assumptions. Now the team has a shared understanding of what a subscription actually means in this domain: variable weekly contents, curated by Maya, charged on a recurring basis.

This is the first thing to build. It’s the entry point to the entire system. And critically, the team now agrees on why it’s first – not because Tom already started it, but because the value stream doesn’t exist without it.

2. The supply matching problem is complex, but can be manual.

The matching, shortfall, and substitution steps are the most expensive part of the supply value stream. Automating them properly would be a significant piece of software – seasonal rules, customer preferences, farm reliability scores, substitution logic.

But Maya is already doing it by hand. She’s been doing it by hand for the pilot customers. It takes her half a day each week, and she knows the domain well enough to make good decisions.

The team decides: don’t build the matching engine yet. Give Maya a simple spreadsheet or a basic admin screen where she can see supply and subscriber numbers side by side, and let her do the matching manually. Automate it later, once they understand the rules well enough to encode them.

This is a crucial insight that comes from VSM. The map shows you where the effort is, but it also shows you where human effort is acceptable for now. Not everything needs software on day one.

There’s a bonus here too. Every week that Maya does the matching by hand, the team learns more about the rules. They’ll spot patterns. “Maya always swaps zucchini for cucumbers but never the other way round.” “She prioritises variety over quantity.” These observations become the requirements for the eventual automated system. The manual process is the discovery.

3. Delivery logistics can be outsourced.

The dispatch and delivery steps are well-understood problems. Courier services exist. The team doesn’t need to build delivery tracking or route optimisation. They need to pick a courier, integrate with their API (or just email them a manifest), and move on.

Sam volunteers to handle this. “I’ll find a local courier. We can worry about our own delivery fleet if we ever get big enough.” It’s the kind of thing Sam always does – quietly claiming the operational work that falls between everyone else’s job descriptions. Delivery logistics is becoming Sam’s domain, whether anyone has formally assigned it or not.

While tracing the supply flow, the team discovers something awkward. Staging has fake farm data – ten farms, all in Perth, all with reliable supply numbers. Production has real data: fourteen farms, some with intermittent availability, some who routinely over-promise. A feature that works perfectly in staging – the new farm matching algorithm Tom has been testing – produces wrong results in production because it doesn’t handle the messiness of real supply data. Charlotte: “Your staging environment is a fantasy. It tells you what your code does in a perfect world. Production is not a perfect world.” Tom adds a task: mirror production data into staging weekly, anonymised where necessary but structurally honest.

Lee makes one more observation as they wrap up. “Right now, all of you were in the room for this. You can all see the map. But at scale, you’ll need people who weren’t in this room to understand these flows. Think about how you’ll pass this knowledge on.”

Nobody writes that down. They will wish they had.

This is a common pattern in VSM: you find a step that’s important but well-solved by existing services. Building your own version is waste unless you have a specific competitive reason to do so. GreenBox’s competitive advantage is the curation and the farm relationships, not the last-mile delivery.

What the map reveals that Event Storming didn’t

Event Storming gave the team a shared understanding of the domain. Value Stream Mapping gave them a shared understanding of priorities.

The Event Storming board showed that substitutions were complex. The Value Stream Map showed that substitutions eat 1–2 hours per week and can be handled manually. Those are different insights.

The Event Storming board showed that customers subscribe and receive boxes. The Value Stream Map showed a 3–10 day gap in the customer experience where nothing visible happens. That gap doesn’t appear as a domain event. It’s not a command or an aggregate. It’s absence – and it’s exactly the kind of thing customers complain about.

VSM surfaces the time dimension that Event Storming misses. How long does each step take? Where does work sit idle? Where are the handoffs? These questions matter enormously when you’re deciding what to build first.

The two techniques complement each other. Event Storming answers “what happens in our domain?” Value Stream Mapping answers “where should we focus our effort?” You need both. Doing VSM without Event Storming means you’ll argue about what the steps are instead of measuring them. Doing Event Storming without VSM means you understand everything but prioritise nothing.

When to use Value Stream Mapping

Prioritisation. You have a list of things you could build. VSM shows you which steps in the value chain are bottlenecks, so you can focus on the ones that matter most.

Finding waste. If a process feels slow but you’re not sure why, map it. The wait times will jump out at you.

Choosing what to build next. After your first release, VSM helps you decide where to invest next. Is the bottleneck in customer onboarding? In the weekly operations? In delivery? Build where the constraint is. If you optimise a step that isn’t the bottleneck, the overall flow doesn’t improve.

Understanding existing processes. If you’re replacing or improving an existing system, map the current state first. You can’t improve what you can’t see.

After incidents or complaints. If customers are unhappy and you’re not sure why, map their value stream. Often the problem isn’t a bug – it’s a gap in the process where nobody is doing anything and the customer is left wondering what’s happening.

When NOT to use it

When you don’t understand the domain yet. If the team can’t agree on what the steps even are, you’re not ready for VSM. Do Event Storming first. Get the shared understanding. Then map the value flow. The GreenBox team couldn’t have done this session before their Event Storming workshop – they wouldn’t have known what steps to put on the board.

When you’re exploring a brand-new problem space. VSM works best when there’s an existing process – even if it’s manual, even if it’s messy. If you’re inventing something genuinely new and nobody knows what the steps will be, VSM won’t help yet. You need at least a rough idea of the flow before you can measure it.

When the team is too large. VSM works best with 4–8 people who are close to the work. If you have 30 people in the room, you’ll spend all your time debating step definitions and never get to the timing.

As a one-off exercise. The real power of VSM comes from revisiting your map as the system evolves. The GreenBox team will come back to these maps after they’ve built the subscription system. Processing times will change. Wait times will shift. New bottlenecks will appear. A map you drew once and filed away is a historical artefact, not a tool.

A note on accuracy

The times on the GreenBox board are estimates. Maya’s are grounded in real experience from the pilot. The customer-side times are Sam’s best guesses based on similar subscription services.

That’s fine. VSM doesn’t require stopwatch precision. You’re looking for orders of magnitude. The difference between a 2-minute step and a 3-minute step doesn’t matter. The difference between a 30-minute process and a 10-day wait is what matters. If your estimates are within a factor of two, the map will still point you in the right direction.

Don’t let the pursuit of exact numbers stop you from drawing the map.

The GreenBox backlog, rewritten

Before the VSM session, the team’s mental backlog was vague: “build the subscription system, build the farm portal, build the matching engine, build delivery tracking.”

After the session, they have a prioritised list grounded in the value stream:

1. Subscription signup and payment – the entry point. Without it, nothing else matters.
2. Order confirmation and communication – fill the gap between payment and first delivery. Even a simple email helps.
3. Basic supply visibility – a screen where Maya can see what farms have available. Doesn’t need to be fancy. Needs to be accurate.
4. Manual matching support – a side-by-side view of supply and demand. Maya does the thinking; the tool shows her the data.
5. Courier integration – outsource delivery. Integrate later if needed.
6. Automated matching – only once the manual process is well understood and the rules are clear.

Every item on this list traces back to a specific step in the value stream. Every prioritisation decision has a reason the whole team understands.

Compare this to the backlog they would have had without VSM. It would have been driven by whoever argued loudest, or whatever felt most technically interesting, or what the team happened to start building first. Tom might have pushed for the matching engine because it’s a fun problem. Jas might have pushed for the customer experience. Sam might have pushed for marketing pages.

None of those are wrong in isolation. But without the value stream to anchor the conversation, there’s no principled way to choose between them. VSM gives you that principle: start where value flows, fix where value stops.

That’s the power of making the invisible visible. You stop arguing about what feels important and start seeing where value actually flows.

The whole session took two hours

That’s worth saying explicitly. Two hours of whiteboard work gave the GreenBox team a prioritised backlog, three clear architectural decisions (build subscriptions, defer automation, outsource delivery), and a shared understanding of where value flows and where it doesn’t.

Compare that to the four weeks they’d already spent building the wrong things. The VSM session cost roughly one person-day of team time. The previous four weeks cost twenty person-days and produced work that mostly had to be thrown away.

Discovery isn’t free, but it’s dramatically cheaper than building the wrong thing. And unlike code, the output of a VSM session doesn’t go stale. The map is a living document the team can return to as they learn more.

Maya photographs the whiteboard and pins the pictures in the team’s shared workspace. They’ll come back to these maps.

Next up

The team has their priorities. Now they need to turn “build subscription signup and payment” into something concrete enough to actually implement. What are the rules? What are the edge cases? What does “done” look like?

That’s where Example Mapping (coming 14 April) comes in.