The 7-Step Process I Use for Business Writing

A practical process for turning messy ideas into clear, persuasive business writing.

Share
The 7-Step Process I Use for Business Writing
Azores, Portugal. Photo credit: Me

Welcome to my newsletter! I'm Dave Anderson, an ex-Amazon Tech Director and GM. I write this newsletter I've called Scarlet Ink, which is a weekly newsletter on tech industry careers and tactical leadership advice.

Free members can read some amount of each article, while paid members can read the full article. For some, part of the article is plenty! But if you'd like to read more, I'd love you to consider becoming a paid member. 99% of my articles are intended to be evergreen (readable and valid forever). Some weeks I have fresh content; other weeks I'll update/rewrite something from 4+ years ago because I want to keep the quality of all articles high.

In my experience, school does not prepare us well for business writing.

When I was in high school, I took AP English. We had dozens of writing assignments. Mostly non-fiction, although we did have a poetry section, which I enjoyed.

Almost all of our non-fiction writing assignments followed the same process. Research a topic and cite your research using the fancy prescribed format. You get marked down severely if you don't cite with the exact right format. As a side note, I remember our teachers repeatedly saying that as adults, we'd need to be meticulous with our citing. I have to disagree, considering I've never cited anything since school.

Then we'd write our thesis statement, 3 body paragraphs to support the thesis statement, and a conclusion. Frequently 5 monsteriously large paragraphs to cover whatever topic we needed to cover.

Many (many) years later, my son was in high school, and had similar assignments. Nothing has apparently changed. I tried bucking the system once, insisting that he try writing more paragraphs to make it easier to read. He got marked down, and I got into a brief but frustrating argument with his teacher about it.

This type of rigid format might be appropriate for academic writing, but not business writing. In my biased opinion, it's because the people creating the AP tests and school curriculum are academics, and they teach what they know.

Unfortunately, I don't feel that students are taught how to write business documents. Or business emails. Or newsletter articles for that matter.

Instead, we all learned how to do proper writing while on the job.

Amazon has a writing culture, and I think it's brilliant when implemented properly. Proper non-fiction writing can convey a depth of explanation that a PowerPoint or presentation can never cover. You can explain an area of a business, a technical roadmap, or a product proposal.

A well-crafted email is easy to read, answers the necessary questions, and provides a clear path to moving a discussion forward.

An educational article can be interesting, entertaining, educate you on a topic, and expose you to a new way of thinking.

Readers often mention that they find it difficult to write documents at work, and they want to know how to improve.

When I wrote documents at Amazon (2-pagers, 6-pagers, PRFAQ's), and when I write articles for this newsletter, I have always followed a similar workflow and process.

For anyone who doesn't have their own preferred method of writing, I think it would be worthwhile stealing this one. Having a purposeful approach to writing (rather than just winging it) might help.

Step 1 — Figure out the "So what?"

Ok, this is not only the first step, but it's also the most important step. A critical step that far too many people skip. Which is weird, because this is an incredibly obvious step. I've skipped it in the past as well.

You need to get clarity around what you want your document (or email, or article) to accomplish. We frequently called that the "so what?", as in "I wrote a document about X." "So what?"

You should not write a document / email / article about something. You write it to accomplish something. What's the difference, you ask?

Jacob: "Please read this document about the CatalogDelivery service."

Me: "Ok, and what's it for?"

Jacob: "Um, I don't understand. It's about the CatalogDelivery service."

Me: "No offense, but I'm asking why I'm reading this?" (that's the "So What")

Jacob: "Um, well, I wrote a document about it."

In real life I did my best to be polite in these types of situations, but I've had this come up often. Not just with documents, but with status update emails, presentations, or meetings. Very often. I can't overstate how often this happens.

  • Someone runs a project and decides they need a regular status update email.
  • Someone has statistics on user behavior and begins to generate a report to share that user behavior.
  • Someone takes over a team, and creates a team weekly meeting.

I'm not saying any of these things are bad. And perhaps Jacob did have a need for a document. But the first thing on his mind was that this was a document about a service. What he didn't have on the top of his mind was the reason he wrote that document at all.

Preferably, anything you write has one specific purpose. One goal you want to accomplish.

  • Fund your project with more headcount.
  • Make your leadership team recognize that you're ready for a promotion.
  • Teach a specific skill to the members of your team.
  • Update critical stakeholders for a project about impactful changes over the last week.

You determine the audience. And then what you need them to know or decide or learn.

The counterpoint is that there is no point in writing (or reading) something if you're not trying to accomplish something. Our entire goal at work is to create influence and change. If you're not trying to influence or change something, why are you sitting there writing something?

Part of what you'll quickly realize is that a single document or email or article, then, can't accomplish multiple purposes well. If you write enough to accomplish two separate goals, you're almost certainly including things that the audience does not need to know or decide or learn.

The most common version of that is writing a status update for active stakeholders (those people working on the project on a daily basis), and then sharing that status update with a senior leadership team. They almost certainly only care about a small percentage of what's in that update, and everything else is wasting their time and attention.