Feature Dossier
Documentation that gathers itself.
Product documentation depended on a late, manual handoff from PMs on one of the busiest days of the release. I designed Feature Dossier to gather what documentation needs from the artifacts product teams already create, so by the time a feature is ready to ship, its documentation foundation is already there.
4.7 out of 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.
The dossier starts forming one week before go/no-go. That timing is deliberate. Shortcut holds far more projects than will ever ship in a given release, and starting earlier would bury the dossier in work that's still exploratory. One week out, scope is settled enough to trust, and there's still time to document it properly. From there, the dossier matures as reliable information lands.
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. Once the PM confirms it, the dossier becomes the brief that InkLoom, my AI editorial system, drafts from.
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, when it's ready.
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. It also waits until the information is worth having. Pulling from every open Shortcut project would have meant documenting features that never ship. Starting one week before go/no-go keeps the dossier focused on what's actually releasing.
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 request, and a much better-timed one.
03
Reconcile sources instead of stacking them.
Not every source is equally reliable, current, or written for the same audience. So the system follows explicit rules for which source wins: A later artifact replaces an earlier one on the same detail. A status change always overrides, whatever its source. A PM's edits and comments are always the final word.
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 explain the feature from memory
AFTER
One week before go/no-go → Shortcut, PRD, Figma and training material gathered → 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 for the August 2026 release was ready roughly two weeks ahead of release, instead of being assembled in the final release window. The five pilot PMs rated the experience 4.7 out of 5.
The pilot worked. Feature Dossier is now the standard intake for release documentation.
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 set the timing window that decides when a feature is worth documenting.
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 documentation starts late, because it's been cut off from the information that creates it.
Feature Dossier showed me a different model: documentation can draw on the product as it's built, instead of reconstructing it after.
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 the system takes on more of the release process, that's the part I expect to get harder, not easier, since not every team writes decisions down the same way.
Want to discuss the reconciliation rules, the exact edge cases, or what almost went wrong with the confirm flow? Reach out and I can go into the details!