Everyone knows this.

The problem is that many trade-offs are quietly ignored rather than explicitly chosen.

Here are the trade-offs I see ignored most often:

Speed vs. clarity

Teams move quickly to ship, but defer decisions about ownership, standards, or long-term intent.

Speed is gained early, but clarity debt accumulates, "who owns this?", "what was this built for?", "can we change it?" and eventually slows everything down. The questions you avoided upfront become blockers downstream.

Flexibility vs. simplicity

APIs, platforms, and systems are designed to be highly flexible to accommodate future needs. In doing so, they become harder to understand and adopt.

I've seen APIs with 30 optional parameters that take weeks to integrate because teams need to understand every option, even the ones they'll never use. A simpler API with three required fields would have been adopted in days.

Flexibility is preserved, but usability suffers.

Local optimisation vs. system health

Teams optimise for their own roadmap, timelines, and metrics, often rationally. They choose the database that makes their work easiest, the API pattern that ships fastest, the integration approach that doesn't block them.

But without a system-level view, those local wins add up to global inefficiency. You get seven databases, four authentication systems, and integration work that requires custom code every time.

Autonomy vs. alignment

Autonomy feels empowering. Alignment feels restrictive. Teams want to choose their own tools, patterns, and approaches.

But at scale, alignment on core standards is what allows autonomy to persist without fragmentation. Without shared contracts, every team's independence becomes every other team's integration problem.

Short-term certainty vs. long-term leverage

It's tempting to choose options that feel safe and predictable now, the vendor everyone knows, the monolithic approach that's easier to reason about, the manual process that "just works", even if they limit future choices.

The cost of that decision rarely shows up immediately, which makes it easy to rationalise. By the time the constraints bite, you're too invested to change course.

The pattern I've noticed is that ignored trade-offs don't disappear.

They resurface later as:

• Slower delivery

• More coordination

• Harder decisions

• Rework and reversal of earlier decisions

The teams that scale well aren't the ones that avoid trade-offs.

They're the ones that make them explicit, name them, document them, revisit them when context changes.

Ignored trade-offs compound. Explicit ones can be managed.

Autonomy. Scalability. Faster delivery.

For many organisations, they deliver exactly that, at least initially.

What's discussed less is the cost side of that trade-off.

Microservices shift complexity; they don't remove it.

The complexity just moves from inside your codebase to between your teams.

From a product perspective, the dark side shows up gradually:

• Coordination replaces simplicity; what used to be a function call is now a cross-team negotiation

• Integration replaces implementation; you spend more time connecting things than building things

• Failure modes multiply quietly; every network call is a potential failure point

None of this is immediately visible on a roadmap.

I worked on a product where adding a new field to the user profile used to take one PR.

After microservices: the field needed to live in the user service, be exposed via the API gateway, consumed by the mobile app, synced to the analytics pipeline, and validated against the permissions service.

Same feature. Five teams. Three sprint cycles. Endless Slack threads about data contracts.

We'd gained team autonomy. We'd lost feature velocity. Both were true.

As services proliferate, product decisions become harder to reason about.

A small change; adding a filter, changing validation logic, updating a workflow, can span multiple teams, each with its own priorities, roadmap, and release cycle.

The PM work shifts from problem-solving to dependency management. You spend less time on "what should we build" and more time on "how do we coordinate building it."

Another issue is cognitive load.

Understanding the system becomes harder as boundaries increase. Context is fragmented across repositories, teams, and documentation.

New PMs take months to understand data flows. Debugging requires tribal knowledge. Simple questions, "why does checkout behave this way?", require archaeology across five services. The system becomes illegible to the people who need to change it.

This isn't an argument against microservices.

It's an argument against adopting them without recognising the product cost.

Microservices demand stronger discipline:

• Clear ownership: every service needs an accountable owner, not just a maintaining team

• Stable contracts: APIs can't change casually when dozens of services depend on them

• Intentional governance: someone needs to prevent the same logic from being reimplemented in fifteen places

Without those, autonomy turns into fragmentation. You get the coordination cost without the architectural benefit.

For PMs, the challenge is knowing when the benefits outweigh the coordination overhead and being honest when they no longer do.

Ask: Are teams actually moving faster? Or are we just coordinating more?

If most of your time is spent aligning services rather than delivering value, the architecture might be working against you.

The dark side isn't that microservices fail.

It's that they succeed in ways that make systems harder to change over time.

