Product Triad, Revamped
The Classic Triad
Almost every product manager has encountered this model early on—whether in books, courses, or boot camps—etched into our minds as the foundation of product management.
“Product management is in the intersection between UX, Tech, and Business.”
But anyone who’s spent real time in product management knows this “model” barely scratches the surface. In large organizations, the forces shaping a product go far beyond UX, Tech, and Business—think data, legal, operations, and countless others. So, is there a simple way to make sense of this growing complexity? As new influences keep piling on, I believe there is—and it’s time to rethink the triad.
The New Triad
Let’s break down the role of product managers to its most fundamental level. What are PMs actually doing when they interact with cross-functional teams, tackle a wide range of problems, or rollout a product?
Understanding what is
When PMs study existing features (internally and from competitors), ask for honest feedback from users, or query usage data (e.g., signups, purchases, button presses), what we are doing is truth-seeking. We need to have a solid grasp of what the environment is like, what problems people are facing, and whether the existing solutions to those problems are working.
This truth-seeking can be done at any point during the product cycle—whether in discovery or delivery—and it can involve any role on the product team (other PMs, data analysts, designers, engineers, data scientists, operations, marketers, sales, legal, etc.). All these roles have insights into some aspects of the product or the problems the product is intended to solve.
It’s been said that curiosity is one of the biggest strengths a PM can have. The reason why curiosity is necessary for PMs is that there’s a lot of “what is” to understand. The bigger the product and the team, the more true that becomes. If curiosity doesn’t match the complexity, PMs will lose their grasp of the truth and will be more likely to make the wrong calls.
“I have no special talent. I am only passionately curious.”
Envisioning what can be
When PMs co-design a product, estimate engineering feasibility, or co-draft marketing content, what we are doing is exploring the possibilities of what can be. Our products are bound by a variety of constraints. Our engineers might lack the manpower, know-how, or technology to build the ideal product on time and within budget. Our marketers might be limited by communication rules based on previous pushback. As PMs, we need to be aware of all the constraints facing our products so that we can build realistic solutions to problems.
The key difference between dealing with what is and what can be, is that “what is” is a matter of validity (there’s right and wrong), while “what can be” is a matter of confidence (degree of belief). We might think that we can do things we actually can’t or think that we can’t do things we actually can. Even a strong team has a limit to what they’re confident they can achieve. Accurately gauging this confidence requires empathy—the ability to truly understand and sense how the team feels about their potential.
Good PMs envision possibilities that people believe would be beneficial but doubt can be achieved. Remarkable products push the boundaries of what is possible and solve previously unsolvable problems.
“If you want something you’ve never had, you must be willing to do something you’ve never done.”
Delivering what should be
What should be is the culmination of understanding all the truths pertinent to a problem and envisioning all possible solutions. It’s the art of choosing the best vision to realize—the best solutions within all the existing constraints.
If we’re wrong about what is, we’ll solve the wrong problems. If we’re wrong about what can be, we’ll build the wrong solutions. When we build the right solutions to solve the right problems, we’re delivering what should be.
As PMs, when we:
Know all the important facts about products across all functions;
Have visions that take into account the limitations of the team, technology, social acceptance, and other important constraints; and
Have the courage to rally the team to realize one or more of the visions,
we might have what it takes to deliver what should be.
“Vision without action is a daydream. Action without vision is a nightmare.”
Conclusion
If you want to see product management as more than just the intersection of Tech, UX, and Business, consider it as the intersection of understanding what is, envisioning what can be, and delivering what should be. Embracing this perspective can inspire you to approach your work with greater curiosity, empathy, and courage—qualities that truly define impactful product leadership.
