Notes

Operations is design work

August 20264 min read

The calendar says none of it is design work: invites, onboarding messages, release notes, feedback triage. The product disagrees. Every week five to ten creators show me what the latest build did to their work, and I run every piece of that loop myself, on purpose.

Operations is a product surface

The unglamorous list first: recruiting creators for the alpha, writing the onboarding message they actually read, scheduling sessions across time zones, answering questions in the community channel, writing release notes that tell people what changed and why, and sorting this week's feedback into "bug", "friction", and "we framed this wrong". At most companies that list is scattered across three job titles and treated as overhead.

But every item on it is an interface the product has with its users. The onboarding message is the first screen of the product, even though it lives in an inbox. Release notes are how a creator decides whether the build is worth reopening. If nobody designs these surfaces, they still exist — they're just designed by accident.

Owning them also closes a gap that user research can't. A session shows me what a creator does with the build in front of me. The operational exhaust — who stopped opening builds, which onboarding step people quietly skip, what gets asked twice in the channel — shows me what happens the other six days of the week.

MML ONE hero screen with the tagline 'Your story. Every world. Every screen.' above a dark production-pipeline strip showing screenplay, character, world, and shot-board stages connected in one graph
The build creators open every week: MML ONE's production pipeline — screenplay, characters, world, and shot board — connected as one graph. Every operational surface in this note exists to get people into this screen, and to learn from what they do once they're there.

If nobody designs the operational surfaces, they still exist — they're just designed by accident.

The cadence is the feature

The weekly rhythm does more than keep us honest. It sizes the bets. Anything that can't produce a testable slice within a week gets broken down until it can, which is uncomfortable for grand plans and very good for finding out early that a grand plan is wrong. The roadmap isn't a quarterly document; it's the running answer to "what did the last four loops teach us?"

It also changes which numbers I trust. Dashboards read like scoreboards; the numbers that actually steer decisions are the ones the loop produces as exhaust — who opened this week's build, who stopped, what got asked twice in the channel. When the loop stalls, the graphs stall a few weeks later. That lag is the most useful early warning I have.

The honest cost: running operations myself puts a ceiling on how many creators the loop can serve, and a founder who triages their own product's feedback will sometimes grade it kindly. The fixed weekly cadence is the guard against the second problem — the sessions happen whether or not I liked last week's read. Scale is the reason this job eventually gets shared; the loop itself is the part I'd hand over last.

MML ONE's six platform stages laid out end to end — Story and Script, Characters, World, 3D Stage, Shot Board and Cut, and Deliver — each stage inheriting the cast, world and creative decisions locked in the stage before it
Where the weekly slices land: every bet gets broken down until it fits inside one loop and one of these six stages. If it can't produce something testable by Friday, it's too big.

Taste is mostly exposure

The product decisions people credit to taste mostly come from here. The ideas I'm proudest of weren't invented at a whiteboard; they came out of watching the same friction show up in session after session, and being close enough to the operational signal to trust that it was a pattern and not an anecdote. Where one of those ideas ended up is in the MML ONE case study →; the workflow underneath it is in Why I don't hand off my designs →.