The ambiguity trap

Contributor: Puja Kathuria

What is a technical product manager? It’s one of the most common titles in our industry today, yet it’s also one of the most confusing. When we add the word “technical” to the role, are we describing the person’s background? Are we describing the scope of the product? Or are we describing the level of detail we expect them to manage? There’s significant ambiguity; this creates a trap.

If we assume “technical” describes the person, we might hire a former developer who struggles with strategy. If we assume it describes the product, we might silo them away from the business.

This problem isn't limited to individual contributors. We’re seeing this exact same "taxonomy trap" play out at the organizational level. Enterprises are currently in a frantic race to label their infrastructure, trying to force complex ecosystems into boxes labeled “business platform,” “data platform” or “engineering platform.”

Just like the confusing job title, these labels create false binaries that distort expectations, block funding and obscure value.

This is the taxonomy trap; when we use titles and categories as shortcuts for thinking, we stop defining outcomes and instead argue about labels often after expectations, funding and accountability have already been set.

False binaries lead to distorted expectations

Labels create ambiguity when their domain isn’t clear.

In the rush to organize, we often assume that if a platform is technical it cannot be strategic. Or if it is business-focused, it cannot be engineering-led.

• The engineering platform trap: When we label something an engineering platform, stakeholders often perceive it as a cost center, a playground for developers that is necessary but "non-strategic." This leads to funding gaps and a lack of executive buy in.

• The business platform trap: Conversely, a business platform is sometimes viewed as non-technical. This signals to engineering talent that this isn't a place for rigorous architectural standards, leading to shadow IT, fragility and adoption barriers.

We are reducing multidimensional capabilities into a single, flat dimension. We are obscuring the true cross-boundary nature of a modern digital business.

DORA and the shift to interactions

We need to stop defining platforms by what they contain (e.g., data, code, business logic) and start defining them by how they behave. Platforms should be defined and labeled by the interactions they enable between teams, not by the assets or components they happen to contain.

The recent DORA State of AI Assisted Software Development report highlights a critical shift in thinking. It suggests platforms shouldn’t be viewed merely as static assets, but as a series of interactions.

A platform is defined by the relationship between the team providing a capability and the team consuming it.

When we look at it through this lens, the lazy labels fall apart.

• If a data Platform is difficult to consume, it fails regardless of how good the data is.

• If an engineering platform requires high cognitive load to operate, it fails regardless of how powerful the tools are.

In each case, the platform isn’t failing by accident; it’s being executed in line with the expectations its label creates.

Real success isn’t about the category; it’s about the interaction. Is the platform designed as a self-service interface? A collaborative partnership? An AI-assisted facilitator?

Define the capability, not the category

Labels without context harm more than they help. The core issue is not whether something is “technical” or “business,” but whether its purpose, scope and value are clearly articulated.

To escape the ambiguity trap, we must define our platforms by capabilities and outcomes.

Instead of debating whether to call it a business platform or a technical platform, focus on the platform’s purpose. A useful label communicates who participates, how value flows and what outcomes the platform enables. Consider starting with the core interactions:

Core interactions: How services or offerings flow through the platform’s interface between participants. Is it a one-way push, a multi-way exchange, or a collaborative system? This flow is the core formula for value creation, delivery, and consumption.

Compensate & exchange value: What benefit does each participant gain from the platform? Understanding value clarifies whether the platform is meeting its purpose.

Connect participants: Who is involved and in what role?

Producers & owners: Provide the capabilities, control IP and governance

Consumers: Adopt the products or services

By evaluating a platform along these dimensions, a label becomes meaningful: it signals purpose, not just category. A business platform label should hint at the participants, interactions and value it orchestrates. A data platform label should communicate how data flows, who benefits and how the platform scales. When alignment is absent, labels become meaningless words, hollow signposts that hide expectations and misdirect execution.

Conclusion

In practice, this is how a technical product manager operates. They navigate a constant battlefield of interactions: engineering constraints versus business urgency, platform teams versus product teams, long-term architecture versus short-term delivery. Their effectiveness isn’t defined by how “technical” they are, but by how well they design, orchestrate and optimize these interactions. Like a platform, a technical product manager succeeds when they reduce cognitive load, clarify intent and turn friction into flow.

A platform, like a role, is defined not by its label but by how it behaves: the interactions it enables, the value it delivers and the outcomes it drives. Labels matter only when they accurately describe that behavior. Undefined interactions create misalignment between people and ghost towns in platforms.

Stop debating names. Start designing interactions that reflect purpose.

For a deeper dive into how transactions drive value-generating network effects, see my colleague Puja's article on "Platformability."

If you’re interested in my broader thinking on platforms, I’ve also written a Thoughtworks Insights article, “Building an AI first platform strategy,” which you can check out here.