Pre:
The topic of product documentation has been on my mind recently, and I did some digging and found this old write-up in my personal archive of startup ideas. I’ve gone through and made a few minor edits/additions - as always any thoughts/feedback/criticism is welcome!
Self Service Scalable CX
Customer documentation is broken, confusion is the default experience. Every time a customer needs to email, chat, or call represents a failure in customer experience. Yet, we all see the proliferation of live chat widgets across the web. This represents both the poor state of documentation as well as a fundamental misunderstanding of how scalable CX can be provided.
The problem that customer documentation seeks to solve is to fill gaps in product knowledge. A perfect solution would empower every user with the required product knowledge when and where they need it. There are a few levers that every product can utilise to reduce this problem:
Better product design (e.g. more intuitive UI, automate/abstract away confusing steps)
More guidance in-app (pop ups, modals, tooltips, etc.)
Better documentation (relevant, accurate, discoverable)
Product training
As you can see, documentation is only one part of the solution.
However, there are certain products where documentation is a proportionally larger lever. One such area is API products, due to the lack of UI removing the ability to add in-app guidance". Here, quality of documentation is paramount. As an example, Stripe is well-known for their stellar developer experience, and this is predominantly driven by the quality of their developer documentation. For Stripe, developer documentation is their customer documentation as developers are their target customer.
The benefit of quality documentation is that it is infinitely scalable, great synchronous customer service on the other hand isn’t. Great documentation can be enjoyed by your customers forever. This is an example of the power of scalable CX, markets susceptible to bottom-up (self-service) sales will be won by companies with scalable CX. As PLG / Modern GTM continues to spread, this is especially pertinent.
There are many players already offering documentation platforms, knowledge bases, and other CX offerings. Many of these already have widgets that embed into websites for ease of access. The bottom-up growth loop for these customer communication platforms is simple: A customer integrates the widget, this widget is seen by their customers, a proportion of their customers also run their own sites, a proportion of these customers then sign up and integrate thereby restarting the loop. To be clear, this likely isn’t the only growth loop that these companies have.
The pricing of Intercom, Drift, Zendesk, Help Scout, etc. represents either an intentional move into the enterprise market or a fundamental misunderstanding of their growth loops (at least in the SMB market). This leaves an opening in the market for a new player to progressively bite off slices of functionality (e.g. feedback, checklists, knowledge base, etc.).
Beyond the gap from pricing model inefficiency, I believe the feature bundle of most existing incumbents is bloated and sub-optimal. Live chat should not be the default, not only is it costly to maintain (quick response times require around the clock staffing), but a failure to respond quickly leads to a very poor CX. Instead of a positive or neutral experience, you create a negative experience. Scalable CX should be the default for most companies. The only incumbent that I think has got this right is Help Scout, however, they are support focused and they are still supporting email/live chat.
More specifically, documentation may be a gap in the market where there is no good off-the-shelf solution. The providers listed above (Intercom, Zendesk, etc.) tend to provide knowledge bases / help centers rather than documentation specifically and are targeted at Customer Success/Support functions rather than product teams. Yet, documentation is a part of the product (in all likelihood a large percentage of users of any B2B software will come to interact with the documentation). There are also a number of open source option targeted at technical documentation (e.g. Docusaurus) and are aimed at devs.
Documentation should be iterative, write, collect feedback, re-write (like the product development cycle).
What might a better documentation look like? It might look like a subset of the following enhancements:
Top-class editor experience - this includes tables
Top-class end user experience e.g. support variables (e.g. user can pass in the user’s name which can then be inserted)
Support in-app experiences e.g. embed modal
Recommend documentation articles based on fields passed into query parameters on embed modal
e.g. url=XYZ, membership=XYZ
Users that have already viewed an article are less likely to view it again
AI to summarise support articles to enable easier browsing?
Auto-trigger documentation on rage click or other signals?
Track search results and where people end up to help users improve/write more support articles
Deep analytics - track each page that a user has been on
Use AI to generate documentation?
Ability for end users to highlight and provide feedback (e.g. something is out of date / doesn’t make sense etc.)
Hover preview like Wikipedia / Obsidian
Reporting on time savings:
Meetings/support requests saved
Hours saved
For more inspiration see: https://www.swyx.io/the-surprisingly-high-table-stakes-of-modern-blogs/
Documentation is just one part of the scalable CX equation and might not necessarily be the best place to start.
As an alternative approach, the initial product should be focused on kickstarting the growth loop. This means that having the lowest integration friction or time to value is paramount. This implies less customisation and setup. The other requirement is a use case that is broad in terms of appearing across websites e.g. feedback. This means the help docs functionality should be delayed in favour of a lower friction, broader use case of collecting feedback. The downside here is that feedback collection is less broken and our offering will be less differentiated.
Another low friction, broad use case is a link launcher for docs. Users can then leverage their existing docs and simply link to them in our widget. This is a more natural entry point for our vision, but is higher friction compared to a simple feedback widget.
Subsequent iterations of the growth loop can then focus on progressively deeper integrations / higher friction integrations.