The quarterly planning session had reached the part where everyone pretends the board reflects reality. Epics sat in neat columns, each with a label that sounded like a decision: Platform Modernization, Data Layer Unification, Service Mesh Readiness. The senior engineer in the corner—the one who had been quiet for forty minutes—was staring at the screen with the specific stillness of someone doing mental arithmetic that doesn’t add up. She wasn’t looking at three epics. She was looking at one unsolved architectural problem, dressed in three different labels, spread across three quarters so nobody had to admit it was still unsolved.
She said nothing. The planning session concluded. The roadmap was committed. And the project acquired a new, invisible artifact: a story the team was telling itself, with a plot that had already stopped making sense.
This is not a story about bad intent. Nobody in that room was lying. The product manager genuinely believed the epics represented distinct deliverables. The engineering manager genuinely believed the sequencing was logical. The team genuinely believed they had a plan. What they had was a narrative—a plot—and the machinery of project planning had seduced them into mistaking it for a map.
The Narrative Structure of a Project Plan
Every roadmap is a story. It has a beginning (the current state), a middle (the sequence of work), and an end (the delivered outcome). It has protagonists (the team), antagonists (technical debt, dependencies, resource constraints), and a rising action that builds toward a climax (the launch). This is not a metaphor. It is literally how humans process complex, uncertain work: we impose narrative structure because narrative is the only way we know how to make sense of time.
The problem is that a story has different requirements than a project. A story needs coherence. It needs cause and effect. It needs a plot that feels inevitable in retrospect. A project, by contrast, is a series of interventions into a system that does not care about narrative coherence. The system will produce surprises. It will reveal that two epics are actually the same problem. It will demonstrate that the dependency you thought was resolved in Sprint 4 is actually a political negotiation that hasn’t started. But the roadmap—the story—has no mechanism for absorbing these revelations. It was built to be coherent, not to be true.
This is where the illusion of control takes hold. The act of plotting work—sequencing, naming, estimating—creates a sensation of mastery that is deeply satisfying and deeply dangerous. You feel like you’ve wrestled chaos into order. You’ve given the amorphous mass of work a shape, a direction, a plot. And once that plot exists, the team begins to protect it. Not consciously. Not maliciously. But the roadmap becomes the thing you report against, the thing you defend in stakeholder reviews, the thing you use to reassure yourself that the project is on track. The story becomes the standard by which you measure reality, instead of the other way around.
How the Plot Seduces the Team
Consider the screenplay. A professional script follows rigid formatting rules: scene headings, subheadings, transitions, character cues. These conventions exist to make the script readable and producible. But they also create a powerful illusion: that the story is complete, that the structure is sound, that the only remaining work is execution. As the StudioBinder guide on how to write a movie script explains, proper formatting ensures “your ideas are communicated clearly and professionally.” The format itself becomes a signal of readiness. A well-formatted script looks like a film that’s about to be made.
Project roadmaps work the same way. The conventions of modern planning—epics, user stories, story points, sprint boundaries, dependency arrows—are formatting rules. They make the plan legible. They signal professionalism. And they create the same illusion: that the plan is complete, that the structure is sound, that the only remaining work is execution. A well-formatted roadmap looks like a project that’s about to succeed.
But a screenplay is not a film. It is a document that describes a film that does not yet exist. And a roadmap is not a project. It is a document that describes a project that does not yet exist. The gap between the document and the reality is where projects die, quietly, while everyone continues to report green status against a story they stopped believing three sprints ago.
The senior engineer in the planning session understood this gap. She saw that Platform Modernization and Data Layer Unification were not two epics with a dependency. They were the same architectural decision, deferred, relabeled, and spread across two quarters because the team lacked the organizational capital to make the decision now. The roadmap had solved the narrative problem—“we have a plan for the architecture”—without solving the architectural problem. And because the narrative problem was solved, nobody felt the urgency to solve the real one.
The Specific Mechanics of Roadmap Fiction
Let’s get concrete. Here are the specific ways a roadmap becomes a story you’re telling yourselves, with examples drawn from real projects (details changed, patterns preserved).
1. The Same Problem, Different Labels. This is the opening scene. A team faces a hard architectural or organizational decision. Instead of making it, they create multiple work items that all orbit the decision without addressing it. Evaluate Options for Service Mesh becomes one epic. Improve Inter-Service Communication becomes another. Reduce Latency in Cross-Cluster Calls becomes a third. They look like three distinct pieces of work. They are actually one decision, deferred, with three different names so the backlog looks productive.
2. The Dependency That Isn’t. Team A’s roadmap shows a dependency on Team B’s deliverable in Sprint 6. Team B’s roadmap shows no such deliverable. Nobody has talked to Team B. The dependency exists only in the narrative structure of Team A’s plan—it’s a plot device, not a coordination agreement. But it makes the story work, so it stays on the board.
3. The Estimate as Narrative Anchor. A story point is not a unit of time. Everyone knows this. But once a number is assigned to an epic, it becomes part of the story. “This is a 13-point epic” starts to mean “this is a large but manageable piece of work.” The number creates a sense of boundedness. The problem is that the number was generated by a team that didn’t yet understand the problem, using a process that rewards consensus over accuracy. The estimate is a narrative device, not a prediction. But the roadmap treats it as a fact.
4. The Phase Two Graveyard. Every roadmap has a “Phase Two” section. It’s where hard problems go to be forgotten. “We’ll address observability in Phase Two.” “We’ll refactor the authentication layer in Phase Two.” Phase Two is not a plan. It’s a narrative resolution. It allows the Phase One story to have a happy ending—“we’ll handle the hard stuff later”—without committing any resources to later. The plot is complete. The project is not.
5. The Status Report as Continuity Edit. Weekly status reports are not descriptions of reality. They are continuity edits to the story. When something goes off-script—a delay, a discovery, a dependency that materialized—the status report smooths it over. “We’ve identified an opportunity to revisit the data layer approach” means “we discovered the data layer approach doesn’t work.” “We’re adjusting the timeline to ensure quality” means “we’re late.” The language preserves the narrative coherence of the roadmap while reality diverges further and further from the plot.
Why Teams Protect the Story
If the roadmap is fiction, why do smart, experienced teams keep treating it as fact? The answer is not incompetence. It’s incentives.
A roadmap is not just a planning tool. It is a social contract. It is what you promised your stakeholders. It is what your manager used to secure headcount. It is what the VP of Engineering presented at the all-hands. Admitting that the roadmap is fiction is not a technical admission. It is a social one. It means admitting that you promised something you couldn’t deliver, that you didn’t understand the problem when you made the promise, that the story you’ve been telling for months is not true.
Most teams would rather protect the story than make that admission. They would rather relabel the same unsolved problem for three more sprints than tell the sponsor that the original estimate was wrong. They would rather add a “Phase Two” section than admit that Phase One doesn’t actually deliver the outcome anyone wanted. They would rather edit the status report than edit the roadmap.
This is not cowardice. It is a rational response to an organizational environment that punishes uncertainty and rewards the appearance of control. The roadmap is a performance of certainty. The team knows it’s a performance. The stakeholders know it’s a performance. But everyone has agreed, implicitly, to treat it as real because the alternative—admitting that nobody knows exactly how this will unfold—is too uncomfortable to sustain.
The Plot Generator Problem
Here’s where the analogy gets uncomfortably precise. There is a whole category of tools designed to generate plots. Writers use them to break through creative blocks, to explore structural possibilities, to see their story from a different angle. The Reedsy plot generator is a perfect example: you input your protagonist, your conflict, your stakes, your genre, and it returns a structured outline—acts, beats, turning points. The tool is genuinely useful for writers who understand that the output is a starting point, not a finished story. It helps you see a shape. It does not write the book.
But imagine a writer who treats the generated plot as the final manuscript. Who submits the outline to their publisher as a completed novel. Who insists, in editorial meetings, that the story is on track because the plot structure is sound. That writer would be delusional. And yet this is exactly how many teams treat their roadmaps. The planning process—the quarterly session, the story mapping workshop, the estimation poker—is a plot generator. It produces a structured outline of the work. It gives you acts, beats, turning points. It helps you see a shape. But it does not build the product. And treating the outline as the deliverable is how projects drift into fiction without anyone noticing.
This is not an argument against planning. It is an argument against confusing the plan with the project. The roadmap is a hypothesis about how the work might unfold. It is a story you are telling yourselves to coordinate action. The moment you start treating it as a commitment—as a plot that must be preserved—you lose the ability to see when the story has stopped making sense.
There’s a related danger in how teams use planning artifacts to generate the appearance of structure without the substance. You can feed a few bullet points about your product vision into an AI plot generator that structures a narrative from fragments, and it will return something that looks like a coherent plan. The danger isn’t the tool—it’s the temptation to stop there, to accept the generated structure as the plan itself rather than as raw material for the harder work of questioning assumptions and confronting the unsolved problem hiding behind the labels.
The Habit That Changes What the Team Sees
So what do you do? You cannot abandon roadmaps. Coordination at scale requires some shared story about what you’re building and when. The goal is not to eliminate the narrative. The goal is to hold it lightly enough that you can see when it’s diverging from reality.
Here is the habit. It is small, repeatable, and costs nothing except the willingness to be uncomfortable for ninety seconds.
Before every planning cycle—before you touch a single Jira ticket or draw a single dependency arrow—ask this question: “What is the one thing we are pretending not to know about this plan?”
Write the answer down. Put it somewhere the team can see it. Not in a private document. Not in a Slack thread that will scroll away. On the wall. In the planning doc header. In the retrospective notes that you’ll actually review next quarter.
The question works because it targets the gap between the story and the reality. It forces the team to name the unsolved architectural problem that’s been relabeled across three epics. It surfaces the dependency that exists only on your board, not in the other team’s commitments. It acknowledges the estimate that everyone knows is a guess but nobody has said is a guess. It makes the invisible visible, not to punish anyone, but to prevent the roadmap from becoming a document that everyone protects and nobody believes.
I’ve seen this question change the trajectory of planning sessions. In one case, a team wrote: “We are pretending that the authentication service rewrite is a separate epic from the API gateway migration, but they are the same decision about session management, and we haven’t made it.” That sentence, written on a whiteboard in the first ten minutes of planning, saved the team three months of parallel work that would have collided in a spectacular integration failure. They didn’t solve the problem in that session. But they stopped pretending it was two problems. And that changed everything.
In another case, a team wrote: “We are pretending that the VP of Infrastructure has agreed to our timeline, but we haven’t actually shown it to her.” That sentence led to a conversation that led to a meeting that led to a revised timeline that was actually achievable. The previous timeline had been a story the team was telling themselves about what the VP would agree to. The question surfaced the fiction before it became a crisis.
What Happens When You Stop Protecting the Plot
When a team stops treating the roadmap as a story that must be preserved, several things shift.
First, status reports become less performative. You can say “we discovered that Epic A and Epic B are the same problem, so we’re collapsing them and rethinking the approach” without feeling like you’ve failed. The roadmap was a hypothesis. The hypothesis was wrong. You’re updating it. That’s not failure; that’s learning.
Second, estimation becomes more honest. When the team knows that the estimate is a starting point, not a commitment, they can give a number without the terror of being held to it forever. The number is a tool for conversation, not a plot point that must be defended.
Third, dependencies become real. When you’re not protecting the narrative coherence of your plan, you can admit that you don’t actually know what Team B is doing, and you can go find out. The dependency arrow on your board becomes a prompt for a conversation, not a substitute for one.
Fourth, and most importantly, the team starts to see the project as it is, not as the story says it should be. The unsolved architectural problem gets named. The deferred decision gets a deadline. The Phase Two graveyard gets excavated. The roadmap becomes a living document—a hypothesis under continuous revision—rather than a monument to a planning session that happened six months ago.
The Cost of Not Asking
The alternative is the project I described at the beginning. Three epics that are actually one problem. A team that knows, silently, that the plot doesn’t make sense. A planning session that ends with commitments nobody believes. And six months of work that produces motion without progress, because the team is executing against a story instead of solving the problem the story was supposed to describe.
This is not a rare failure mode. It is the default. The narrative structure of project planning is so seductive, and the organizational incentives to protect the story are so strong, that most teams drift into roadmap fiction without ever making a conscious decision to do so. They don’t lie. They don’t deceive. They simply confuse the map with the territory, and then they spend months walking a path that exists only on paper.
The question—“What is the one thing we are pretending not to know?”—is not a solution. It is a discipline. It is a small, repeatable interruption to the machinery of narrative self-deception. It won’t fix your roadmap. It won’t solve your architectural problems. But it will surface the gap between the story and the reality, and once that gap is visible, you can decide what to do about it. You can relabel the epics for another quarter, or you can have the hard conversation. You can add another item to Phase Two, or you can admit that Phase One doesn’t deliver the outcome. You can edit the status report, or you can edit the plan.
The choice is yours. But you can’t make it until you see the fiction for what it is. And the first step to seeing it is asking the question, out loud, in a room full of people who are also pretending not to know.