The Deadly Doc Writer Approach
By seapegasus on Jun 23, 2008
I just came across a (not so new, but still valid) article by Amazon's Werner Vogel. What's the best way to plan a new product? Work backwards.
Reminded me of a great talk I attended at the ADHOC (MacHack) some years ago, "Writing books backwards", but it turned out to be a different punchline. What Vogel means is, before you implement anything, write the press release and manual. Interesting. (Is he a tech writer, by any chance? I always document my weekend projects so well, I never really get around to implement them...!) ;)
A press release is the summary of your completed work, when it's ready for the customer. Vogel's point is that thinking about the press release first forces you to think in a way that is perfect for customer-oriented planning. Write down concisely what the product is (category) and does (features), why anyone would want it (uniqueness), for who it is (target group), how to obtain it. Looking at it from the point of view of a future customer helps you not to get lost in internal details early on.
The next step of backward planning is to write a basic FAQ page. While laying out the project's (fake) press release, which disconnects did you and your colleagues have about feature priorities? Will your customers have similar misconceptions about the product's purpose? Antecipate the most important questions and find "one line" answers to them. What is this product, what system requirements do you target, how much will it cost, how will customers obtain, install, trouble-shoot and update the product.
Next you write a quickstart tutorial, show-casing an example of how a typical user solves a task with your product. Should be very short and simple, (UI draft) screenshots of the user interface are a plus. (Tip: Use the NetBeans GUI builder for prototype screenshots.) Again, this forces you to think about the workflow from the user's point of view.
The last level of backward planning (we're still planning here, we haven't implemented anything yet) is outlining the user manual. This forces you to clearly define concepts and processes — what to do with your product, and how. The manual should also include a reference section that allows for different ways (incl. syno-/hyper-/hyponyms) of finding information (but you should agree on one way to refer to a process throughout). If your product is used differently by different target groups, write separate content for each target group (don't split up each paragraph of the general manual into "if you are x, do this, otherwise do that"). For example, NetBeans.org has two sets of FAQs, targeting either developers who work with the IDE, or developers who work on top of the Platform.
Of course you are not supposed to immediately publish these documents. Keep them as references on your internal planning wiki. Looking at the normal work process backwards during the planning phase has (hopefully) made your project's goal clearer to everybody involved.
It doesn't have to be software, many everyday types of plans can be approached backwards. For example, I once went to an anti-procra— uh, I mean, time management class: One of the strategies we learned was to write down how people will perceive our completed task. Next we determined what we have to do to make this outcome come true. Do this analysis for the best outcome (planning), and for the worst outcome (risk preparation). This risk preparation is called pre-mortem (or premortem) analysis, in contrast to post-mortem. If you think that's morbid - did I mention the time management trainer asked us to write our own obituary?!
Oh, and the "Writing Books Backwards" talk I mentioned? Turned out it wasn't suggesting to write books backwards. It was the same talk as the "Writing Books" presentation. So why the name? Well, in presentations, speakers often draw people's attention by reversing the order of the cognitive process: They show the cool conclusion first, and then elaborate how they figured it out. On that day, this particular talk was the first one in the morning, and the speaker expected people to be tired and show up late. So he decided he'd go through the slides in reverse order, starting out with the details, and working towards the results overview, so the late-comers wouldn't miss the main points!
Which probably shows that the most important factor for choosing a strategy (be it backward or forward) is still how well you know your target group. :)