Michael Jenkins

Home / ProductOps

ProductOps · the short version

An AI-first operating system for product leadership.

You can't skip great leadership. A leader's real asset is judgment, and judgment doesn't scale on its own. Shared context, distributed decisions.

Picture the monthly review. Twelve people, ninety minutes, forty slides. The first hour is narration. Somewhere in the last twenty minutes a decision comes up, and it gets pushed to a follow-up, because the people who'd make it have just heard the context for the first time.

Nobody in that room is careless. The meeting is the report because no report exists until someone builds one, and the reasons behind the numbers live in people's heads. They arrive with the person and leave with them.

I've spent about two years working on that problem in my own organization. This page is what came out of it. The wins are early and the theory is ahead of the evidence, so read it as a theory I'd like help testing.

The idea

You can't skip great leadership. Process doesn't replace it, and neither do tools. A leader's real asset is judgment: which outcomes matter most right now, which bets to make and how much, when a team is one ask away from breaking, when to stop.

Judgment doesn't scale on its own. In a large organization the portfolio is too big for anyone's head; in a small one everything fits in the owner's head, so nothing moves without the owner. Same problem: decisions go wherever context is, and context is stuck.

AI makes this urgent. Known work is getting cheap. Once anything we can describe can be built, deciding what we want, and why, is the next frontier. AI already outperforms us at most known tasks; what it usually lacks inside a company is the right context, the judgment to align with, the guardrails to hold, and a clear outcome to deliver. Those four are what leaders produce every day, and most organizations have nowhere to keep them.

So the design choice is: shared context, distributed decisions. Give every leader the same view, write their judgment down beside it, and decisions can move to the people closest to the work without drifting apart.

The model

STRATEGYGUARDRAILSTHE RECORDPROJECTSPRODUCTSOPERATIONSLOOP
Take the guided tour →

Four parts, two rules, one boundary, and strategy above.

  • The Tree. One shared view of three things: what we bet on, the value we create, and how we work. Every product, project and team has a place in it and one named owner. The leader of the whole organization and the leader of one product read the same kind of page.
  • The Loop. Expect, see, explain, adjust. Every decision runs through it, at the paces you set: daily for the numbers, per bet for the work, monthly for the weights, and at your budget cycle for strategy. Adjust means a decision is written and the action it implies is dispatched: to a person, to the system, or to another loop.
  • The Record. The system raises flags. People respond with observations: a note, a question to one person, a decision with its expected effect. The reasons stay beside the numbers, so every number, product, team and portfolio carries its own story over time.
  • The Guardrails. What's never traded: security, safety, compliance, privacy, the people doing the work. Pass or fail. A breach stops the loop.

Strategy sits above, sets the objectives, the envelopes and the guardrails, and reads the record. That closes the loop.

Two rules. Every judgment call names its expected outcome. Every number has an owner who explains it when it moves. One boundary. Guardrails are never traded.

It's an operating system in the sense that EOS is one: the parts interlock, and the same two rules run at every pace, so the daily, the per-bet, the monthly and the budget-cycle loops are one system rather than four meetings.

It isn't where the work gets done. Discovery, design and delivery are loops of their own, with their own tools. ProductOps is the hub they hook into: observations in, actions dispatched, results read back. The first line of AI is task completion. This is the line above it: deciding what to do, why, and whether it worked.

What's new, and what isn't

The parts are old. Deming asked for the prediction before the change. Toyota gave anyone the cord. Bungay gave us the back-brief. Cagan and Perri gave us products over projects. Wickman showed that an operating system has to be simple enough to run.

What's new is what they're assembled for. Every management system before this one was built for a world where people did the execution and the judgment stayed in their heads. They recorded the work and left the opinions in the room. ProductOps records the opinions: the weights, the expectations, the reasons, the calls. That record is a context engine: the context other leaders and, now, AI agents can run on. It's the bet the whole system rests on.

Software engineering is moving from writing code to building the loops that write it. Leadership is about to make the same move: from making every call to designing the loop that makes, records and checks the calls. The judgment stays the leader's. The system is what carries it.

