A few years into my career, I started noticing a trend—one that became hard to ignore. Companies, whether they were early-stage startups or well-established enterprises, kept misplacing their product teams. And by misplacing, I don’t mean physically (though I have seen some questionable desk assignments). I mean structurally.
Welcome to Episode 23 of Product with JnrJose
In the first part of this article, I discussed about enterprise A that have their product teams buried under sales, forced to chase every high-value customer request like a waiter at a fancy restaurant. I also shared about a specifict startup where the CEO wakes up, has a lightbulb moment, and before anyone blinks, the engineers are scrambling to build it—no research, no validation, just pure instinct. And then there’s the classic setup where PMs act like project managers, engineers are treated like order-takers, and designers are invited to the party last minute to “make it look good.”
But let’s be real—this isn’t how great products are built.
At the heart of every successful product team is the Product Trio, or what I like to call the Triplets—Product Managers, Engineering Managers, and Designers. They’re not a chain of command. They’re not a hierarchy. They are the “Product Trinity” co-owners of the product, each bringing a different strength to the table.
Let’s Talk About the Reality of the Trio
For some reason, a lot of companies still think of the Product Manager as the “boss” of the team. But a good PM isn’t a CEO of the product (and honestly, can we retire that phrase already?). They don’t walk into a room dictating what gets built. Their job isn’t to tell engineers and designers what to do—it’s to define the problem space, ensure alignment, and facilitate smart decisions.
The Engineering Manager isn’t just responsible for execution. If all they’re doing is making sure Jira tickets get closed, something’s broken. They are technical strategists, not just builders. They’re there to ask: How do we scale this? What are the trade-offs? Is there a better way? A strong engineering lead doesn’t just build—they shape the solution.
And then there’s the Designer—often misunderstood, sometimes tragically underutilized. A lot of teams still bring in designers at the end, treating them like decorators. But design isn’t just about how something looks—it’s about how it works. A great designer ensures the product isn’t just functional but also usable, intuitive, and frictionless. They ask, Does this experience make sense? How can we simplify this?
When these three roles are treated as equal partners, you get magic. The best product decisions don’t come from one person leading and others following—they come from the tension, debate, and collaboration between these three perspectives.
Why Trying to Establish a Hierarchy is a Huge Mistake
The minute you try to put one of these roles “above” the others, you’re asking for trouble.
If a PM dominates, engineers disengage and start treating their work like a ticket system. If an Engineering Manager calls all the shots, technical decisions can override user needs. If design is sidelined, you end up with a feature-heavy, clunky product that no one wants to use.

