---

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.