More Docs, Same Questions: How to Measure What Your Documentation Actually Covers

Documentation stopped being a writing problem about two years ago.

Drafting used to be the expensive part, so that’s what everyone measured: pages written, features covered, the docs box ticked at release. Then drafting got cheap and those numbers stopped meaning anything.

We asked sixty product teams how they know their documentation is any good. Every one of them could tell us whether it exists. Not one could tell us whether it works.

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.

Exists is easy to answer by accident. Every shipped feature has a page, every screen is described, the release checklist is green. And support keeps forwarding the same question anyway. The answer is in there, split across three topics, none of them about the thing the customer was trying to do.

A coverage gap doesn’t stay in the documentation. It leaves as a support ticket, a stalled onboarding, or a feature nobody adopts, and it lands on your numbers, not the writer’s.

So the useful question is the second one. Here’s a way to answer it: one measure, and a map you can fill in for your next feature in about thirty minutes.

The volume problem nobody planned for

Writing documentation used to be expensive enough that teams rationed it, and that constraint was doing quiet work for you. It forced a decision about what deserved a page.

That constraint is gone. Anyone can produce a plausible page in minutes, so the decision stopped being made at all.

A product manager at a European CRM vendor (B2B SaaS, 500+ employees) described the before-and-after bluntly. Before, he told us, before AI nobody documented anything, because documenting anything took a huge amount of time. Now, in his words, “everybody documents everything that is not important to document.” The result is a lot more documentation and no more usefulness.

Cheap drafting removed the only forcing function you had. Nobody decided to stop scoping documentation; scoping just stopped being necessary to start writing.

And volume is the easiest thing to see and the least useful thing to know. A shrinking backlog, a growing page count, a “docs done” checkbox on every release: all true while your customers stay stuck.

What you’re actually measuring right now

Ask a team how they know their docs are complete and you usually get one of four answers:

• Feature parity. Every shipped feature has a page. That tells you it was described, not that anyone can act on the description.
• Interface completeness. Every screen, tab, and field covered. The most common answer and the most misleading: easy to verify, feels rigorous, maps to nothing a customer is trying to do.
• Volume. More pages, more words. See above.
• Vibes. Someone read it and thought it was fine. Usually the person who wrote it.

None of these is bad faith. They’re the only measures available without a better unit, and nobody handed you one.

Some lower the bar deliberately. A head of product at a data platform vendor (1000+ employees, APAC) told us they stopped chasing perfect text: “We don’t need 100% quality of document writing. 90% is okay.” Reasonable call — but polish was never the thing failing.

The better unit is the job, and you already own it. You write jobs when you scope features. You just never point that unit at the thing that explains the feature.

Why the interface is the wrong organizing principle

One job might touch four features; one feature might serve six unrelated jobs. Documentation that follows the interface hands the customer that translation, and to do it they’d need to already know which part of the product solves their problem. Which is what they came to find out.

Your product gets planned around jobs to be done. Then the documentation gets organized around screens, and hands the customer a translation problem nobody would tolerate inside the product itself.

It gets worse, because nobody opens documentation calm. They open it because something broke, or because they’ve been clicking around for ten minutes and are starting to feel stupid. One documentation lead we spoke to described her entire approach as making sure the reader never feels the anxiety of searching, or of facing more material than they can take.

Readers in that state don’t browse. They scan one page, decide in seconds whether it’s about them, and leave if it isn’t. A page describing the merge dialog is not, to them, a page about cleaning up duplicate records before a quarterly report.

Real story: the feature that was fully documented and completely unusable

A workflow automation vendor — B2B SaaS, 200+ employees, Europe — shipped an approvals feature. Their product team had absorbed documentation after the writing function was dissolved, so the PM who built the feature also wrote it up.

He did a thorough job. Every setting on the approvals configuration screen was explained: conditions, routing rules, escalation timers, notifications, permissions. Accurate, screenshotted, published on release day.

