i. the bet
There’s a real pressure in product design right now. The gravity of the moment pulls in one direction: More. Faster. Automate. Think less, move more, let the model carry the cognitive weight. Even the careful thinkers are asking how to do that well, not whether to do it.
I built something that runs the other direction.
The detailed design narrative is the core of my practice, and it is not passive. You write a story about one person moving through the product – beat by beat, procedure by procedure – and you do it carefully enough that the story catches what a requirements document misses: where the logic breaks, where the UX makes a silent assumption, where two source documents contradict themselves about something basic, like when an applicant becomes an applicant. You can’t skim your way to that. You have to be present.
That is, in 2026, an unfashionable position to hold.
I’ve been building this methodology for twenty years. It has worked, not in a “we shipped something” sense but in a “we all understood the idea and built the right thing together” sense. And I find myself asking, in a year when the whole industry is optimizing for less reading and less friction: am I asking too much?
I don’t have a clean answer. I can tell you what the practice actually is, what it’s produced this year, and where it’s still breaking.
ii. the volume problem
The hard part for anyone in product right now is managing the volume. My colleagues are leveraging AI to analyze markets, synthesize PRDs, generate prototypes, spin up agentic workflows. Everyone is producing more, sharing more, generating more. Anyone without a system to parse the avalanche is buried in a tranche of possibility.md. What is the count of output tokens that have gone unread by a human? Are we even the audience anymore?
The practice I’ve been building isn’t a way to generate more – though it does.
It’s a way to not read it all and still make the right thing.
The mechanism is the design narrative – but what the narrative does has changed. For twenty years, writing the story was the synthesis. You couldn’t write “Marci checks the waitlist” without having resolved the competing inputs into what that moment actually meant for one person. The act of writing was the act of thinking. Now the AI synthesizes the story from the inputs – prototypes, procedural documentation, a pile of context nobody has fully read – and the cognitive task shifts from generation to editing. You’re not writing from scratch. You’re cutting what’s wrong, adding what the first pass missed, throwing curve balls until the model’s version of the story becomes your version of the story. The cognitive work is different, not gone. The story is still the control surface.
Writing it is now relatively fast. Reviewing it requires you to slow down and actually feel the story – to care whether Marci gets what she needs. That is a contrarian design philosophy in a world of dopamine-fueled vibe coding.
iii. the foundation
The infrastructure is plain files. If you’re a product designer and you aren’t routinely pointing a coding harness at a folder of .md files on your own hard drive, you need to catch up. A folder is a project. A conversation ends in a file, not a chat thread, and the next conversation starts by reading that file. Feedback goes in the margins, not the composer. Do that for a few weeks and your work looks like iterative development on artifacts.
On my team that layer has three shelves: Canon (the story bible), Features (the active project), Workflow (how we work, in a GitHub repo, because a repo is both shared and local). That choice looked like plumbing. It turned out to be the point – a repo lets you see how other people work.
iv. making it multiplayer
In 2024, I ran these loops alone. This year I had to make them work for other people. That is a different problem.
The solo loop is straightforward. Scaffold the story, hand it to the model to enrich, annotate the results, let the annotation become the next prompt. It ran exactly as fast as I could read, and I was the only one who could tell whether it was working.
The multiplayer version is the same loop with the artifact shared and the people annotating it not having made it. That sounds like a small change. It changes everything.
This summer a three-person squad picked up a compliance feature I wasn’t on. Over one long day, Moody committed eight times: processed documents, a specification folder, a prototype built checkpoint-by-checkpoint, a team journal, and a file called CLAUDE.md – how we work here. Their journal: “We hit the real turning point when we mirrored Miles’s sprint-6 specification split.” I read that sentence two months after they wrote it.
They translated a pile of input into a coherently scoped story set, built a prototype, and packaged both into a wiki that walked the product team through open questions until the questions ran out. Nobody told them to make a wiki. The loop needed one.
The first time Willie and I ran a story through a review surface, the synthesis came back as thirty-seven proposed changes. Dennis got the document cold the next day. In front of everyone, he said it prescribed a way of working he wasn’t sure the team had agreed to, and that the whole thing “feels very uncomfortable.”
He was right.
I stopped explaining the document and started explaining the story. The team stopped talking about process and started arguing about Lindsay. Their note was better than anything I had: do it in smaller chunks.
That moment – Dennis in front of everyone – is the clearest evidence I have that even a well-made plan requires onboarding. What story level is this? How do we use this method? What are the rules for annotation? I had spent a week and a hundred turns with an AI building an annotation taxonomy. Walking someone cold into it was still hard. The density is real. The cognitive ask is real.
Now the review surface is the studio itself. The recording processes into decisions and open questions, and those become the next prompt. On a recent Friday afternoon, Moody prompted a story: one applicant, one procedure, grounded in documents none of us had fully read. Those documents came from three product managers doing real work, making sense of all the business and market requirements around them, and handing it over WIP. By Monday we were in the studio with what the model had made of it.
What the narrative gave the designers was a way to take all of that seriously: absorb the complexity, keep what the PMs had actually figured out, and ask not whether it cleared requirements but whether it would work for Marci. That question doesn’t live in a spec. The story is where it lives.
v. what the loop required
A common home. Github as an artifact layer almost matters less than the window it gives into how other people work. Commits, journals, files where a team wrote down their own rules – that’s so much of the magic. Common home before common method.
Useful friction. Every annotation session asks someone to think carefully about work they didn’t produce. Make the expectation explicit. This is where the work happens now, where the human judgement gets inserted into the loop. The friction is not a bug.
Discarding well. We set aside a prototype last week and kept only the questions it raised. Nobody flinched. That ease runs deeper than prototypes: a rough first story isn’t a failed story. We call it a productive discard — you’re finding out exactly what you’re not building. The artifact goes. The understanding stays.
vi. what I still don’t know
Narratives break down nicely into story sets, which bound scope cleanly and enable release sequencing. End-to-end of story one, backlog of what follows, delivery units better defined because of the goal-directed narrative framing. That part works.
Whether it generalizes – maybe? The harder question is whether I’m asking something of teams that most teams won’t earnestly give.
Here’s what I keep coming back to: you cannot shape a narrative – even a generated one – without imagining a real person. Editing the model’s draft forces the question a spec never asks: does this work for Marci? Not ‘does it clear requirements.’ Does it work for her. That’s the anchor.
The detailed design narrative is heavy cognitive work. It demands presence. It is, in 2026, swimming against the tide. I’ve been swimming against it for twenty years on the theory that understanding what you’re building before you build it is worth the effort, and that you can’t know that until you’ve imagined at least one real person who needs it.
I still think that’s true. I’m just watching it get faster.
Terrific insights, Miles. Sharing this with a client who is willing to struggle with us as we evolve better ways to use AI in our creative process.
It helps us if we avoid thinking of ourselves as asking AI to complete tasks with names. If the task is ‘agentic workflow,’ AI has already set the parameters, no matter how infinite. Instead, we’re learning to be hyper aware so we can ask AI for process input at discrete steps. At every intervention point, we’re back in charge as creators. Slow? Yes. Warmer, more human product? Also yes.
Right now we’re neophytes who would laugh out loud at ourselves if we called anything agentic. I think that’s what resonated about your article. You’re talking about the difference between being simple minded and preserving beginner’s mind. Preserving beginner’s mind is nigh on impossible at the levels of sophistication you’re encountering. Impossible and definitely worth doing.
Thanks for the clarity! Looking forward to reading more.