How often have you been shopping and, while looking at something that might be suitable, you just had the feeling that it wasn’t right? When shopping for houses last year, we had that feeling many times (too many times). They were, for the most part, all nice homes, but they just didn’t do “it” for us. Sometimes we could articulate the reasons, other times, it was something less tangible. In every case, except for the last one, of course, we walked away without becoming a customer.
We finished house hunting about two years ago and I hadn’t given that feeling a second thought until I came across a blog post about making the Build vs. Buy Decision. Point 4 of that post, whether it is cheaper to build than to buy, got me thinking about one of the value propositions that technical communication frequently asserts–to increase product adoption. To tie it back to house hunting, let’s call it making it easy for potential customers to see themselves using your product and becoming a customer instead of just a prospect.
Try it, you’ll like it!
In API marketing, one of the methods recommended to promote your API to potential customers is to provide some easy way for potential customers to take a test drive. Options such as providing a sandbox, having an accessible Hello World application or example, and providing tutorials that provide solutions to common customer pain points. The idea is to get them into the driver’s seat and let your potential customers take it for a spin. The lower the barrier to entry, the easier it is for your potential customers to see if this is a product for them and to see themselves as satisfied customers.
For API products (and, I would imagine, almost any product), creating this type of accessible entry into a product generally has to be designed and built into the product from the start. It is difficult to bolt on ease of use as an afterthought. I talk about what not doing this looks like to the technical writer in If your API is hard to document, be warned.
Would more or better documentation help?
While technical communication, as a field, likes to promote “increasing adoption” as an element of their value proposition, I’ve also been critical about how that is often something that is over promised and under measured (without valid measurement, it’s hard to tell how they’ve actually delivered). Clearly, it makes sense that if adoption is hindered by a lack of documentation, then adding or improving documentation would be a reasonable solution. But, part of the reason I’m critical about how technical communication promotes this as a part of their value proposition is that much of the adoption journey is out of the writer’s control. See If your API is hard to document, be warned for how few adoption problems are the result of inadequate technical writing.
That said, when technical content is part of the adoption problem, it should be an easy fix. When evaluating the question of whether it’s cheaper to build or buy software, technical content is definitely a factor in the decision.
I can’t say whether the product referenced in the blog post could be fixed with more or better technical content because I couldn’t find any (however, to me, that suggests that there might be a technical-content problem). The product’s web site is full of features, promises, animations, SEO-catching terms, and analytics tags that choke on my LAN’s pi-hole, but it’s very light on details, free trials, etc.
I can’t really tell from the web site, but if the product was easy to use and integrate, they wouldn’t have written the blog post. That leaves two possible cases that could motivate the experiences described in the blog post.
- The product is easy to use and integrate, but there’s no way for customers to know that with sufficient certainty in advance, thereby making it look riskier than it is and riskier than the DIY option.
- The product is neither easy to use nor integrate, and the customers are justified in their decision to DIY. That’s a wake-up call.
If it’s option one, the problem could be solved by providing the technical content necessary to demonstrate their value proposition. That’s definitely a job for technical writers.
If it’s option two, there’s still room for technical writers (and user researchers) to help. How will you know if a design is hard to document unless you have some technical writers working with you on the design?
For Wicket Labs, I hope they sort it out and are soon writing blog posts about how customers see how easy their software is to adopt.