If I were building a commercial engine from scratch today, I would not start with an org chart, and I would not start with a tool list. I would start with the loop.

Almost every commercial function I have seen was assembled the other way around. Someone got budget, hired roles, bought platforms, and the structure emerged from the accretion. The work got organised around who was hired and what was bought, not around what the engine is actually supposed to do. It runs, but nobody designed it, and it shows.

The better starting point is a single question: what makes the loop turn faster and truer. Design everything in service of that, and the team, the tools, and the org chart fall out as consequences rather than as the first decisions. This is how I would build it now, and the principles matter more than any particular tool I would name.

What the loop actually is

Strip a commercial engine down to first principles and it does four things, in a cycle. It finds the right people. It helps them decide. It closes. And it learns from what happened, so the next turn is a little better than the last.

That is the whole machine. Everything else is implementation detail: the channels are how you find people, the tools are how you help them decide and close, the headcount is who runs it. Those are real choices, but they are downstream. They are answers to the loop, not the loop itself.

The mistake nearly everyone makes is to build the implementation detail first. They buy the automation platform, hire the content person, stand up the ad accounts, and assume a working engine will emerge from having the parts. It does not. You get motion without a designed cycle, which is why so many commercial functions run hard and improve slowly. The loop is running, but nobody built it to turn truer over time, so it just turns.

How to build the engine

Principle one: instrument for truth before volume

The first thing I would build is not a campaign. It is the ability to know what actually works.

Most engines are built to produce first and measure later, which sounds pragmatic and is backwards. If you scale on bad measurement, all you have done is make the wrong thing bigger, faster, and more expensive to unwind. You end up with confident dashboards pointing at effort that may have caused nothing, and no way to tell the difference. The volume feels like progress and quietly buries the signal.

So the truth layer comes first. Before the engine scales, it needs a way to separate what it caused from what merely happened alongside it: the discipline to run a holdout on the decisions that matter, to withhold something and measure the gap, to treat a number as a claim until it has survived a real test. That layer is unglamorous and nobody is impressed by it, which is exactly why it gets skipped and exactly why building it first is an advantage. You cannot honestly scale what you cannot honestly measure.

Principle two: small and senior, with AI on the execution

I would not staff the old department shape. No separate seats for demand gen, content, ops and analytics, each with its own headcount, hired to carry a manual workload that no longer needs carrying.

Instead I would hire few people and senior ones, the kind who understand the whole loop rather than one slice of it, and I would put AI on the execution layer underneath them. The drafting, the assembling, the reporting, the routing, the repetitive production that used to eat a team: that is what the machine is good at, and handing it over is the point, not a compromise. What is left for the humans is the part that actually decides outcomes, which is choosing what to do and judging whether it worked.

The design goal is judgment density, not headcount. The constraint in a modern commercial engine is not how much you can produce, because production is becoming close to free. The constraint is how well you can choose what to produce, and that is a function of how much judgment per head you have, not how many heads. A small team of people who can see the whole loop, with AI doing the volume, beats a large team running the wrong things efficiently.

Principle three: one source of truth, held ruthlessly

The quiet killer of commercial engines is not a lack of data. It is data that disagrees with itself.

Five systems, each with its own definition of a lead, its own version of the funnel, its own number for the same quarter. Marketing cites one, sales cites another, finance has a third, and every pipeline review spends its first twenty minutes arguing about whose figure is real instead of deciding anything. That fragmentation does not announce itself; it accretes, one well-meaning tool at a time, until nobody trusts any number without caveating it.

So from the start I would be ruthless about one definition of the funnel and one place the numbers live. Every tool that comes in has to reconcile to that spine or it does not come in. This is boring, upfront discipline that feels slower than just buying the thing everyone wants, and it is the difference between an engine you can actually steer and one you are forever reconciling. Integration discipline paid at the start is a fraction of the cleanup cost paid later, and it is the foundation the truth layer sits on.

Principle four: build an owned asset, not only rented reach

