I wanted to see how far I could get from a completely raw product idea to a real, living backlog in StoriesOnBoard by running it through the story map skills. Not as a demo: I wanted to find out where the process pushes back, and where it fills in things I wouldn't have thought of myself.
The section breakdown below is deliberately generic — I'd mark the same points in any other use case.
Where this test came from
This experiment follows the skill-family setup described in Five Skills, One Backlog. That earlier article explains why the workflow is split into discovery, story-map creation, gap analysis, refinement, and navigation. This article is the practical follow-up: what happened when I used those skills on a raw food delivery app idea.
1. The use case: what I was actually building
The idea was a food delivery app for people whose calendars are booked back-to-back.
The insight behind it: for someone in meetings all day, the problem isn't that delivery is slow. It's that it's unpredictable. If you only have a 25-minute gap between two calls, food arriving "sometime in the next 40 minutes" is useless — it turns up mid-meeting and goes cold on your desk. These people know in advance exactly when they're free, which is unusual and exploitable. And there's a second, quieter job to be done: working out when you have to order so that the food lands in the gap rather than outside it.
That's all I brought to the table:
Food delivery app for a customer base with a lot of meetings, who know in advance when they're free. They can't tolerate imprecise delivery because they're only available in a specific window — so it matters that they know when to place the order for it to arrive exactly when it suits them.
No personas, no scope, no business model. In theory, exactly the kind of input a generator would happily turn into a hundred forgettable user stories.
2. Discovery: the skill asks first
It didn't generate. It said the problem and the target user were clear, then flagged that three decisions would produce materially different structures, so we'd settle those before building anything:
What's the delivery model? Own courier fleet with partner restaurants? Aggregating existing services (Wolt, Foodora)? Or restaurants delivering themselves? How does the app know when the user is free? Calendar integration? A manually entered window? Both? Who places the order? An individual professional, a company team, or both?
Those three questions were worth more than I expected. None of them is a matter of taste — each one changes the backbone. As an aggregator there's no courier- or kitchen-side scope at all; with an own fleet you need four different surfaces before a single meal moves.
My answers: own courier fleet + partner restaurants, calendar integration (Google/Outlook), individual professional (B2C).
Transferable lesson: good discovery doesn't ask "what else would you like". It asks which decision changes the structure. Two or three questions, each a fork in the road.
3. The uncomfortable question: how is this different from what already exists?
This is where it got interesting. With the structure sketched, it didn't start building — it logged an open risk:
Wolt and Foodora already support scheduled orders. The switch test is unanswered: why exactly would someone move?
That was uncomfortable because it was true. "Tell us when you want it" is not a gap in the market. When I asked about the unique value, it put three different bets in front of me — not three phrasings of the same one:
| Positioning | The unique value | The riskiest assumption |
|---|---|---|
| The guarantee | We promise a window and refuse your order if we can't hit it | Will people accept "no" often enough for the promise to stay credible |
| The backwards clock | We tell you when to order so it lands in your gap | Is the deadline the real pain, rather than the accuracy |
| Calendar-native | Your calendar plans lunch, not you | Will people grant calendar access to a food app |
Its argument was that only the first survives the switch test: bets 2 and 3 make the incumbent experience nicer but give nobody a reason to leave. What you can't get anywhere is somebody being accountable for the window — and the reason nobody offers it is precisely that accountability is expensive.
I picked 1 and 3. Combined:
Your calendar picks the moment, and we guarantee the food lands in it — or we don't take the order.
It immediately named the cost too: this carries two risky assumptions into the MVP at once, so the MVP can't be trimmed down to a thin test of a single thing.
Transferable lesson: if a skill never asks what makes this better than the strongest alternative, you'll end up with a feature list rather than a product. This was the most valuable stretch of the whole process.
4. Positioning has to move the scope
It didn't stop at a slogan. The choice re-sliced the MVP:
Promoted into the MVP: suggesting the best eating slot of the day; a minimum meal-break rule (without it the app offers five-minute gaps and looks broken); automatic compensation for a missed window; plus two new stories — seeing before I order what happens if the window is missed, and having the app place a lunch hold in my calendar so the slot doesn't get booked over.
Dropped out of the MVP: live courier tracking. I liked the reasoning: if the window is guaranteed, watching a map is anxiety theatre.
Transferable lesson: positioning is only worth something if you can see it on the board. If the MVP would look the same under any of the three bets, you haven't decided anything.
5. Backlog generation — with an approval checkpoint
story-map-creator then laid out the full proposal in chat, for approval — goals, steps and stories with releases and personas — without writing a single card. That's the right order: unpicking 100+ cards afterwards costs far more than reading a list.
Only after I approved it did the real map get built in StoriesOnBoard: 9 goals, 24 steps, 99 stories, 4 personas, 3 releases.
6. What it added on its own — the "didn't think of that" category
This was the other surprise. My idea mentioned none of the following, but they landed anyway, because the skill carries a baseline checklist of what every product needs:
Foundations: sign-up and login, password reset, profile editing, accepting the privacy policy, GDPR data export and account deletion, managing saved payment methods, notification preferences, an audit log, in-app support.
Error states I'd have skipped: an empty state for when no suitable slot exists; retry after a failed payment; narrowing calendar access to free/busy only, so meeting contents stay private.
The entire supply side: left to myself I'd almost certainly have described only the consumer app. Instead the restaurant got its own goal (when to start cooking, accept/reject, kitchen capacity), as did the courier (a day known in advance, marking handover, reporting a delay with a reason) and the dispatcher (capacity reserved ahead, spotting at-risk deliveries).
My favourite addition: the miss-cause taxonomy. When I asked about analytics, it recommended making the analytics product its own story map, but keeping one thin slice in the MVP — every missed window recorded with a cause (kitchen late / no courier / travel / customer unavailable). The reasoning: without it you'll know your promise-kept rate is 87% and have no idea why, and it's nearly impossible to backfill.
Transferable lesson: this is the section worth walking through in every use case. The question isn't whether the skill guessed the essence of your product — it's whether it supplied the 30–40% everyone forgets in the excitement.
7. Gap analysis: what was still missing
On the finished board I ran story-map-gap-finder. It didn't work from memory — it read the live map back, and found twelve gaps plus three structural problems.
Missing journey phases:
Delivery coverage. Nothing on the board decided whether an address was servable. With an own fleet in a single city that's the first gate — without it, a user outside the zone hits a dead end somewhere deep in the flow. Pricing. Payment existed; price didn't. Even though the guarantee is the one thing here that could plausibly carry a premium.
Missing edge cases:
The customer isn't there at handover. "Customer unavailable" appeared in the miss-cause list, but no story produced that outcome. And it's the likeliest real-world failure — a meeting ran long, which is precisely my target user. Capacity runs out during checkout. Refusing orders is the core mechanic, yet the moment it bites a real user mid-payment was uncovered. Refund on cancellation. I could take money and cancel, but never give it back. Expiring calendar token. In a calendar-native product, a stale OAuth token degrades the core feature invisibly. The restaurant accepted but can't cook it. Rejection before the promise existed; failure after it didn't. Plus: a courier can't hand back a job after a breakdown, restaurants have no day view of incoming orders, saved addresses can't be edited or deleted.
Structural findings:
One step had no MVP story at all — it slipped out during the re-slice, and an earlier check had wrongly passed it. The gap analysis caught it. Release 3 was down to two stories. Two stories isn't a release. Two admin stories were sitting under the wrong step (platform administration filed under the dispatcher's workflow).
I accepted all of them. Final state: 9 goals, 26 steps, 111 stories — 62 in the MVP, 49 in Release 2.
8. What isn't a gap, but a decision
It listed separately the things that look missing but may be deliberate scope cuts — and didn't "fix" them on its own: a manual time window without calendar access (right now, if you decline permission there's no path into the product at all), ops roles and permissions, acquisition and referral, tipping, multiple cities, company team ordering.
That list matters more than it first appears. It's the place where the generator doesn't overwrite your intent.
9. What I'm taking away
Structure-deciding questions first, cards later. Three good questions saved a complete rewrite. The switch test isn't optional. With no answer to why someone would leave the strongest alternative, you're building a feature list. Positioning must show up in the scope. If the decision doesn't move stories between MVP and Release 2, it wasn't a decision. Approval checkpoint before writing. Fixing things in chat is cheap; on the board it's expensive. Run the gap analysis on the built board, not the plan. What's missing from what got built differs from what's missing from what you imagined. Size is information too. A 62-story MVP isn't sloppy slicing — it's a consequence of the model: four sides plus two kinds of onboarding before one meal moves. If you want it smaller, change the model, not the backlog.
These nine sections should map onto any other use case. The content will differ; the questions won't.