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.<\/p>\n
The section breakdown below is deliberately generic \u2014 I'd mark the same points in any other use case.<\/p>\n 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 \u2014 and the reason nobody offers it is precisely that accountability is expensive.<\/p>\n I picked 1 and 3. Combined:<\/p>\n Your calendar picks the moment, and we guarantee the food lands in it \u2014 or we don't take the order.<\/p>\n 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.<\/p>\n 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.<\/p>\n It didn't stop at a slogan. The choice re-sliced the MVP:<\/p>\n 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 \u2014 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.<\/p>\n Dropped out of the MVP: live courier tracking. I liked the reasoning: if the window is guaranteed, watching a map is anxiety theatre.<\/p>\n 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.<\/p>\n story-map-creator then laid out the full proposal in chat, for approval \u2014 goals, steps and stories with releases and personas \u2014 without writing a single card. That's the right order: unpicking 100+ cards afterwards costs far more than reading a list.<\/p>\n Only after I approved it did the real map get built in StoriesOnBoard: 9 goals, 24 steps, 99 stories, 4 personas, 3 releases.<\/p>\n 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:<\/p>\n 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.<\/p>\n 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.<\/p>\n 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).<\/p>\n 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 \u2014 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.<\/p>\n 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 \u2014 it's whether it supplied the 30\u201340% everyone forgets in the excitement.<\/p>\n On the finished board I ran story-map-gap-finder. It didn't work from memory \u2014 it read the live map back, and found twelve gaps plus three structural problems.<\/p>\n Missing journey phases:<\/p>\n 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 \u2014 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.<\/p>\n Missing edge cases:<\/p>\n 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 \u2014 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.<\/p>\n Structural findings:<\/p>\n One step had no MVP story at all \u2014 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).<\/p>\n I accepted all of them. Final state: 9 goals, 26 steps, 111 stories \u2014 62 in the MVP, 49 in Release 2.<\/p>\n It listed separately the things that look missing but may be deliberate scope cuts \u2014 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.<\/p>\n That list matters more than it first appears. It's the place where the generator doesn't overwrite your intent.<\/p>\n 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 \u2014 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.<\/p>\n These nine sections should map onto any other use case. The content will differ; the questions won't.<\/p>\n","protected":false},"excerpt":{"rendered":" A calendar-timed food delivery app becomes a 111-story StoriesOnBoard backlog through discovery, positioning, and gap analysis.<\/p>\n","protected":false},"author":13,"featured_media":6391,"comment_status":"closed","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[7],"tags":[],"class_list":["post-6392","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-story-mapping","resize-featured-image"],"_links":{"self":[{"href":"https:\/\/storiesonboard.com\/blog\/wp-json\/wp\/v2\/posts\/6392","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/storiesonboard.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/storiesonboard.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/storiesonboard.com\/blog\/wp-json\/wp\/v2\/users\/13"}],"replies":[{"embeddable":true,"href":"https:\/\/storiesonboard.com\/blog\/wp-json\/wp\/v2\/comments?post=6392"}],"version-history":[{"count":1,"href":"https:\/\/storiesonboard.com\/blog\/wp-json\/wp\/v2\/posts\/6392\/revisions"}],"predecessor-version":[{"id":6393,"href":"https:\/\/storiesonboard.com\/blog\/wp-json\/wp\/v2\/posts\/6392\/revisions\/6393"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/storiesonboard.com\/blog\/wp-json\/wp\/v2\/media\/6391"}],"wp:attachment":[{"href":"https:\/\/storiesonboard.com\/blog\/wp-json\/wp\/v2\/media?parent=6392"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/storiesonboard.com\/blog\/wp-json\/wp\/v2\/categories?post=6392"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/storiesonboard.com\/blog\/wp-json\/wp\/v2\/tags?post=6392"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Where this test came from<\/h2>\n
\n\n
\n \nPositioning<\/th>\n The unique value<\/th>\n The riskiest assumption<\/th>\n<\/tr>\n<\/thead>\n \n The guarantee<\/td>\n We promise a window and refuse your order if we can't hit it<\/td>\n Will people accept "no" often enough for the promise to stay credible<\/td>\n<\/tr>\n \n The backwards clock<\/td>\n We tell you when to order so it lands in your gap<\/td>\n Is the deadline the real pain, rather than the accuracy<\/td>\n<\/tr>\n \n Calendar-native<\/td>\n Your calendar plans lunch, not you<\/td>\n Will people grant calendar access to a food app<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n 4. Positioning has to move the scope<\/h2>\n
5. Backlog generation \u2014 with an approval checkpoint<\/h2>\n
6. What it added on its own \u2014 the "didn't think of that" category<\/h2>\n
7. Gap analysis: what was still missing<\/h2>\n
8. What isn't a gap, but a decision<\/h2>\n
9. What I'm taking away<\/h2>\n