Writing and editing are taught widely in schools and professional programs, but content review is a neglected and unloved (and rare) skill that I’ve never seen taught or even acknowledged – but it’s widely required in jobs throughout the tech industry. If you’re a product manager, product marketer, comms professional, content writer, developer advocate, community manager – take your pick – you probably need to participate in content review as part (or most) of your job, but do you feel confident you’re doing it well and efficiently?

By “content review” I mean blogs, white papers, talks, things that are meant to be used as content marketing or external communications. To be clear I don’t mean copy editing or some other form of purely editorial review. That’s an entirely different topic that would send me down several rabbit holes. I’ll just say Grammarly is nice – but it isn’t a replacement for real editing – and leave it at that.

I mean participating in the review process of business content as part of the process of publishing something – whether it’s a press release, a post on a blog, a product page, documentation, a deck for analysts, a mission statement, or something else.

Usually this involves getting feedback from stakeholders who need to verify a few things:

  • The piece is accurate as written, which means:
    • Contains up-to-date information, such as pricing or SLA terms.
    • Product names are accurate.
    • Event details are accurate.
    • Titles are accurate.
    • Images and illustrations are accurate, and have most recent logos, etc.
    • Information is as complete as necessary.
    • Messaging is accurate and up to date.
    • Information elsewhere agrees with the new material so you’re not giving customers and users conflicting instructions or requirements.
  • Technical details are accurate and have been tested:
    • Screenshots are current.
    • Instructions and commands work.
    • No missing details like prerequisites or missing steps.
    • Where appropriate, make sure that if you’re presenting something as “recommended” that it’s actually supported for users and customers. It’s Bad(TM) when you publish something a reasonable user would take as a recommendation from your organization and it’s an unsupported configuration, tool, or process.
  • All the information is cleared to be published:
    • Any customers or references mentioned have been cleared for public use.
    • Doesn’t contain any non-public information, unannounced roadmaps, etc. It’s amazingly easy for things to creep in that aren’t yet public.
    • Artifacts are or will be live when the document goes live. No dead links, landing pages are finished, etc.

On top of that, the final editor is responsible for additional content review including:

  • Legal considerations:
    • Don’t make claims you can’t back up / prove on short notice.
    • I shouldn’t have to say this but, no plagiarism.
    • Permission to use images, trademarks, etc. as needed.
  • The piece is at the right level for its audience and their stage in the user journey.
    • The piece isn’t introducing a technology at an awareness level in the first graf and then trying to close a sale in the final one.
    • The piece is at the right technical level throughout.
  • Identify any additional stakeholders who need to sign off.
    • Bonus points: fend off reviewers who don’t need to sign off and will bog down the process.
  • Ensure you don’t have 5 pieces all about the same thing being published in short succession.

That’s a lot. What isn’t being asked is almost equally important. Of course if you spot a typo or something, it’s fine to fix it at this stage, but if you’re a stakeholder (not editorial) being asked to review something your input on writing style probably isn’t being solicited.

Your thoughts and feels about the style guide definitely aren’t being solicited. It’s nice that you do/don’t like the Oxford comma or two spaces after a period, but that’s been decided elsewhere and is out of scope for content review.

Tips when asking for a content review

Everything about publishing content at an organization that isn’t a publication tends to be a bit messy. (Come to think of it, it can be messy with actual publications too, but…)

Most organizations seem to have no real structure around content review. It’s often unclear who is, in the RACI model, responsible, accountable, consulted or merely informed that something is being produced, reviewed and published.

It’s also often treated as an “other duties” task. Meaning, if you depend on someone for content review, they may or may not get to it quickly… or at all. Or they may pipe up ten minutes before publication, or ten days afterwards, with a boatload of edits that derail publication or cause a kerfuffle when the ship has already sailed.

That in mind, you can sand off some of the rough edges:

  • Be very clear about deadlines. Don’t just ask someone “can you review this when you have time?” Be reasonable, but set a specific deadline, like “can you please review this and provide feedback and/or a thumbs up by Friday at 4 p.m. Eastern?”
  • Even better: Consider sending a calendar invite with the doc, guidelines, and your requested deadline. Help them find time by putting an appointment on their calendar.
  • Have a set of guidelines that you can send with content review requests. What you want, what you don’t want, what is being done by someone else.
  • Lock down sharing. No, really. Lock it down tight. If any group discussion or editing needs to happen it needs to happen before a doc enters the final pathway to publishing.
  • If you use Google Docs or similar, only give Edit permissions if you really and truly are willing to have the reviewer perform major surgery on the doc.

One thing I haven’t done in the past, but want to find a way to do in the future, is give more credit to reviewers when possible. Authors get a byline, and sometimes other perks. Reviewing is often thankless, but can be a lot of work. Folks who’ve done significant work on reviews should get recognition as well.

This has been sitting in draft for well more than a year, but I decided today was the day to ship. I’m sure there are some gaps, no doubt because I had no one to do content review for my blog. If you have thoughts, suggestions, tips, or good editorial puns please feel free to leave a comment.