Communicating with Extreme Clarity

Communicating something in a way that leaves no ambiguity in the mind of the reader such that all readers ultimately leave with the same understanding

TL;DR:

1. Extreme Clarity means communicating something in a way that leaves no ambiguity in the mind of the reader such that all readers ultimately leave with the same understanding.

2. Extreme Clarity helps prevent misunderstandings, conflict, overlaps, or gaps in execution, and thus the time wasted resolving those issues.

3. Shorter is generally (but not always) better. Avoid acronyms. Use numbered lists. Deep link. Use absolute numbers along with percentages. Qualify your units. Highlight changes in state. Proof read before sending.

Note: This blog is a version of a post I shared internally at Meta that’s received over 520 likes, 66 comments and 73 shares. People ping me several times a week to tell me they’ve found it useful, so I thought I’d share it here too.

---

Communicating the progress of a product team is an essential part of a PM’s job. Leaders and stakeholders need to understand your progress and your problems. You need their support and guidance. Success depends on everyone having the same understanding of what’s going on.

But in complex areas (like, say, a high-scale digital product), it’s easy to get lost in the details. This is bad. How can leadership help you if they don’t understand what’s happening? How can teams make decisions if different people have a different understanding of the situation?

In my old org at Meta, we about striving for “extreme clarity” in how we communicate. There’s strong culture of ensuring documents and decks are written in a way that enables people to really understand the details of something, especially if they’re not steeped in the context.

I’ve had the great fortune to learn from some of the best PMs in the business. My own writing has improved as a result, to the point where I have my own tips to share.

What does Extreme Clarity mean?

Extreme Clarity means communicating something in a way that leaves no ambiguity in the mind of the reader and that all readers ultimately leave with the same understanding.

Extreme Clarity matters because ambiguity requires follow ups to resolve disagreements and misunderstandings (wastes time). If people leave with a different understanding, there’ll be gaps or overlaps in execution that may result in bad outcomes.

Extreme Clarity is hard. It takes more time to make a document or a post extremely clear, but it’s worth it — particularly as teams grow, and we work with people separated by time and space.

Let’s work through an example together.

Here’s a weekly status report from an entirely fictional integrity (aka trust & safety) product team dealing with potentially fake accounts. While fictional, this example is very similar in style to a genuine update I recently got from one of my teams.

SIP is integrated with XFAC. 20% of global detections that have 95%+ precision are XFAC-ed and there is an overall 4% conversion-rate; meaning we are getting to harm faster and curbing review workload substantially. 13% of user reports are routed to SIP’s queues. With no automations applied, the action rate is 16% for reports and 28% for feedbacks. Feature-logging completed this week so we can ramp up this percentage further and start building automations. Manually reviewed 130K and auto-disabled 105K dormant profiles for likely-PCI profiles.

When I read this, there were immediately a bunch of questions in my brain. Let’s annotate where they appeared:

SIP is integrated with XFAC [1][2]. 20% of global [3] detections [4] that have 95%+ precision [5] are XFAC-ed and there is an overall 4% conversion-rate [6]; meaning we are getting to harm faster [7] and curbing review workload substantially [8]. 13% of user reports [9] are routed to SIP’s queues. With no automations applied, the action rate [10] is 16% for reports and 28% for feedbacks [11]. Feature-logging completed this week so we can ramp up this percentage further [12] and start building automations [13]. Manually reviewed 130K and auto-disabled [14] 105K dormant profiles for likely-SIP profiles [15].

Whoa. From reading just four sentences, I had fifteen questions!

1. What’s SIP? What is XFAC? I might know, but will every reader?

2. Has it always been this way or has there been a change of state? Do you mean “…is now integrated…”?

3. Global? Do you mean “all systems”, or “worldwide”?

4. What volumes are we talking about here? How many per day? Per week?

5. Precision, relative to what? Relative to labelling? Ground truth?

6. Overall conversion rate? Does this mean across the whole funnel, or conversion rate of one step? And over what time period are you calculating this number?

7. How much faster? What reduction in latency have we observed? And while we’re at it, what harm?

8. Curbed workload substantially? From what to what?

9. 13% of ALL user reports??! (that sounds like a lot) Or just some subset, and if so which one(s)?

10. What is the definition of action rate?

11. What’s the difference between “user reports” and “feedbacks”? Isn’t a user report a kind of feedback. Are these different, or is one a subset of the other? Why would the action rate differ between the two?

12. Which of the previous three percentage stats are you referencing? The “user reports” number (13%), the “reports” % (16%) or the “feedbacks” % (28%)? Or all of them (did you mean “these percentages”)? And increase them from what to what (even ballpark)?

13. What kind of automations? Auto-close automation or auto-clear automation? Both?

14. Hang on, I’m confused — how can you auto-disable things you’ve manually reviewed?

15. What time period do these numbers refer to? a week? the last week? something else?

If I was close to this team’s work, I could perhaps extrapolate to the correct meaning — but few will be close enough to the team’s work to unequivocally understand this, and that will create problems.

Extreme Clarity would be communicating in such a way that there are no questions left in the mind of the reader, and the writer isn’t relying on the domain-knowledge of the reader for them to answer their understanding.

Let’s try re-writing that same product update with Extreme Clarity in mind:

