# What Do You Need Your Content to Do?
> Most technical documentation teams are measured on output — topics written, tickets closed — not on business outcomes. Without executives having clarity about what they need content to accomplish, individual contributors will optimize based on how they're measured and their paycheck.

## Your writers are optimizing perfectly for the wrong thing

Revenue is the number one priority that drives decisions for business leaders. For technical documentation teams, it
ranks dead last. What is that?

It happens because nobody told the writers what business objectives they were supposed to produce with their content.
And when that direction is missing, writers do exactly what you'd expect: they optimize for what gets measured. Number
of closed tickets or pages written or their sprint velocity. Of course they do. If they do that well, they'll get their
bonus. It is not a failure of the writers. **Nobody can clearly articulate "What do you need your content to do?"**

So the user assistance gets thrown over the wall. Everyone moves on to the next task at hand. Nobody can say if the docs
have true purpose. The value question goes unanswered.

## The writers don't know they're in sales

Writers view their own work as post-sales content. Just as this view needs to shift for executive leadership, it must
change for the writers as well. Quite clearly, this does not mean that the documentation will or should look like the
marketing pages. Just the opposite. The reason buyers are in the documentation is because they trust it to be more
accurate than marketing.

In software specifically, [67% of buyers' first meaningful product interaction is self-service](https://heretto.com) (help portals, knowledge bases, documentation sites) before they have spoken to a single sales representative. Twenty percent of those sessions are prospective buyers doing pre-purchase technical due diligence. (Hint: the evaluator is not asking "is this documentation thorough?" They are asking "can this product do what I need it to do?")

When your content fails to answer that question at that moment, you put more burden on your prospect. They'll take
longer to make a buying decision. And this is before a salesperson is ever involved. This is not a writing quality
problem, the content is fine. 

Nobody told the writers that pre-sales conversion was one of the things the content was supposed to do.

And so it goes. That gap between what the business needs from documentation and what documentation teams are measured on
isn't fully aligned. It shows up in budget reviews, headcount decisions, and eventually in the question every documentation manager has heard at least once: "What does this team actually do for us?" That question is hardest to answer when nobody agreed on the answer before it was asked.

## Stop waiting for permission

One might argue that this is fundamentally an leadership problem. Until leadership decides to look closer at content
outcomes, nothing changes on the documentation side. That is not wrong. But it is also not the whole story.

In practice, the documentation leader who brings the business goals conversation to senior leadership is the one who
gets taken seriously. You don't need a mandate to start the conversation. You need a framework. And the framework here
is simpler than you might think. Easier said than done, of course.

## Before the next sprint, answer one question: what's this for?

Consider: content strategy research maps documentation value to five outcomes that executives already think in.

![Content Strategy Business Case](/blog/images/content-strategy-business-case-plus-stats.png)

These five categories are how business leaders choose where to invest. Every documentation task should be traceable to
at least one before writing starts. If you cannot trace it, then it's just guesswork. 

You need to know if the content is to help growth or to reduce support or both. You need the
[strategic value of content](/blog/strategic-value-user-assistance-content).

So, before the next planning cycle, here are things worth considering.

**Identify the business goal the content is supposed to serve.** For each major initiative, which of those five outcomes does it address? Be specific. "We have to have it" is not a business goal. "This onboarding guide reduces time-to-first-value for new users, because time-to-first-value correlates with 90-day retention" is.

**Define what success looks like before the work starts, not after.** Meghan Casey's in her _Content Strategy Toolkit_
has this MadLibs-style exercise: "_Our content will help [audience] accomplish [goal] by providing [content type] that
[differentiator]. We will know we've succeeded when [measurable outcome]._" Have your stakeholders complete it for each
project. If they fill in different words — excellent. That disagreement is the point. It surfaces misalignment that would otherwise show up as a documentation review dispute six months later. 

**Learn the difference between metrics and KPIs.** Metrics are ingredients. KPIs are the cake recipe. Page views, session counts, and topics published are raw measurements. They are useful as inputs. A KPI has a threshold, triggers a
decision, and is calibrated specifically for the stakeholder who needs to act on it. That means that different teams
have different KPIs. The KPI for a VP of Support might be deflection rate and net savings. Page views tell that executive nothing actionable. And naturally, the right KPI for a VP of Sales is not the same as for a compliance officer or a localization manager. A single dashboard, in other words, serves no one well.

**Give writers a story, not just a backlog.** After the business goal and success criteria are set, writers can be told
what the work is actually for. They can see the connection to business outcomes. They can better understand how their
work has meaningful impacts in other parts of the business. That changes the decisions they make: about depth, about what to cut, about what questions to answer and which to defer.

## The team that can answer the question

Teams that have made this shift describe it in practical, operational terms. Documentation stops being measured by how much it produces and starts being measured by what it prevents and enables.

Intelligent, findable content deflects 30 to 40 percent of information-based support tickets at scale. Your internal
staff accounts for nearly half of all self-service content users, more than your prospects or customers, according to
Heretto's research. Your employees need the same quality answers as the people they are trying to serve. They need it to
do their job, develop your products, and help your customers. With good content they work faster. 

And technical buyers who find answers during an evaluation make buying decisions faster, getting you closer to revenue.

And here's a hypothetical example, but grounded in real data. Take a mid-sized documentation team with 100,000
self-service sessions per year. Those sessions deflect 30% of request-for-information cases. At an average 12 minutes
saved per avoided case, and with a fully-loaded support cost of $60 per hour: that's $360,000 in annual savings from one
deflection lever alone. Now localize that content into three languages and publish it across four delivery formats. You
are no longer looking at one number. You're looking at a program that can pay for itself. Imagine those savings!

**Documentation becomes a profit driver, not a cost center.** 

## Have the conversation. Don't have it alone.

Everything in this post, you can take into your next planning cycle and use tomorrow. The framework is not complicated. The questions are not hard to ask.

Facilitating the room is the hard part. And it gets harder when your own position is part of the conversation.

That's where a guide is useful. Not to audit what you've built. Not to sell you a tool. To run the working session that gets the right people aligned on what your content is supposed to accomplish for the business.

**If you're ready to have that conversation, let's run it together.** One working session. The five outcomes your stakeholders already think in. And a documentation strategy that finally has an answer when someone asks what it's for.