Why 70% of Digital Value Is Lost Before Reaching Customers

According to McKinsey data cited by MIT Technology Review, organizations capture less than one third of the expected value from their digital investments. It's not a budget problem or a lack of technical talent: it's a direction problem. Most large companies start with available technological capabilities and build applications on top of them, rather than beginning with customer needs and working backwards to find the right technical solution.

The result is predictable: fragmented solutions, disconnected experiences, and AI projects that generate impressive demos in the lab but don't move any real business metrics.

The structural problem behind the numbers

When a company adopts a language model or deploys a conversational agent because "it's available" or because competitors have done it, the starting point is the tool. That inverts the logic: technology becomes the search for a problem to solve, rather than solving a specific, known one.

This pattern repeats especially in large corporate environments, where IT or innovation teams have early access to new capabilities—today, for example, a million-token context window or agents with access to external tools via MCP—but lack the mandate to articulate what customer pain justifies their deployment. The result is pilots that never scale.

The concept of customer-back engineering isn't new: Amazon has been practising it for decades with its "press release before writing code" methodology. What is relevant now is that the emergence of generative AI has amplified the problem. The speed at which new capabilities launch outpaces many organizations' ability to evaluate whether those capabilities solve something their customers actually need.

What changes when the order is right

The proposal outlined in the MIT Tech Review article is simple in theory and difficult in practice: first define the outcome the customer needs, then identify the most costly friction point in the path to that outcome, and only then select the technology that eliminates it most efficiently.

Applied to today's tool ecosystem, this can mean very different things depending on the case:

• A financial services firm wanting to reduce claims resolution time doesn't necessarily need an autonomous agent; it might need a Claude skill that retrieves customer history in seconds and drafts a response for the human agent to review.
• A development team wanting to accelerate code reviews doesn't start with "let's use Claude Code"; it starts by identifying which phase of the review cycle loses the most hours, then evaluates whether a PostToolUse hook or a specialized subagentu is the best-fit solution.

The difference isn't just philosophical: it determines whether the project generates measurable returns or becomes expensive infrastructure nobody uses consistently.

Who this approach matters to

This debate is especially relevant to three profiles: digital transformation leaders at mid-size and large companies justifying AI budgets to executives; product teams building on Claude APIs or deploying MCP servers who need to prioritize what to integrate first; and consultancies and systems integrators selling AI projects with perverse incentives to prioritize technical sophistication over demonstrable utility.

For all three, the McKinsey data should function as a calibrator: if the project they're building doesn't have a concrete customer problem at its origin—with a name, frequency, and measurable cost—the odds of landing in that 70% of value that evaporates are high.

Editorial view

The article doesn't introduce new methodology, but its timing is apt: the market is in a consolidation phase after initial enthusiasm, and many teams need to justify in business terms what has so far been sold as a strategic bet. That MIT Tech Review is giving space to this argument now says something about where the conversation is moving.