Step 4: Peer learning

No matter how good your docs, content, or best-laid plans, successful tools will have both newbies and edge cases.

Docs and content are a form of automation, and all automation needs exception handling.

Two common exception cases:

• Newbies don’t have enough context to use documentation confidently
• Power users have backed into an edge case you haven’t yet documented

You can build ways for developers to help each other get unstuck when your docs aren’t enough, and when Cursor isn’t cutting it. This feeds energy back into your product’s traction, instead of frittering it away when developers give up.

We also live in a reality where Stack Overflow is in decline. This means developer tools companies which host their own learning spaces have an edge.

​

A self-organizing, distributed hive for problem solving

Positive community learning experiences become positive associations with your tool.

When it works, you’ll see things like:

• Posts explaining how developers have implemented your product
• Tutorials made by your users
• Publicly-documented workarounds to known issues you haven’t managed to patch yet
• Developers starting consultancies selling their expertise in your product
• Conspiracies to help people get jobs where using your tool is encouraged

Healthy, active community creates a flywheel, and de-risks the decision to adopt your product.

Your job, as a devtools company, is to use your product to make developers more successful in their careers. If you build a way for your users to scaffold each other’s efforts, you and your users get to be part of the same upward trajectory.

​

Decide what creates status in the spaces you control

The internet is vast and at the extremes of success, your community will be an archipelago of chats, forums and comment sections.

But there are places you can control, like the official Discord, Discourse or repos for your project.

Make clear, for yourself and for newcomers, what behavior creates status in these spaces. Without explicit definition and planning, status becomes an accident. High status people might become experts in your code who are also unfriendly, and this would put a ceiling on your growth.

Instead, you want status to accrue to those who are helpful, welcoming and generous.

You can do this through simple, low-cost rewards. Things like public recognition, more direct access to your team, and elevating the work of your most helpful contributors. You can and should give the cold shoulder to people who are capable of building cool stuff, but prevent other people from learning.

The network effects of a helpful peer learning community can change the trajectory of your business altogether. But this requires deliberate, transparent stewardship of norms and values.

Discourage the assholes, embrace the helpers. Five intermediate users who are eager to help are far more valuable than a single expert who makes people avoid your space.