The audit is finished. I’ve spent weeks inside this client’s content — reading pages, scoring criteria, flagging ROT, tracing broken user journeys, noting every place where the voice went off-brand or the metadata was missing or a procedure dead-ended without a logical next step. The spreadsheet is enormous. The notes column alone could fill a short report. I know this content set better than anyone at the organization does, possibly better than anyone ever has.
And now I have to do something useful with all of it.
This is the moment I’ve been building toward for the past several weeks, and I’ll admit it feels different than I expected. The audit phase had a certain comfort to it — you’re collecting, evaluating, categorizing. The work is concrete. You open a page, you assess it, you move to the next one. There’s a rhythm. What I’m sitting with now is messier: how do you take hundreds of individual findings, sort them into something coherent, and then tell a story that moves an organization to actually change?
Paula Land addresses this directly in the final section of Content Audits and Inventories, and I keep coming back to one framing in particular. She borrows from a professional development model that asks three questions in sequence: What? So what? Now what? The inventory is the What — here is what you have. The audit is the So what — here is what’s wrong with it, and why that matters. The roadmap is the Now what — here is what you do about it, in what order, with what resources, to what end. It sounds clean on paper. In practice, the distance between those three questions is where the real work lives.
The Temptation to Present the Spreadsheet
There’s a version of this deliverable I could produce fairly quickly: export the audit sheet, format it nicely, write a cover memo summarizing the major issues, and hand it over. I’ve seen this done. I’ve probably done a version of it myself. It feels thorough because it is thorough — every finding is in there, everything is documented, the rubric is explained in the notes.
Land is unambiguous about why this is a mistake. Spreadsheets, she writes, overwhelm and obscure. They’re great for collecting data; they are not a strategy. Row after row of assessments doesn’t tell a decision-maker what to do next or why the issues found should matter to the business. It tells them that a lot of things are wrong. That’s demoralizing, not motivating, and it rarely produces the organizational will to actually fix anything.
The job of the roadmap — the real job — is translation. You are translating a large body of granular findings into a small number of coherent themes, prioritized against business goals, expressed in language that connects content quality to outcomes the client cares about. That translation is not a summary of the spreadsheet. It is an entirely different kind of writing, and it draws on a different set of skills.
As a technical writer, I find this genuinely interesting. We are trained to be precise, complete, and accurate. We resist oversimplification because oversimplification is how documentation kills people — sometimes literally. But the strategic roadmap requires a different relationship with completeness. You have to be willing to say: of the four hundred things I found, these seven are the ones that matter most right now, for these reasons, and the rest can wait. That prioritization requires judgment, confidence, and a willingness to make a case rather than just report findings.
Finding the Themes Before Writing a Single Recommendation
The most useful advice Land gives for this phase is deceptively simple: before you start assigning work or writing recommendations, sort and filter for patterns. Step back from the individual page assessments and look for clusters. What issues keep appearing across content types? What sections of the site are consistently underperforming, and what do they have in common? Where does the data point toward a systemic problem — a workflow issue, a training gap, an architectural decision made years ago — rather than a collection of isolated content problems that happen to look similar?
This is the work I’m doing right now, and it’s slow. But it’s the work that determines whether the roadmap I produce will be genuinely useful or just an expensive list of to-dos. A finding like “37 pages have outdated product descriptions” is a fact. A finding like “product content written before the 2023 rebrand has not been systematically updated, creating brand inconsistency that affects the evaluation stage of the customer journey for your primary buyer persona” is a strategic insight. Same underlying data. Completely different level of usefulness to the person reading it.
Technical writers are well-positioned to do this kind of synthesis, though we don’t always claim that positioning out loud. We’re practiced at pattern recognition — at reading across a large body of content and noticing where the terminology drifts, where the structure breaks down, where the same conceptual gap keeps reappearing in different forms. The skill is the same one we use when we’re deciding how to organize a documentation set or when we’re identifying which user questions a help article is failing to answer. It just needs to be applied at a different scale and expressed in a different register.
The Story Has to Come Before the Recommendations
What I’m learning in real time, working on this roadmap, is that the recommendations only land if the story lands first. The story is: here is the current state of your content, here is what that costs you in concrete terms, here is what a better state looks like, and here is the path between them. Land calls this the audit narrative — and she’s pointed that it needs to live in a written document and a presentation, not just in the data.
The written document provides the detail: the methodology, the criteria, the section-by-section assessment, the evidence behind each recommendation. The presentation provides the argument: the two or three most important things the client needs to understand and act on, expressed as clearly and compellingly as possible. Land’s guidance on the presentation is worth sitting with. She says every audit presentation needs a clear call to action — everyone in the room should leave knowing exactly what is being asked of them in terms of time, resources, and decision-making authority. No one should be able to mistake this for an informational session.
“It is not enough to simply catalog the issues, make recommendations, or discuss benefits. What is the desired outcome, and how does that involve or affect your audience?”— Paula Ladenburg Land, Content Audits and Inventories, 2nd ed.
That question — what is the desired outcome, and how does it involve this specific audience — is one I’m asking myself repeatedly as I build this roadmap. The executive sponsors need to understand the business case: what the content problems are costing the organization, what it will cost to fix them, and why the return justifies the investment. The content team needs to understand the operational plan: what gets fixed first, who does it, what the quality standards are, and how they’ll know when it’s done. These are not the same presentation. They are not even the same story, though they draw from the same findings.
The Roadmap Is Not the End
One of the things Land returns to repeatedly in the final chapters is the idea of the rolling audit — the governance practice that turns a one-time project into an ongoing process. The audit I just completed is a snapshot. The moment the roadmap gets approved and work begins, the content landscape starts shifting: pages get updated, new content gets published, old content gets archived or quietly forgotten. Without a governance structure to maintain quality over time, the organization will find itself in the same place a few years from now — or sooner, depending on how fast the site grows.
This matters for the roadmap I’m building because the most durable recommendation I can make isn’t a list of content to fix. It’s a set of practices that make content quality self-sustaining: review schedules, ownership models, style guide maintenance, content lifecycle policies, and a lighter-touch rolling inventory that keeps the site from becoming unmanageable again. The one-time cleanup is the easy sell. The ongoing governance is the harder conversation, because it asks the organization to commit to something ongoing rather than just approving a finite project.
For my career, this is the part of the work I find most interesting and most relevant to where I want to go. Technical writers are often brought in to produce deliverables — documents, help systems, release notes — and then the engagement ends. What I’m reaching toward is something more continuous: a role where I’m not just producing content but helping an organization build the systems and habits that produce good content reliably, over time, as the business changes. That’s a content strategist’s function as much as a writer’s, and the audit-to-roadmap pipeline is one of the clearest demonstrations of why those two roles belong together.
What I’m Taking Away From Doing This Work
There’s a version of this project I could have done faster and shallower. I could have spent less time on the upfront stakeholder conversations, made rougher judgments during the audit, and produced a leaner deliverable. It might have been perfectly adequate. The client might not have known the difference.
But working through Land’s framework carefully, from the goal-setting in the early chapters through the synthesis and presentation guidance at the end, has given me a different standard to hold myself to. The test isn’t whether the deliverable is thorough. The test is whether the client has what they need to act. The test is whether, six months from now, something has actually changed — whether the roadmap became a real project, whether the governance practices took hold, whether the content is measurably better and the organization has the muscle memory to keep it that way.
That’s a high bar. It’s also, I think, the right one. And it’s the kind of work that moves a technical writer’s career forward — not by accumulating more deliverables, but by demonstrating that you can take complex, ambiguous information and shape it into something a business can act on. That skill doesn’t come from any single project. It comes from doing the work, reflecting on it honestly, and doing it better the next time.
This is me doing the reflecting. The doing-it-better part starts now.