Education and Content Creation
Rainkit has just launched webhooks: instead of asking for forecasts over and over, an app can register a URL and Rainkit calls it when rain becomes likely. The engineers want a post called "Introducing Rainkit Webhooks v1". Meera suspects almost nobody would finish it, because nobody wakes up wanting webhooks. They wake up wanting their app to do something.
The rule
Teach the job the developer is doing, not the feature you shipped.
Most of what a developer advocate produces is education: tutorials, videos, workshops, talks, sample apps, short courses. Every piece is a small lesson, and a lesson is judged by what the learner can do afterwards.
Compare two titles for the same launch:
- Feature-first: "Introducing Rainkit Webhooks v1"
- Task-first: "Warn your delivery riders before the rain arrives"
Webhooks appear in both, but only the second is about the reader's work. It tells a food-delivery developer, in one line, that this piece solves a problem they already have.
Before making anything, answer three questions:
- Who is it for? Their stack, their experience, what they already know.
- What job are they trying to do? A real outcome in their product, not "learn about webhooks".
- What will they be able to do at the end? Something they can check: it works or it doesn't.
Then pick the format that fits that reader and that outcome:
| Format | Best when |
|---|---|
| Written tutorial | the reader will follow along and copy code |
| Short video | the idea is visual, or involves clicking through a UI |
| Live workshop | a group needs hands-on help and answers on the spot |
| Sample app | developers want to see a complete, working example |
| Talk | a room needs to understand an idea or see what is possible |
Content also ages. A tutorial that still calls a removed function does real harm, so keep a list of published pieces and re-check them whenever the product changes.
The shortcut
Fill in a one-line brief before you write a word: "For [who] who want to [job], this [format] gets them to [outcome]." If you cannot fill a blank, you are not ready to write yet.
Who
Backend developers at food-delivery start-ups, comfortable with Python.
The common mistake is the feature tour: a piece that shows every option of every endpoint. It covers everything and teaches nothing, because no reader has every job at once.
Drills
Answer fast — trust the rule.
Which title is task-first?
A developer wants to see a complete, working app that uses Rainkit from end to end. Which format fits best?
Which outcome statement is most useful when planning a tutorial?
A popular tutorial from last year still uses a function the SDK has since removed. What is the best response?
Remember
- Teach the job the developer is doing, not the feature you shipped.
- Shortcut: "For [who] who want to [job], this [format] gets them to [outcome]."
- Trap: feature tours and stale tutorials. Both teach less than they seem to.