Aaron Hoos

I’ve been working on a huge technical writing project for a client. They expect to start rolling some of my work out to their staff and partners between November 2010 and March 2011. They have thousands of pages of supporting documents that go back at least 4 years. So,  for the next few months, I’m trying to make sense of it all while I turn it into something useful.

I’ve been swimming in a flood of paper: Reading, sorting, and mapping it out. And recently I was asked by three different people, “What’s your process of turning a great big pile of unsorted guidelines, case studies, and marketing documents into a comprehensive, user-friendly, step-by-step document that someone can follow?” I thought it might make an interesting blog post.

So here’s a generalized version of my technical writing process:

1. One of the first things you need to do is figure out who the end user is going to be and what they are supposed to accomplish as a result of this project. From branch operations to CRM systems to selling a specific product, each technical writing project I’ve worked on had an end user who was supposed to achieve an end state. So find out what it is. It also helps to try and figure out what their motivations are (will they accept the changes or resist them?) because you can shape your work according to their level of alignment with the purposes of the content.
2. Get a high level view of the project, review the business case, and review some of the material to get a feel for what you’re facing.
3. Now here’s the secret ingredient and this step will make all the difference for you: Start mapping out an ideal future pathway or methodology that you will be writing to. These are the steps in the process that people will be taking to achieve the end goal. Each step in your work will probably be a major point in the step-by-step instructions you’re writing.
4. Build out a similar “current” pathway so you can outline how the process is done today and can compare the two.
5. Now start reading all of that reading material in-depth. Assign a code to each document and then look at your process map (in step 3) and see if you can find a place for the document on that map. If you can, great. If you can’t decide if it a good reference material. Chances are, if it can’t be tied to one of the steps on your process map and if it won’t make a good reference then it should be discarded.
6. As you build your map, write in the names of people who can help or reference sites to obtain more information.
7. Below each point, start fleshing out subpoints, steps, or tasks, and arrange them in order within each point.

By now, you should have a big piece of paper (or, more likely, a Word document or several pieces of paper taped together) that captures the information of the entire solution.

File those documents into some kind of order. Put the discards in a discard file (and keep them until the project is published). Put the rest of the documents into coded files that align with the steps in your process map.

And now you can start writing, interviewing, and continuing with research. Of course, all good technical writing is iterative and collaborative so expect to get back to earlier steps and make adjustments as necessary.

[Photo credit: epSos.de]

Reid Hoffman, founder of LinkedIn, shares what he believes are the key principles of entrepreneurship.

A sale happens when you convert a prospect into a customer. But not all prospects convert. Some prospects say “no” (or they simply decline to buy or they abandon their shopping carts, depending on your sales funnel). You shift your focus to those who have said yes and you serve them to get them to buy again. Good idea.

But what do you do with the other prospects? With the ones who say “no”? Here are some ideas:

• Build a relationship with them. Take an interest in them. Follow them on Twitter, read their blogs, listen closely to them. Invest time in them as research into the mind of people who DON’T want your services.
• Look for common points among them to see why you are missing the mark. If they share a similarity, you can augment your existing product or create a new product to better serve them.
• Test different products – at lower price points or with different elements – and see what they buy. Don’t offer these products to everyone, just to the ones who said “no” the first time.
• Partner with another vendor who might be better able to provide a solution to their problem. Don’t just refer them; arrange an affiliate relationship so you can still profit from the ones who say no.
• Ask to put them on your newsletter or ezine list.
• Better yet, create a special “no” list that gets extra special treatment with plenty of high-value information and free samples.
• Get their contact information and revisit them a few weeks or months down the road. (I have several clients who started working with me after initially turning me down… they found another writer, weren’t as happy as they thought they’d be, and my email or call prompted them to reconsider my services).
• Stay positive, stay available, and invite them to contact you at any time. You never know: Their needs might change in the very near future.

While your customers are great to have, your “no” prospects can teach you so much about why people don’t buy… and they will often be the vocal minority to a much larger group of people who didn’t even bother going through the process to get to the prospect stage.