I just read The Lean Startup by Eric Reis, and found that the Build – Measure – Learn cycle can easily be adopted in technical writing. The idea is to build (design, and write), then measure (SME reviews, editor comments), and learn from the data from the reviewers to build better topics in the next iteration. This works for small batches as well as large ones, but working in small batches gives you the added benefits of learning quicker, incrementally improving the product, and delivering useful content quicker. Working in small batches also lets you make course corrections earlier than working with large batches. It helps you avoid situations where you are delivering content that users don’t really want.
A story about stuffing envelopes
In the book (The Lean Startup) there’s an interesting story about a father and his two daughters stuffing envelopes. The daughters first address all the envelopes, then stamp them, and then fill them. The father processes one envelope at a time. The daughters are following the intuitive approach, but the father finishes first, because in the small batch approach, lead times are smaller – daddy doesn’t spend as much time sorting, stacking, and moving around the piles of envelopes. And because the father processes one envelope at a time, he starts delivering finished product almost straight away. The added benefit of processing one envelope at a time is that he quickly figures out if the letters don’t fit the envelopes, or if the envelopes are defective, and the seal doesn’t work.
How would this work in techwriting?
When writing, say, a new “manual” – one of the first things you do is to analyze the requirements – what are the end-user tasks I need to support, and what kind of topics (procedure, concept, reference) will do the job best. You might jot down a list of potential topic titles: “Installing the coffee maker”, “What is coffee?”, or “Making the perfect mocha latte”. Once you have that list in place, throw it into the review cycle – ask some of your SMEs if they think you’re aiming for the right target. Now – start writing, but not everything at once. Do small iterations with single topics. Once you have written “What is coffee?”, pass it on to your neighborhood SME who will then provide feedback on the accuracy and completeness of the topic. Incorporate the SMEs comments, and pass the topic on to the editor. Once you have received and incorporated the feedback on the topic, publish it! Even it’s supposed to be a part of a bigger product (e.g. a single topic in a user manual), just get it out there! Let your customers use the information, and maybe you’ll even get valuable feedback from them, letting you change course on the remaining topics if necessary.
The case for small batch writing
When you work with small batches, you get a finished product (a stand-alone topic) published quicker than if you’d wait for all topics to finish. In the process you get valuable feedback from your reviewers, editors, and possibly even users. This lets you make course adjustments already at the stage of creating the manual, rather than having to find out six months later that the manual is no good and you need to rewrite the whole thing. If you’re working with SMEs with a tight schedule, they might be able to fit in a single topic review while they’re waiting to get the tires changed on their car, but they would find the task of reviewing a complete manual too cumbersome to even think about. Working in smaller batches decreases the lead time, and you deliver an incremental product, which also improves incrementally because the feedback you get on each topic helps you improve the next one. The small batch approach is especially useful in more volatile environments where there is no anchored process for creating documentation – it’s easier to convince someone to review a single topic than a complete manual.