Everyone Writes the Docs. So Who Owns Them?

Ask your team who writes documentation and you’ll get a list: the PM who shipped the feature, the engineer who explained the API, the support lead who wrote the workaround article, and now AI drafting the first version of most of it.

Ask who owns documentation and the room goes quiet. Or worse, everyone answers yes, which is the same thing.

60+ product and documentation teams at B2B SaaS companies, interviewed through 2025 and 2026: teams that lost their writers, teams that never had one, and teams where the writers never left.

Several of the teams whose documentation held up had no writer at all. What they had was an answer to four questions about documentation, and a name against the two that matter.

How this landed on you

Two roads lead to the same place.

The first: there was a documentation team, and it was dissolved. A product manager at a European CRM vendor (B2B SaaS, 500+ employees) described the aftermath plainly — the dedicated team doesn’t exist anymore, so responsibility sits with the product team and gets shared among product managers.

A head of product at a data platform vendor (1000+ employees, APAC) took that road deliberately and came out with a rule rather than a regret. His team decided the PM should own the process and own the contents, and he was blunt about the reasoning: any one person will do, as long as somebody starts. A PM is not the ideal owner. A PM is a named one, and the naming matters more than the argument about who.

The second road is quieter and more common than it looks: there was never a writer to begin with. Documentation got written in bursts by whoever needed it. A marketer for a launch, an engineer for an integration. Then one day it landed on someone’s plate as a permanent thing, often the head of support, because they were closest to the customer and the pain.

Either way, the person now accountable is not a professional writer, has no criteria for what good looks like, and inherited a portal in whatever state it was in.

What nobody handed over was the part that says which of these decisions are yours and which you can pass on.

Because a writer leaving doesn’t only take away the ability to write well. It takes away a set of decisions that were invisible while someone was quietly making them: does this need a new article at all, or does it belong inside an existing one? Is anything here already written somewhere else? Who can confirm the technical details are right? Is this finished enough to publish? And has any of the old material stopped being true?

Nobody handed those over because nobody had written them down. They weren’t anyone’s process. They were somebody’s professional habit.

“Everyone writes” and “nobody owns” are the same state. You just notice them at different times.

Four questions, and only two of them are delegable

Strip documentation down to the decisions that actually get made about it, and you get four:

1. What gets documented at all? Which jobs deserve a page and which don’t. You’d never let someone outside the team decide which features ship; this is the same decision, and right now it’s being made by whoever has the file open.
2. Who writes it? A PM, an engineer, a contractor, AI. Whoever is closest to the knowledge and has the time.
3. Who confirms it’s true? Someone who can say the steps work, the code runs, and the permissions are described correctly.
4. Who decides it’s done? The point where “good enough” is declared and the page goes live.

Questions 2 and 3 delegate cleanly. They’re bounded, they have obvious owners, and handing them over feels like progress, which is why teams hand them over first and stop there.

Questions 1 and 4 don’t delegate. Not because delegation is forbidden, but because they’re judgment calls about the product, made against criteria only the person accountable for that area holds. Pass them to whoever happens to be writing and you’ve handed your scope decisions to the person with the least context about where the product is going.

You can delegate the writing and the fact-checking. You cannot delegate deciding what deserves to exist and when it’s finished.

“It’s the whole team’s responsibility” — true, and not an answer

In several of the teams we interviewed, documentation belongs to the whole cross-functional squad: everyone contributes, everyone reviews, and nobody treats it as one person’s chore. It’s a healthy culture and worth having.

It’s also not a substitute for this grid, and the teams doing it well know that. Shared contribution sits in rows 2 and 3, where it belongs. Rows 1 and 4 still resolve to a person, normally the one who owns the area, because “the squad decides what’s worth documenting” means the decision gets made by whoever speaks last before the release.

If you’re thinking RACI, you’re right

In larger organizations this work is formalized as RACI or RASCI, and there’s nothing wrong with it. It’s just heavier than this needs to be. A full matrix distributes dozens of tasks across a permanent team. Documentation has four contested questions.

If you map ours onto the letters, something useful falls out: writing and verification are Responsible and Consulted, and both have obvious candidates. Scope and sign-off are both Accountable, and Accountable is the letter that kept coming up missing in our interviews. Nobody was short of contributors. They were short of a name next to the two decisions that carry no deadline.

Real story: every topic had an author, and nobody owned anything

An analytics vendor — B2B SaaS, 150 employees, North America — did what looked like the responsible thing after their one writer left. Each PM would document their own features. They added a docs field to the release checklist and a column to the tracker, so every topic had a name against it.

For a year, this appeared to work. Every release shipped with documentation. Every page had an author. Nothing was obviously on fire.

What they couldn’t answer was anything about the whole. Was a feature worth documenting at all, or had it been written up because the checklist demanded it? Was a page finished, or had it been published because the release was going out that afternoon? When two PMs described the same permissions model differently, whose version stood?

Those questions never made it into anyone’s week, because none of them belonged to a specific ticket. The tracker column had covered authorship, which was never the hard part.

What actually changed

Nothing about who writes. The writing stayed exactly where it was — with the PM who built the thing.

What they added was a name against scope and sign-off, per product area. Two people, both already owning those areas. The rule was written in one line: no page goes live until that person confirms the job is worth documenting and the page finishes it. Whether a missing page should also hold up the release was a separate argument, and they had it later.

