A More Ideal Process For Writing Content [Diagram]
As of recent, I have fallen prey to what the psychologist Robert Cialdini called the tapping problem. It goes like this: Two people sit together. One of them taps a popular tune on the table, the other tries to guess the song. If you’re near someone, grab them and try this now.
The inevitable result is this: The tapper gets frustrated. The song is obvious. So obvious! But what the tapper fails to realize is that it’s only easy for them because they’re hearing the song in their head. The guesser isn’t.
For years now, I’ve been judging the effectiveness of clients and contributors by how well they followed my ideal content writing process—a process I’ve never actually shared. I’m only just beginning to grok it myself, so I sketched a diagram. It is my intention to bring all of our clients into a discussion over this and agree to a workflow because, hopefully, it makes the writing easier, faster, and clearer. I think this diagram has that potential.
The diagram borrows heavily from IDEO’s design thinking process. There are phases of expansion and of contraction. During expansions, you add ideas. During contractions, you merge and reduce them.
In its simplest form, this process is about getting all the ideas on the table and distilling them into an outline. When an outline is agreed upon, the writer goes about filling in the blanks and conducting extra research. In revision, they sharpen it to a fine point. Then the design team follows a similar process.
It also shows each person what role they have to play, and where. Note that the writer and designer are the two most responsible people, and are involved throughout.
A diagram of who’s involved when, and what steps we follow for each piece of content.
Deviations from this process cause chaos and lead to poorer quality work. The prime reason I see projects drag on is that someone tries to add or subtract ideas at the wrong time. They say, “That’ll never work” during ideation and “Hey, I just found this article, can you incorporate it?” during revision.
The second reason projects flounder is people usurp each other’s roles for a lack of clarity around what those roles are. In a dark room, one person elbows another and suddenly everybody’s brawling.
All the titles in the chart above are hats. Someone can wear multiple hats, but they have to know which they wear and when. Otherwise, an executive will proof an outline for grammar, which wastes time, or a topic expert will change the tense of the piece at final draft, necessitating a full revision.
Writers and editors are very rarely paid for the added work and, though you can cap the number of revisions in your contract, no client likes to be held to it. A client that disobeys the process and triggers a waterfall of unnecessary work often does so unknowingly. They’ll feel the fault lies with the writer and good luck telling them they need to pay extra to correct it.
Principles that give this process teeth:
There are four checkpoints of no return: Think of the chart as a submarine. The group is moving from left to right and at each checkpoint, closes and locks the door behind them. If you fail to secure the door properly with a written confirmation that the draft is approved, you run into scenarios where the topic expert runs back and forth through the submarine spilling things and it all takes twice as long. There are, of course, exceptions, like when breaking news alters the facts or when the writer mistakes a term, but let these remain exceptions.
Interpretational generosity: Everyone on the project should assume by default that things were done for a reason. If the writer chose a funny phrase, why? If an SME dislikes a term, why? In all cases, over-communicate. Collaborating through a shared Google doc is akin to sending the whole Library of Congress through a dial-up modem. It is the worst way—except for all the others.
The writer is CEO of word choice: Ideas are best generated in groups. But a headless committee with the power to second-guess word choice produces formless babble. As Ogilvy said, “Search your local parks. You’ll find no statues to committees.” A piece of writing should be one person’s voice throughout.
Hat lock: Everyone is assigned a role that tells them exactly when and where to participate and they stay in their lane. This is a blessing. It relieves them of the burden of feeling compelled to interject out of uncertainty, or of withholding important feedback, thinking it’s not their turn. The process gets everyone doing what they’re supposed to be doing at the right time to keep the conveyor belt moving.
If you hold to this process, you avoid these problems:
Reason: The reviewer doesn’t fully trust the writer.
Everyone has opinions but not everyone’s opinion is valuable on every subject. Legendary investor Ray Dalio calls this believability-weighted decision making: Your influence on a project should be directly correlated to your subject matter expertise and track record. If you know everything about virtualized machines, you should be the one to decide the article topic. But you should not be the one to decide the exact words used. That’s the job of the writer, who’s spent thousands of hours considering word choice. In many cases, that writer is translating for the reader.
By assigning roles, everyone knows where they get to have input and where they don’t. If those roles blur, you get people who’ve spent very little time considering word choice line-editing things because it doesn’t sound like they’d write it. But if you left them to write it alone, it wouldn’t be clear. So they shouldn’t be editing the writer’s work.
Reason: Not everyone agreed on the brief.
Anything you don’t agree on in the brief can cause chaos later. I’ve written e-books where I thought I was writing for the end user and the client thought I was writing for the CMO and we figured it out late. It’s the same for voice and tone: Get that agreement in writing upfront because revising it later can be more work than rewriting it from scratch.
Reason: They don’t know what role they’ve been assigned.
The roles in the chart aren’t necessarily job titles, but hats. The writer could know enough to be their own expert. (This is ideal.) Or, the executive could also be the topic expert. What matters is people know what hat they’re wearing when and don’t interject out of turn.
Here’s an example that’s still raw for me: Let’s say the person with the promoter hat is the team’s marketing specialist. They’re going to post the article on social media when it’s done but have been invited to the shared doc without instructions. If the CEO has empowered them to make decisions and they start asserting their newfound dominance by line-editing the writer’s work in the draft stage, they’re going to annoy the writer and set them back. The writer has to ask the CEO why this is happening and possibly offend the specialist by asking them to stop.
Reason: They don’t know their responsibilities at each stage and don’t have a view of the whole project.
The feedback on a first draft should come from the SME and product owner and they should be focused on veracity. Are the statements true? Are the right ideas present? Is the overall piece cohesive? What they shouldn’t get bogged down in is checking punctuation and grammar. The writer and the proofreader will handle that later. For now, focus on ideas.
Reason: They procrastinated.
In the chart, SMEs are required to get all their ideas in at the outset. It’s speak now or forever hold your peace. The reason: Unless they’re also an expert in expressing ideas in writing, in which case, the writer is irrelevant, they must cede creative control to the writer. For the storyteller to tell the full story, they need all the facts upfront. Without the pressure to enable others at the outset, it’s common for the SME to give a half-effort (they’re often busy) and then leap into overdrive with an onslaught of new information at the revision stage, which the writer can’t then reasonably incorporate.
I had this happen on a project recently. I spent over an hour interviewing an SME to produce an outline, which I infused with additional research. The SME quickly approved it. But when I wrote a draft, they left disparaging remarks based on information I didn’t have, but they did. We went through four iterations of the e-book: Each time, the SME would complain that I hadn’t covered everything, and provide thousands of new words worth of notes. Each time, I had to tear it down and start again. It still isn’t finished. This all could have been saved if the SME had given sufficient attention to the outline.
An SME’s response to this might be, “It’s hard for me to see it until it’s written.” That’s called not putting in the work and it’s a choice. If you’d rather see a finished draft before providing feedback, you are committing to allowing the project to run on at twice the length and twice the rate.
Reason: Lack of taste.
Only the editor gets to be editor. The thing about good writing is, it takes a lifetime to develop good taste and until you have good taste, you don’t know what’s bad. In B2B, it’s common for people to go their entire career without developing good taste and if these people are allowed to edit, they edit all the wrong things. One former client would always insist on replacing “local” with “localization” and “use” with “utilize,” which they preferred. The client couldn’t distinguish between words that were clear and those which were simply comfortingly familiar.
Product owners often use funny language because:
They can confuse their familiarity with buzzwords, jargon, and cliché for clarity.
They’re sometimes so close to the product they can’t appreciate how a layman might describe it.
They’re accustomed to evasive terminology from analyst agencies, such as “data-driven strategy.”
They put keywords before clarity.
Some fear that simple language will be interpreted as dumb language.
My admittedly unsolicited advice for product owners: You hired someone who’s an expert. Tell them the facts, let them tell you how they should be portrayed, and don’t second-guess your surgeon.
Reason: Everyone’s busy multi-tasking and thinks it’s just as easy to change things later.
It’s not uncommon for everyone on the project to not actually read the outline. They skim it, assume things are on track and trust that it can be corrected at a later date. But outline approval is a point of no return. Whatever is decided here is truth and the writer can’t be held accountable for any materially important ideas that aren’t present. The writer may add more in the draft phase and may collaborate with the product owner or SME for clarification, but it cannot be assumed that they’ll write about things they weren’t apprised of.
Reason: The writer didn’t hold everyone to checkpoints of no return.
Sometimes it’s not until the final draft that the executive steps in and has detailed feedback on the voice, format, channel, or order which were covered in the brief. This is why upfront contracts are so important: The client verbally agrees that if they forgot to include something or review carefully at one of the checkpoints, that’s on them.
There are endless exceptions to these rules. You’ll run across a topic expert with an MFA in literature who provides prescient feedback. Or a product manager with an unusual eye for word choice, or an executive who trusts you entirely. These people make the aforementioned process unnecessary. But most others demand it. For everyone’s sake.
If you have ideas or feedback, write me at chris at findaway.media.
My goal is a world where everyone is such a clear writer that process is irrelevant. But until that time, it’s a helpful way to create better content faster with a fraction of the frustration.
