Bill Chambers 
Deliver great content with Hyperlint
[By {{ $doc.author.name }} on {{ $doc.date }}.]{.text-small}
Developer products are struggling.
The landscape is more competitive than ever. Teams are shipping faster and faster. They support more and more surface area - everything from integrations, partnerships to the hottest AI tools.
There is so much to do.
It’s not just product and engineering, developer relations and technical writing teams are swamped. Whether it’s updating documentation issues that a user pointed out or trying to meet the deadline for the next release.
AI promised more content, but it’s getting worse. Developers skip the marketing and go straight to your documentation. And that’s when so many products and projects lose. They have terrible documentation.
Why your documentation probably isn’t great
It’s because of what we at Hyperlint call the Maintenance Monsoon. I’ve seen it at every company I’ve worked at and I see it now as a startup advisor.
Here’s what happens:
- Your company gets focused on delivering an important new initiative.
- Your team ships new features to seize the moment.
High fives all around! Hooray. 😃
But wait, in the flurry, documentation doesn’t get updated. Some pages need to be overhauled and added. Tutorials need to be rewritten. Launch blog posts get outdated the following week. The team moves onto the next and the product suffers for it.
Developers want your new product but struggle to succeed because developer content falls to the back burner.
Now you’re stuck taking your best engineers (who understand the product the best) and having them write prose. They struggle through it and produce something mediocre. If you’re lucky, you’ve got a technical writer to help keep your documentation consistent and ensure a resemblance of quality.
Then you do it all over again next quarter. And again next quarter. And the quarter after that. Now you’re stuck with bad documentation. You’re trapped in the Maintenance Monsoon.
What are the consequences of bad documentation?
Consequence 1: lose early users
Developers hate marketing. At least traditional marketing. End developers are going to skip right over your content, want to try the product, and check out your documentation.
If it’s out of date or incorrect. End users are going to struggle, you’re lucky if they at least let you know that it’s wrong. But most are just going to move on. Not their problem.
Consequence 2: disappoint the community
The consequences are insidious, like any debt. We binge and feel great. Feature shipped! Job well done. Then all of a sudden, you get blown up on twitter.
If you’re lucky, people and your community will help.
Or your boss reaches out to you on slack and asks you to “take a quick look.”
So how do teams deal with these challenges?
Over the course of our research, we’ve talked to dozens of product teams about poor quality documentation and ways in which they deal with poor documentation.
There are two fixes: tolerate mediocrity and hiring.
Short Term: Tolerate Mediocrity
Who’s seen this banner before?
That’s what developer teams that need help do. They do what they can and ask for forgiveness from their users.
You want to support new initiatives and changes but in the process end up neglecting existing documentation and tutorials. Conversely, you can get swamped in maintenance and make no progress on the new feature.
Either way, your team members will get burnt out if they take pride in their work.
This is unsustainable, so what’s left? Hiring.
Long Term: Hiring
Hiring is no panacea. Great developer content and technical writers are hard to come by and for teams that don’t have the resources of larger organizations, at times they’re out of the question.
More concerning for organizations of any size is that it’s hard to allocate content resources effectively. Priorities change, some areas are too small while others need a lot of help.
Hiring tech writers is risky too. You’re going to need recruiting resources, you’ll need an interview panel, interviewers, it’s a ton of work and that all assumes you have head count!
Hiring is a long term solution and as your product grows, it’s inevitable but we believe that there’s a third way.
The Hyperlint Mission
We are building Hyperlint to help product teams write and maintain great developer content at a fraction of the effort.
We believe that AI is here to help us build great developer experiences. We believe that AI is not here to replace our work but to augment it. To simplify it.
Hyperlint exists to take the toil out of technical content for:
- Documentation and Developer Relations Teams that need to maintain large collections of developer facing content like developer documentation, API documentation, and SDK documentation.
- Developer product and engineering teams that don’t have head count or budget for hiring a tech writer but need to produce results.
- Open source projects that need to source from a large number of contributors with different writing styles, tones, and experiences.
The Hyperlint Vision
We believe that AI and humans need to work together to build great content. In an era of cheap tokens, high quality content is a critical differentiator for developer products and we believe that AI can help us achieve that.
We believe that AI exists to free teams from the toil and chores that they have to build a product that they’re proud of. That might be removing the need to proofread your own documentation changes. That might mean improving the SEO of your documentation portal. It might mean getting suggestions for changes happening in your API, automatically.
Documentation is a part of the product and for developer products and open source projects. It’s a critical one.
