The case for the enabling engineer

Prologue

We use the same words everywhere. Product. Product Manager. Agile. Engineer. And we pretend they mean the same thing everywhere. They don't. And with AI in the mix, that's about to cost us money.

This is a case for forward-deployed engineering: craftsmanship to the front line, close to the customer and the business. But who you push forward, and with which control layer, depends on one question almost no one asks out loud: what is your real product?

Along the way I ask a few more. Which world are you in? Are you building the product, or something that makes the product possible? Where is your brake, now that building has become so cheap? And who steers the engineer when the Product Owner has no mandate?

That last one I'm chasing myself. The Product Owner without a mandate was always mostly a translator, and you solve that translation two ways: you automate it, or you catch it with training. I'm going after both; and what I build, I build in the open, because a control layer you can't inspect is not control.

What is your real product?

"We want to become a tech company with a banking license." That's how ING once framed its ambition, years ago. A lovely sentence. And a category error.

ING is a bank. The technology has merely become essential, so essential that it feels like the core. But your customer doesn't pay for the software. He pays for a mortgage, a checking account, trust with his money. The software makes that possible. Brilliant, maybe. But it's the means, not the product.

A tech company with a banking license? No. A bank whose IT has merely become indispensable.

Sounds like word play. It isn't. This difference literally decides how you organize, who makes which call, and soon how AI redraws your roles.

Take Picnic. One of the most technology-driven companies in the country: algorithms, route optimization, a slick app. And still you don't pay Picnic for software. You pay for groceries, on your doorstep tomorrow morning. The Product Manager there works on the app and the routing, and by doing so contributes to one thing: those groceries, on time, at your door. The software is essential. It is not the product.

Put that Product Manager next to a Product Manager at a SaaS company. Same job title. Same ceremonies. Same language. And still not the same role. One serves the groceries; the other serves a product that is itself the point. Same word, opposite gravity.

• THE TEST‍
• What does your customer actually pay for? For the thing you build, or for something else that your build merely makes possible? That answer decides which world you live in. And it's almost never said out loud.

This isn't a new idea. Strategists know it as core versus context. What's new is what AI does with it: it makes getting this distinction wrong suddenly expensive. Because everyone already feels it. An experienced Product Manager knows full well that Picnic is something other than a software house, but we never gave it words. So we slap one playbook onto the other world, and wonder why it grinds. Time to give that split a name.

The divide

Out of that one question fall two worlds. From the outside they look identical: teams, sprints, backlogs. But they serve a different purpose. And that changes everything that follows.

World one: IT is the product. Accounting software, Slack, a simple site that turns your pdf into Word. What you build is exactly what you sell. Nothing sits between your code and the value to the customer. The software is not a means; it is the end.

World two: IT serves the primary process. Groceries, cars, banking, insurance, logistics. Here IT, however advanced, serves. Essential, often decisive for who wins. But in service of a product that lies outside the IT.

The line is sharp, with one rare exception. Sometimes a serving component tips over and becomes a product in its own right. The Volkswagen Golf's platform also sits under the Audi and the Å koda: what was an internal component has become a reusable platform, with its own roadmap and its own customers. But note: that's the exception, not the rule. Picnic's software serves the primary process, groceries at your door, and stays enabling. Until the day Picnic sells its routing engine to Albert Heijn. Then, and only then, does it cross over into world one.

That Product Manager at Picnic isn't doing it wrong. He rightly serves the groceries, unless Picnic sells the routing to Albert Heijn.

Until now the confusion didn't matter much. The two worlds could borrow each other's language without much harm; you slapped "Product Manager" and "agile" onto everything and it worked well enough. So why be sharp about it now? Because AI is about to redefine what each world needs. And whoever doesn't know which world he's in will copy the wrong playbook. Faster than ever.

AI puts the seam under pressure

Roles broaden. That's the first thing AI does to an organization: someone can suddenly handle work that used to take three job titles. Sounds like a win. It is. But it happens in two directions, and it goes wrong in one place, in both.

The engineer gets pulled forward. With AI beside him he sees more of the business, translates a customer question faster, works closer to the front line. This is the move the industry has started calling "forward-deployed."

And the Product Owner gets pushed toward building. That same AI suddenly lets him "build it himself": a prototype, a script, a whole feature, spoken to an agent. The mirror image of the first move. It already exists, and it feels like magic.

Take the accounting software I built with AI recently. Weeks of work, and not because of the code; that was done in no time. The time went into truly understanding. Ask an AI for "a balance sheet" and you get a balance sheet. But the difference between a trial balance and a tax balance sheet? If you don't tell it, it builds the wrong one: confident, tidy, and wrong. The code wasn't the bottleneck. My domain knowledge was.

