/14-founder-led-content

name: founder-led-content
description: "Build authority by teaching the problem space, not announcing features. Use when the user finds \"marketing\" distasteful and does none, publishes only product updates, or wants a sustainable content and GitHub-README strategy that developers actually respect."

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*). If you want help finding your angle and a cadence you'll actually keep, reach out to me on [LinkedIn](https://www.linkedin.com/in/devtoolgtm/).