---
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/).