Case Study: Mapping Antar

Use the first half as your reference: the one rule that decides when to split work onto a new story map and when to keep it on the one you have, plus the definitions behind it. The second half walks a real company, Antar, board by board — so a new joiner can picture how it all actually looks.

If you remember one sentence, make it this: a board is one primary persona’s end-to-end journey.

The pieces

A story map (a “board”) describes one journey. Everything on it has a precise meaning:

The unit that decides every split: primary vs secondary persona

This is the definition everything hangs on. Get it right and “split or combine?” stops being a judgment call.

• Primary persona — the one actor whose end-to-end journey is the backbone. A board has exactly one primary persona: the owner of its journey.
• Secondary persona — an actor who steps into the journey at specific activities without owning it. On a shopping journey, customer support shows up at “Support”; legal/compliance shows up at “Checkout”. They are real and they get a persona pill on the stories they touch — but they never get a board of their own.

A board is not “everyone who touches this product.” It is one primary persona walking one journey, with secondary personas appearing along the way.

The one question: split or combine?

Before you ever create a new board, ask one thing:

Is there a new primary persona who owns a new end-to-end journey — or just a new participant in, or a variation of, a journey we already have?

That single question resolves every case:

The trap to watch in every row: “a different person is involved” is not enough. Lots of people touch one journey. The split only happens when someone stops participating in a journey and starts owning a different one.

Don’t over-split: the proliferation trap

The most common — and most damaging — mistake is one board per partner, client, brand, or segment. It feels organised. It is a trap.

If you sign three corporate clients who all use the same journey, that is one board, with “which client” as a persona or a feature flag — not three boards. Here’s why it matters more than it looks: a board quietly shapes how the team thinks. One board per client nudges you, week after week, toward per-client features — and you wake up maintaining three forked products instead of one configurable one. Boards should pull you toward leverage (one journey, served many ways), not fragmentation (a bespoke build per account).

“Who do we serve?” is the right question — but you serve many partners through the same journeys. A partner earns its own board only when it brings a journey someone owns end to end that doesn’t exist yet (e.g. a partner-admin portal where their staff manage their own account) — never just because it’s a new logo.

Make creating a board a deliberate act. Like committing a rock in quarterly planning, a new board should be rare and discussed, not spun up on a whim. The default answer to “should this be a new board?” is no — it’s usually an initiative, a persona, or a segment. Reach for a board only once you’ve named the new primary persona, drawn their journey, and confirmed it isn’t a variant of one you already have.

When in doubt, default to fewer boards. A board too few costs you a slightly crowded map. A board too many fragments the journey, hides stories from the path they belong to, and makes you maintain the same backbone in two places. No more boards than there are primary personas with their own journeys.

Antar, board by board

Now picture the rule on a real product. Antar is a food-delivery company (the same one from Quarterly Roadmap Planning). Follow it across four quarters and a pivot, and watch the call at each fork — the wrong one is usually the tempting one.

Q1 — One journey, one board

Antar launches with a single product: an app where a hungry person orders food. One primary persona (the customer), one journey, so one board. The backbone is the customer’s path, left to right:

Everything else hangs off that backbone. Here is Antar’s board a few months in — one shipped initiative collapsed, one in build, one planned, and the backlog. This is the whole vocabulary from the reference above in one picture: activity columns, initiative rows, story cards, a backlog:

The Q1 fork. An engineer wants to add a “Courier accepts order” column here — couriers matter, it feels related. Run the one question: is the courier the owner of this journey? No — the customer is. “Courier accepts order” is a step the courier owns, not one the customer walks (and the courier isn’t even a secondary persona here; they never appear in the customer’s flow). Wrong call. A step owned by someone else is the first sign of a second board, not a new column. Right now dispatch is manual, so that step lives on no board yet.

Q2 — A second board earns its place

Antar builds a courier app. Now run the one question on the courier: do they own an end-to-end journey? Yes — and it looks nothing like the customer’s:

A new primary persona owning a different journey → a second board: Courier. The customer board does not gain courier columns.

A goal can touch two journeys; an initiative can’t. Antar’s quarter has a goal: deliveries feel fast and predictable. A goal is broad and is not an initiative — it lands as two initiatives, one per board, each with its own sharp, measured problem:

• On Courier — Cut pickup wait (under Get Assigned): couriers idle ~6 min at restaurants; smarter dispatch timing targets under 2 min.
• On Customer — Trustworthy ETA (under Track): the flat “30 min” we show is wrong 40% of the time; a live estimate targets within ±5 min, 85% of orders.

Same goal, two initiatives, two boards. They can’t be merged into one initiative because each one’s stories hang off a different board’s activities — and an initiative’s stories all live on its own board. A goal spanning two journeys is normal; an initiative spanning two boards is a smell: it’s two wearing one name. Split them, and let the shared goal connect them.

Q3 — Loyalty vs. restaurant: the question in action

Two proposals land the same quarter and feel equally big. The one question separates them instantly.

Proposal A — a loyalty programme (points, tiers, rewards). New primary persona? No — it’s the customer, doing more on the same journey. → an initiative on the Customer board, not a board. Giving loyalty its own board would fragment the customer’s map and hide the work from the journey it belongs to.

Proposal B — a restaurant dashboard (today restaurants get a printer and a phone call). New primary persona? Yes — the restaurant owner owns a journey nobody owns yet:

Concretely, here’s how each proposal lands. Loyalty becomes one initiative threaded along the Customer backbone — its stories sit under the activities they change, and the backbone doesn’t move:

The restaurant becomes its own board, with its own first initiative — a different backbone, a different owner, its own stories:

See the difference in the pictures: loyalty is one row on a board that already exists; the restaurant is a whole new board whose columns are steps the customer never takes.

The near-miss to catch: a restaurant also “touches the order flow,” so you could mistake it for a participant. But it earns a board because it owns a separate journey end to end — not because it touches orders. (If touching were the test, CS and Legal would each have a board and the map would be in pieces.) Antar now runs three boards — Customer, Courier, Restaurant:

The Q Overview still shows all three boards’ initiatives in one quarterly view — three boards for working, one overview for seeing.

Q4 — Groceries: the same journey, so don’t split

Antar adds groceries. It feels like a new product, and the instinct returns: a “Grocery” board. Run the one question: new primary persona? A customer buying groceries discovers a store, builds a basket, checks out, tracks, receives. Same customer, same end-to-end journey. No new owner → no new board.

Grocery is a set of initiatives on the Customer board, plus at most one new activity if the journey genuinely gains a step — Substitute Items, when something is out of stock:

Adding one activity to an existing backbone is normal evolution. Cloning the whole backbone onto a second board because the catalogue changed is duplication you’ll regret — now you maintain “Checkout” in two places for no reason. (This is the same discipline as the proliferation trap above: a new product line on the same journey is not a new board.)

The pivot — when a journey’s shape really does change

A year in, Antar drops restaurants and goes grocery-only. This is the one case where boards genuinely restructure; it’s covered under Handling Pivots. In short:

• The Restaurant board is archived, not deleted — its initiatives and decisions stay readable as the product’s memory.
• The Customer board evolves in place — the journey still holds, so activities get renamed and food-only initiatives archived; no new board.
• The Courier board barely changes — a courier delivering groceries walks almost the same journey.

A pivot is a deliberate decision, per board, to evolve, archive, or migrate — never a reflex “start over.”

Next: Quarterly Roadmap Planning