On Writing Descriptions
Because sometimes you should just do it
Remember playing Chinese whisper as a kid? That game where messages are whispered from person to person and then the original and final messages are compared? Well, that’s kind of how it is working within a large company sometimes.
Nobody does it on purpose, but stuff can get lost in translation. I’ve experienced many times where we’ve explained what we’re planning to do to someone, only to later receive misunderstandings from other people that has heard about what we are trying to do — or what they thought we were trying to do.
It’s a mess.
Funny game.
Less funny to deal with as a PM.
Part of the problem is that you can’t rely on everyone remembering what you’re (probably great) pitch was. It’s the same as everyone demanding that you remember their (probably boring) picthes — which you of course don’t. You might remember parts of it. The rest you just forget or, worse, sprinkle your own agenda on.
This is where a good description comes in
A good description is sharable either via link or image and goes straight to the point on what change or experiment your team is embarking on, why it’s important and how it’s tied up to the strategy.
Generally you can sum up what should be in the description with these 5 questions.
The 5 questions
- What are we doing
- Why are we doing it
- What does success look like
- How does this relate to our strategy
- When will it happen
Notice I havent used the word “documentation”? We’re not trying to document how everything is working. We are giving a brief description on what we are trying to do, so the discussion stays focused.
When I write a description, I’m vary that it should be actually readable. With that in mind, I try to write in a way so that the reader:
- Reads the whole thing.
- Understands everything, without me needing to explain.
- Being able to repeat what we’re working on, at least the essence of it.
If all of those three things happen, I call it a success.
In 1997 Jakob Nielsen wrote an article on “How Users Read on the Web”. I first read it over 10 years ago, and it’s still relevant today. Here’s a snippet from the article on what’s good, scannable text:
- highlighted keywords (hypertext links serve as one form of highlighting; typeface variations and color are others)
- meaningful sub-headings (not “clever” ones)
- bulleted lists
- one idea per paragraph (users will skip over any additional ideas if they are not caught by the first few words in the paragraph)
- the inverted pyramid style, starting with the conclusion
- half the word count (or less) than conventional writing
Examples of descriptions
I stay away from templates, but use the five questions as guidelines, or check points, to make sure I include the most important information.
I prefer Miro, because that’s what our team uses and that’s what I show stakeholders when we talk. (read: collaborating with stakeholders).
The point of showing these examples are:
- You don’t have to make it pretty
- You should’t use any template
The tricky part is that the examples I want to use are stuff we are working on now — which of course I can’t share.
So I had to, eh, blurr a lot of stuff out, but hopefully it still gives some value.
Anyway, here goes.
The example over explains a change we wanted to do for everyone that’s being onboarded to SpareBank 1. We knew this change could be viewed negativily if we didn’t address what “bad” could happen. That’s why we added that to the bottom left corner.
We used this for:
- Other teams in SpareBank 1 Utvikling that we needed to colleborate with
- Key stakeholders in the banks
- Everyone in the alliance, when we’re ready to launch
The second example is an experiment where we’re not 100% where it should be placed, but we have enough data to believe it’s important. That’s why we added four examples at the bottom where it could be put, and where we decided to add it.
We used this description as much as a tool for our team, as it was information for key stakeholders that is doing the experiment on their bank.
As you could kind of see:
- There was no template, because every case is a bit different
- I didn’t use all the five questions. It’s guidelines, not a template
- It wasn’t pretty
Both of these examples gave clarity and focus to the conversations.
Sometimes we also write descriptions in SharePoint, which is easily distributed throughout the alliance. There’s no template here either, just more words based on the five questions.
“But Lasse, do I have to write a description for everything that we’re doing?”
No! That would slow things down. For some experiments and changes, we just write an hypothesis and that’s it. Sometimes if you try to over explain a change, it can feel more complicated or serious for the reciever.
I write descriptions when I know there will be a lot of eyes on what we’re trying to do, and it will potentially needs some explanation.
Meanwhile, it’s been quite popular to mention Amazons One-Pager or Six-Pager, where the leaders of the company don’t use Power Points to look at important decisions, but instead read documents. For that, I enjoyed Danny Sheridan’s article about “How Amazonians share their ideas: 1-pager and 6-pager”.
Hey, you made it to the end! 🎉
P.S. On a related subject, read about Collaboration With Stakeholders.
P.S.S. You can of course follow me on Medium, and Linkedin or Goodreads.
If you would like more stories like these, check out Failing Forward.
