Listening to customers
How do we truly ‘listen’ to our customers and improve customer value of documentation?
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 have approached a documentation improvement? The fundamental step here is taking a deeper dive into your audience and relearning everything about their business needs. Building an awareness of how their business has evolved over time and aligning with competitors in the industry is a key to successful audience analysis.
Designing documentation effectively begins with deeply understanding your audience profile and their business needs. I feel like this ties in nicely to how organizations must leverage customer feedback to make their products useful and improve customer experience.
The next step is, how do we learn about our audience?
- Do we go to previously documented user profiles to look up a ‘typical’ user?
- Do we ask our support teams or stakeholders about this?
- How do we know what our audience really wants amidst a flurry of feedback and requirements we receive?
Technical writing teams may have some processes in place to continuously learn about their audiences. Though very often, they’re not the people who directly speak to a customer and the information coming to them is filtered through layers of people in various roles.
How do you navigate through this pile of feedback sitting at your desk? Try asking some questions and writing down your findings for each.
- Which issues are one-offs versus common problems they ask about repeatedly?
- What does this tell you about the audience ‘profile’ you were previously familiar with?
- Were some of the assumptions you made incorrect?
- Are they using the product in ways that are not the best practice and hence running into problems?
- Which issues are are not problems the documentation can resolve, but instead require feature improvements?
Navigating conflicting priorities - Deliverables vs Improvements
Often in organizations, improving and keeping older documentation up-to-date takes a lower priority over new features and bug fixes.
What if you could help prioritize the new feature requirements from your audience needs analysis and turn them into the new features they’re prioritizing in the next few sprints?
Then you not only get a useful new feature for the customer and your documentation update also gets prioritized. Write down the requirements, gather all the information and use cases you have, and discuss it with your product owner and other stakeholders who have impact on feature prioritization.
This is your opportunity to show that you understand your organization’s customers well and be an advocate for them.
What if your analysis leads to a gap in your documentation that needs your time and focus to resolve? Gather data around how many key or strategic customers would benefit from this enhancement? Alternatively, you could also gather data about the volume of customers who would benefit from this enhancement. This helps you build consensus with stakeholders and your management to prioritize and plan in some time to work on this update.
Depending of what kind of information you have access to, you may also be able to tie a monetary value gained from such an improvement for the organization. Monetary gains make a strong case for feature prioritization.
The advantage of gathering data is that it can also lead you to realizing that very few customers or no key customers benefit from the updates. Document all this and record your findings and make an informed decision about dropping this as a priority item. Clearly write down the basis of your decision for historical purposes and future requirements that can come up. A lot of times something that’s not a priority today, can become a priority a year or two later. Writing this down gives you a jump start in the future and be able to easily recall all your findings in the future.
If nobody is using it, then stale data doesn’t have to take priority. Consider removing or hiding the outdated information that is not used by customers, and focus on the more important deliverables.
Identifying business needs and your audience profile
Begin by understanding your audience’s goals and day-to-day lifecycle.
What is the business goal of your audience?
Run their business and be profitable
What is the industry your product focuses on?
Payment processing
I like to use lots of internal diagrams to visually document the workflows, identify the roles that perform each action, and then use it for brainstorming and communication to others.
Diagrams help our mental models to identify where the gaps are and know exactly who is performing what action and where the concerns are.
Learn about the the workflow
Use the product and walk through the workflow yourself, if it is feasible, and you have an environment with real-time transaction data. Visualize what your audience maybe doing correctly or incorrectly and attempt to anticipate their questions or points of confusion. List your findings clearly in a manner that can be used for discussions with stakeholders. Example of your audience being a developer.
The developer wants to use your product figure out the best way to get their yearly statements to file their taxes.
Additionally, if you want to have a broader perspective, do some research on how similar users of competing products in the industry use the products. Look at your competitor’s documentation to understand how that product works and how they explain similar topics.
‘Listen in’ to customer interviews
If you have an opportunity or become aware of customer interviews being conducted in your area then request to listen in. If you can’t attend them live, then request for a recording that you can listen to later.
Being able to simply listen with unbiased curiosity, with an intention to learn, like this cute dog, and controlling the urge to jump in and say ‘Oh, but that is already documented’, or ‘This is how you do it, let me show you’, can be more informational than you realize.
You may dig deeper and realize why something that was already documented or so obvious and easy to you, led to a mature customer being confused or attempting to use the product in a manner you didn’t expect.
This is when you may have your eureka moment and realize, “Oh, I never thought they will use our export feature to import data into Quickbooks to file their taxes!”.
Listening unbiasedly to customers talk about their experiences can help eliminate assumptions we make and help us focus on what’s important to them and their businesses.
Listen to your stakeholders, identify patterns, before concluding
Take the information you have gathered and begin looking for patterns of related questions in your product area or the related areas.
Create a list of specific questions that you can focus on. Set up time with your stakeholders, or anyone who regularly answers customer questions and works with them on a day-to-day basis. Here are some example questions.
- How do you resolve the problem when a customer can’t understand if they were paid?
- How long does it take for this problem to be resolved?
- Does this occur frequently or is this a niche requirement or a one-off user error?
- How much money do we lose each time a similar problem is reported, if you’re comfortable sharing that?
- Why do you think it was not obvious causing them to run into the issue?
- Are there product or documentation enhancements you believe that can resolve this issue?
- What do you think must be a long term solution to prevent repeated questions in this area?
- Can you help me prioritize the list of issues? Here is my priority list for you to comment on.
Organize and write down everything you learn along the way.
List the issues with your findings, and categorize related issues and one-off niche cases. Then begin to shortlist the issues. Categorize issues that are showstoppers, important, and nice to have.
Also list the issues that lead to product improvements and will not benefit from documentation updates. This is your opportunity to be a customer advocate to help prioritize this product improvement.
Prioritize your action items
Now you can go through your list and add a priority column. Focus on the showstoppers and important issues initially.
- Reread the relevant documentation wearing your customer lens on and assess how clearly you have explained the topic.
- Identify specific improvements you can make in the documentation.
- Log bugs or create tasks to track your updates, perform an estimation, and define a realistic deadline by when you should have this ready.
When I create a task or a bug as an action item, I like to provide as much information as I have gathered with links and references required to complete the task or resolve the issue.
- Identify who your reviewers will be and ensure a broad variety of roles are involved including the people who you worked with to gather this information. Ideally you want people with expertise in the area from product management, strategy, support, engineering, and other technical writers working on related products.
In your estimate, include the effort and time from your reviewers and iterations needed until approval.
Implement documentation updates
If you are simultaneously working on new feature update, and the action requires a lot more time than a quick few hours, then prioritize the release deliverable, and plan to start this work after you send those features out for review. Here is where your estimate of time needed to make the change becomes significant.
- If the change is simple and can be made in a few hours and you already have information available, plan to do it alongside your release updates. A strategic time is between review cycles or waiting for the feature to get done.
If you’re lucky and some of your actions impact the same feature area the release documentation is for, this could be a win-win situation to delivering your release deliverable along with documentation improvements!
- If the change is major and needs an entire chapter to be rewritten or reorganized, plan these changes in a design document in the time gaps you get while working for your release deliverables, such as time needed for stakeholder reviews.
- Begin making the changes when you have a sufficient window of time to complete the task with complete focus. This ensures you have thought through your changes and ensure you maintain the quality of the updates needed.
A combination of planning, research, and analysis can help you transform an insurmountable load of customer problems into actionable documentation updates.
Being a customer advocate
Take the list of issues from your analysis that didn’t indicate that documentation updates would help resolve the problems. Where possible, take these actions:
- Identify any temporary workarounds or best practices that can prevent customers from facing the problem or accomplishing this goal without the new feature.
- Create a bug and track this task.
- Discuss the specific improvement with your product owner and share the data that led you to your conclusion.
- Log a bug or feature improvement including the data and impact on the customer. Include all the data leading to this request.
- Assist with answering questions during backlog prioritization.
- Document the feature when done and prepare to announce it in your release notes.
- Work with product management on product positioning and language to use when announcing the new feature.
- Announce the new feature.
