The classic PM triangle — business, technology, and user experience — is both a useful model and an enormous oversimplification. The real challenge isn't balancing three forces. It's managing a system where each force has a different time horizon, a different language, and a different definition of success.
The first time I was told I needed to "balance business, tech, and UX," I nodded. It sounded right. I drew the triangle in my notebook. I thought: yes, I will stand in the middle and balance these three things.
Six months later, I had learned something important: the triangle metaphor implies a static balance, as if you find the center point and stay there. The reality is that the center point shifts constantly, the three points of the triangle are in tension with each other in dynamic ways, and the PM's job is not to find the balance but to actively manage the tension.
That's a different job. And it requires a different mental model.
What Each Force Actually Cares About
Before you can manage the tension, you have to understand what each force is actually optimizing for. Not the stated goals — the real ones.
Business
The business is optimizing for: revenue, margin, market share, and retention — roughly in that order of immediacy. The business cares about the quarter. It cares about the deal that's at risk, the churn that's affecting the metrics, the competitor that just announced something. It operates on short and medium timescales and wants the product to generate visible results in both.
The business's pathology: short-termism. Without the counterweight of technology and UX perspectives, the business would build whatever closes deals right now, at the expense of what creates a defensible position over time. Left unchecked, this produces technical debt, user experience degradation, and a product that serves the sales team but not the users.
Technology
The engineering team is optimizing for: code quality, system reliability, developer experience, and long-term architectural integrity. Engineers think in systems. They care deeply about the way things are built, because they're the ones who have to maintain what's built and extend it over time. When a corner is cut, they live with the consequences.
Engineering's pathology: perfectionism and scope expansion. Without constraint, engineering would refactor indefinitely, over-engineer for scale you don't have yet, and struggle to ship because the system isn't ready. They're not wrong to care about these things — but left unconstrained, they create products that are beautifully architected and never shipped.
User Experience
The design and UX function is optimizing for: coherence, simplicity, and user delight. They care about how things feel, how they flow, and whether a user can accomplish what they're trying to accomplish without friction or confusion. Good UX practitioners are ferociously protective of the user's experience and often the most willing to push back on features that make the product more complex.
UX's pathology: idealism and scope creep in the other direction. The perfect solution for the user might require rebuilding half the product. A UX team without constraint will push for comprehensive redesigns when targeted improvements would serve users just as well. They're right about the direction; they're sometimes wrong about the timeline and the cost.
The PM's Real Job: Managing Competing Timescales
Here's what I've found to be the deepest truth about this tension: it's fundamentally a timescale problem.
Business concerns are immediate. Engineering concerns are medium-term. UX concerns are long-term. When you're making a product decision, you're implicitly choosing which timescale to prioritize.
Add that feature for the enterprise customer? Good for business now. Probably adds UX complexity. Might require engineering workarounds that create debt. You've prioritized the immediate timescale.
Invest in refactoring the authentication system? Good for engineering health. Neutral or negative for the business short-term. Might improve UX over time but users don't see it now. You've prioritized the medium timescale.
Redesign the onboarding flow? Great for user experience. Requires significant engineering effort. Business won't see the impact for 60-90 days after launch. You've prioritized the long timescale.
None of these choices is inherently right. The right choice depends on where you are in the product lifecycle, what's currently rate-limiting your growth, and what the team has capacity to execute well. The PM's job is to make these tradeoffs explicitly, with awareness of all three timescales, instead of defaulting to whichever voice is loudest.
Practical Techniques for Managing the Triangle
Make the tradeoffs explicit
The most powerful thing a PM can do when facing a tri-directional tension is to name it. Not just in their own head — out loud, in the room, with the relevant stakeholders. "If we build this the way sales is asking, we're accepting 3 months of technical debt and adding complexity to the onboarding flow. I want to make sure we're all making that choice intentionally." This kind of clarity is uncomfortable. It's also how you build a culture of deliberate decision-making instead of reactive one.
Create separate forums for each perspective
Mixing business, engineering, and UX concerns in the same meeting is a recipe for conflict. Create separate spaces where each perspective can be fully expressed without immediately colliding with the others. A weekly engineering sync where tech debt and architecture get discussed without business pressure. A separate session for UX review that isn't also a requirements meeting. A business review where metrics and commercial priorities get airtime without being immediately mediated by engineering constraints. Then bring the full picture together in a roadmap discussion where tradeoffs get made.
Know which force is currently being under-served
In healthy teams, the tension between these three forces is dynamic — sometimes you favor business, sometimes tech, sometimes UX, depending on what's been neglected. In unhealthy teams, one force is consistently under-served, and the others don't even notice. The symptoms: if UX is being ignored, your product gets harder to use over time. If engineering is being ignored, your system gets less reliable over time. If business is being ignored, you build features that don't generate value over time.
The PM's job is to notice which force is accumulating debt and to make a deliberate case for rebalancing. This is one of the most valuable things a PM can do, and it's almost never the thing PMs spend their time on.
Struggling with competing priorities?
I've spent nine years navigating business, tech, and UX tensions in real products at every stage. If your team is stuck in the middle of competing forces, let's talk about what's actually driving the conflict.
Work with Yogesh →