Overread

The product thinking behind Overread, a documentation workflow and conversational interface for developers.

895 words

Pivot from Old mate: Overread

Decided to pivot to (still) documentation as a service but instead of hosting the whole doc, we provide a chat interface for end user to interact with documentation.

Business problem

API first businesses want to convert leads to life-time users. To do this, DevExp is very important, especially time to first call. Overread should solve this problem of businesses. Instead of maintaining a big DevExp, DevRel team, a chat interface should be suffice and/or aid DevRel team.

Solve problem of:

  1. Ease of Use: The API should be easy to use and integrate into developers’ applications. Providing clear documentation, code examples, and tutorials can help developers quickly understand how to use the API and reduce the time it takes to integrate. A simple and consistent API design can also make it easier for developers to use the API.
  2. Support: Providing developer support is critical to retaining users. Offering developer support channels, such as chat or email support, can help developers quickly resolve issues and reduce frustration. Providing timely and effective support can also demonstrate the business’s commitment to its users.

Big problem is the lack of documentation Postman State of API Report

When researching on problem of documentation, a recurring problem is insights hidden in different channels (Stackoverflow, Discord, Slack, Github, Documentation, Discussion forum, etc), and business usually doesn’t own all of the data (say Stackoverflow data). Plus, analysing them becomes a burden for business, especially for startup when they don’t have the resource to do so.

Value proposition

Provide an entire suite of tools to aid with documentation. These tools integrate seamlessly to docs-as-code (DaC) workflow that saves time for developers and boost conversion.

Typical flow:

  1. User inputs OpenAPI file, or Postman collection.
  2. Overread generates Markdown files for documentation. User has the option to create a repo on Github/Bitbucket or download.
  3. Every time OpenAPI file changes (on a specific commit), Overread rewrites documentation. User has the option to create PR with new documentation.
  4. Once merged, documentation can be deployed by user’s stack of choice. Overread doesn’t lock users in its hosting.
  5. Once the documentation site is up, user can embed Overread chat bot to the site to answer questions about documentation.
  6. The chat bot can provide insights about the documentation, how end-users interact with the docs. This serves as feedback for the DevExpt teams to keep honing the documents.

Overread fits nicely to existing workflow of business, provide aids throughout the whole documentation life cycle.

The chat bot, apart from helping end-users with documentation, also provides insights for business. Business data belongs to the business.

Improving API Comparing with Kapa AI, seems like there is no unique value preposition for Overread regarding the chat bot. Some values to consider:

  • More beautiful (Nah not enough)
  • Focus on analytics to help DevEx team.
  • Generate content based on the analytics (or from social platforms like Slack or Discord).
  • Writing tools

It’s strange. Many companies using Kapa don’t actually host Kapa chat bot in their documentation sites, they only host in Discord. The sample size is too small so can’t say much here, but something to watch out for.

Market

Serve API-first businesses. It’s a huge market which gains traction for the past several years Read this TechCrunch article,

Hurdles

Readme is doing chat bot like to ask question about docs

Gitbook AI

Kapa AI

Mendable AI

Features

Focus on the ability to generate documentation that augment technical writers.

Chat interface: Summarisation, Q&A.

What’s specific about documentation: Generate code

Contextualise content in the chat. Things like integrations users are using, token, stacks, etc. Copilot for Docs cannot offer this, unless they partners with businesses.

  • Login
  • Show the builder with Training Tab. Allow user to add data to training.
  • I will train the bot myself (cost of training will be on Overread)
  • Should be up in 24 hours.
  • Show user the code to embed to their website.

Deadline: Sunday

Flow

  1. Design the chat bot.
  2. Chuck in training data
  3. Test
  4. Embed
  5. Analytics

Training: Connect to Github so that every time a change is pushed, retrain the bot

Some other thoughts

Don’t lock people in:

  • UX/UI: Docusaurus and Nextra are doing a great job in UI/UX for documentation.
  • Hosting: Netlify is doing good for hosting
  • CI/CD: Version control is good enough, let people use their own toolchains, CICD pipelines.

So what’s left? The writing itself.

Interesting read about tech com tools: State of tools

The end goal of documentation is to educate users. Developers go to documentation page to see what a software is capable of, then scan through some examples to get started, then start to apply the examples to their specific use cases. They will read through specific documentation/API references that suit their needs, then start to implement. Along the way, if there are any challenges, developers will google the problem(s), hope for an answer to come up. The process iterates.

The end goal of user is to implement the product.

The end goal of business documentation is to help users implement the product as quick as possible.

Problem is with discoverability. Users don’t know what they don’t know.

Some good examples include: Stripe, Twilio, Github, Heap, Postman, Shopify, Hashicorp and Square.