1. The Spam Team (SIP) has started (as of 15th June) enrolling likely violating accounts into the Cross-app Fake Account Checkpoint (XFAC) at 95% precision.

   1. In the last 14 days, they enrolled 79k accounts. Since launch, 4% of accounts enrolled cleared XFAC within 7 days, in line with expectations.

   2. Previously, suspected spam accounts were sent for human-review and, if found to be violating (high-precision), were direct-disabled with appeals via Contact Forms (high friction).

   3. This has reduced our p50 actioning latency from 8 hours to 1.4 hours (-82.5%) and saved 150hrs/wk of human-review workload (~7% of overall Ops utilization).

2. Separately, 13% of users submitting feedback or reports on spam accounts are now (as of 28th June) being routed to SIP’s queues. Previously they were handled by Generic Review.

   1. With no auto-close automation applied, the action rate is 16% for reports and 28% for feedback. Hypothesis: action rate is higher for feedback because report stats are skewed by abusive reporters who (sadly) have higher intent than regular users, and thus get further down the funnel.

   2. Feature-logging was completed this week so we can ramp up the 13% further (targeting 50% by EOW) and start building auto-close automation to further increase human-review efficiency.

   3. In the last week, we manually reviewed 130K likely-SIP accounts above a 0.6 classifier threshold, of which we went on to disable 105K (equivalent to 80% precision).

What a thing of beauty!

While this version is more verbose, it’s extremely clear. It prevents all those questions arising in the mind of the reader, and leaves no ambiguity.

Now, instead of the reader having to ask basic questions like “what does that mean?”, they could ask useful substantive questions about strategy and next steps.

How can you write with Extreme Clarity?

A few simple rules can make a big difference:

1. Shorter is (generally) better than longer. The more words you use, the more opportunity you have to introduce ambiguity – not to mention lose the reader’s attention. Sweat the details. What are you saying in three words that could instead be said in two? What are you including that’s irrelevant?

   1. Yes, this was a long post — but that’s because I’m trying to engage you with narrative. To compensate, I included a crisp TL;DR.

   2. And yes, the example above got LONGER not shorter — but that’s because the purpose of a product status report is to update someone who’s likely unfamiliar with the day to day of your space in a standalone way. That requires more information inline to provide clarity. Denormalisation.

   3. But generally, shorter is better. “I didn’t have time to write a short letter, so I wrote a long one instead” — Mark Twain.
      

2. Avoid acronyms. Where you want to use them (because you’d otherwise have to repeat some long-form text multiple times) then use the expanded form first, then use the abbreviation e.g. use “Three Letter Acronym (TLA)” the first time, then you can use TLA subsequently. Even Elon Musk has banned them, except, it seems, when they’re part of his son’s name.
   

3. Use numbered lists, not bulleted lists. Numbered lists allow the reader to know where they are. It lets people quickly and unambiguously reference a point (“in 2a you say…” vs “In that bullet about X you say…”). It forces you to be clear about ordering (despite what the HTML spec says, there’s no such thing as an unordered list!).
   

4. Represent statistical changes in both absolute and percentage forms. Using either the absolute (e.g. “saved 150 hrs/wk”) or relative (e.g. “saved 7%) forms in isolation makes it impossible for the reader to understand the real value of any change. 7% could be a tiny amount top-line workload, or could be a massive amount. Similarly, 150 hrs/wk might be a tiny amount of top-line workload but might represent a heroic improvement for this team. Only with both numbers can the reader compare between teams AND understand the significance of the impact within the team.
   

5. Deep Link. Where it adds too much weight to explain something inline, deep link to a post, doc or deck that explains your point or concept in more detail. Readers that get it can read on. Readers that want more have somewhere to go to get the context. If you’re communicating via slides, including the details in the appendix is a functional equivalent.
   

6. Qualify your units. A common mistake omitting the timescale over which the presented data is calculated. (“we enrolled 50k accounts” – what? per day? per hour? per second?!). I often see HPMs say something like “we saved 100 hours of workload”. I know from experience that they likely mean 100 hrs/wk — but another reader may lack that intuition. Extreme Clarity demands you qualify your units.
   

7. Highlight changes in state. Often, I’m reading updates which highlight the great work some team has done to make something work in a new, better way. People within the team will inherently know why the old way was bad and the new way is better – but someone outside the team likely lacks this context. In order for the reader to understand the impact of this change, the writer should explain what the new thing is, AND what the old thing was — and, critically, why the new thing is better than the old thing.
   

8. Proof-read. Before you publish, stop and take a few minutes to read everything you’ve just written. Try an imagine how someone outside your team would read it — would they understand it? Is it full of inside baseball? Is every word the right word? You’ll be amazed at how much you want to change upon second reading.

   1. Even better, peer-read. Ask someone outside your team to read your post/doc/email/deck and ask them if they have any open questions after reading it.

If you’re working in a growing org or company, it’s a certitude that there’ll be fewer people that are closer to your work tomorrow than there were yesterday. If we communicate in a way that requires the reader understand the details of your space, you risk creating gaps, overlaps and misunderstandings, and that’s bad for everyone — especially your customers.

Communicating with Extreme Clarity doesn’t come for free — it takes time and practice, and, as evidenced by the example above, sometimes requires more words.

But hopefully the tips above help you understand what I mean by Extreme Clarity, and give you specific, actionable advice to improve your next code comment, task title, email subject, Google slide or Workplace post.