There maybe no single user journey. No conversion funnel. Success doesn't show up the day after launch.

That's why many platform teams default to proxy metrics; adoption, usage, number of integrations. Useful signals, but insufficient on their own.

For me, platform success is best defined by what becomes easier over time.

I look for a small set of outcome-oriented indicators.

First, downstream efficiency.

Are teams delivering faster with less coordination?

Are common problems solved once instead of repeatedly?

When the platform is working, integration time drops from days to hours. Teams stop rebuilding authentication. They spend less time on plumbing and more time on differentiated work.

Second, decision clarity.

Does the platform reduce ambiguity?

Are teams clearer on what's supported, how to integrate, and what patterns to follow?

Good platforms remove questions rather than generating tickets. When teams can get started without asking for help, clarity is working.

Third, system health.

Is the overall product surface becoming more consistent?

Are we reducing divergence, fragility, and bespoke implementations?

Healthy platforms improve the system even when no new features are shipped. The absence of problems is itself progress.

Fourth, trust.

Do teams feel confident building on the platform?

Are breaking changes rare, communicated clearly, and handled predictably?

Trust is often the earliest and strongest signal of long-term success. When teams build critical paths on your platform, they're voting with their risk tolerance.

In one platform I worked on, we tracked "questions per integration." Early on, it took 15-20 Slack messages for a team to get their first service connected. Six months later, it was down to 2-3, and those were usually about their specific use case, not our documentation.

We hadn't shipped major features. But decision clarity had improved. That showed up in velocity across every team using the platform.

Adoption still matters, but I treat it as a lagging indicator.

If teams choose the platform without being pushed, if they recommend it to other teams, if they build critical paths on it, value is already there. Voluntary adoption is the strongest signal.

Platform success isn't about how visible the work is.

It's about how much unnecessary work quietly disappears.

The best platforms reduce effort you never see.

Platform success isn’t about how visible the work is.

It’s about how much unnecessary work quietly disappears.

More teams onboarded. More services integrated. More usage across the organisation.

It looks like success. Often, it's a trap.

Adoption without value is just distribution.

When platform teams chase adoption, a few predictable behaviours emerge:

• Features are added to satisfy individual teams

• Standards are relaxed to reduce friction

• Short-term uptake is prioritised over long-term coherence

The result is a platform that's widely used but poorly trusted. Teams integrate because they have to, not because they want to. They build defensive layers. They work around limitations. The platform becomes plumbing they tolerate, not a tool they rely on.

I've seen a platform team celebrate reaching 50 service integrations. On paper, adoption was up 300% year-over-year.

But when we looked closer: teams were using only the basic features, building their own solutions for anything non-trivial, and routing around the platform whenever they hit complexity.

High adoption. Low trust. The platform wasn't creating leverage, it was creating compliance.

Value looks different.

Value shows up when the platform:

• Reduces duplicated effort

• Removes common failure modes

• Makes the right thing the easy thing

• Teams choose to build on it, not just because they have to

These outcomes are harder to measure and slower to materialise. But they're what actually compound.

Another issue with adoption-first thinking is incentive misalignment.

Platform teams are often evaluated on adoption metrics, teams onboarded, services integrated, API calls made. Not on whether those teams ship faster, fail less often, or trust the platform with critical paths.

That misalignment creates pressure to say yes to everything, even when "no" would preserve long-term value.

In my experience, the most successful platforms don't optimise for adoption directly.

They optimise for:

• Clarity: clear contracts, obvious patterns, no surprises

• Stability: changes are intentional, breaking changes are rare

• Leverage: small investments by the platform create large returns for consumers

Adoption follows when teams trust the foundation.

Interoperability sounds like a technical problem.

Make systems talk. Align schemas. Expose APIs.

At small scale, that framing works. At larger scale, it breaks down.

Interoperability at scale is less about connectivity and more about coordination.

The first shift in thinking is recognising that not all systems should integrate deeply.

Tight coupling increases speed early on, one team can directly read another's database, systems share state, changes propagate automatically.

But it raises the cost of change exponentially. At scale, you need permission to evolve. Interoperability needs to be selective, optimising for resilience and independence, not just convenience.

The second shift is around contracts.

Stable contracts matter more than flexible ones. When many teams depend on the same interfaces, predictability beats expressiveness.

A contract that changes monthly creates coordination overhead across every consumer. A contract that changes yearly, with clear versioning and deprecation, lets teams build with confidence.

Clear boundaries reduce the need for constant coordination.

