Skip to main content

Command Palette

Search for a command to run...

Trade-offs I've seen teams ignore

Updated
2 min readView as Markdown
A
I lead the strategy and delivery of products and systems that solve real problems, support commercial goals and scale across teams and markets. My work spans platform foundations, user-facing experiences, commercial tools and developer products, and I adapt my approach to the needs of each domain. My experience covers early-stage, scale-up and enterprise product environments, combining hands-on delivery with team leadership and award-winning work recognised across several innovative organisations.

Most product decisions involve trade-offs.

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.

More from this blog

L

Leverage Points - Product & Tech

45 posts

Insights on product strategy, platform thinking, and career decisions that create disproportionate impact. For PMs who want to understand where effort matters most.