Documentation coverage: is your product documented at all?

Code coverage is an old habit in software engineering: measure the fraction of your code that tests exercise, and the guessing about how well-tested you are turns into a number you can track. Docs never got the equivalent number. Documentation coverage is the share of your product's user-facing features that have published, current documentation, and behind it sits the blunter question in this post's title: is your product documented at all?

The number carries more weight now that people are no longer the only readers. AI assistants answer customer questions from your published articles, so a feature with no article is a feature your chatbot cannot explain and your support team re-explains, one ticket at a time.

Is this the same metric developers use?

No. The tools that currently own the phrase, Compodoc, Sphinx, and docstr-coverage, measure docstring coverage: the fraction of your functions and classes that carry comments for the next developer. Useful, and aimed at a different reader. Whether your product is documented for the people paying to use it is a separate number, and no linter computes it, because the feature list it needs lives in your release history rather than your source files.

How to measure documentation coverage

Documentation coverage is measured by dividing the features that have a published article by the features you have shipped. The division is trivial; listing everything you've shipped is the actual work, and your changelog is the best source for it. Walk the release history, list every user-facing feature, and check each one against the knowledge base. A feature with an article counts. A feature mentioned only in a release note doesn't, because a release note announces a change and an article explains how to use it.

On calls with new customers, the feeling we hear before anyone has measured anything is that there's so much to write about, nobody knows where to start. A count dissolves that dread into arithmetic: fifty features and thirty-one articles is 62 percent, and the missing nineteen become a list you can rank.

Support data is what ranks the list. Pageloop finds the gaps by analysing your tickets, Slack, Linear, Jira, and GitHub, and surfaces the features customers keep asking about that have no article at all. High ticket volume against zero documentation marks the articles that pay for themselves in deflected tickets the week they publish, and those go first.

What is documentation debt?

Documentation debt is the backlog of missing and outdated articles that builds up when a product ships faster than its docs. The trade is the one technical debt describes, speed now and interest later, except this interest is paid by whoever answers the questions the docs don't. One knowledge base manager we spoke with maintains close to a thousand articles across four help centers, alone, by following the product team's emails and release notes and hoping she catches every change. She knows outdated information is live right now. She can't be in four places at once. Fast-shipping companies end up hiring a dedicated knowledge manager for exactly this situation, because someone has to dig out.

Coverage is how you take debt's measure: count what exists, and the debt is what the count exposes.

How do you find undocumented features?

Undocumented features surface in two places: your release history, which the audit above walks, and your support queue. The support queue is faster: pull last quarter's tickets and conversations and flag every question about a feature with no article linked, because customers find the gaps whether or not you've measured them. When we run this exercise with customers, we cross the support data against feature walkthroughs, and the features with the most requests and no article anywhere set the writing order.

You don't need 100 percent. Around 80 percent documented is the tipping point we see with customers: below it, docs work feels like archaeology; above it, documenting each feature as it ships becomes a routine step in the release, and coverage holds itself.

Documentation coverage FAQs

What is a good documentation coverage percentage?

A good documentation coverage target is around 80 percent of user-facing features, based on what we see across Pageloop customers. Past that point, teams shift from clearing backlog to documenting each release as it ships, which is the cheaper mode to live in.

How is documentation coverage different from code coverage?

Code coverage measures the fraction of code exercised by automated tests; documentation coverage measures the fraction of shipped features that have a published article. One protects the codebase, the other protects the people using the product.

How do you reduce documentation debt?

Reduce documentation debt by measuring coverage first, then ranking the gaps by support demand and writing the most-asked-about features first. Pageloop automates the ranking, drafts the missing articles in your team's style, and holds every draft for your approval before it publishes.

Image courtesy of Unsplash and Museum of New Zealand Te Papa Tongarewa.
Tarohonga Creek, Rimutaka Road, 1868, by Nicholas Chevalier.