Feature Dossier
Documentation that gathers itself.
Product documentation was being created through a late, manual handoff from product teams to PMs. I designed Feature Dossier as a system that gathers the information needed for documentation throughout the product lifecycle—so by the time a feature is ready to ship, its documentation foundation is already there.
4.7/5
PM satisfaction
ROLE
Content Systems Designer & Technical Writer
TIMELINE
2026, 6-weeks
TEAM
Product PMs, Design, Engineering, PMM, Enablement
TOOLS
Claude Cowork, Shortcut, Figma, Notion
01
THE CHALLENGE
Documentation started too late.
After a restructuring reduced both writing and Product Management capacity, PMs were carrying more releases while working within the same six-week release cycle. Documentation still depended on a manual handoff. Near the end of development, I would ask the PM to explain the feature: what it did, how it worked, what changed, what users needed to know, and what edge cases mattered. That handoff could take 2–3 hours of PM time. And it happened on one of the busiest days of the release.
I was asked to fix that handoff, so I built an AI-powered version of it: an agent that scanned Shortcut for tagged epics and stories, then sent PMs a chat-based questionnaire. It failed in trial. The flow still needed careful, detailed input at exactly the moment PMs were most overloaded, and it produced partial, duplicate, and incorrect entries that created more follow-up work than the manual process it replaced. A smarter questionnaire was still a questionnaire. I was optimizing the handoff when the real problem was that the handoff existed at all.
02
THE INSIGHT
The information wasn’t missing.
It was arriving at the wrong time. Once I stopped focusing on the handoff itself, the pattern was obvious: almost everything I was asking PMs to tell me already existed somewhere, in the Shortcut epic, the PRD, Figma, and the Train-the-Trainer deck.
The documentation process wasn't creating most of this knowledge. It was reconstructing it at the end. That changed the design question from: "How can I make it easier for PMs to give me the information?" to "Why am I asking them for information the product lifecycle has already produced?" The solution wasn't a better intake form. It was to move documentation upstream.
03
THE SYSTEM
One dossier. Multiple sources. Continuous accumulation.
I designed Feature Dossier as a standalone pipeline that creates a living release record for each feature.
Instead of waiting for a final handoff, the dossier begins forming roughly one week before go/no-go and matures as reliable information becomes available.
Each source contributes something different.
Shortcut establishes the feature's purpose and scope.
PRDs add requirements, behavior, constraints, and edge cases.
Figma contributes the actual interface, interaction patterns, and user-facing terminology.
Training materials provide the mature explanation of how the feature works and why it matters.
The system reconciles those inputs into one structured dossier that can support documentation.
By the time I need to write, I'm no longer starting with a blank page or trying to reconstruct the feature through an interview. I'm starting with a nearly complete, traceable body of information.
04
KEY DECISIONS
Automation wasn't the hard part.
01
Capture information where it's created.
I didn't create another place for teams to document the feature. The system works from artifacts teams already produce as part of product development. That reduces duplicate work and makes documentation a consumer of the product lifecycle rather than another workflow competing with it.
02
Don't ask the PM to become the system.
PMs still own the truth of the feature. But ownership doesn't mean they need to manually reconstruct everything the organization already knows. Feature Dossier changes their role from: “Tell me everything I need to know.” to: “Is this accurate?” That's a much smaller—and better timed—request.
03
Separate source truth from documentation language.
Not every source is equally reliable, current, or written for the same audience. The system has to reconcile information across artifacts rather than simply concatenate it. Product artifacts establish what is true. The dossier organizes that truth. Documentation then determines how to explain it to a user.
04
Stop automation before ownership disappears.
I deliberately designed the system to stop at a confirmable draft. It does not autonomously publish documentation. The PM remains the last word on product accuracy, and I remain responsible for the quality of the final documentation. The goal was to automate information gathering—not accountability.
05
THE TRANSFORMATION
From a handoff to a lifecycle.
Feature Dossier changed where documentation work happens.
BEFORE
Feature scoped → Build → Release week → PM interrupted to write documentation from memory
AFTER
Epic opens → PRD, Figma, and training land → Dossier assembles quietly → PM confirms a near-finished draft
06
the outcome
Documentation moved upstream.
I tested the system through shadow runs against the existing PM-involved process.
Early runs matched approximately 80% of the information gathered manually. As I refined source selection, reconciliation, and dossier structure, that reached 95% accuracy without PM input.
In the pilot, documentation was ready roughly two weeks ahead of the August 2026 release, rather than being assembled during the final release window. PM response also validated the ownership model.
"I went in wanting to keep control over my own documentation. Once I actually used the review flow, that concern went away fast."
— Project Manager, pilot participant
07
What I Actually Designed
More than a document generator.
The visible output is a dossier. The more important work sits underneath it.
I designed the information model that determines what the dossier needs to know.
I mapped the source hierarchy that determines where each type of information should come from.
I defined the extraction model for turning different product artifacts into consistent structured information.
I established reconciliation rules for situations where sources disagree or mature at different rates.
I designed readiness criteria for determining when a dossier contains enough trustworthy information to support documentation.
And I placed human validation points where ownership and judgment matter more than automation.
The result is an information pipeline connecting product development to documentation.
08
THE BIGGER IDEA
Documentation shouldn't be downstream.
Documentation is often treated as the final step in product development.
Build the feature. Finish the design. Train the team. Then tell the writer what happened. That model guarantees that documentation begins late because the documentation process has been disconnected from the information that creates it.
Creating Feature Dossier showed me a different model: Documentation can accumulate as the product accumulates.
The writer doesn't need to be present for every product decision. The PM doesn't need to repeat every product decision. The system just needs to capture the right information, from the right source, at the point where that information becomes trustworthy.
09
Reflection
The hardest part wasn't automation.
Getting an AI system to extract information was relatively straightforward. The difficult part was deciding:
What information matters?
Which source should own it?
When does that information become trustworthy?
What happens when two sources disagree?
Where should automation stop?
Once those rules became clear, automation became much easier.
What the rules can't fix is information that never gets written down anywhere the system can see. A decision made out loud in a hallway conversation or a fast Slack thread doesn't make it into the dossier, no matter how central it turns out to be later. That gap doesn't show up in the accuracy numbers, because there's nothing to compare it against. It shows up in what PMs still get asked at handoff. As I extend this to other teams and release cycles, that's the part I expect to get harder, not easier, since not every team writes decisions down the same way to begin with.
Want to discuss the canonicity rules, the exact edge cases, or what almost went wrong with the confirm flow? Reach out and I can go into the details!