Your Documentation Is a Sales Problem. So Why Does Engineering Own It?
Bad documentation doesn't lose deals in the demo. It loses them three weeks later, in the quiet moment when the developer tries to implement and the integration guide sends them to a 404. Or when the API reference uses terminology that doesn't match what the sales team said during the evaluation. Or when the getting started guide assumes a level of context that the buyer's technical team doesn't have, because the buyer's technical team wasn't in the discovery call.
Nobody from sales is in that room. Nobody from marketing knows it happened. The deal isn't dead yet — it's just accumulating the kind of friction that eventually produces a churned account or a stalled expansion, six months after anyone could have done something about it.
The Ownership Structure That Created the Problem
In most technology companies, documentation is owned by Engineering. It's written by engineers, reviewed by engineers, structured around how the product was built — the architecture, the API, the configuration options — rather than around how it's evaluated, purchased, or adopted.
This made sense when documentation was primarily a technical reference — a manual for the people who had already bought the product and needed to understand how it worked. It makes considerably less sense now, when documentation is part of the pre-sales evaluation process, the onboarding experience, and the ongoing customer success motion simultaneously.
Engineers write excellent documentation. They describe the system accurately, completely, and at the appropriate level of technical detail. What they typically don't optimise for is the buyer journey — the specific questions a CTO asks during evaluation, the anxiety a first-time implementer feels when the first API call fails, the narrative context that makes a capability feel like a solution to a real business problem rather than a feature in a list.
Marketing, by contrast, understands the buyer journey. It knows which capabilities drive evaluation decisions, which objections surface repeatedly in the sales cycle, and which customer outcomes resonate with which buyer profiles. What marketing typically doesn't have is the technical depth to write accurate documentation — or, in most organisations, the access to the systems where documentation lives, the relationships with the engineers who own it, or the standing to change it.
The result is a split that seems sensible from an organisational chart perspective and produces a gap that is expensive from a revenue perspective.
The Hidden CAC Multiplier
Documentation failures show up in the revenue data in ways that are genuinely difficult to attribute.
The prospect who completed a trial, got stuck on implementation, and never came back. The deal that closed but churned at the first renewal because the implementation was more complex than the documentation suggested it would be. The expansion that didn't happen because the customer's technical team had a bad experience with the API reference and was reluctant to add more surface area. The referral that wasn't given because the customer was quietly embarrassed by how long their implementation took relative to what they'd been promised.
None of these show up as "documentation failure" in a CRM. They show up as trial abandonment, implementation churn, low expansion rates, and weak NPS from technical users. The root cause sits in a place nobody thinks to look, because the ownership model has categorised documentation as a technical function rather than a revenue function.
The companies that have recognised this tend to treat their documentation as a product with its own user journey, its own quality bar, and its own relationship to business outcomes. Stripe's developer documentation is one of the most frequently cited competitive advantages in developer-facing financial infrastructure — not because the product is radically superior to alternatives, but because the documentation makes the implementation experience so much better that developers advocate for it internally when their company is evaluating options. The documentation is part of the product. It's part of the GTM motion. It's part of the reason Stripe's net revenue retention looks the way it does.
The RACI That Needs to Change
The structural fix is a documentation RACI that reflects the function documentation actually serves in the revenue lifecycle, not the function it served in 1995.
Engineering owns accuracy. The technical content in documentation needs to be correct — API endpoints, configuration parameters, error codes, system behaviour. Engineers are the right people to write and maintain this, and engineering review should be the gate for any change to technical content. This ownership should not change.
Marketing owns buyer journey alignment. Which parts of the documentation does a prospect read during evaluation? Are those parts written to reduce evaluation anxiety and build confidence, or to describe technical architecture? Which documentation does a new customer encounter in the first week of onboarding? Is it optimised for the person who is implementing the product for the first time, or for the person who has been using it for three years? These are not engineering questions. They are marketing questions, and they require marketing judgment to answer well.
The practical expression of this RACI is that marketing should have edit rights to documentation — not unrestricted rights, but the ability to propose changes to language, structure, examples, and narrative framing that are then reviewed by engineering for technical accuracy before being published. The current model in most organisations is the reverse: engineering publishes documentation, marketing requests changes through a ticket system, and the changes happen slowly if at all because they're not on the engineering priority list.
This isn't a trivial change. It requires engineering teams to accept that documentation has stakeholders beyond the technical users they were optimising for. It requires marketing teams to develop enough technical literacy to propose changes that don't compromise accuracy. It requires product leadership to recognise that documentation is a product — one with users, with a user experience, and with measurable impact on revenue — and to manage it accordingly.
The Internal Dynamics
The resistance to this change is predictable and worth naming directly.
Engineering teams resist because documentation is one of the few places where they have sole ownership of something that touches the customer experience. Accepting marketing's edit rights feels like accepting marketing's judgment about their work — a category of interference that engineers have historically been protective against.
Marketing teams resist because documentation is technical enough that getting involved feels risky. If marketing proposes a change and it introduces an inaccuracy, the accountability for the error feels disproportionate to the value created by the improvement.
Sales teams are often not part of this conversation at all, even though they're closest to the documentation failures that affect deals. The account executive who knows that every prospect asks the same question about the authentication flow, and that the answer in the documentation is technically correct but practically confusing, doesn't have a reliable channel to surface that observation in a way that produces a documentation change.
The companies that break through this dynamic tend to do it the same way: they make the revenue impact visible. They track where documentation failures appear in the customer journey — trial abandonment, implementation churn, expansion reluctance — and they connect those outcomes to specific documentation gaps. When the cost of the status quo is quantified, the organisational friction of changing the RACI becomes easier to justify.
The question worth sitting with: when was the last time your CMO read your getting started guide — and if they haven't, what does that tell you about who you think documentation is for?
If you haven't read Blog 3 yet — documentation ownership is a version of the narrative authority problem. The RACI for documentation is a specific instance of the broader question: who has the right to define how the product is described to the people who use it?