Great teams don’t operate on hierarchy—they operate on trust and shared accountability.
In high-performing teams, the Trio works together like this:
PMs own the “why.” Why is this problem important? Why should we prioritize this?
EMs own the “how.” How do we build this in a scalable and efficient way?
Designers own the “what” and “experience.” What should the product feel like? What’s the best way for users to interact with it?
They push back on each other. They challenge each other’s assumptions. They make sure the end result isn’t just built, but built well, for the right reasons, with the right experience in mind.
What Happens When the Trio is Misaligned?
I’ve seen what happens when this balance is off, and it’s not pretty.
When PMs and Engineers don’t align, roadmaps turn into wish lists. The product backlog grows endlessly, engineering debt piles up, and execution slows down.
When Design is an afterthought, you get products that function technically but frustrate users at every turn. The UI feels clunky, the onboarding sucks, and nobody knows why adoption is low.
When the Trio falls into feature factory mode, the team focuses on shipping, shipping, shipping—without asking if any of it actually makes a difference. The measure of success isn’t impact; it’s output. And that’s how you get products filled with features that no one really needed.
Lessons I learnt from the book “Team Topologies”
One of the biggest insights from the book Team Topologies by Mathew Skelpton and Manuel Pais is that teams work best when they are structured around value streams—not traditional department lines.
This means:
The Trio must be embedded within a single team, not split across different departments. PMs, EMs, and Designers need to be working together daily—not just meeting for roadmap discussions every quarter.
They should co-own decisions from the start. This isn’t about PMs coming up with a plan and handing it off to engineers and designers—it’s about collaborative decision-making.
The Trio should focus on outcomes, not just output. This means measuring success by how much value they create—not how many tickets they close.
How to Build a Stronger Product Trio
If your Trio isn’t working the way it should, here are a few things to fix it:
Stop treating PMs as the “boss.” Instead, encourage shared ownership.
This is where so many teams fall into the trap of corporate hierarchy creeping into product teams. I can’t count how many times I’ve seen companies treat PMs like mini-CEOs, sitting at the top of a pyramid, handing down instructions for engineers and designers to follow. And every time that happens, the team starts to break down.
When PMs act as decision dictators instead of facilitators, you end up with:
Engineers who stop challenging ideas and just build whatever they’re told (even if it doesn’t make sense).
Designers who aren’t brought in early enough, so they’re left trying to fix broken experiences at the last minute.
A culture of compliance instead of collaboration—which means worse products, slower execution, and way more frustration.
A healthy product team distributes ownership. It’s not about who has final say—it’s about who brings what to the table. The PM owns the why, the Engineer owns the how, and the Designer owns the what. But the only way that works is if decisions happen as a team, not in a vacuum.
If your PM is the only one driving the roadmap while engineers and designers are just "brought in later", you’ve already lost. Break the hierarchy, start co-owning decisions, and trust that your engineers and designers have just as much of a say as your PMs
Make sure incentives are aligned, or the Trio will pull in different directions.
Here’s a scenario I see way too often:
The Product Manager is measured on business impact (e.g., revenue, retention, activation rates).
The Engineering Manager is measured on delivery speed, uptime, and system performance.
The Designer is measured on UI improvements, usability scores, or subjective aesthetic appeal.
At first glance, this seems fine. But if you think about it, these are totally different goals that push people in opposite directions.
A PM might push for a highly experimental feature to test user engagement, but the Engineering Manager might resist because it could introduce technical debt and instability. Meanwhile, the Designer might be focused on making a beautiful, intuitive experience, while the Engineer is saying, "We don’t have time for this level of detail right now."
This tension isn’t just frustrating—it slows the team down.
The fix? Make sure all three roles are aligned on a shared set of success metrics. That means:
PMs, EMs, and Designers should all care about product success, not just their individual functions.
If the PM is rewarded for business success, but the Engineer is rewarded for shipping fast, you’ve already created a conflict.
The Trio should set shared goals together—for example, instead of measuring each role separately, tie everyone to something like "Increase activation rate by 15%" or "Improve conversion by 20%". That way, everyone is working toward the same outcome instead of optimizing for their own KPIs.
Prioritize deep collaboration: If the Trio isn’t working together from day one, it’s too late.
Let’s be real—a lot of teams still work in silos. I’ve worked with teams where:
The PM creates the roadmap alone, then presents it to engineering and design.
The engineers get requirements late, build what they’re told, and don’t feel like they’re part of the decision-making.
The designers are only looped in at the end, which means they’re forced to “paint over” bad UX instead of fixing it at the core.
When teams work like this, they’re always playing catch-up. Designers are fixing problems they didn’t get a say in, engineers are questioning why they’re building certain things, and the PM is stressed trying to manage it all.
Instead, the Trio should be working together from the very start of a product decision. This means:
PMs, Engineers, and Designers should all be part of discovery—user research, customer feedback, and strategic discussions.
Engineers should be giving input on what’s feasible and scalable before a feature gets planned.
Designers should be part of shaping the problem space instead of just designing screens after decisions are made.
This isn’t about meetings for the sake of meetings—it’s about making sure decisions are made together, not handed down in a sequence.
The Product Trio isn’t a reporting structure—it’s a partnership. If you’re still running things like a command-and-control system, you’re slowing your team down.
Great products aren’t built by one person calling the shots—they’re built by a group of equals pushing each other to make the best decisions possible. If your team is stuck in a top-down approach, it’s time to rethink how the Trio operates.
Because when the Product Manager, Engineering Manager, and Designer truly work as partners, everyone wins—your team, your product, and most importantly, your users.