Sign in

Being part of the Agile process gives technical writers a lot of visibility compared to the older days. In the waterfall days the engineer didn’t know who the technical writer was and vice versa. When the technical writer began planning their document, they were pretty clueless on where to start for multiple reasons.


How do we truly ‘listen’ to our customers and improve customer value of documentation?

Picture with scrabble blocks saying ‘Listen More’
Photo by Brett Jordan on Unsplash

Knowing your audience and their day-in-the-life is key to producing great documentation. Because this seems very fundamental, it can often be neglected and not taken seriously. The value that can come from driving product and documentation improvements aligned to customers needs is often understated. I believe a lot of times when you want to improve or fix something you have to go back to the basics.

When customers see the impact of their feedback translating into features or documentation improvements, they feel heard. This can increase overall customer satisfaction.

Going back to the basics

Take a step back and think through ideally how would you…


If docs can be built iteratively like products and have roadmaps, then they can improve customer satisfaction

Documentation can have its own roadmap, like a product. But why would you want to have a roadmap? What does a doc roadmap mean or do? Sounds like a lot of work, why bother?

Here’s the thing, how do you address the age old problem of ‘stale’ documentation? How do you enhance a doc site built 15 years ago to a modern and usable site? How do you gain competitive advantage in the industry? How do you get budget to staff your team…


Backstory of the problems, open questions, and resolutions of transitioning to iterative documentation

Transitioning from waterfall development to Agile was an experience in itself in my previous organization. To the average person on my product team, it seemed like an impossible goal to take such huge complex products with hundreds of moving parts and break them down into units that we could build iteratively. The technical writer was equally baffled about how to transition from writing entire guides, to just making updates for the features of the sprint, especially in such short cycles. My product team, Project Portfolio Management, was chosen to be the trail blazer for this incomprehensible task. We began ‘sprinting’…

Sreya

An instructional designer, technical writer, environmental volunteer, yogi, and traveler, with experiences to share.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store