I worked in an organisation where 30+ services all integrated with a "flexible" user service. It returned different fields based on which team asked. Each team got exactly what they needed.

When we tried to add a new field, we had to coordinate with 12 teams to understand if the change would break them. A simple schema update took months.

A stable contract, "here's what we return, period", would have been less flexible but infinitely more scalable. Flexibility at scale becomes fragility.

Another key consideration is ownership.

Interoperability fails when it sits between teams with misaligned incentives. One team optimises for their velocity, another for stability, the integration becomes a battleground.

Someone needs to own the relationship between systems, not just the code, and be accountable for how changes propagate, how failures are handled, and how evolution happens.

I also think about interoperability in terms of failure modes.

What happens when one system is slow, unavailable, or wrong?

At scale, those scenarios aren't edge cases, they're inevitable. Every dependency is a potential point of failure.

Designing for graceful degradation, cached fallbacks, circuit breakers, clear timeout strategies, matters more than perfect integration. The question isn't if it will fail, but how it fails.

Finally, I try to be honest about cost.

Interoperability creates long-term obligations. Every connection adds coordination overhead, testing complexity, and deployment dependencies.

At scale, fewer, better-defined integrations usually outperform many shallow ones. Five deep, stable integrations scale better than fifty fragile ones.

For me, interoperability isn't about making everything work together.

It's about making the system evolvable over time, where changes don't require permission from everyone, where failures are isolated, where teams can move independently.

Loose coupling scales. Clever integration doesn't.

A line item on the roadmap. Something to estimate, schedule, and move past once the "real" product work begins.

That's a mistake.

Integration costs are rarely just technical. They show up across time, teams, and decision-making, often long after the initial work is "done".

What PMs tend to underestimate isn't the first integration.

It's everything that follows:

• Aligning data models and assumptions

• Handling edge cases that don't fit clean abstractions

• Coordinating changes across teams with different priorities

• Debugging issues that span ownership boundaries

Each individual cost looks manageable in isolation. Three days here, a week there. The cumulative cost, measured in months and coordination overhead, isn't.

I once scoped an integration between our checkout system and a new payment provider at "two sprints."

The technical work took two sprints. But we spent another month after that:

• Reconciling how we defined "refund" versus how they did

• Handling partial payments that our data model didn't account for

• Coordinating testing across three teams with conflicting release cycles

• Debugging failures that only appeared in production under load

The integration worked. But it cost 3x what we'd planned and created ongoing coordination overhead we hadn't budgeted for.

Another issue is optimism bias.

Integrations are often scoped based on how the system should work, not how it actually does. Legacy constraints, undocumented behaviour, and partial ownership only surface once teams are deep into implementation.

By then, the scope has doubled but the timeline hasn't.

Integration also carries an ongoing tax.

Once systems are connected, they move together. Changes require coordination. Failures propagate. Teams inherit dependencies they didn't explicitly choose.

A "simple" schema change on one side now requires migration planning, backward compatibility, and synchronised deployments. The integration becomes a shared constraint.

That tax rarely appears in the original business case. The ROI calculation assumes the integration is "done" once it ships. The real cost is measured in years, not sprints.

In my experience, the PMs who manage integration well do a few things differently:

• They surface assumptions early

• They budget time for coordination, not just build

• They treat integration as a product decision, not a delivery task

• They question whether the integration is necessary at all

Integrations can create enormous leverage.

But only when their true cost is understood and intentionally paid.

The first integration is cheap. The second is where you pay.

Reuse is often treated as a technical problem.

Build the right abstraction. Create a shared service. Publish an API.

Then wait for teams to use it.

In practice, reuse is mostly an organisational challenge.

The first requirement is aligned incentives.

If teams are rewarded for shipping locally and quickly, reuse will always lose to bespoke solutions. Even when a shared option exists, the short-term cost of integration often outweighs the long-term benefit.

Reuse only works when teams aren't penalised for choosing the common path. Better yet, when choosing it makes them faster.

The second requirement is ownership.

Shared components need clear owners who are accountable for:

• Quality and stability

• Consumer support

• Evolution over time

• Saying no to use cases that don't fit

Without ownership, reuse becomes fragile. Teams lose confidence, and workarounds creep back in.

The third requirement is trust.

Teams won't reuse something they don't trust to remain stable. Predictable change, clear contracts, and honest communication matter more than feature completeness.

