Skip to content
ISSUE / 16 4 MIN READ

The operating model is the product decision nobody writes down

The operating model is the product decision nobody writes down

Title card reading The operating model is the product decision nobody writes down, with the closing phrase in acid green italic.

Every serious product organisation documents its decisions. The roadmap is written down. The spec is written down. The architecture decision record is written down, reviewed, versioned, and stored in the repo. Teams that would never ship an undocumented API change will happily run an undocumented company.

Because the biggest product decision of all — how the organisation actually works — almost never gets written down. It gets inherited.


The decision you made without making it

Ask a founder what their product strategy is and you’ll get a considered answer. Ask them what their operating model is and you’ll usually get an org chart, which is not the same thing. An org chart tells you who reports to whom. It doesn’t tell you who decides, how fast a decision travels, what “done” means, where quality is enforced, or what happens when two priorities collide.

Those are the questions that determine what actually ships. And in most companies, nobody answered them deliberately. They were answered by accretion — a process copied from a previous employer, a ritual that survived because nobody cancelled it, a decision right that lives with whoever shouted first. The model exists. It’s just unauthored.

Unauthored systems still produce outcomes, and they produce them reliably. A company that takes three weeks to make a reversible decision will make roughly seventeen such decisions a year. That number is a product decision. Nobody made it. Nobody wrote it down. But it will shape the product more than anything in the spec.


Strategy doesn’t ship. The model underneath it does.

Strategy fails politely. It sits in the deck, agreed by everyone, contradicted daily by the way work actually moves. When a product is late or bloated or wrong, the post-mortem reaches for the visible causes — the estimate, the dependency, the hire. It rarely reaches for the real one: the operating model made this outcome likely long before anyone opened a ticket.

You can see it in the questions teams can’t answer quickly. Who owns this decision — one name, not a committee? What is the cost of a week of delay on this, in numbers? When did we last kill something, and how long did it take from doubt to decision? If the answers are slow, the model is the bottleneck. Not the people. The people are usually fine. They’re just operating inside a system nobody designed.

This is why copying the practices of companies you admire so rarely works. The rituals are the visible layer. What made them work was the model underneath — the decision rights, the cadence, the tolerance for reversal — and that layer doesn’t transfer by imitation. It has to be designed for the company you actually are.

And the people matter as much as the model — we’ve learnt this the hard way. The best-designed system fails in the hands of people who won’t hold it, and the best people inside a bad system spend their talent compensating for it. The model decides what your people’s effort becomes. You need both. Only one of them ever gets written down.


Writing it down

The fix is authorship. An operating model that’s written down can be inspected, argued with, and changed. One that isn’t can only be endured.

Writing it down is half the work. The other half is adoption. The document has to be the thing people reach for at the point of decision — quoted in the review, amended when reality disagrees with it. A model that sits in a folder nobody opens is as unauthored as one that was never written. So write it where the work happens, build the cadence around it, and let it earn its authority by being used.

Writing it down means answering, in plain sentences, the questions the org chart dodges. Where does each class of decision live, and is it one name or a meeting? What is the operating cadence — what gets reviewed, at what interval, against what number? What are the interfaces between functions, and what does each side owe the other? What is the definition of done, and who is allowed to say so? What gets killed, and on whose authority?

It’s unglamorous work, and it is product work. Every one of those answers constrains what your product can be — how fast it evolves and how coherent it stays. Leave them unwritten and you haven’t avoided the decision. You’ve just delegated it to habit.

And the cost of leaving it unwritten is rising. AI is collapsing the price of execution — code, copy, analysis, the artefacts themselves. What it cannot collapse is the cost of a badly routed decision. When execution is cheap, the operating model becomes the advantage. Give two companies the same tools and the same talent, and they diverge on the quality of the system that decides.


Why we exist

This is the work Lucid does. Not strategy on a slide — the operating model underneath it. We work in two modes: Engagement, where we operate inside your company — fractional CPTO or COO, not fractional attendance — and Venture, where we build with the model designed in from the start rather than retrofitted after the pain.

We’ve put the firm’s site live this week. It’s built like we think — an instrument, not a brochure. If your company is running on a model nobody wrote down, that’s the conversation to start.

START

Forty-five minutes. Bring the constraint.

Tell us where the model is bending. We'll say what we'd do, and whether we're the right people to do it.

WHAT DO YOU NEED?
LONDON — GMT TAKING ENGAGEMENTS