Or: how to get user insights with minimal effort and without handing out gift certificates
What do we want? Data!
And when do we want it? Now!
Data data data. Product managers live data, breathe data, eat data and sleep data. All professional (and sometimes personal) decisions of a good product manager should be driven by data analysis and drawing conclusions based on that data.
A good product manager defines for himself and his product what are the data points, sources of information and relevant goals in the various stages of the product's life.
According to this data, fates will be sealed. The data analysis will provide answers to existential questions in the life of the product and the company (does the product meet the growth goals we expected? is the company progressing towards its business goals? what is the next step for the product?), but also to everyday questions, such as what will we be working on in the coming quarter? How do we know that the feature we developed provides a real solution for the customer? And what does the customer really want?
This is why product managers invest a lot of resources and energy in designing a data collection system that will allow them to answer these important questions from an informed position. Product teams work with development teams on dashboards and data bases that monitor the behavior of users and measure every detail in the user flow, conduct hours-long meetings with data analysts on the quality and significance of the data, and also conduct in-depth conversations and interviews with the product users themselves to make sure that the features indeed meet their needs.
All of these are important and critical to the continued success of the product, but they take up a lot of time and attention from the product managers, who are already dealing with a million more items on their desk.
What if I told you that right under the noses of product managers, inside the office, in the next room, there is a resource of quality data, with which you can sit over a cup of coffee and get refreshing insights?
I am talking about your technical writer. The technical writer who usually accepts the product and the features as set in stone, the technical writer who is at the end of the development chain whose job is to understand the feature and explain it to the users, the technical writer who sits right in the room next to you but you never really got to talk to.
What does technical writing have to do with anything?
It might surprise you, but the work of the technical writer is broader and more comprehensive than a simple documentation of the product or feature you've developed. Working on the documentation puts the technical writer at a critical crossroads where different perspectives on the product merge together: from the product team he learns about the feature and its behavior, from QA he understands what can go wrong while using it, and then he places himself or herself in the user's own shoes to provide them with the knowledge they need to use the product successfully. This way, the technical writer can provide you with insights that, as product managers, you cannot obtain from another source within the company.
Deep identification with the user
Like a common chameleon, the technical writer should also adapt to each product he documents, whether the product deals with ad-tech, insurance, logistics or health. To do this, he must know the users of the product as he knows himself: who are they? how old are they? what is their education level? how do they use the product? what does their schedule looks like? how often do they use the product, and what questions might arise during use?
The technical writer uses this knowledge to try and predict in which areas the users will need help, in what form to provide them with that help, and what frustrations they may experience during use. If you, as a product manager, are not talking to your technical writer about these topics, you are throwing away these valuable insights. Wouldn't you like to know in advance what might frustrate your user, and perhaps prevent this experience in the first place?
The ability to simplify complicated ideas
As product managers who work with development teams, management and other stakeholders within the company, we sometimes tend to "fall in love" with the product or feature we are working on. It's natural, we're human. Like any creative person, the product person also feels that his product is complex, sophisticated, the best thing we could do to solve the user's pain.
All this may be well and good, but when the feature reaches the documentation stage, where the technical writer is supposed to explain its operation to the users, in most cases it ends with 2-3 lines of text and one image. Maybe as a product manager it's a little disappointing, but that's the role of the technical writer: to take a complicated concept with different layers, and turn it into an digestible byte for the user. The technical writer removes everything that is unnecessary for the user to know, and distills the feature into a practical and simple explanation.
An excellent way to take advantage of this ability of the technical writer is to present the feature to them during the development phase, before we've invested 5,000 man hours in it, and ask them what they think. You will be surprised to find that sometimes this ability to simplify can provide "cheaper" and simpler solutions than you thought of as product people. This external point of view is an asset since it does not require you to leave the boundaries of the company or the office, it exists in your immediate environment, it's available, and it's more convenient than a user interview campaign that will rob you of many resources. In this way, you can also get insights about the feature in early stages, to which users are not usually exposed, thus saving development time and iterations.
Attention to detail
When a technical writer begins to document a product or feature, they perform the series of actions that the user is supposed to perform, and record them step-by-step in the correct order, without missing a single detail. The documentation also sometimes requires taking pictures of the product at the various stages of the process, when clicking on a drop-down or when a certain field is empty or full. The granularity of this process is very high, during which the technical writer is exposed to logical failures in the UX or in the feature itself that managed to escape the QA people. But unfortunately for our technical writer, he receives the feature just before the release of the version, there is no time to improve and change, and there is not even a listening ear for his insights and comments.
As product managers, a regular meeting with the company's technical writer before the release of the product will benefit you and bring up bugs you didn't know existed, especially when it comes to user experience. Don't give up on this meeting, it can save you from an embarrassing situation with the client, when the feature you released may work in the backend but its usability is not mature enough or logical to the end user.
Trusted source of knowledge
It is unpleasant to say, but in most cases the technical writer knows your product better than you know it. As product managers, some of us work on one aspect of the product, business, growth, fraud, etc. We also do not design and plan the feature from start to finish, but share the process with other professionals such as UX professionals, designers, QA professionals and developers. But the technical writer documents everything starting from the logic behind the feature, the origin story, and the UI, so they have a comprehensive picture of the final product as a whole, its capabilities, its limitations, and even its previous versions and how it has changed over time.
Take advantage of this source of knowledge if you have questions about the product itself and how it behaves. Are you new to the company? Let the technical reporter walk you through the product, its usability, and how it looked and behaved before you arrived.
So what now?
Once you have understood the importance of the hidden data point called the technical writer, you are already on the right track. In my experience, you can use this resource optimally if you take the following steps:
Bring the technical writer into the product team. The technical writer is supposed to live and breathe the product just like you, so it is of great importance to invite them to product meetings, share features with them starting from the planning stage and receive their feedback in real time.
Don't be afraid to take the feedback of your technical writer and go back to the drawing board. Good feedback is one that will make you look at your feature from a fresh perspective, which you don't have.
Use the conversation with the technical writer as a preliminary step before interviewing users. Before you reach out to users and start handing out gift certificates, schedule some time to chat with your technical writer and ask them to connect with the users' point of view and answer your questions. This conversation will lead to more accurate and focused interviews with real users.
The technical writer knows the product better than you and in most cases is the source of the company's internal and external knowledge. Don't hesitate to reach out to them with questions about features you don't know or how a feature has changed and developed over time. Use the written knowledge assets that the technical writer produces to learn more about the product from the user's perspective.
Last and important point - If your product's documentation feels too long and complex - you probably have a UX problem. If your users need so much help to use the product, you need to stop everything and rethink the issue of usability. The technical writer will be able to provide you with an indication if the documentation they write is essentially a crutch, aiding the user experience to stand or provides the user with a source for additional information and troubleshooting.
I know, it's a lot and it's heavy, but even if you adopt one of my five suggestions, I believe that you will become better product managers and as a result, you will be able to deliver products that better meet the needs of your customers. So find out where your technical writer sits, and don't forget to arrive with a cup of coffee and patience :)
Commentaires