Trust takes time to build, but collapses instantly. One unannounced breaking change, one poorly communicated deprecation, one "just deploy and we'll fix issues as they come up", and teams start hedging their bets again.

Another requirement is timing.

Reuse works best after a pattern has emerged naturally, when two or three teams have solved the problem independently, and the commonalities become clear.

Trying to enforce reuse too early often freezes assumptions before they're well understood. You end up reusing the wrong abstraction.

Finally, reuse needs constraints.

Paradoxically, the more flexible a shared solution tries to be, the harder it is to reuse.

Every option becomes a decision. Every configuration becomes cognitive load. Teams spend more time understanding what's possible than building what they need.

I worked with a team that built a "flexible" notification service. It could send emails, SMS, push notifications, webhooks. It had templating, scheduling, retry logic, delivery tracking.

Teams took weeks to integrate because they had to understand every option, even the ones they'd never use.

A simpler service, "we send transactional emails, here's the three required fields", would have been adopted faster. Flexibility felt like a feature. It was actually friction.

Clear boundaries, "we support these three patterns well", make adoption easier. Constraints clarify intent.

In my experience, successful reuse isn't mandated. It's made obvious.

The best path is clearly documented. Integration is faster than building. Support is responsive. Changes are predictable. The decision to reuse becomes trivial.

Reuse follows trust, not mandates.

It promises efficiency, consistency, and scale, everything platform teams are under pressure to deliver.

In practice, it rarely works as intended.

The main issue isn't technical. It's contextual.

Different teams operate under different constraints:

• Varying performance requirements

• Different regulatory or market needs

• Uneven maturity and delivery pressure

• Different definitions of "done" and quality thresholds

A single solution that perfectly fits all contexts is rare. When teams are forced into it, they either resist or quietly work around it.

I've seen a shared authentication service built to serve "all teams." It was designed for the needs of the most regulated product line, comprehensive audit trails, complex session management, multi-factor flows.

For teams building internal tools, it was massive overkill. Integration took weeks. Simple use cases required workarounds. Teams started building their own lightweight auth rather than use the "reusable" solution.

The platform team saw resistance. The consuming teams saw bloat. Both were right.

Another problem is timing.

Reusable solutions require stability. But reuse is often pushed early, when only one or two teams have used it, when the problem is still being understood, when edge cases haven't surfaced yet.

The result is a shared solution that locks in assumptions too soon, then becomes painful to evolve because "breaking changes" affect everyone.

There's also an ownership challenge.

When something is built "for everyone," it's often owned by no one in particular. The team that built it moves on. The teams using it can't change it.

Decisions become slower, changes become riskier, and accountability blurs. Everyone depends on it. No one can fix it.

Reuse works best when it's earned, not mandated.

In my experience, effective reuse emerges when:

• A problem repeats across teams in a consistent way (not just similar-looking)

• The solution has stabilised through real use (not theoretical design)

• There's clear ownership and support (someone accountable for consumer experience)

• Teams choose it because it's better, not because they're told to

At that point, reuse becomes the natural choice, not a mandate.

The failure of "build once, reuse everywhere" isn't a failure of ambition.

It's a reminder that leverage comes from understanding variation, not ignoring it.

Reuse is an outcome, not a strategy.

Most API maturity models are too detailed to be useful.

They look good in presentations, but they're hard to apply in real organisations where APIs evolve unevenly and constraints are real.

The model I use is intentionally simple. It focuses less on technology and more on behaviour and ownership.

Level 1: APIs as plumbing

APIs exist to unblock delivery.

They're built quickly, owned loosely, and changed freely. Documentation is minimal, and consumers adapt as needed.

This stage is often necessary early on. The risk is staying here too long.

Key signal: APIs optimise for the producing team, not the consumer.

Level 2: APIs as shared assets

APIs are recognised as reusable.

Standards are emerging but inconsistently applied. Documentation exists but varies in quality. Teams are aware of downstream impact but still break things under deadline pressure.

This is where many organisations stall.

Key signal: Teams want reuse, but still optimise locally under pressure.

Level 3: APIs as products

APIs have clear ownership.

Consumers are understood. Contracts are explicit. Changes are versioned intentionally. Success is measured by adoption quality, not just uptime.

This is where real leverage starts to appear. Teams stop building defensive layers. Integration time drops. Confidence increases.

Key signal: Teams trust the API and build on it confidently.

Level 4: APIs as platforms

APIs shape how the organisation builds.