Support kept forwarding the same question anyway: how do I let a manager approve a request without making them an admin?

That was not a missing answer. It was three answers in three places: role scopes in the permissions topic, a field called “approver scope” in the approvals config, and delegated rights in the admin guide. All accurate, all findable individually, none about what the customer was trying to do.

And every internal check passed. The docs existed, they were correct, review had signed off. By every measure the team had, the work was done.

What actually fixed it

Before writing anything for the next release, the PM sat with two support agents for forty minutes and wrote down the questions customers actually asked about approvals, in the customers’ own words. Six of them. Then he mapped each one to where its answer lived. You’ll see that map further down.

Then he reorganized around those six jobs: two pages merged, two written from scratch. The field-by-field reference stayed exactly where it was. It’s still useful once you know which field you need. It just stopped being the entry point.

Two things changed after that, and neither was a metric on a dashboard.

First, the shape of incoming questions changed. The recurring “how do I…” questions stopped, replaced by edge cases: unusual configurations nobody could have anticipated. A healthier support load, and a better signal for the product team.

Second, and less expected: writing got faster. He had been answering “what do I document?” while writing, so every draft doubled as a scoping exercise. Deciding scope up front made drafting far smaller, including for his AI drafts, which stopped wandering once the prompt had a defined job to cover.

The measure: job coverage

Stop asking whether something is documented. Start asking whether one page finishes the job.

A job is covered when the customer who has it lands on one place that takes them from where they are to done.

That gives you three possible states for every job:

• Covered. One topic takes the reader end to end.
• Scattered. The information exists, in pieces, across two or more topics. The reader has to assemble it, which means they have to already understand the product to succeed.
• Missing. Nobody wrote it, often because it seemed too obvious to write.

Scattered documentation passes every check you know how to run. Documented? Yes. Accurate? Yes. Findable? Yes. Can the customer finish the job? No. This is where most documentation actually sits.

This does not mean writing more pages

A fair objection after everything above: if every job needs its own page, you’ve just multiplied your library and your maintenance load.

In practice it works the other way round. Coverage asks for one entry point per job, not one page per job. Scattered jobs get fixed by merging what exists, retitling it, and cutting the duplicate explanations that piled up across three topics. In the teams we interviewed that left them with fewer pages than they started with, not more.

New writing is reserved for the Missing rows. Two or three per feature, not twenty.

Your artifact: the job coverage map

Here’s the completed map for the approvals feature from the story above:

The job (in the customer’s words)	Where the answer lives today	One place, end to end?	Verdict
“Set up approvals for my team for the first time”	Getting started with approvals	Yes	Covered
“Let a manager approve without giving them admin rights”	Permissions topic + approvals config + admin guide	No — three places	Scattered
“Send anything over $10k to a second approver”	Approvals config, conditions section	Yes	Covered
“Stop approval emails while someone is on vacation”	Notification settings + escalation timers	No — two places	Scattered
“Find out why a request was auto-rejected”	Nowhere	—	Missing
“Approve something from my phone”	Nowhere	—	Missing

That feature scores 2 out of 6, and every page in it was accurate, reviewed, and published on time.

Write the job in the customer’s words. If the row contains your feature name, you’ve written a feature description wearing a costume. “Configure the approver scope field” is not a job. “Let a manager approve without making them an admin” is.

Aim for five to seven jobs per feature. Fewer and you’re describing the feature again. More and you’ve slipped into edge cases: real, but not what determines whether the feature is usable.

Your coverage number is the count of Covered rows divided by the total. Crude, and probably the first number about documentation quality you’ve ever had.

One warning about that number. If your first pass comes back mostly Covered, the likely explanation is that the jobs came from your side of the table. A list written from what you built will always be covered by what you wrote.

Where the list of jobs comes from

The answer is different before and after the feature ships.

Before release: you already have a draft of the list

