I recently listened to a webinar by the team behind Variance which I found to be highly informative. The first part was an introduction to Product-led Growth (PLG) and Product Qualified Leads (PQLs) which is too far outside of the scope/focus of this publication to cover here but quite interesting for business nerds like myself.
This post focuses on the second part, delivered by Noah Brier and detailed in full here:
There were two highly useful knowledge management nuggets in that section that are worth highlighting:
Nugget #1: Writing is being used in the service of four different purposes
- Writing to communicate — get ideas across.
- Writing to converse — synchronous.
- Writing to think — as a way to crystallize and firm up abstract ideas/connections.
- Writing to archive/document— to make knowledge explicit and sharable.
It is often the case that writing that was used to serve one purpose cannot be used effectively to serve a different purpose. So the next time that you’re digging through a long Slack exchange (#2 writing to converse) trying to find that small bit about how to set up the environment variables so the software will work correctly (#4 writing to document) getting frustrated— you will know why.
Nugget #2: 6 rules of good documentation.
Digging deeper into the fourth purpose, Brier offers the following list as guidance:
- Fit for context.
- Clearly written and to the point.
- Visual where possible.
- Skimmable (can easily skip irrelevant sections).
- Discoverable and tracked.
KM nerds can endlessly debate additions, omissions, and refinements to the list, but I think they’d agree that it’s a pretty great starter list. If your documentation checks the box on those 6 things — you’re in good shape.
I particularly appreciate including #5 and #6 on the list, which go beyond the way the text is structured to highlight a couple of additional elements that ended up tripping many documentation efforts that I’ve seen.
And as a useful double-click on #1 (fit for context), Brier offers the adaptation to a framework developed by Daniele Procida captured in the diagram above, distinguishing between different documentation artifacts depending on whether the documentation is aimed at helping the reader perform an action or understand a concept; and whether consuming the content is self-directed or guided.