Who Should Write Your Help Center Articles?

It's one of those debates that flares up every time a help center falls behind. Support says the PM should document features since they understand them. The PM says support should write articles since they know what customers actually ask. Someone suggests hiring a technical writer, and finance asks if that's really necessary. Meanwhile, three features shipped with no documentation and the ticket queue is growing.

The argument feels like it's about ownership. It's really about a broken handoff. Once you see that, the "who writes it" question mostly dissolves — and you can build something that ships docs fast no matter who's holding the pen.

Why "who writes it" is the wrong question

Picking a single owner sounds tidy. In practice it fails for a predictable reason: no one role has all the inputs a good help article needs.

A help article needs three things. It needs to be accurate — match how the feature actually works, including the edge cases. It needs to be relevant — answer the questions customers really ask, in their words. And it needs to be clear — well-structured, consistent, easy to skim. Those three live in three different heads. Force the PM to do all of it and you get accurate but jargon-heavy articles that ship late because the PM is busy. Force support to do all of it and you get relevant, friendly articles that sometimes miss how the feature was actually designed to work. The single-owner model trades one weakness for another.

What each role is actually good at

Instead of asking who owns it, get specific about what each role uniquely brings. Then the collaboration designs itself.

Read that table and the answer is obvious: none of them should work alone. The PM has the raw truth, support has the customer lens, the writer has the craft. The job is to combine them without a week of email tag.

A collaboration model that works

Here's the split that consistently ships fast and accurate help articles. It maps cleanly onto the three roles.

The PM captures, once. Not a polished article — a faithful capture of the feature: a recording of it being used, narrated, with the intent and edge cases spoken aloud. This is the part only the PM can do, and it should cost them ten minutes, not a day.

Support adds the customer lens. They reshape the draft around the questions people actually ask, add a troubleshooting note, and use the customer's vocabulary instead of the internal feature name.

The writer (or whoever has the eye) polishes and publishes. Structure, consistency, a final read. On a small team this is the same person as support; that's fine. The roles are jobs, not necessarily separate people.

Shorten the loop: capture once, finish together

This model only works if the contributions land in the same place. The usual failure is tooling: the PM writes in a doc, emails it to support, support comments in a different tool, the writer copies it into the help center, and every round trip adds a day. By the time it publishes, the feature's a month old.

The fix is a single workspace where the capture and the edits live together. The PM records the feature once — narrating what it does and why — and that recording becomes a structured draft with the steps, screenshots, and annotations already in place. Then they invite support and the writer into the same workspace. Support refines the wording, the writer tightens the structure, and it publishes — no emailing drafts, no re-capturing screenshots, no "can you re-explain step 4."

That's exactly what WriteHow is built to do. A PM records a walkthrough, the AI drafts the guide (you approve it), and the team collaborates on that one source until it's ready to publish — to your help center, and into 50+ languages if you serve more than one market. The argument about who writes it fades, because everyone's writing the same article instead of passing it down a chain. If you want the upstream half of this, documenting the feature without becoming the bottleneck covers how the PM should capture it in the first place.

When to hire a technical writer

So do you need a dedicated technical writer? Early on, usually not. Founders, PMs, and support can keep a strong help center running if the workflow is low-friction. A writer earns their seat when volume and consistency start to strain — when you have enough articles that tone, structure, and findability matter at scale, and when someone needs to own the system rather than individual pages.

Even then, the writer's job isn't to be the sole author. It's to raise the floor: set the templates, keep the voice consistent, and make sure the accurate-relevant-clear trio keeps happening as you grow. The collaboration model doesn't change when you hire one. It just gets a dedicated steward.

So, who should write your help center articles? Whoever's closest to each part — together, in one place. The PM brings the truth, support brings the customer, the writer brings the polish. Stop assigning ownership and start shortening the loop, and your help center stops being the thing that's always a month behind your product.

More from this series: how to document a new feature and how to write release notes that get read.