SCQA stands for the *s*ituation, *c*omplication, *q*uestion, and *a*nswer. It’s a way of writing an introduction in a way that clearly communicates the key question a piece of writing will answer.
I’ve found this greatly improves business writing and it’s easy to coach others to do.
See also:
- Introduced by Barbara Minto in The Minto Pyramid Principle
- Writing is thinking
- When to write a brief
Links to this note
-
Sometimes you should try to build the thing instead of writing about the thing. While I’m a staunch believer that writing is a super power (especially for remote teams), it can make small problems seem bigger than they actually are. Knowing when to reach for a brief can be difficult to pin down.
-
The way I write more is by doing it every day. I write first thing in the morning (journaling and note taking) and publishing my notes (like this one). For work, I write product briefs to clarify the situation, my interpretation of the facts, and what we should do about it. I write memos for the team for anything important. I write investor updates. I do it without thinking—even when drafting a tricky email I’ll write it out to understand what I’m trying to do.
-
A lecture from Kurt Vonnegut about how to analyze and critique fictional stories. By graphing the plot along two axes, Good to Bad and Beginning to Entropy, you can visualize the story and compare their shapes to other stories. It also shows that stories seldom tell the truth that we don’t know what the good news is and what the bad news is.
-
The Pyramid Principle (Literature Notes)
The Pyramid Principle by Barbara Minto.
-
Writing is the much-discussed secret to building great remote teams. How do you write for a remote team?
-
Ideas to Support a Key Line Should Be Inductive or Deductive
When forming a horizontal relationship between ideas (e.g. supporting sentences of a summary statement), they should form an inductive or deductive argument. This makes the connection of ideas more clear to the reader and improves overall reader understanding.
-
Solution Disguised as a Problem
There is a tendency to write a problem statement as the problem you want to solve (i.e. the solution). For example, “We give users no guidance on X” is unlikely to be the problem statement rather than “users are confused”. The former is a solution disguising as a problem and the latter is actually the problem which may have many other solutions.