Most commercial engines are built entirely on rented land. Ad platforms, social channels, search: all of it belongs to someone else, all of it can change its rules or its price overnight, and increasingly it sits between you and the customer and takes a cut of the value on the way through.

Rented reach is fine, and you will use plenty of it, especially early when you need flow now. But an engine built only on rented reach has no durability. The moment the channel economics turn or an answer layer intercepts the traffic, you are starting over. So alongside the rented reach, I would deliberately build something owned: a first-party audience that is actually yours, proprietary data nobody else has, an owned presence that becomes a source rather than a renter of attention.

The owned asset is slower to build and it compounds, which is the opposite profile of rented reach, and that is precisely why you want both. Rent the reach you need today. Build the asset that is still yours in five years, and still yours when the channel you depend on changes the deal.

Principle five: design the loop to learn, not just to run

Every version of the loop I described ends with the same step, and it is the step almost everyone drops: learn from what happened so the next turn is better.

It gets dropped because it is the least urgent thing in the building. There is always another campaign to ship, another quarter to chase, and the honest look back at why the last thing worked or failed is the easiest item to skip when nobody is asking for it. So teams run the loop a thousand times and barely improve, because they are repeating the cycle without ever closing it. Motion without learning is just a faster treadmill.

So I would build the learning in, not leave it to good intentions. A standing habit of the post-mortem on what died and why, feeding directly back into what the engine tries next. That is the mechanism by which the whole thing compounds: each turn deposits a pattern that makes the next decision sharper, and over enough cycles the engine is not just running, it is getting measurably better at choosing. An engine that learns pulls away from one that merely runs, slowly at first and then not slowly at all.

What it adds up to

Put the five together and the shape is clear. A small, senior team. One clean data spine everything reconciles to. AI doing the execution underneath. A measurement layer built for truth before volume. An owned asset growing alongside the rented reach. And a learning step wired into every turn of the loop.

That is not a leaner version of the old department. It is a different shape entirely: denser in judgment, truer in measurement, more owned than rented, and built to compound rather than just to run. You would struggle to draw it as a conventional org chart, because it was not designed as one.

I want to be honest about where I stand on this, because it matters more than the blueprint. This is how I would design it and what I am building toward, not a finished machine I am waving the receipts for. The principles are the argument, and they stand on reasoning: each one is the constructive answer to a failure mode I think is real. The proof is a separate thing, earned over time, and when I have it I will show the numbers rather than the design. Until then this is a thesis I will defend, offered as a blueprint, not a victory lap.

Most commercial engines are accidents of hiring. You got headcount, you drew an org chart around it, tools accreted in the gaps, and the thing that emerged is what you now call your go-to-market. It was never designed. It was staffed.

Designed from scratch today, with cheap execution and honest measurement available in a way they were not a few years ago, it looks almost nothing like that. The first question stops being what department you need and becomes what makes the loop turn faster and truer. Answer that one well, and the team, the tools and the structure arrange themselves around it. Start anywhere else, and you are decorating an accident.

Frequently asked

What is a commercial engine?

It is the system a company uses to turn attention into revenue, and then to get better at doing so. Stripped to first principles it runs a loop: find the right people, help them decide, close, and learn from what happened so the next turn improves. Channels, tools and headcount are how the loop is implemented, not the loop itself. A well-built engine is designed around that cycle; most are just assembled from whoever was hired and whatever was bought.

How do you build a lean commercial team?

Hire few, senior people who understand the whole loop rather than one slice, and put AI on the execution layer beneath them: drafting, assembling, reporting, routing. The design goal is judgment density, not headcount, because production is becoming cheap and the real constraint is choosing what to produce. A small team that can see the whole loop, with the machine doing the volume, outperforms a large team running the wrong things efficiently.

What should you build first in a go-to-market engine?

The ability to tell what actually works. Before scaling campaigns, build a measurement layer that separates what you caused from what merely happened alongside it, including the discipline to run holdouts on decisions that matter. Scaling on bad measurement just makes the wrong thing bigger. Pair that with one clean source of truth (a single definition of the funnel and one place the numbers live) so the whole engine reconciles to the same reality.