Prefer listening over reading? 🎧 Listen (AI-Generated Audio Version)
Cheap to Start, Expensive to Own
For years I have described my approach in two sentences.
Strategy without delivery is fiction. Delivery without strategy is just expensive activity.
Recently I am noticing that the second part no longer holds as written. Delivery without strategy used to be expensive, but AI made it cheap and that turned out to be worse.
In a previous post I argued that AI makes building faster but does not make deciding easier. Since then I have come to think that undersold the problem: it doesn’t make owning any cheaper either.
Cheap to start
When building took months, a weak strategy failed loudly and early and most of the times friction was doing strategy’s job for it. For example, you could not staff the work, the business case did not survive or someone said no because they had to.
That friction is now disappearing. A product team or a business user with the right tools, can now stand up an automation, an AI agent or a dashboard in an afternoon. Each one is reasonable and it looks like progress. Thus, now a weak strategy fails one “sensible” prototype at a time.
Expensive to own
However, everything cheap to start still has to be maintained, secured, supported and reconciled with the other cheap things across the organisation that overlap with it. In many cases, prototypes quietly become production without anyone deciding they should. So, the bill for delivery does not vanish, it just moves.
One can think of it as:
Starting is a decision you make once. Owning is a decision you keep making.
Strategy changes shape
Strategy must change to support and guide this fast and cheap delivery. If starting is nearly free, a three-year plan is the wrong place for most of the product decisions that matter. Long-horizon plans still do real work, such as justifying funding, building skills and setting direction. But they cannot govern a stream of work that arrives faster than any plan can be revised.
What has worked well for me so far is a small set of rules, published in advance, that teams can apply without asking permission. For example:
- What we say no to
- What evidence moves an experiment into a supported product
- When something gets retired
So the product roadmap tells us where we are heading, while the rules tell us what survives on the way.
It is important to clarify that rules are not approval gates. A rule is explicit, public and cheap to apply. A gate needs a committee and if it takes a meeting to interpret a rule, it is just a slower plan.
What this looks like in practice
A real example I have worked on is on the platform side, where one product decision shaped many others:
AI agents are a user of the platform in their own right, with their own needs, not a feature bolted onto interfaces designed for people.
The rule that follows is that every platform capability is accessible to agents by default.
The matching “no” is about manual interfaces and dashboards. We do not build fixed ones by default. For example, we expose the data to agents first and build skills on top that help teams find what they need and generate the views they want. A fixed interface gets built when self-serve use shows a stable, repeated need or when a regulatory requirement demands one.
So, the effort is shifting from building manual interfaces towards standardising data and making it accurate.
What is still hard
However, this has uncovered new challenges. Consistent definitions are the part I am least settled on. For example, when people build their own views, you risk ten dashboards with ten meanings of “revenue”. Encoding definitions in the skills agents use helps, but a skill steers an agent, it does not enforce anything.
The real answer lives in the data layer and that is where the effort is going.
My new line
Strategy without delivery is still fiction, but delivery without strategy is cheap to start and expensive to own.
I believe that strategy is becoming less of a document that precedes the work and more a decision system that governs it.