Systems thinking: What PMs can learn from urban planning

Product managers and urban planners rarely appear in the same conversation. One develops software, the other plans cities. One works in sprints, while the other works over decades.

However, at their core, both jobs seek to tackle the same problem: designing systems that people can use, depend on, and keep using as needs evolve.

Urban planners build environments that must scale, adapt, and remain viable long after the original designers have left. Product managers confront a similar challenge: creating solutions that can withstand growth, evolving user behavior, organizational change, and technical limits.

By borrowing urban planners’ mental models, you can make better long-term decisions, avoid common scaling errors, and create products that seem holistic rather than chaotic as they develop.

In this article, we’ll look at some of these mental models that product managers can apply to make better long-term decisions and products.

Why product managers need systems thinking

A lot of product problems look like feature problems at first, but they’re really system problems.

Your team sees an onboarding drop-off and adds another tooltip. Sales pushes for more flexibility, so you add another setting. Retention stalls, so the roadmap picks up another engagement feature.

This is how products end up bloated, inconsistent, and difficult to navigate. It’s also how teams create hidden operational costs for engineering, support, design, and go-to-market teams.

Systems thinking helps you zoom out.

Instead of asking, “Should we build this?” it asks bigger questions like: How does this affect the rest of the product? What dependencies does it create? What new behaviors will it encourage? What will it make harder later?

Urban planners work this way by default. They know that one road can change traffic flow, land use, safety, and economic activity.

Product decisions work the same way. One feature can change user expectations, support burden, data complexity, and the shape of the roadmap that follows.

Design the product as a system, not a set of features

One of the most common PM mistakes is treating each request as a standalone problem.

A customer asks for a feature. A stakeholder pushes for a workflow tweak. A team sees a gap in the funnel and adds another surface.

---

---

The work gets done, but the product starts to sprawl. Soon your navigation gets messier, patterns become inconsistent, and teams build exceptions they later have to support forever.

Urban planners avoid this by thinking about the whole environment, not just the individual asset.

As a product manager, you need the same mindset. Strong PMs look at how users move through the product, where data flows across experiences, where friction compounds, and which decisions are starting to conflict with each other.

In practice, this often means asking whether a proposed feature strengthens the system or just adds another layer to it. A feature can look valuable on its own and still make the overall product worse. It may increase cognitive load, duplicate an existing pattern, or create edge cases in other workflows.

This is also why behavior matters more than stated preference alone. Urban planners don’t rely only on public meetings. They observe traffic flow, footpaths, and how people actually use a space.

PMs should do the same with analytics, support tickets, workarounds, drop-offs, and repeated actions. What users do often tells you more than what they say.

Balance short-term wins with long-term product health

Most product teams are under pressure to deliver short-term results. That pressure is real. Teams are measured on velocity, growth, launches, and visible progress.

The problem starts when those short-term incentives become the only decision criteria.

Urban planners know that early shortcuts can create long-term problems. Weak infrastructure, poor zoning, and bad traffic assumptions don’t stay small for long.

Product decisions behave the same way. A shortcut in permissions, a weak data model, or a rushed workaround may help the team move faster today, but it can create major costs later.

This is also where teams need better judgment on what can be fixed later and what cannot. Some issues are easy to clean up, but others are not. Trust violations, brittle architecture, fragmented UX patterns, and broken governance models usually get more expensive as the product scales.

Metrics matter here too. If you only measure growth, you’ll keep optimizing for growth, even when the product becomes harder to use or support. Long-term product health needs a broader view. That can include reliability, support load, quality of experience, adaptability, and user trust, not just DAUs, retention, and revenue.

Build strong foundations before growth exposes the cracks

When building cities, urban planners start with the infrastructure that makes that experience possible.

PMs should work the same way. But in product teams, infrastructure work is often harder to defend because stakeholders don’t see it as easily as a new feature or redesign. That is why PMs are often pushed to prioritize visible output over foundational work.

In practice, though, APIs, data models, permissions systems, internal tools, and platform reliability often determine whether a product can scale smoothly or not. A better UI cannot compensate for bad data, slow systems, fragile integrations, or workflows held together by manual operations.

This becomes especially clear as the product grows. A workflow that works for 100 users may fall apart at 100,000.

Support volume rises. Performance drops. Power users stretch the product in ways the original design never anticipated. Enterprise customers introduce complexity the early product model did not account for.

That’s why planning for scale matters before scale arrives. It’s also why incremental change is usually safer than big-bang transformation.

Cities evolve through phased development, pilot programs, and gradual upgrades. Product teams benefit from the same approach through feature flags, structured rollouts, iterative UX updates, and progressive modernization.

Use constraints and tradeoffs to make better product decisions

PMs often talk about constraints as if they’re interruptions. You hear engineering capacity, compliance requirements, legacy systems, legal reviews, organizational politics, and budget limits framed as things standing in the way of the ideal solution.

But constraints are part of the design problem.

Urban planners work within geography, funding, regulation, existing infrastructure, and politics from the start. They don’t pretend those forces are separate from the work.

In practice, constraints often improve decision-making. They force prioritization, reduce over-engineering, and push teams toward simpler and more durable solutions.

Compliance requirements can lead to better data design. Technical limits can expose unnecessary complexity. Organizational realities can force a more realistic path to change.

The same logic applies to stakeholders. Product work always involves competing priorities.

Users want simplicity. Sales wants flexibility. Engineering wants maintainability. Leadership wants growth. Legal wants safety. Support wants fewer exceptions.

Your job isn’t to make everyone equally happy.

This is where many products lose coherence. Teams keep approving exceptions to satisfy one stakeholder at a time. Over time, the product becomes harder to use and harder to build on.

Strong PMs avoid that trap by making the tradeoff explicit, explaining the rationale, and staying consistent about what the product is trying to become.

Design for edge cases before they become mainstream

It’s easy for teams to design around the average user. It’s harder, but more valuable, to design for the edges of the system too.

---

---

Urban planners know that cities need to work for more than the dominant user. They also need to work for children, older adults, people with disabilities, and people whose needs don’t fit the default model. Designing only for the average case creates exclusion and weakens the overall system.

Products face the same risk. Teams often deprioritize accessibility, internationalization, minority workflows, or power-user needs because those cases look smaller in the short term. But many of those “edge cases” become much more important as the product expands into new segments, markets, and use cases.

A common PM mistake is to assume that designing for the majority automatically serves everyone else well enough. In reality, ignoring edge cases often creates friction that shows up later as adoption problems, support burden, churn, or expensive redesign work.

The upside is that inclusive design usually helps more people than expected. Accessibility improvements often improve usability overall. Better support for non-ideal workflows can make the system more adaptable. Internationalization can open growth opportunities that the team didn’t initially prioritize.

Final thoughts

Thinking in terms of urban planning is useful for PMs because it shifts your attention away from isolated features and toward the larger system those features shape over time.

Instead of chasing features, product managers that adopt this perspective start building environments. They think in systems, respect limitations, prioritize foundations over speed, and prepare for scalability.

The best products, like the best cities, aren’t defined by how much gets added. They’re defined by how well the whole system holds together as it grows.

Featured image source: IconScout