Storytelling through code

Storytelling for products has always been a context problem disguised as a writing problem. For years I ran it out of Notion. Now I run it from the terminal. I want to walk through how the process moved, what it produces, and the part of the job I'm still the most interested in — the part that can't be encoded.

The context problem

The expensive part of product marketing was never writing. It was getting context — high-fidelity, current, trustworthy context — the moment something is ready to ship.

Context is always moving. It lives in commits, in PR comments, in Slack threads, in a Figma file someone didn't link, in a decision that got made on a call last Tuesday. No single place holds all of it at once, and the product keeps evolving while you're trying to describe it.

Getting the story right, at the right resolution — that's the real job.

Version 1 — the Notion backstory

My first attempt at fixing this was a template. A single Notion doc I called the Product Backstory. Seven sections:

What is this? — the shape, then what it does.
Who is it for? — by role, and by the situation that brought them here.
What problems does it solve? — three to five, each a distinct pain.
Why now? — the shift that opened the window.
What is different or better? — against real alternatives, not strawmen.
How it works. — concrete commands, paths, example prompts.
Considerations and limitations. — honest caveats, not softened.

The Backstory is not a PRD. A PRD answers what should we build, and how. The Backstory answers what is this, really, and why should anyone care — a different document, written for a different reader.

It worked. Marketing could plan a launch off a single source, and signal improved. But it was slow. The document lived one layer away from the code it described, and every pass felt like a reconstruction rather than a reading. Worse — I had to drive every one of those passes myself.

Version 2 — /storyteller in the repo

The next version was to encode the process as a skill the product owner runs on their own branch.

It works like this. The product owner runs /storyteller in their repo. The skill reads the branch for context — code, PR description, recent commits — then walks the owner through a short, dynamic questionnaire shaped by the Backstory template: what is this, who is it for, what problem it solves, why now, what is different, how it works, where it breaks.

The questionnaire is linear on purpose. Backstory first, because until that is settled, nothing downstream has a spine. Once the Backstory is locked, the messaging brief generates off it — summary, value proposition, three key messages, use cases, considerations. Both drop as .md files in the repo, next to the code they describe.

The terminal is the meeting. No chaotic Notion page, no endless syncs, no "can you fill out this doc by EOD." The process runs where the engineer already is, in the tool they're already in.

The brief as spine

If the Backstory answers what is this, the brief answers how do we talk about it.

At Firecrawl we chain other skills off the brief. Blog post skills takes it as input. So does the social skill, the changelog skill, etc. One high-signal source, several parallel outputs, all inheriting the same spine.

Why the product marketer still matters

Skills encode rules. They do not encode taste.

I still review every Backstory, every brief, and every output by hand. I cut more than I keep. The skill will faithfully produce the thing I asked it to produce, and some of what comes back is still wrong — subtly wrong, confidently wrong, the kind of wrong that sounds persuasive until you read it cold.

The job of the product marketer is reductionist. You sit between the product and the customer, and your value is the judgment about what to leave out.

AI makes this both harder and easier in the same breath. The output is fluent and verbose. At times, it can be surprisingly convincing nonsense — if you do not read cold.

So I read cold.

I cut hard.

I ship the signal.

The job has not changed

Moving storytelling into the repo did not make the craft smaller. It made the context richer, the turnaround faster, and the judgment more load-bearing. Skills get me closer to the code. Judgment is what still gets me closer to the customer.

Converting noise into signal, so the customer arrives with context and without fog, is still the whole job.