One of the foremost challenges that a product team faces is “How to bridge the information gap between the customer and their product? How to reach out to the customer effectively?” You can make excellent product videos and demos. You can even explain the workings of the product to your customer face to face. But none of these methods can eliminate the need for good and solid technical documentation.
Technical writing has always been an integral part of the product lifecycle. Before the digital revolution, technical documentation was the only way to reach out to the target user, at any lifecycle phase. Even today, the modern media-intensive methods of communicating with the customer need to be ably supplemented with clear, concise documentation that the customer can refer to as and when a need arises.
So technical writers, pad up and get ready. You are and will always be a critical link between your product and your customer!
It would help to first understand the knowledge gap which technical writing is expected to fill. Once we understand the need, the appropriate documentation can be chosen.
The types of technical writing are based on 2 important criteria – the intended user and intended purpose.
This guy requires a lot of convincing before he decides to shell out precious bucks to buy your product! So the documentation is directed towards educating him or her on the virtues of the product and how it would fulfill his needs. Obvious coercive marketing is not as powerful as passive influence. Quite often, this is not the person who is going to use the product, so it’s not important for him or her to understand your product workings in detail. He or she simply must be convinced of the absolute need for your product.
Press releases, marketing brochures and catalogues, technology/product white papers, competitor analysis reports, client testimonials, case studies, demos.
For small products, deployment is a simple thing, the end user can handle it himself or herself. Imagine complex ERP solutions or telecom installations. Here, installation and deployment is an elaborate and technical affair. Also, the customer is still new, so his or her trust in your product is fragile. It’s important to reinforce his or her belief in your product, make him or her feel he or she did the right thing by choosing your product. Generally, the technical team that handles installation is also in charge of troubleshooting and maintenance after the product is in use. Though these activities happen at different time periods, the nature of documentation is similar. By now the customer is quite familiar with your product, so you can take some of his product knowledge for granted.
Installation manuals, FAQs, release notes, maintenance manuals, service warranty, SaaS subscription plans.
Can you remember that fantastic toy train set you always wanted as a child? But before you got your hands on it, your mom made the decision to buy it, your dad spent hours assembling it for you. Only then did it reach you! Similarly, the software infrastructure that an employee gets to use at his workplace is chosen and deployed by other people. As an end user his view of the product is limited to its run-time use cases. One of the key reasons for poor product adoption statistics of enterprise software solutions is this – the actual user is not consulted about the product. So, the gap in the user’s expectations and the product features is wide. This gap has to be bridged with very sensitive and user oriented documentation. Documentation teams must put themselves in the user’s position and then develop content. Today, the challenge of user adoption is being tackled with the help of a newly introduced category of technology called Digital Adoption Solutions (DAS). One of the most preferred vendors in this category is Whatfix. Top Fortune companies use Whatfix to build seamless software experience for their users with the help of onboarding task lists, step-by-step walkthroughs, beacons highlighting new features etc. This allows users to learn the application at the moment of need, within the platform itself.
Online help, demos and samples, FAQs
Some products and solutions are built and sold off-the-shelf. Some others are built to a customer’s specific need. The pre-sales documentation in both cases is slightly different. However, the goal of documentation in this phase is to establish a thought / domain leadership in the space that your product operates in. Some documentation would elaborate the product specifications, some others will be to highlight your company’s presence and dominance in the given business space. These documents are prepared and delivered before your software goes live, so the documents are not meant for an end user/lay man’s consumption, they are targeted at decision makers in the customer team. For one time purchase products, this phase has a definite start and end time. All documentation between ‘establishing initial intent’ and ‘signing the purchase’ fall under this phase. But when companies adopt the SaaS model to deploy their products, they are perpetually in the pre-sales mode. That’s because the customer’s commitment has to be renewed month after month! So you have to constantly stay in the customer’s orbit and make your presence felt.
Tender proposals, competitive bids, product specifications, delivery agreements, market research reports, media promotions, white papers. Even the blog you are presently reading falls under this type for that matter!
The commitment is made, the customer has been locked in. Now the documentation should focus on how quickly and effectively the product gets into use. Building customer relationship and user on-boarding are the main objectives here. This corresponds to the ‘going-live’ phase of software products where transferring product knowledge from the product to the customer team is the key goal of documentation.
To enhance a user’s experience, the onboarding should ideally be personalized to them based on their role and language. The initial help content that is provided should also cover all the features and functionalities that are relevant to that user. This is where solutions like Whatfix play a major role in creating a seamless onboarding experience by overlaying on top of the application. Users are introduced to the software application through interactive pop ups and flows to swiftly get them started on the application.
Sales agreement, customer persona, installation manual, online help, demos and samples, FAQs
An often neglected part of the documentation. Once the customer is locked in, if you take him for granted, that’s suicidal for your product’s reputation and continued patronage. Documentation for after sales support must be top notch, focused and time saving. There is a lot of technical writing associated with version upgrades and bug fixes too. This is also the best place to influence your customer to increase his engagement in your company, try out your other offerings. So the cycle actually never ends. Remember your software is already live now, so any mistakes made at the documentation will be immediately visible and greatly impact the customer.
User experience reports, trouble-shooting guides, AMC documents, migration manuals, SLAs.
Technical writing is an umbrella term that loosely describes various kinds of documentation that a company needs to prepare. Not all writing is technical here, but all of it is user-oriented. There is no point in creating volumes of documents that don’t match a specific user’s needs. Understand the need and deliver the appropriate type of technical documentation. It’s one sure shot way of winning a satisfied customer or a user! Learn more about how Digital Adoption Platforms (DAPs) like Whatfix can help you build a winning user-focused documentation, request a demo today.