Nobody pushed back, and the reason is worth noting: they weren’t being asked to do anything new. Both were already making these calls — silently, at the end of a release, under time pressure. Resistance comes from new work. This was naming existing work.

The visible change was in the arguments. Before, disputes about documentation were about capacity — who has time to write this. After, they were about whether a job deserved a page at all. That’s a much better argument to be having, and it happens before the writing, not after.

The second change was slower and mattered more. Because someone was accountable for scope, gaps stopped being nobody’s fault. A missing page had an owner, which meant it could be prioritized like anything else with an owner.

Your AI drafts don’t change this. They change one row.

AI is an author. It goes in row 2. It’s fast, tireless, and sometimes confidently wrong, and it needs what every author needs: a defined scope going in and verification coming out.

Teams that use it well know exactly how much correction it takes. A product manager who drafts articles with an AI assistant against his Jira epics told us he rewrites roughly 20 to 30 percent of what comes back: “I will modify, I will say between 30 and 20% of what is automatically writes by cloud.” He describes that as a working arrangement, not a complaint: a human does verification and sign-off, exactly where they belong.

AI is an author, not an owner. Handing drafting to it moves the row that was always delegable and leaves the two rows that never were.

Where this goes wrong is when the model is treated as the answer to the ownership question rather than the writing question. Then nobody defines what to draft, nobody checks the output against the product, and you get what we described in the last lesson: more pages, same questions.

Why the tooling won’t rescue the process

Teams arrive convinced that adding AI will fix documentation. When you ask how their current process works — who decides what to write, who checks it, who publishes — the answers are vague. Some have started cutting headcount on the assumption that the tooling will absorb the work, before any of it is set up or even specified.

Calling this naive misses what’s happening. It’s a reasonable hope that a tool will supply a decision structure, and the hope goes unmet. A model executes the process you describe to it, and if you can’t describe yours, what you get back is your existing process, faster and at greater volume.

AI can’t fix a process you never wrote down. It scales whatever you’re already doing, including the parts that aren’t working.

Your artifact: the ownership grid

Four rows, one name each, and a last column you fill in as things actually are.

Decision	Name	How it happens today
What gets documented		Nobody decides; the checklist decides
Who writes it		Whoever shipped the feature
Who confirms it’s true		Sometimes; skipped under deadline
Who decides it’s done		Whoever is publishing that day

Rows 2 and 3 tend to fill themselves: the PM or engineer who shipped the thing, and the engineer or tester who can confirm it behaves that way. Rows 1 and 4 are the ones to slow down on, and they should carry the same name. Deciding what deserves a page and deciding it’s finished are one judgment applied at two moments.

You enforce this everywhere else. Nobody accepts “the team” as the owner of a release date, and nobody closes a ticket assigned to a department. Documentation is the one place where “the product team owns it” passes without comment. If you can’t write a single person against rows 1 and 4, that’s the finding, and it’s the most useful thing this exercise will tell you.

The last column is where teams learn the most. Writing “whoever is publishing that day” next to sign-off is uncomfortable and accurate, and it turns a vague sense that documentation is messy into something specific to fix this quarter.

If rows 1 and 4 come back empty, that’s not a sign your team is sloppy. It’s the normal outcome of how these decisions surface: they only become visible when something has already gone wrong, like a gap someone noticed or a page that shipped half-finished. Problems that appear only in hindsight never make it into a backlog, so they never get an owner. Which is also why this doesn’t resolve on its own.

One thing this grid deliberately leaves out: it covers a page up to the moment it goes live, and says nothing about what happens to it two releases later, when the screen it describes has changed. Somebody has to notice that, and “somebody” is a different problem with a different fix. Get the four rows named first. We’ll come back to what keeps them true.

If your team doesn’t look like this

If you’re three people and you do all four rows yourself, the grid is a self-check rather than a distribution exercise. Fill it in anyway. The value is in noticing that rows 1 and 4 are decisions you make implicitly, in the moment, under release pressure. Making them explicitly takes about the same amount of time and produces different results.

The other exception: if you have a writer or a writing team, rows 1 and 4 still sit with the area owner. A writer executes scope; setting it requires knowing what’s coming next quarter and what the business needs from adoption. Teams that hand the whole grid to a writer are the ones most surprised when documentation drifts away from what’s actually shipping.

What to do this week

• Fill in the grid for one product area. Twenty minutes, last column included.
• Look at rows 1 and 4 first. If either is blank, ambiguous, or answered with a team name, that’s your finding.
• Put a name there. Almost always the person who already owns the area. If that’s someone other than you, you’re not assigning them work. You’re asking them to confirm out loud what they already decide in private.
• Have the conversation in one sentence. Something close to: “You’re already the one deciding whether this needs a page and whether it’s finished. Can we just say that’s yours, so the gaps stop being nobody’s?” That’s the whole ask, and it’s hard to argue with, because it’s already true. Don’t pretend it’s free, though: once the decision is named, it has their attention on it, and sometimes a release will wait for them.
• Write it down where the team works: no page goes live until that person confirms the job is worth documenting and the page finishes it. One sentence, not a process document.
• Don’t touch rows 2 and 3 this week. Row 2 is probably working. Row 3 probably isn’t, and it needs more than a name. That’s the next lesson.

Ownership is a name attached to two decisions that currently don’t have one. Everything else is commentary.

You’ll notice that row 3, the one about confirming it’s true, is where people nod and then quietly skip. Telling your engineers to care more won’t fix that. It’s next.

FAQ