You can’t ask customers about a feature they haven’t seen, but you’re not starting from nothing. Whatever the feature was specced from — a PRD, a ticket, a paragraph in a planning doc — contains the reason it exists, and that reason is a set of jobs. If you weren’t the one who wrote it, ask the person who did what problem it solves for whom. Same answer, one conversation.

Rewrite each one in words a customer would say out loud, with your feature names stripped out. Then treat the result as what it is: a hypothesis. Good enough to scope the first version of the docs, not good enough to stop there.

After release: correct it against what actually arrives

Two to four weeks in, your list will be wrong in two predictable ways. Some jobs you were sure about never come up. And one or two you never considered turn out to be the most frequent thing anyone asks.

You already talk to support. That’s not the gap; the gap is how. Those conversations cover the product in general, get summarized into your vocabulary on the way back, and end as impressions instead of a list. All three have to change: one feature, verbatim phrasing, written down as rows.

Verbatim is the part people skip and the part that matters. The moment “I can’t tell why this got rejected” becomes “visibility into rejection logic,” you’re describing your product to yourself again.

The spec tells you what customers should need. Only the people who take the questions know what they actually came to finish, and only in the words they arrived with.

There’s a more systematic version of this: pulling patterns from search logs and ticket data as a repeatable audit. That work belongs to whoever writes and maintains your documentation day to day. If that’s someone on your team, our other course, 5 Steps to Smart Documentation, covers exactly that.

What about the four hundred pages you already have?

Everything above assumes a feature you shipped recently. Most of your library is older than that: a portal several years deep, written by people who have since left.

Don’t map all of it. That project has no end, it competes with shipping, and it loses: new features always win, which is how the backlog got old.

Pick two or three areas by repeat questions rather than traffic. Topics generating the same support conversation month after month are where coverage is worst, however healthy their page views look. A busy page with no answer is worse than an empty one, because people spent time on it before giving up.

Traffic tells you where people went. Repeat questions tell you where they went and left without what they came for.

The rest stays on planned decay. Parts of your library describe a product that no longer exists, and pretending otherwise costs more than admitting it. Those pages get fixed when a release touches them, not before.

When this doesn’t apply

Reference material is the one real exception. In API references, parameter tables, error codes and configuration schemas, the entity is the job: someone looking up a parameter wants it described precisely, in a predictable place. Don’t rewrite reference docs into scenarios.

Reference is what you consult when you already know what you’re doing. Everything else is what you read when you don’t. Job coverage applies to the second kind.

When every job is covered and the questions keep coming

If a job is genuinely covered (one page, end to end, people landing on it) and the same question still arrives week after week, you have a different problem. Either the page answers a different question than the one being asked, or the product is making the job harder than any page can compensate for.

That second case is the valuable one, and it’s the subject of a later lesson. For now, just note it when you see it.

A question that survives good documentation has stopped being a documentation problem. It’s a product signal, and it’s the most valuable thing your docs will ever give you.

What to do this week

• Pick one feature from the last month. A normal one, not your flagship. If you’re drowning in legacy docs instead, take the area support asks about most.
• Get the jobs. Shipped over a month ago: twenty minutes with two support agents, that feature only, questions verbatim. Newer than that: start from the jobs in whatever it was specced from, and set a reminder to redo this in a month.
• Keep five to seven. Beyond that you’re collecting edge cases.
• Map each one to where its answer lives and mark it Covered, Scattered, or Missing.
• Fix the Scattered rows first. They’re merges and retitles: fast to do, and where customers lose the most time.
• Put the score where your team sees it, and run the same map on the next release.

You probably have enough documentation. The question is whether it’s organized around what your team built or around what your customers are trying to finish.

Fill in the map for one feature and you’ll walk away with a list of gaps. Which raises the question the map can’t answer. Who on your team is supposed to close them, and who gets to decide a job counts as covered? That’s where we go next.

FAQ