Research
What a 186-word tutorial page actually looks like
One competitor publishes 115 tutorial pages at a median of 186 words. They score lowest in the corpus on every measure we applied, and none of them is about that company's product.
We had already decided that our highest-volume content would be task-level tutorials, one page per job someone wants to do in a specific tool. Part of the reasoning was that three competitors had converged on that shape. Convergence felt like evidence.
Then we read the pages.
The numbers first
One competitor’s tutorial section runs 115 pages. Median length: 186 words. The interquartile range is 173 to 200, which tells you these are not articles that happen to be short. They are a fixed template with a fixed budget.
On the extraction quality score our scraper assigns, this cluster averages 57. Every other cluster in the 3,038-page corpus scores between 70 and 100.
They are not about the product
This is the part that changed our thinking. The pages are:
- how to add an emoji in Slack
- how to add a watermark in PowerPoint
- how to access version history in Google Docs
- how to add bullet points in Google Slides
- how to add speaker notes in PowerPoint
None of it has anything to do with the company publishing it. This is a demo-video company publishing Microsoft Office how-tos.
What is on the page
Here is the complete substantive content of one, reproduced in structure:
A title. A one-sentence summary. Four numbered steps, each a single sentence naming a button. A line thanking you for following the tutorial. Three FAQs, of which the answers are “Yes, you’re free to add as many as you’d like”, a list of image formats, and “Yes, once you add a custom emoji it becomes available for all members of your workspace.” Then a promotional line stating the tutorial was made with the company’s product in under ten minutes, and a signup link. Then previous and next links.
That is the page. It is not badly made. It is competently made and almost entirely weightless.
Why it is a reasonable thing to have built
I want to be fair to it, because the logic is sound on paper.
The company sells a tool that turns screen recordings into documentation. A tutorial page about adding an emoji in Slack is a live demonstration of the output. The reader searching for that query has a real problem, the page solves it in four steps, and the footer says “this took ten minutes to make with our product”. As a product demo embedded in search results, it is a clean idea.
The problem is that the idea only works if the page is worth arriving at, and there are several thousand pages on the internet explaining how to add an emoji in Slack. Nothing about this one is better, and the reader has no reason to prefer it.
What we took from it
Our tutorials will be about tools other than ours too. That part we are keeping, because a tutorial about our own product is useless to someone who has not bought it.
What we are not keeping is the part where the page could have been written by anyone. Every tutorial we publish has to contain something that came out of actually driving the software: what the agent hit, where it stalled, how many steps it took, what the interface actually calls things. Those are the parts a competitor cannot copy off our page, because they would have to do the work to get them.
Which means far fewer pages. We think that is the correct trade, and this cluster is a large part of why.