Standards are enforced, not just recommended. Governance is lightweight but real. Platform decisions remove entire classes of problems—teams don't need to think about auth, data validation, or observability because the platform handles it consistently.

APIs become an enabler of strategy, not just delivery.

Key signal: Teams spend less time solving the same problems repeatedly.

The value of this model isn't the labels, it's the conversations it enables.

You can ask:

• Where are we actually operating today?

• Where does rigour matter most right now?

• What behaviours need to change to move up a level?

• What's preventing us from moving to the next level?

I've seen organisations that believed they were at Level 3 because they had API documentation and versioning. But when we looked at behaviour, teams still building workarounds, changes causing surprise breakage, no one measuring adoption quality, they were operating at Level 2.

The documentation existed. The product discipline didn't.

Most organisations don't need to be at Level 4 everywhere.

But knowing where you are, and why, makes API decisions far more intentional.

Maturity is about behaviour, not technology.

The biggest risk is thinking you're more mature than you are.

Far fewer have an API product strategy.

The difference matters more than the words suggest.

On paper, the language is familiar: standardisation, reuse, platform thinking. In practice, the strategy often stalls at the technical layer and never fully matures into something the organisation can execute against.

The gap usually shows up between intent and behaviour.

Teams are encouraged to build APIs, but:

• Ownership is fragmented

• Standards are optional or inconsistently applied

• Success is measured by APIs built, not problems solved

• Reuse is hoped for, not designed for

This creates a pattern where APIs exist, but leverage doesn't.

I've seen organisations with 40+ internal APIs, many overlapping in functionality. Teams built what they needed when they needed it. The strategy doc said "reuse and standardization," but there was no mechanism to enforce it, and no one empowered to say "we already have an API for that."

Another sign of immaturity is how change is handled.

Early-stage API strategies optimise for speed. That makes sense initially. But many organisations never graduate from this phase.

APIs remain easy to change long after they become widely depended on. What worked when three teams used an endpoint becomes dangerous when fifteen do, but the governance doesn't evolve to match.

Mature API strategies make a deliberate shift:

• From flexibility to stability (fewer changes, more confidence)

