Two entirely different assets are being funded from one budget line and judged against one set of measures. The mismatch is not an accounting inconvenience; it is why one of them will be starved and the other mispriced.
Somewhere in most enterprises there is a paper headed AI investment, containing a total, a set of initiatives and a benefit statement. Read the initiatives closely and they divide, without exception, into two kinds: things that go inside what the organisation sells, and things that change how the organisation designs, builds, plans or tests.
Those are not variants of one investment. They have different owners, different cost behaviour, different liability, different measures of success and different ways of failing. Managed as one category, the predictable result is that each set of measures is applied to the wrong asset, and both suffer in opposite directions.
The question for the leadership team is therefore blunt. For each line in that paper: which one is it, who owns it, and does the measure attached to it match?
The Strategic Context
An embedded feature is capability inside the offering. A customer experiences it, whether or not they can name it. It belongs to the product owner or business line carrying the profit and loss. Its economics are unit economics: a cost recurring with every use, against a price, inside a margin. Its risk is external and attributable — when it fails, a customer is affected, an obligation may be engaged, and the failure has your name on it.
A development tool is capability inside the enterprise. No customer experiences it. It belongs to engineering, research, operations or planning. Its economics are cycle time, cost per experiment and the value of the options it makes available. Its risk is internal, and its characteristic failure is invisible: a decision made faster from a narrower set of possibilities, which looks exactly like progress.
The distinction is not about technology; the same technique appears on both sides of the line. It is about where the capability sits relative to the boundary of the transaction, and that boundary determines everything that follows — who is accountable, which budget it comes from, how success is evidenced and what happens when it goes wrong.
The Cross-Wiring
The common failure is not misclassification. It is classifying correctly and then measuring across the line.
A tool measured like a feature. The organisation asks its internal capability to demonstrate revenue attribution. It cannot: nothing it touches reaches a customer directly, and everything it influences has a dozen other causes. Either the tool is defunded as unproven, or someone produces an attribution model that satisfies the finance review and is, in substance, a construction. The second outcome is worse, because the enterprise now believes something.
A feature measured like a tool. Engineering velocity is reported, model performance is reported, adoption inside the build team is reported. Nobody has established whether a customer will pay more, stay longer, or choose you because of it, and nobody has priced the recurring cost of running it against the margin of the product it sits in. The feature ships, is well engineered, and quietly reduces contribution per unit.
The marginal-cost fallacy. A per-use cost is dismissed because it is small. But a variable cost inside a fixed price is not a rounding item; it changes the shape of the margin, and it scales with success. The better the feature performs, the more it is used and the more it costs — a structure that penalises the outcome the business case promised.
The assumption that internal means safe. A tool carries no customer-facing liability, which is not the same as carrying no risk. Its failure mode is a well-supported choice drawn from a narrower field than the organisation believes it searched, and no incident report is ever written about that.
Reframing the Issue: Two Assets on Two Clocks
The clearer frame is a balance-sheet one. The embedded feature is an asset in the product. The development tool is an asset in the enterprise's capacity to produce products at all. Both are real, both consume the same scarce engineering people, and their returns arrive on different clocks.
The feature's return is dated and attributable: a release, a price, a cohort, a renewal. The tool's return is diffuse, and shows up as an option the organisation was able to exercise — a design it could evaluate, a failure it caught before commitment, a market it could enter because the work fitted the window.
A portfolio that cannot tell them apart will over-fund the one with a dated return, because that is the one that survives a quarterly review. This is not a failure of discipline but the consequence of applying a single evidentiary standard to two assets with different evidence available. The correction is to give them different funding routes and different tests, not to argue harder for the tool inside a process built for the feature.
The Cost That Arrives With the Customer
Embedded capability changes the cost structure of the product, and the change is easiest to see when usage is not controlled by you.
Consider, hypothetically, a facilities maintenance provider that embeds an automated diagnostic into its service agreements, priced as a flat annual fee per site. Each run carries a small computing cost. Light users remain profitable. Heavy users — the ones the sales team is proudest of — now consume the margin, and the more valuable the feature proves, the faster they consume it. The enterprise has, without deciding to, written an uncapped option to its own customers.
Three commercial questions follow, none of them technical.
Is it bundled or metered? Bundling is a pricing decision with a cost consequence, taken by whoever owns the margin, having seen the cost curve at plausible usage rather than expected usage.
Who bears the cost of a wrong answer? Embedded capability that advises the customer creates an expectation; one that acts on the customer's behalf creates something more consequential. What the feature is permitted to decide, within what bounds, is a governance question in its own right and should not be settled inside a product backlog [Related article: What Has Your Enterprise Already Authorised a Machine to Decide?].
Do you control the route by which the feature reaches the buyer? If the offering is distributed through a channel or platform you do not own, your pricing latitude is constrained by an intermediary's terms, and the economics are only partly yours to set [Related article: Do You Own Your Route to the Customer, or Rent It?].
The Return That Has No Invoice
Internal tools are justified almost universally on speed. Speed is the weakest half of the case.
Compressing a step produces value only where that step constrains throughput. The point is old and well established — it is the core of the theory of constraints set out by Eliyahu Goldratt — and it is routinely ignored when the tool is new and impressive. If design iteration is not what holds your development cycle, halving it buys a faster wait for whatever does: a certification queue, a supplier lead time, a single approver, a test rig. The first question about any development tool is which constraint it relieves, and the honest answer is often none, yet.
The stronger half of the case is the option set. A tool that lets an organisation evaluate possibilities it could not previously afford to evaluate changes what gets considered, not merely how fast. That demands a different measure: not the throughput of options, but the proportion of the plausible field examined, and how often a candidate that would not otherwise have been assessed survived to selection.
It also carries the failure mode that makes internal tools deceptively risky. Systems built on what has been done tend to return the centre of what has been done. An engineering office, hypothetically, adopts one and finds its designers producing three times as many candidate designs, all clustered nearer the historical mean than the smaller set they generated before. Every measure improves; the exploration has narrowed. Nothing in the reporting will reveal it, because volume rose — which is why a tool needs a diversity measure beside its productivity measure, and someone senior enough to ask why the interesting proposals stopped appearing.
When One Becomes the Other
The most expensive governance failure in this area is not misclassification at the start. It is a reclassification that nobody re-approved.
An internal tool proves useful. A customer sees a demonstration and wants it. The organisation, flattered, agrees — and in that moment the asset acquires a different cost structure and risk profile: support obligations, availability commitments, security review, documentation, a liability position, and a data-provenance question internal use never had to answer. None of it was in the original case, because the original case was for a tool.
The reverse crossing is quieter and equally mismanaged. A capability built for the product turns out to be more valuable inside the business, and continues to be measured on customer metrics it will never influence.
The instrument is simple: classification is recorded in the funding decision, and any change of classification requires fresh approval by the same authority, with a new cost model and a new owner. A capability that crossed without that re-approval is being run by whoever happened to be holding it, on measures designed for something else. Whether it is fit to deploy at all is a separate test, and the bar differs by side — a tool can ship at a lower standard because its errors are recoverable inside the building, while a feature cannot [Related article: When Is a Model Good Enough to Deploy — and What Shelves It?].
Decision Framework
| Embedded feature | Development tool | |
|---|---|---|
| Owner | The product owner or business line carrying the profit and loss | The engineering, research or operations leader who owns the process |
| Funding route | Product investment, against price and volume | Capability or research investment, against option value |
| Unit of economics | Cost per use, against price, inside contribution margin | Cost per experiment, and cycle time on the binding constraint |
| Primary measure | Willingness to pay, retention, margin per unit, cost to serve | Share of the option field examined, and decisions changed by it |
| Characteristic failure | Margin erosion that grows with adoption; customer-facing incident | Faster convergence on a narrower set; a constraint relieved that never bound |
| Kill condition | Contribution per unit falls below threshold at realistic usage | The constraint moves, or the option set demonstrably narrows |
| Liability | External and attributable | Internal, and rarely recorded |
Three questions classify anything in the portfolio. Does a customer's use of it consume our cost? Would a customer notice if it were switched off tomorrow? Is it named, described or implied in something we have sold? Two affirmatives and it is a feature, whatever the funding paper calls it.
From Strategy to Execution
Immediately, take the current investment paper, classify every line, and check the measures attached to each. Expect several mismatches, and at least one internal capability being asked for revenue attribution it cannot honestly produce. Reassigning that measure is a same-week decision that costs nothing.
Within two or three quarters, separate the funding routes so each asset is judged on evidence it can generate. Build a per-use cost model for anything embedded before it ships, tested at heavy-user volumes rather than average ones, and put the result in front of the person who owns the margin. Give every internal tool a named constraint it is meant to relieve, and measure whether that constraint moved.
Over years, the durable capability is moving an asset across the boundary deliberately: taking an internal tool to market with a re-approval, a proper cost structure and an accountable owner, or withdrawing a feature and keeping its value internally. Enterprises that can do this hold a real option in both directions. Those that cannot keep discovering the crossing after it has happened, usually in a customer conversation, usually with the wrong person in the room.
Signals to Monitor
- Gross margin drifting down in a product with embedded capability as adoption rises — the earliest reliable evidence that the unit cost was never modelled.
- Usage concentration, where a few customers account for most of the recurring cost.
- A tool asked for revenue attribution, or producing it.
- High tool adoption with no movement in end-to-end cycle time, which indicates the relieved step was not the constraint.
- Convergence in design proposals — more options, less variety.
- Internal capability demonstrated to customers without a recorded change of classification.
- Supplier price changes for underlying services, which alter the unit economics of every embedded feature at once and arrive as an invoice rather than a decision.
Questions for the Leadership Team
- For each line in our AI investment, is it a feature or a tool — and does its measure match?
- What does our most-used embedded capability cost per use, and what is contribution margin at the usage of our ten heaviest customers?
- Which constraint was each internal tool bought to relieve, and did that constraint move?
- What have we promised customers, explicitly or by implication, about capability embedded in what we sell?
- Which internal capability is closest to being sold externally, and who would re-approve it as a product?
- If a supplier doubled the price of an underlying service, which of our products would stop being profitable?
Closing Perspective
The two assets are easy to tell apart once someone asks. What makes the confusion persistent is that the language flatters it: one word covers both, one paper funds both, one executive sponsors both, and nobody experiences the moment the category error is committed.
The cost of leaving it unexamined is asymmetric and it compounds. The tool, judged on evidence it cannot produce, is defunded or fabricates its case — and what is lost is not a productivity increment but the organisation's capacity to consider what it currently cannot. The feature, judged on engineering quality rather than unit economics, ships into a margin nobody modelled and becomes more expensive precisely as it succeeds.
One question separates them, and it belongs on every line before the money moves: does a customer's use of this consume our cost? An enterprise that answers honestly, line by line, will find it has been running two portfolios all along — and only one was ever managed.
About the author
Kevin Jogin is Founder & Principal Advisor at EraNorth. Meet the Founder.