What an AI builds when you tell it nothing.
This is part one of a three-part series about building a product backlog with Claude, five custom story mapping skills, and the StoriesOnBoard MCP server.
It started with one lazy sentence:
“Create a story map called Todoista app.”
That was all the context I gave Claude. I had a product idea in my head, a domain, and a StoriesOnBoard workspace. I assumed the rest would become clear as we went.
Claude created the empty map, asked which product it should belong to, and then did exactly what a capable AI assistant is designed to do: it filled the silence.
When context is missing, AI returns the category average
I asked Claude to build the backlog. With nothing but the name “Todoista,” it proposed a complete, plausible structure:
- Access the app
- Capture tasks
- Organize tasks with projects, labels, and filters
- Plan daily work
- Complete and track tasks
- Collaborate through assignments and comments
- Manage the account and settings
There was nothing obviously bad about it. In fact, that was the problem. The structure would fit almost any task manager. It was reasonable, tidy, and completely wrong for the product I intended to build.
Claude had not failed. The name pulled it toward Todoist, and I supplied no evidence to pull it back. When an AI product specification is missing, the model does not leave a blank page. It generates the statistical average of the category.
That is a dangerous failure mode because generic output rarely looks broken. It looks professional.
The specification described a different product
The real product was not a task manager. It was an attention layer for managers, organized around one question: who has the next move?
A manager delegates, asks, reviews, and waits. They may have open threads with team members, customers, and suppliers at the same time. What gets lost is not necessarily a task. It is the fact that Anna promised a quotation three weeks ago and nobody followed up.
That changes the product model. Work is divided into two views:
- My Tasks: the ball is with me.
- Waiting: the ball is with someone else.
Capture is voice-first because commitments happen in meetings and calls, not only at a desk. The product also includes an MCP server so external AI agents can record commitments on the manager’s behalf.
Once Claude had the actual specification, the original backlog stopped looking “slightly off.” It described another product.
A person in the data model is not automatically a persona
The specification was unusually precise about the people being tracked. Anna, a client, or a supplier would never sign in. They would receive no notification, hold no permission, and might never know the product existed.
That makes them data entities, not product personas.
The distinction matters. If I had modeled a supplier as a persona, the story map would naturally start generating stories such as “As a supplier, I want to receive a reminder.” A few iterations later, the product would have accounts, invitations, permissions, comments, and collaboration. In other words, it would drift back toward the generic task manager Claude first imagined.
Only two personas remained:
- the Manager, who uses the product directly;
- the AI agent, which acts through MCP.
This was not a naming preference. It was a scope boundary.
A product specification is not product discovery
I had already built a product-discovery skill for exactly this kind of work. It covers four areas:
- Fundamentals: whose problem is this, how do they solve it today, and why now?
- Users: specific personas with jobs-to-be-done and pain points.
- Uniqueness: real alternatives, a one-sentence value proposition, and a switch test.
- Journey: a four-to-eight-phase outline from entry to outcome.
The skill is deliberately skeptical. It challenges vague answers instead of polishing them into a brief.
And I never ran it.
I assumed the specification made discovery unnecessary. It covered the fundamentals, users, and journey reasonably well. What it did not answer was the uniqueness question: why would somebody switch?
If a manager currently uses a notebook or Asana to track delegated work, what is the one capability that makes changing tools worth the effort? We never made that explicit.
The missing answer came back during release slicing
The gap stayed invisible while Claude built the backbone and the stories. It surfaced only when the story-map-navigator evaluated the release gates.
The MCP server was one of the specification’s highlighted differentiators. Yet the entire “Let AI agents track for me” goal sat outside the MVP. Not one story under it was in the first release.
Formally, the MVP still passed. It was a coherent, usable product on its own. Strategically, it might have shipped without the capability that made the product worth noticing.
No one had been careless. We simply had not declared the differentiator, so there was nothing against which to test the release slice.
What I would do before asking AI to build the backlog
The fix is not a bigger prompt. It is a short checkpoint before generation:
- Name the user who actually operates the product.
- Separate users from people or objects that merely appear in the data model.
- Describe the strongest current alternative, including “do nothing.”
- Write one concrete reason to switch.
- Mark the capability that must appear in the MVP to test that reason.
- State the platform and usage context instead of letting the model infer them.
Five minutes spent here can prevent hours of excellent work on the wrong product.
The lesson I did not want to learn
Skipping discovery did not stop the process. That is what makes it tempting. In a few hours, I still had a large, release-sliced backlog with acceptance criteria. The tools worked.
The cost merely moved downstream. The gap finder later found the cold-start problem. The navigator found the missing differentiator. I eventually exposed the unstated web-versus-native assumption by accident, after several stories already depended on it.
Every mistake was fixable. Every one would have been cheaper before the first card was created.
Next in the series: 82 cards in four hours — but which 82? The backlog grows from an empty map, a foundations checklist adds the boring essentials, and a read-back catches a counting error.