Cheap doesn't mean good. "Made in China" once stood for junk; today top quality comes from there, but only if you ask for it explicitly, and know what you're asking. It's the same with AI execution. It's cheap and fast, and it can be excellent, provided you ask the right question. And asking that question is the work. That's the craftsmanship.

That craftsmanship comes in two forms, and here's where it often goes wrong. Pull an engineer forward and he brings technical craft, but he has to learn what makes the business valuable. Push a Product Owner toward building and he knows the value, but he has to learn the architecture. Both moves are forward-deployment. Both are safe as long as the missing control layer comes along: through a framework, good review cycles and tools an expert set up, or simply through training. And both are dangerous without it.

The danger is never the direction you push someone forward. The danger is pushing forward without the control layer that their world demands.

And so the real question isn't "engineer or Product Owner?" but: who owns the judgment over value, the role itself, or the business around it? That answer differs per world.

Skills, not headcount

Forget the job titles for a moment. Look at what they really are: bundles of skills we've crammed into one person for convenience.

Product manager, engineer, UX designer, tester, business analyst, architect, SRE, data scientist. Every one a collection of skills. And if you needed more skills, you used to have exactly one lever: more people. One head per skill. Scaling was hiring.

AI flips that lever. AI supplies the execution: it types the code, writes the tests, fills the table, draws the first version. Hands are no longer scarce. Whoever leans on the old reflex and hires more people to go faster is buying the wrong thing.

Because, and this is the whole joke, "AI supplies the execution" also means "AI does exactly what you say." Cheap, but not free, and certainly not automatically good. You need someone who knows what to ask, and who can see whether the answer holds up. The scarcity shifts from doing to directing and judging: architecture, craft, domain knowledge.

You no longer scale with people who do the work, but with a single person who directs a swarm of agents, and sees when that swarm marches the wrong way.

Here's what I mean by that swarm: one human keeps the judgment, the agents do the execution. That's the new unit of productivity. And it holds in both worlds: the same money that used to go to ten pairs of hands now goes to a handful of people with judgment plus the agents they direct. The question at the board table shifts with it. No longer "how many people per skill?" but "which judgment sits where, and what does it steer?" And that judgment lives in a different place in the two worlds.

Use case 1: the product world

In the world where IT is the product, something counterintuitive happens. The old fear, "product will end up under engineering," reverses. Product doesn't go under engineering. Engineering comes into product.

Makes sense, too. If the execution is done by agents, "engineer" is no longer a separate department to hand work to. It's a skill the product people get in their own hands. Product Management doesn't disappear here; it stays the core. It just gains a leg, and splits along a simple axis: time.

The Product Manager becomes the Product Engineer, and builds tomorrow. Here strategic and technical product management merge with engineering. This role discovers and builds what isn't there yet: the next product, the next breakthrough. Opportunity and architecture in one head.

Operations runs today. Here product marketing, operations and engineering merge: build and run. Not because those things are the same, but because one person with agents can now oversee them. This role keeps the existing product healthy for existing customers: improve, adjust, keep it running, keep it growing.

Here the role owns the judgment over value: there is no business to do that for you; the product is the business. And that's exactly why this world is symmetrically demanding. Come from product, and you have to build real engineering skills, or get a framework and guardrails that catch what you lack. Come from engineering, and you have to learn the whole product-management repertoire.

That repertoire is no mystery. There's a well-known chart that lays out all the tasks of product management in blocks, along one axis: from strategy on the left to execution on the right. Nobody owns the discipline, but it's a smart depiction, and a fine dissecting knife. On the strategy side the blocks about tomorrow: market problems, win/loss analysis, market definition, positioning, the product roadmap, buyer and user personas. On the execution side the ones about today: requirements, launch plan, sales process, collateral, readiness, support. Lay that chart next to the two roles and you see roughly which block flows where: the strategic, market-facing side to the Product Engineer; the execution and run side to Operations.

So the all-rounder pressure here is real, but manageable. It becomes two broad roles, not one impossible one. And the goal is never "everyone does everything." The goal is judgment plus craft, carried by agents, with the missing leg explicitly built in.

Use case 2: the enabling world

The enabling world flips that around. The judgment over value here lies not in the role but in the business. I build software for a grocery service or a financial product; it's not my product. The problem comes from there: "the cookies need to be smaller, faster, cheaper. Solve it."

