Founder Led Content Agent Skill

Founder-led content

> You don't have to "do marketing." You have to become the person developers trust on *the problem*. Sell the category, not the product, and let the authority pull people in.

Use this when: content feels slimy so you avoid it, your "blog" is a changelog, or a competitor is quietly becoming the go-to voice while you ship in silence.

The core idea

Developers reward technical depth, honesty, and a real point of view, and punish polished fluff. The move isn't promotion; it's education. Be the trusted expert on the problem, take a stance on where the space is heading, and the product sells itself as the obvious answer.

Before product-market fit, only the founder can do this. It's the #2 hire (DevRel) later, not now.

Framework: authority positioning (Frankl)

• Own the problem, not just the product page. Talks, posts, teardowns, a distinctive thesis.
• Sell the category: teach the problem, describe the need for "a tool like this," share results, without proactively pitching (that trips developer defenses).
• Have an actual point of view on where the industry is going. A trusted expert has opinions; a vendor has features.

The "O'Reilly book" content plan (Frankl): imagine the definitive book on your problem, ~10 chapters, ~10 sections each. That's ~100 genuinely useful pieces mapped out. Publish against the outline consistently. You're writing the book that makes you the authority.

Framework: content & GitHub as distribution (Czakon)

• Teach the problem space (DigitalOcean model): tutorials and deep dives that are useful even if the reader never buys. Curiosity-feeding > promotional.
• README = your real landing page for an OSS/dev tool: what it is (one line) → why it exists → quickstart in <5 min → a copy-pasteable example → badges/social proof. A developer decides from the README, not your website.
• Repo SEO: put the actual search terms in the repo name, description, and topics; developers (and Google) find repos by problem keywords.
• Authenticity over polish: first-person, real, transparent. A rough honest post beats a glossy empty one.

Decision tree: what to write next

Do you have a real, contrarian-but-true opinion about your problem space?
├─ YES → write that. POV posts build authority fastest.
└─ NO  → write the tutorial you wish existed when you hit this problem.
         (Useful-to-a-stranger is the bar. If it only helps someone who already bought, rewrite it.)

Mistakes that look reasonable

• Changelog-as-content: "we shipped X" is not a story or a draw (Frankl: a feature isn't news; a customer win is).
• "Pleased to announce": nobody cares how you feel about your release.
• Polish over substance: developers smell marketing and leave.
• Neglecting the README: a great product with a lazy README converts nobody.
• Inconsistency: three posts then silence. Cadence you can sustain beats a heroic burst.

Your next 30 minutes

• [ ] Sketch your "O'Reilly book" outline: 10 chapters on your problem. You now have a content roadmap.
• [ ] Write one POV sentence you actually believe about where your space is going.
• [ ] Audit your README against the anatomy above (what · why · <5-min quickstart · example · proof).
• [ ] Put your problem's real keywords into the repo name, description, and topics.

Built from real dev-tool GTM experience, with frameworks from Adam Frankl (*The Developer-Facing Startup*) and Jakub Czakon (*markepear.dev*).

When a framework can't make the call, that's what a human is for: The DevTool GTM Company.