It takes me five days to come up with a fifty- pager Product Documentation and ten for a six-pager!

It is easy to describe the chair right in front of you in a thousand words.

Try it.

You would probably start from its color, expand to its build quality, and talk about its comfort and possibly material.

Now what would you say if I ask you to describe it using a single word (that’s not chair).

Can you describe the chair in a single word that replicates your perception of the chair in the mind of the listener?

It is difficult, isn’t it?

You are probably forced to think. To think from multiple perspectives, across different angles.

Writing a one-pager, or a six-pager product documentation is as difficult. So let us talk about how to do it effectively.

The six-pager memo format found its popularity through Jeff Bezos and contrary to my initial apprehensions it does represent an idea more clearly than a hundred pager (not literally a hundred, but you get my point!).

The shorter format, while takes more effort for the writer, is extremely easy to consume and understand for the audience.

The difference stems from the mindset of the writer while tapping away at the keys of her laptop. A hundred pager is when you puke all your ideas onto the paper. It helps you think, draw ideas, visualize the structure, and so much more. But the same is more likely to be addled with inconsistencies (in words and ideas) and incoherent ideas.

A six pager is when you distill the most important ideas of your hundred pager, and cut the clutter. It mandates that you utilize real estate for the most important ideas you would like to convey.

To a reader, a six pages adds the perception of a well thought of document with thought-through ideas which creates much less inertia than when served a binder with a hundred pages.

A six-pager, in almost everything is a more effective way of communication. But because we are Product people, let’s focus on Product Documentation.

Clear intent

Hours and hours everyday we tap away at our tired laptop keyboard forming words, ideas and concepts. We write stories, make presentations, product documentation, marketing materials, and whatnot.

The audience for each could be very different, the effective format could be possibly across a wide spectrum, and more importantly your intent for each documentation could be very different.

Before talking about how to write a six pager, let’s be sure of what can be and should be represented in the format to be most effective. Not much would be gained by trying to squeeze yourself in two dress sizes smaller.

Never try to go for smaller documentation when your audience needs details. Examples include your stories, and your requirements for your Technical teams. Communication with tech teams is always a disaster waiting to happen by the slip of a few points and misalignments.

If you do not believe me you got to read the story of how my Product was lost in Translation.

Six-pagers are perfect for interacting and aligning with the other side of the value chain — sales, marketing, Leadership, onwards and across in Product.

The intent of your Six-pager is always to cover the “Why” and to some extent the “What” but never the “How”

Cut the clutter

A six-pager is not the first document I advise you to start thinking with.

Everyone’s style and process is different, but because I am writing this article, I would like to share my own process in the hope that someone might benefit from the experience.

Below is my own five-step process I use to reach the end goal of crystal clear communication through a document.

The purpose I enter the process with, is to produce something that can be used to:

• Justify the need for the Product/feature I am proposing
• Introduce a concept
• Detail it just enough to reduce chances of misalignment

Abstract Thinking

At this stage my ideas are like pieces floating around in space. The whiteboard equivalent would be unrelated points strewn at different corners of the board.

I am aware of user problems, and I have some ideas to solve them but I have not yet put in the effort to make them cohesive. Not yet anyway.

Explain Your Idea In 3 Sentences To Your Neighbor

If you can explain your idea to your neighbor (who most likely is not in your team), then you have the full grip of a problem and a basic solution.

Why 3 sentences?
One sentence to frame the problem.
Another to convey your idea.
I give myself one extra, just in case.

But the intent is absolutely not to explain the idea in full but a bare glimpse of it. Your sentences need to be short, simple. I do not mind sentences which never end when reading Fyodor Dostoevsky’s Crime and Punishment but I do not receive the same pleasure by reading a complicated sentence structure and flowery words in a Business Document.

Here is an illustration:

Problem: People do not want to take an extra trip to get their cars cleaned.
Solution: We can provide car wash services in all popular malls. Cars can be cleaned while people shop.

Resist the temptation to say any more.

Some of my held back sentences were:

• This will increase the profits of shops in malls.
• People will tend to visit malls more
• We do not have to invest anything extra in security. We can leverage Malls’ security
• Reduced cost in marketing. A simple banner at the entrance would do

And I could go on. Believe me the temptation to reveal what a brilliant idea it is and how much you have thought about it is irresistible, but try it anyway.

Detailing in a million pages, or as much as you need.

Before we begin talking about this stage, let me make it clear that the output is completely disposable. I use this stage for nothing but to get more ideas as I write, and then review. This is just how I do it, but feel free to skip.

I begin by focusing on three key parts. Starting with the Why, to talking about the What, and then possibly dipping my toes into the How.

I try to gather market research to verify and make a story for the “Why”. I have everything and more to convince anybody here of why this idea and Product makes sense. This stage is less thinking and more compilation of cohesive data.

While I tap away to capture the “What” that’s usually when some framework or constructs begin to emerge.

Constructs

Constructs are one abstraction level above UX. They lay down the key concepts that represent your idea to completeness. The primary constructs of your Products help determine your User experience to a great extent.

Let me use an example to explain further.

If Google Drive were to be used to store an organization’s documents, how would you design the experience to ensure that the document is visible to only the right folks in the organization?

1. You could define the authorization and controls as you upload a document, or
2. You could define the authorization and control of the underlying folder and every added document inherits the settings, or
3. Number of other creative ways we could possibly solve this..

The ideas of points 1 &2 can be represented in a 2x2 matrix as below:

You have now been able to define the constructs that would affect the direction of your user experience — the interesting ones being explicit declaration per document, and automatic management per folder.

Chop, Chop, Chop

The final step where we are almost there, is putting the final pen to the expensive paper.

The ideas are already drawn, the constructs ready. By this time you would already have filtered the content you want to write.

If you aren’t sure yet, ask yourself the question — Would this sentence/paragraph help a first time reader understand the concept?
There are a lot of things in the predecessor documents that you would be really proud of. Maybe the details, the complex algorithms, the beautiful AI model powering it. And, if you are like me, sometimes you want to mention things you are really proud of but they might not be essential to the purpose of the document.

Edit till the document falls together into place into an easy to follow and represents your ideas and nothing else. And there! You have your effective six-pager.

A few words of caution:

1. It’s perfectly okay and even advised to have a separate — bigger, more detailed documentation for your development teams.
2. The six-pager is not effective to represent the elaborate “Hows” of your concepts and ideas.
3. A good idea I sometimes follow is preparing a longer documentation with the first six pages acting as the hero of this story, and the rest dedicated to adding the required details for my technical teams. This helps me maintain lesser documentation per Product/feature and ensure higher consistency than managing multiple documents.

Hope the Article adds something more to your repertoire of expertise!