The executing role is the Enabling Engineer. And mind that name, because the industry is moving toward a different term, "Forward-Deployed Engineer," and it misses the mark. "Forward-deployed" describes where someone stands: forward, close to the front line. But the Product Engineer from the previous part also stands forward. Position doesn't tell the two apart. What separates them is their purpose: one delivers product, the other enables. So name him after what he does.

"Forward-deployed" names the logistics, not the purpose. One stands forward to deliver product; the other to enable.

And yes, this piece carries exactly that word. No sloppiness. As a job title for one role, "forward-deployed" doesn't work; as a name for the movement, craftsmanship forward in both worlds, it works just fine. I'll come back to it in the close.

Thanks to AI that Enabling Engineer has become lightning-fast, and he speaks more and more the language of the business. And that's exactly where a new problem appears. If IT is no longer the brake, where is the brake then?

The brake shifts to the business itself. The people who deliver groceries or invest money can't decide and articulate as fast as engineering can now build. The friction is no longer between wish and technology. It sits between the business and its own ability to say, and to decide, what it wants.

Note what does not happen here: Product Management doesn't disappear. On the contrary: it stays the core role on the seam between business and engineering. What disappears is the mandate-less middleman, the proxy Product Owner. And that's no new discomfort. Scrum.org has described the proxy Product Owner for years as an anti-pattern: "a bottleneck¦ as they do not have any decision making authority." SAFe places the Product Owner in the team, as part of a larger Product Management function, so the mandate sits higher. And especially in regulated sectors, banking and insurance, the decision lies elsewhere anyway: with risk, compliance, the business. In a survey of 26 transforming organizations (Wolpers, 2026) exactly one thing fundamentally changed: how it was decided what gets built; the decision system stayed where it was. So the problem isn't new. What's new is that you can now do something about it.

The Product Manager stays, with mandate, on the seam, and now steers the Enabling Engineer through a specify layer: partly tooling (think of the specify part of modern agent frameworks), partly training, that captures business intent in a spec the engineer builds from. The mandate-less pass-through role removed; the translation automated or taught.

The business owns and decides, the Product Manager weighs and prioritizes, the specify layer translates to the engineer. No one feigning ownership they don't have. Exactly what the proxy Product Owner always did do.

Forward

This is the case, in one sentence: push craftsmanship to the front line, but know first what your real product is, because that decides which control layer has to come along.

Do that, and the rest follows. In the product world the Product Manager becomes the Product Engineer, and engineering folds into product and ops, split across tomorrow and today. In the enabling world the Product Manager stays, on the seam with the business, and steers the Enabling Engineer through a specify layer or through training. Product Management disappears in neither; it only changes shape.

Both roles are forward-deployed. That's the heart of this case: not one new job title, but a movement. Craftsmanship forward, with the control layer each world demands. Don't fake that breadth. A Product Owner who builds via AI without understanding the architecture feels productive and stacks up debt. An engineer who comes forward without learning the business builds the wrong thing, flawlessly. No romance about handwork, just how you keep your grip when execution gets cheap.

Speed was never the point. Grip is the point. The brake is no longer the technology; it's the business having to keep up with how cheap building has become.

The honest follow-up question. And then? I'm not going to sell you a tidy Monday-morning plan; I don't have one myself yet. What I do have are the questions that belong on the table:

• Which world are you in? Per product line, not per company. Is this the product, or something that makes the product possible?
• Where is your new brake? If IT no longer brakes, who does? And do you dare admit it's the business itself?
• Are you pulling craftsmanship forward, or faking breadth? Are you building the missing leg in, through a framework, tools, or training, or hoping it works out on its own?
• Who bridges the gap to the business, and do you do it with tooling, with training, or both?

That last one occupies me most. The translation the mandate-less proxy always was can be both automated and taught, and I'm going to work on both. What I build, I build in the open. A control layer you can't inspect is not control, but a new black box. Exactly what you want to avoid with AI. An open, shared specify layer is a better road than a sealed product. A follow-up will be about that.

For now only one test counts. Did you recognize the pain? Did the ING ambition, the Product Manager at Picnic, my accounting software that built the wrong balance, feel like something you'd long seen but never named? If the answer is yes, then this isn't theory. Then it's a name for something real, and there's work to be done.

‍

_{This is a case and a stance, meant to test whether the distinction resonates and whether the pain is recognized. Companies and products named serve as illustration, not as case study or recommendation. The Product Owner's limited mandate is broadly documented (among others Scrum.org and SAFe; data from Wolpers' 2026 survey).}

_{Connects to the adoption model From Handwork to Agents: that model is deliberately abstract; this piece makes it concrete with the question of your real product.}

‍

‍

‍

‍