Docs Were a Top-5 Reason Customers Cancelled. Three Years Later, a Top-5 Reason They Bought.

When I inherited Adaptavist's documentation in 2018, it was one of the top five reasons customers cancelled their licenses. By the time we finished consolidating it in early 2021, documentation had become one of the top five reasons customers chose to buy Adaptavist products, and chose to keep them.

No new features were involved. Nobody shipped anything on the product roadmap to make that happen. The thing that had been quietly costing the company customers was sitting outside the roadmap entirely, and that's the part I think founders should hear.

When your team is shipping and the metric you care about won't move, it's natural to look at the feature list for the answer. Sometimes the constraint isn't a feature at all.

What we were dealing with

Adaptavist had grown through a mix of building and acquiring apps, and the documentation had grown with it in every direction at once. Twenty-five-plus apps, spread across six websites and three different documentation platforms. Some products had decent docs on one platform. Others had outdated docs split across two. A few had docs that contradicted each other depending on which site you landed on. There was no consistent navigation, no shared search, no style guide and no clear owner.

From inside the company, this felt like an annoyance. From the outside, it was a sales problem. Prospects would find incomplete docs and conclude the product was incomplete, or find conflicting information and lose confidence in the company. Sales told me plainly: "Documentation came up as a concern in the last three deals." Existing customers were struggling to find answers, which pushed up support tickets and pulled down satisfaction.

That's a revenue problem, not a writing problem. It just didn't look like one on any dashboard product was watching.

Buyers read your docs before they buy

If that sounds like an unusual case, the data says otherwise. In the State of Docs 2026 survey, 80% of decision-makers said they always or often review a product's documentation before buying, and 88% rated documentation important to the decision. For open-source tools the number is even starker: in a 2024 practitioner study, 91.18% of respondents said they rely on the documentation when deciding whether to adopt a project.

And buyers increasingly aren't reading alone. Foundry's 2026 Role & Influence survey found that 93% of organizations now use AI somewhere in the technology purchase process. My read is that a lot of that AI is going to be reading your documentation too, and a model comparing vendors will take your inconsistent docs at their word just like a human evaluator would.

That's a bigger shift than it sounds. A human evaluator who hits a confusing page might ask a sales engineer. An AI assistant summarizing your product for a buyer will just report what the docs say, gaps and contradictions included. I've written about how writing for agents is a different job than writing for people, and documentation is where that difference shows up first.

Yet most teams have no idea what their docs are doing to revenue. The same State of Docs report found that 57% of teams don't track leads from their documentation, and another 17% don't know whether they do. One documentation leader quoted in the report asked whether a customer would ever fail to renew because of declining doc quality, and answered his own question: "It's a very lagging indicator to find that out." That matches what I saw. By the time documentation shows up in cancellation reasons, it's been hurting you for a long time.

What fixing it actually took

The technical part was the smaller part. I evaluated three platforms – Sphinx, Antora, and Confluence published through Scroll Viewport – and chose Confluence. It wasn't the most elegant option, and it has real limits for documentation at scale. I picked it because everyone at Adaptavist already knew how to use it, so the barrier to contributing was as low as it gets. One instance, one search, one navigation, one style.

The bigger job was people. Adaptavist didn't have a single technical writer when I started. All of the documentation had been written by the engineers who built the products, and it showed. They suffered from expert blindness, jumping from step one to step eight without realizing they'd skipped anything, because the missing steps were obvious to them. So I built a technical writing team from scratch, gave them final say over what got published and put templates and a style guide in place so that a customer moving from one product's docs to another's had a familiar experience.

We audited everything first, and that audit was tedious and essential. Some docs were current, some were years out of date, some were near-duplicates with subtle differences, and not everything deserved to make the trip. Then we migrated product by product, starting with the apps that had the worst documentation and the highest customer impact. Each migration forced the product team to review and fix its content, which is where most of the value came from.

It took from 2018 to March 2021, partly because it wasn't my full-time job – I was running multiple teams at the same time. If I had to summarize it, the technical migration was maybe 30% of the work. The other 70% was organizational: getting buy-in from product teams, setting up ownership, building habits and keeping momentum for three years.

The reversal

When it was done, the result was a complete inversion. Documentation went from one of the top five reasons customers ended their licenses to one of the top five reasons they chose to buy and stay. Support tickets about documentation questions dropped, because customers could find answers themselves. That freed the support team to work on genuine technical issues instead of serving as a human search engine for information that should have been findable in the first place. One customer's feedback praised how "honest" the docs were, and I think that honesty mattered because it was real. We documented things as they actually were, including workarounds for known issues and plain notes about what wasn't supported.

I don't want to overclaim. Documentation was one of several reasons customers stayed or left, and it never showed up as a dollar figure on anyone's dashboard. But a cancellation driver doesn't become a buying reason by accident.

Look outside the feature list

If you run a software company and you're shipping steadily but churn won't budge, it's worth asking your sales and support teams a question that never shows up in sprint planning: what do customers complain about that isn't a missing feature? Ask what came up in the last three lost deals. Read your own cancellation reasons all the way to the bottom of the list.

It's also worth asking support what share of their tickets are questions the documentation should have answered. At Adaptavist, every documentation failure created work for someone else in the organization, and support was usually the someone.

And then go read your documentation the way a prospect would, starting from a search engine instead of from inside the product. If you find yourself jumping from step one to step eight, so are your customers.