A Lean Journey Into Agile Documentation

Confession: I have a love hate relationship with product documentation. While I can appreciate the value of well written technical documentation, I can’t help but feel it has a poor ROI these days. So when I started my current company, I committed myself to investing in an intuitive user experience instead of traditional online documentation. Unfortunately as the product became more complex and we either failed to contain the complexity or had features that could not be reduced to a simple UI, I found myself looking for alternatives. What follows is a blog I never thought I’d write: my lean journey into product documentation. ;)

Phase 1: Talking To Customers

I’d like to tell you we proactively went out to talk to our customers about their documentation needs, but it didn’t quite work like that. We waited sufficiently long without a documentation investment that our customers came to us. Unfortunately their feedback was too varied to see a pattern. When we asked whether they wanted videos or written help, they gave us the answer: yes. When asked whether we should deliver targeted context sensitive help or traditional manuals, again they told us: yes. And when asked whether they wanted the documentation to focus more on concepts or how-tos, the answer was a definitive... yes.

When talking to customers does not give you answers, there is only one thing to do: experiment.

Phase 2: Our 1st Experiment

Our VP of marketing and I tag teamed the initial experimentation in documentation. We came up with a few hypotheses to test:

• Traditional manuals / guides would be the foundation of all forms of documentation we would create (e.g. videos, blogs, online help) - even if we chose not to expose them to our users.
• The same content should be exposed in multiple formats (e.g. video, online help) to provide users a frictionless way to acquire information.
• YouTube was the closest metaphor to expressing how our users would want to interact with documentation (i.e. visual, short snippets, videos).

Over a weekend, our VP of marketing and I wrote our first mini product manual, produced a few rough videos, and worked with an engineer to wire these together a YouTube-like user experience for access from the application. That Monday we showed the early experiment to an internal focus group and received mixed but generally positive feedback.

Phase 3: Docapolooza

In true agile fashion we shipped our early prototype, and received less feedback than we had anticipated. Our hypothesis: we had so little online documentation in the product, we’d trained our users to not even look for it. This spawned our next test:

• We needed to achieve a tipping point in documentation where the most common usage patterns were wired for help.
• We needed to highlight these changes to our customers in some highly visible way to elicit early feedback.

To achieve a critical mass of content, we invented Docapolooza: a one day off site for a team of four in which they dedicated themselves to writing documentation & producing videos. One of our investors volunteered their offices for Docapolooza, and by the end of the day we had 20+ videos and context sensitive help wired into the product.

That Friday we released the new content and included it in our weekly product update to our customers. Within the hour the first customers started responding with positive feedback. By Monday we had traffic data that showed initial high engagement with the new documentation, which to our surprise continued over the coming weeks. We also noticed the videos being used by sales and support in working with customers and prospects.

Phase 4: More Experiments

With the early positive traction, we set about gathering feedback on how we could further enhance our online help. Over the coming weeks we centralized our content into a Help Center, added more context sensitive help / videos, integrated our support FAQ into the application, added video sharing, simplified the ability to create a ticket from within the application, and started expanding our pool of people who could produce the content. We continued to watch as the metrics showed sustained engagement, and as our internal team continued to use the help and video in their day to day engagement with customers and prospects.

The Tools We Used

We went decidedly low-tech on our tools. We wrote documents in Google Docs, and initially converted these to HTML for integration into the application. After customer feedback put an end to our own internal debate, we eventually skipped HTML altogether and just exposed public Google Docs directly to our customers, hyperlinked into the application to be context sensitive. In return for the stigma of exposing our customer-facing documentation via Google Docs, we received a great compression in our turnaround time for rolling out new documentation. We used iMovie / Quicktime for creating videos, recording the audio from pre-written scripts to allow for ease of update as our product changed. The rest was all simple software integration into our web application.

Critical Learning

Nothing we did in our documentation work was particularly innovative or cutting edge. In the end we made good progress toward solving a meat and potatoes problem that proved to add value for our customers. Our real innovation was in treating documentation as a product unto itself, that had users, needed a feedback loop, and required constant investment / innovation.