• From team-level convenience to system-level trust (what's best for the whole, not the part)

• From building APIs to managing them (lifecycle, deprecation, evolution)

That shift is less about technology and more about governance, incentives, and accountability.

The hardest part is that maturity requires saying no.

Not every use case should be supported. Not every pattern should be allowed. Not every team should build their own version.

Without these boundaries, APIs accumulate complexity faster than value, and the strategy becomes a collection of one-offs pretending to be a platform.

In my experience, the maturity gap persists because closing it forces uncomfortable conversations:

Who owns this? What standards are non-negotiable? What's the long-term cost of flexibility?

Those conversations feel expensive in the short term. But the alternative, fragmented APIs, duplicated effort, and coordination overhead, is far more expensive. You just pay for it gradually, invisibly, across every team.

APIs don't scale on intent alone.

Maturity shows up in what you're willing to constrain.

On paper, internal users should be easier. They're accessible, aligned to the same company goals, and more forgiving than external customers.

In reality, the dynamics are often more complex.

The first lesson is that internal consumers still have incentives.

They're optimizing for their own delivery speed, reliability, and success metrics, not for the health of the platform they depend on. When your system slows them down, they'll work around it. That's rational, not hostile.

The second lesson is that proximity can mask systemic pain.

Because internal consumers can message you directly, individual issues feel manageable. But that accessibility often hides the real cost: repeated questions, one-off fixes, undocumented assumptions, and workarounds that multiply silently across teams.

What feels like good support is often just band-aids hiding a broken experience.

Another lesson is that empathy must be paired with boundaries.

Treating internal teams as customers doesn't mean saying yes to everything. It means being clear about what's supported, what isn't, and why. Ambiguous flexibility feels generous but creates more friction than clear constraints.

In one case, internal teams kept requesting custom endpoints for edge cases. Each request felt reasonable in isolation. But we had 15 variations of similar functionality.

The shift was saying: "We support these three patterns well. If your use case doesn't fit, let's talk about whether it should become a fourth pattern or if there's a different approach."

Clear boundaries, not infinite flexibility, made the platform more useful.

The most effective shift I've seen is treating internal consumption as a product relationship:

• Clear contracts

• Predictable change processes

• Feedback loops that go beyond anecdotes

When internal consumers trust the platform, they stop hedging. They build with confidence. That's when reuse actually happens.

Working with internal consumers taught me that internal doesn't mean informal.

It means the cost of getting it wrong is paid repeatedly, by people who can't opt out.

Clarity isn't rigidity, it's the best form of support you can offer.

They're "just for us", easier to change, faster to iterate, more forgiving when they break.

External APIs, by contrast, get the full product treatment: documentation, versioning, deprecation policies.

That logic is backwards.

Internal APIs deserve more rigour, not less.

The reason is scale.

Internal APIs are used by multiple teams, often in ways that aren't centrally visible. An authentication API might power checkout, account settings, admin tools, and three mobile apps, each interpreting "session timeout" slightly differently.

A small change can ripple across products, services, and delivery timelines, quietly and repeatedly.

When internal APIs lack rigour, a few things happen:

• Breaking changes are discovered late

• Teams build defensive layers and workarounds

• Coordination costs rise without anyone owning them

• Teams duplicate logic rather than risk depending on unstable APIs

Unlike external APIs, internal consumers can't simply leave. They're trapped inside the system. They can't switch vendors, can't choose alternatives, can't even complain publicly.

That captive relationship makes poor experience more costly, not less.

Another difference is trust.

External APIs have explicit contracts because the cost of breaking them is obvious, customers leave, support tickets spike, reputation suffers.

Internal APIs often rely on informal trust: "Just ping me if something breaks." That trust erodes quickly when changes are unpredictable. And unlike external customers, internal teams can't leave, they just build around you.

Over time, what was meant to create leverage becomes a source of fragmentation.

Rigour doesn't mean bureaucracy.

It means being explicit about:

• Contracts and expectations

• Backward compatibility

• How and when change happens

In my experience, the most effective internal APIs are boring by design. They change slowly, communicate clearly, and remove uncertainty for the teams that depend on them.

Boring isn't a failure of ambition. It's a feature that enables speed everywhere else.

That stability is what allows the rest of the organisation to move faster.

The hardest APIs to change are the ones everyone depends on.

Stability upstream creates speed downstream.

What I focus on now is less visible, but far more consequential.

First, problem clarity.

Before committing to a plan, I spend time making sure the problem is well understood, not just by me, but by everyone involved. Clear problem framing reduces rework and prevents teams from solving the wrong thing efficiently.

Second, decision quality.

I pay close attention to which decisions are being made, by whom, and with what assumptions. Good outcomes usually trace back to a small number of high-quality decisions made early.

Third, trade-offs.

I try to make trade-offs explicit rather than hiding them behind prioritisation language. Every roadmap implies a set of choices. Surfacing those choices early builds alignment and trust.

Fourth, outcome ownership.

I care less about whether the plan is followed and more about whether it achieves the intended effect. When reality diverges, I’m willing to revisit the plan, even if it’s uncomfortable.

Finally, leverage.

I look for work where a small amount of effort meaningfully improves how other teams operate. The best product work often makes future work easier.

A short example

In one role, multiple teams were pushing for roadmap space to solve similar problems in slightly different ways. Instead of negotiating sequencing, I stepped back. The real issue wasn't priority, it was that all teams were hitting the same data access bottleneck. I reframed the issue as a shared constraint rather than a backlog conflict.

That led to a single upstream decision that removed the constraint altogether. The roadmap changed as a result, but more importantly, several downstream teams no longer needed to compete for space in the first place.

No major launch. No big announcement.

But a lasting reduction in friction.

Roadmaps still matter. But they're tools in service of decisions, not the thing being optimized for

Plans are useful. Judgement is essential.

It signals autonomy, trust, and seniority. If you own the roadmap, you must be leading.

In practice, roadmaps are just artefacts.

They’re useful tools for communication and alignment, but they’re not where the real responsibility lies. Optimising for roadmap ownership can quietly shift focus away from what actually matters and turn your team to feature factory.

Owning a roadmap usually means:

• Curating initiatives

• Sequencing work

• Managing expectations

All important, but incomplete.

What roadmaps don’t own are outcomes.

They don’t guarantee that decisions are right, that trade-offs are explicit, or that the work will meaningfully change anything. A clean roadmap can coexist with weak judgement.

The real ambition shouldn’t be owning the roadmap.

It should be owning:

• The problem framing

• The trade-offs behind the sequencing

• The outcomes the roadmap is meant to drive

When things don’t go to plan, no one asks who owned the roadmap. They ask who made the decision, and whether it was the right one.

The more senior I’ve become, the less I care about who “owns” the roadmap and the more I care about who owns the consequences.

Ownership lives with decisions, not documents.

There’s no single outage. No obvious incident. Nothing that immediately demands executive attention.

Instead, it erodes growth quietly.

When DX is poor, teams still ship, just more slowly, more cautiously, and with more workarounds. Each individual delay looks small. Over time, the compound effect is significant.

Bad DX shows up as:

• Longer lead times for even simple changes

• Increased reliance on tribal knowledge

• Engineers avoiding shared systems because they’re unpredictable

None of this appears directly on a growth dashboard. But it changes how fast the organisation can respond to opportunity.

Growth depends on learning speed.

The faster a company can test, iterate, and adapt, the more likely it is to find what works. Bad DX slows that feedback loop. Experiments take longer. Changes feel riskier. Teams default to safer, incremental work.

Another hidden cost is inconsistency.

When teams work around poor DX in different ways, divergence creeps in:

• Slightly different implementations of the same concept

• Inconsistent behaviour across products

• Higher long-term maintenance cost

That inconsistency eventually becomes a growth ceiling.

The most damaging part is that bad DX is often normalised.

Teams adapt. They become productive despite the friction. But that adaptation masks the opportunity cost, what could have been built if the path were simpler.

In my experience, improving DX doesn’t create growth on its own.

But ignoring it quietly caps how much growth is possible.

DX debt compounds faster than feature debt.

Better tooling. Cleaner APIs. Better docs.

All important. All incomplete

The reason Developer Experience keeps resurfacing as a problem is that it’s rarely owned as a business outcome.

Poor DX doesn’t just frustrate engineers. It slows delivery, increases risk, and quietly taxes the organisation, every integration takes longer, every new feature hits the same friction, every team rebuilds similar solutions.

When DX is framed purely as an engineering issue, a few things tend to happen:

• Investment is reactive rather than intentional

• Trade-offs are made locally instead of systemically

• Improvements struggle to compete with feature work

None of that is surprising. Engineering teams are incentivised to ship features for users, not optimise the experience of building for other engineers. That's not wrong, it's just incomplete when no one owns the system-level view.

The moment DX becomes a business problem, the conversation changes.

Instead of asking, “How do we improve tooling?”, the questions become:

• Where are we losing time repeatedly?

• What friction shows up across multiple teams?

• What’s the cost of not fixing this?

Those questions create space for prioritisation, not just goodwill.

Another shift is accountability.

When DX is owned at a product or platform level, decisions about standards, abstractions, and constraints become deliberate. The goal shifts from 'make everything possible' to 'make the common path easy and the exceptions explicit.

In my experience, the best DX work is almost invisible.

It shows up as:

• Fewer exceptions

• More predictable delivery

• Teams spending less time on plumbing and more on value

That’s not an engineering win alone.

That’s a business one.

In one organisation, we measured that authentication setup took new services 2-3 days. Not because it was technically hard, but because the process was undocumented and inconsistent. Standardising it to a single afternoon wasn't a feature launch, but it saved every new team 1-2 days from that point forward.

That's DX as a business outcome.

Good DX reduces costs you never see on a spreadsheet.

If building is hard, scaling is harder.

Actually productising one is harder, it forces clarity in places most organisations avoid

The biggest shift isn’t technical. It’s intentionality.

Productising an API starts with answering questions that infrastructure teams often don’t have to:

• Who is this API for?

• What problem is it solving for them?

• What does success look like from the consumer’s point of view?

• What should consumers not try to do with this API?

Without clear answers, APIs tend to grow by accretion. Endpoints get added to support one-off use cases, and complexity increases without anyone owning the experience.

Another key change is ownership.

A productised API has a clear owner who is accountable for:

• Consumer experience, not just uptime

• Backward compatibility and change management

• Trade-offs between flexibility and simplicity

• Saying no to use cases that don’t fit the product’s direction

This ownership makes decisions explicit instead of implicit.

Documentation also changes in nature.

Instead of describing what exists, good API docs explain:

• How the API is intended to be used

• Which patterns are supported (and which aren’t)

• How consumers should think about evolution over time

Equally important is feedback.

Productised APIs create feedback loops:

• Usage patterns are instrumented and analyzed, not assumed

• Pain points are surfaced early

• Changes are informed by real consumer behaviour

Finally, success metrics shift.

Availability is necessary, but insufficient. Product APIs are measured by:

• Adoption quality

• Ease of integration

• Reduction in workarounds downstream

Productising an API doesn't add ceremony, it removes friction. Done well, it's what allows many teams to move faster, consistently, without reinventing the same solutions."

Productising an API is about reducing cognitive load.

Almost no one treats them that way.

APIs are often built as technical artefacts rather than customer-facing products. They exist to unblock delivery, support integrations, or enable reuse, but they’re not managed with the same discipline as user-facing products.

When APIs aren’t treated as products, a few patterns show up quickly:

• Ownership is unclear or fragmented

• Success is measured by availability rather than usefulness

• Consumers are expected to adapt, rather than being supported

An example, multiple product teams depended on the same internal API to fetch core entity data. On paper, the API was stable and “highly available”.

In practice, each team used it slightly differently:

• Fields were interpreted inconsistently

• Edge cases were handled downstream

• Changes required coordination across multiple backlogs

No one owned the experience end to end. The API technically worked, but it slowed everyone down.

Once the API was treated explicitly as a product:

• A single owner was accountable for consumer experience

• Contracts were clarified and versioned intentionally

• Success was measured by adoption quality, not just uptime

The result: integration time dropped from days to hours. Teams stopped building workarounds. Changes that previously required cross-team coordination could be deployed with confidence.

Treating an API as a product didn’t add ceremony.

It added clarity.

APIs have users, even if they’re internal. They have journeys, pain points, and expectations, even if those users are engineers rather than end customers.

In my experience, the difference between an enabling API and a painful one rarely comes down to technology.

It comes down to whether it’s being treated as a product, or just infrastructure.

APIs fail quietly when no one owns the experience

Due to limited flexibility, product teams built workarounds to accommodate their workflows. We ended up with 5 different currency conversion endpoints.

This created a nightmare: reconciliation problems, treasury headaches, hours of repetitive work at month-end, not just for product teams, but for colleagues in finance as well.

The solution was enablement, not more enforcement.

We spun out a new payment microservice that teams could plug into. With that one piece of work, we eliminated 5 currency conversions, removed grunt work, and unblocked teams to be more productive.

The hidden advantage: the shared microservice let us proxy-enforce the framework without teams feeling constrained.

That experience changed how I think about leverage.

Before working on platforms, I thought leverage came from scope.

More users. Bigger products. Larger teams.

Platform work taught me leverage is something else entirely.

Leverage is about how many outcomes a single decision can influence, not how visible that decision is.

In feature work, impact tends to be linear. You ship something, it affects a specific user journey, then you move to the next problem.

In platform work, the relationship is exponential:

• One decision can unblock multiple teams

• A small improvement compounds across products

• The same constraint affects everyone until it's removed

The trade-off is visibility.

Platform work rarely has a clean launch moment. Success is measured in what doesn't happen:

• Fewer workarounds

• Less duplication

• Teams moving faster without noticing why

That can be uncomfortable, especially in organisations that reward shipping over system health.

Another lesson is that leverage often comes from saying no.

Not every request should be supported. Not every use case belongs on the platform. Strong enablement work creates clarity as much as capability.

The biggest shift for me was realising that leverage isn't about doing more work.

It's about doing the work that makes other work easier.

Once you see that, it's hard to unsee.

Leverage compounds quietly.

Platforms succeed when teams stop thinking about them.

They’re close to users, tightly scoped, and optimised for delivery. When they work well, they move quickly and ship tangible improvements.

So when strong PMs leave feature teams, it’s rarely because the work is beneath them.

It’s usually because the leverage changes.

Feature teams tend to optimise for local outcomes:

• Shipping features

• Improving a specific flow

• Moving a narrow set of metrics

At a certain point, strong PMs start to notice that the biggest constraints on impact sit outside the feature boundary:

• Platform limitations

• Organisational dependencies

• Inconsistent foundations across teams

No matter how well the feature performs, the ceiling remains.

Leaving feature teams is often about seeking work where:

• Decisions have longer time horizons

• Small changes unlock value for multiple teams

• Impact compounds rather than resets each quarter

This shift can feel counterintuitive. Platform, enablement, or system-level work is usually less visible. Success is indirect. Progress can look slow.

But for PMs optimising for leverage, that trade-off is worth it.

It’s not an indictment of feature teams. They’re essential.

It’s a recognition that as judgement matures, the problems worth solving often move upstream, closer to the system itself.

Feature teams optimise locally. Platforms optimise structurally.

Sometimes the biggest impact comes from stepping back.