AI inside

AI proposes. Leaders decide. Every decision teaches the system.

Today, in my practice, AI reads the record. It drafts the summaries, builds reports on demand, proposes improvements, flags risks, and suggests project ideas from what users are doing, and nothing becomes real until a person confirms it. In one product, an agent reads the context, digs into user behavior, logs and alerts, anchored in the weighted KPIs, and proposes five to ten things worth doing each cycle. We decline most. Some become bets. What we did with each proposal stays in the record, so the next run starts smarter. What stays human is the judgment: weights, explanations, settling a commitment, starting or stopping a bet.

Where it goes: every number carries its story, and so does every product, team and portfolio. As that record grows, an agent can learn from a leader's decisions and begin to operate a product, and later a portfolio, reporting up to a real leader and deciding the way they would, with every call visible in the same record. Ownership stays with the person. Agents earn autonomy one kind of action at a time, by a logged decision, never by drift. The record is what makes that possible, and it belongs only to the organization that wrote it. Models will get better and cheaper for everyone. The record won't.

Where to start

You don't need software. Take the list of everything you've funded right now and, beside each item, write the one number it's meant to move, which direction, roughly how much, and by when. Put one name beside it. When it finishes, look at the number on the date you wrote, and write one sentence on why it did or didn't move.

That's it. It takes an afternoon. If you can't write the line for an item, that's the finding.

Second habit, when you're ready: when a number goes red, its owner writes two sentences on why, within days.

Those two habits are most of the value.

What it's for

Adapting. Everything on this page will be rebuilt: the models, the tools, the loops that hook in, probably the software I run it on. What shouldn't be rebuilt is the record of what we wanted and why. An operating system that keeps judgment in one place while everything around it changes is a strategy for evolving in the age of AI without losing the thread.

How sure I am

Not very, yet. I've run a version of this at the scale of a few portfolios, built as we went. What I'd say with some confidence: conversations changed from "did it ship" to "did it work"; leaders got context they couldn't get before without being in every room; autonomy and alignment went up together. The hardest part was never the software. It was the habit of writing the observation, and the honesty of setting weights everyone could see.

The system now measures itself, with two numbers: how fast a change gets explained, and how often a bet does what it promised. I've only started tracking them, and I'll publish them here.

What I'd like from you

If you've tried something like this, tell me what worked and what didn't. If you think it's two good ideas wearing one name, say so. Disagreement is the most useful kind.

Go deeper

The full white paper and fifteen playbooks, with worked examples at a 40-person firm and a 400-person technology org. Locked with a password; ask me for one.

Open the library

The series

Eighteen posts, one idea a week

Next up · 18 posts in all

  • 00The status meeting is the reportcoming soon
  • 01Judgment doesn't scale by itselfcoming soon
  • 02Autonomy or alignment is a false choicecoming soon
See all 18 posts

Wave 1 · Leaders first

  • 00The status meeting is the reportcoming soon
  • 01Judgment doesn't scale by itselfcoming soon
  • 02Autonomy or alignment is a false choicecoming soon

Wave 2 · What breaks

  • 03The product has a manager and no operatorcoming soon
  • 04A dashboard is not a loopcoming soon
  • 05The promise ends at approvalcoming soon

Wave 3 · Why now

  • 06Dollars move once a year. Focus moves every week.coming soon

Wave 4 · What it stands on

  • 07Everything here stands on older ideascoming soon

Wave 5 · The model

  • 08ProductOps on one pagecoming soon
  • 09Every judgment call names its outcomecoming soon
  • 10Weighting is leadership, written downcoming soon
  • 11Outcomes are weighted. Guardrails are not.coming soon
  • 12Machines flag. People respond.coming soon
  • 13A shipped project isn't a finished betcoming soon

Wave 6 · The owner

  • 14What the owner controls, and what they explaincoming soon

Wave 7 · AI inside

  • 15AI proposes. Leaders decide. Every decision teaches the system.coming soon
  • 16Agents earn autonomy the way people earn trustcoming soon

Wave 8 · The horizon

  • 17What I don't know yetcoming soon