TBM 382: Product-Centricity When You Don't Sell A Digital Product

I have been thinking a lot about the struggles of non-digital-product-selling companies when it comes to adopting more product-centric ways of working.

This post is a series of increasingly longer, distinct concepts that build on each other.

Proximity & Feedback Loops

The closer an investment is to a core economic driver (revenue or cost), and the shorter the feedback loop between action and outcome, the easier it is to understand, justify, and manage ROI.

Confidence Horizon

Longer-term capital patience, fast feedback, and sustained customer traction (and revenue growth) extend the horizon of confidence. It’s easier to commit long-term when you can afford to, customers are staying, and early signals are strong.

Software Product Companies

Companies that sell software products tend to have a leg up in how technology investments are perceived, because customers are literally buying the output of those investments. Companies where technology primarily enables other exchanges of goods and services often struggle to trace those investments to returns, unless the work is closely tied to core economic drivers or produces immediate feedback.

Define, Build, and Run

The idea that you can define a need, fund a project to deliver a system, launch it, and then run it as cheaply as possible is heavily ingrained. It shaped how companies planned, budgeted, and organized around technology for decades. It is only relatively recently (a bit longer ago for pure digital product companies) that organizations have begun to view technology as something that evolves continuously and shapes the business itself, rather than something delivered once and operated at minimal cost.

Two interwoven forces drove that shift: competitive pressure to keep adapting software, and the rise of tools and infrastructure that made updating, hosting, and running software dramatically easier.

Agile

Agile introduced shorter feedback loops and more adaptive ways of working, but it didn’t necessarily change the underlying funding or ownership model. You could easily imagine an “agile team” jumping between projects or balancing delivery and run responsibilities. There’s nothing inherently product-centric about agile itself; without structural and financial alignment, it can simply make project-based work faster and less risky, not fundamentally different.

Translation Layer

A popular dynamic today is the adoption of newer models and ways of working by technology organizations, such as the product operating model, continuous discovery, outcome orientation, more stable teams, the “you build it, you run it” approach, alignment around value streams, and the rise of platform and enabling teams. They have done this out of necessity to remain competitive and to meet increasing demands from the rest of the business.

But the core governance model often remains rooted in traditional strategic portfolio management, with funding still organized around projects and programs. This mismatch has given rise to an entire translation layer inside many companies, converting the language of projects and programs on one side into the language of modern product development models on the other. “But we fund teams!” they say, while conveniently leaving out “to work on projects.”

Flow

From around 2008 onwards, as people tried to “scale agile”, there was a surge of focus on “flow” and how to improve throughput and scale delivery across complex organizations. Many companies made real gains by visualizing work, limiting WIP, and improving coordination, but they also discovered an upper limit.

You can only optimize so much inside a company held together by deep dependencies. Eventually, you reach a local maximum where further improvement requires structural change, such as decoupling, stronger platform foundations, and rethinking where teams intersect. Flow frameworks can expose these dependencies, create justification for addressing them, and help teams optimize around their existence, but they do not remove them.

Contextual Fit

Digital product companies don’t provide a fully credible or contextual model for how most large, non-digital-product-selling enterprises should operate. They face different kinds of complexity (primarily technical and scaling challenges rather than deep organizational and legacy complexity). They also tend to sell fewer products, serve fewer segments, and operate much closer to the money, with shorter feedback loops and simpler dependencies.

And the ones that do start to look like large enterprises, with multiple product lines, shared platforms, and global operations, run into many of the same problems: misaligned incentives, an explosion of dependencies, and the slow gravitational pull back toward project thinking.

This is why many catchphrases, such as ‘projects to products,’ ‘ outputs to outcomes,’ and the transformation to a product operating model, tend to fall flat. The average modern enterprise that doesn’t sell digital products is a far more complex ecosystem. It requires more refined sense-making and modeling, as well as a more deliberate effort to link investments to returns, and deeper platform and service design thinking.

The slogans make it sound simple, but the reality is messier and demands a much more nuanced operating model. This isn’t an excuse for why these shifts can’t happen in larger or more complex organizations, but rather a reminder that they must truly put the principles into practice.

The Opportunity

The opportunity is not to simplify complex, non-digital-product organizations. You can’t just rename every product owner to a product manager, paint by numbers with triads and continuous discovery, and call everything a product or every team a product team. It is also untenable to keep the translation game going forever. Something has to give.

The real opportunity lies in embracing a more networked, ecosystem-based approach fully. You have to accept that multiple motions will operate at once. Customer journeys will intersect with operational value streams, which are supported by diverse collaboration streams. You must view the organization through multiple lenses—intent, collaboration, architecture, value chain, capabilities, and product teams—and be able to transition seamlessly between them.

When it comes to funding, you have to accept two truths: first, you fund teams, and second, people need to understand how that funding flows across intent, collaboration, and outcomes. The work is not about simplifying the system, but about designing the connective tissue that enables complex organizations to act with coherence.

We see this opportunity first-hand at Dotwork, my day job. Companies often come in wanting to simplify around a strategy pyramid or a single model. However, it turns out that the real opportunity lies in mapping the different frames and perspectives and being able to navigate between them to gain insights.