The Topology of a Product Team

Structuring for Empowerment and Success

A month into 2025, and I’ve already had more conversations about how to structure a product team than I did in the entire last year. Honestly? That’s kind of insane. You’d think by now—with all the books, Youtube contents, LinkedIn thought pieces, and endless social media debates—companies would have cracked this. But nope. Same old mess, different branding.

Welcome to Episode 22 of Product with JnrJose

Take this one company and call it Company A. Big brand. Huge name, known to own dozens of products than their competitions. They talk a big game about being “product-led,” but their org structure? An absolute trainwreck. A recent restructure got their product team—at least, what was meant to be a product team—tucked under Sales. Yep, Sales. The entire product team reports directly to the Sales Boss, who hasn’t just have them chasing every customer request like a dog after a tennis ball, also sets a sales target for each and every product person. While fingers are pointed to the the engineering team, truthfully, these engineers are beyond frustrated, building random features that don’t connect to any real strategy. The product managers have become glorified account managers, trying to keep the big boss happy instead of, you know, actually thinking about long-term product growth. And then leadership in the next few months will be sitting around wondering why they’re struggling to innovate.

And then you’ve got the other extreme Company B—my dear startup where the CEO wakes up with a “brilliant” idea, storms into the office (or Teams group, let’s be real), and tells the engineers to drop everything to build it. No research. No validation. Just pure CEO gut feeling. In Nigeria we call it “Oga Driven Development”(ODD) the synonyms for HiPPO (Highest Paid Person Opinion) in the product Zoo. And of course, the product managers are expected to “make it happen,” which is corporate speak for write some PRDs and pretend this was all part of the plan. Maybe this approach works if you’re some once-in-a-generation visionary, but for the rest of us? It’s a disaster.

Org Charts Don’t Build Great Products—Team Structures Do

There’s this weird myth that if you hire enough product managers, designers, and engineers, poof, you become a product-driven company. Spoiler: you don’t. I’ve lost count of how many PMs have vented to me about feeling like glorified project managers — Last weekend, it took myself and a couple of other product people a few human hours to explain to someone why product managers are not project managers (it wasn’t the fela’s fault, it’s because of how the organisation have been running product) — stuck pushing Jira tickets instead of solving actual problems. And engineers? Half the time, they don’t even know why they’re building what they’re building. They just get a spec and are told to “make it happen.” No context. No ownership. No connection to the user. Just a feature factory grinding out things no one asked for.

And every time leadership sees things stalling, their solution? More process.
"We just need better execution!"
No. You need better decisions. Because if PMs aren’t empowered to make real calls, and engineers aren’t part of shaping solutions, it doesn’t matter how smooth your sprints are. You’re still shipping garbage.

The Core Team: Three Siblings, Not a Hierarchy

Forget neat little reporting structures in PowerPoint decks—real product teams don’t work like that. The best ones aren’t built on rigid hierarchies; they’re built on partnerships. A PM, an Engineering Lead, and a Designer, working as equals. Not a PM calling all the shots while the others execute. Not an engineer acting as a passive builder. Real collaboration.

I was added to this WhatsApp group with a bunch of product folks in a major enterprise and their senior leadership, and there’s this one guy—senior leadership at this major enterprise—who constantly complains about how their competitors “have more features.”
"Look at what Competitor X just launched! Why don’t we have that?"
And just like that, his PMs are scrambling to copy whatever feature he just saw or even start building out a brand new product on this same premise. No conversation about whether it even makes sense for their customers. No thought about whether it aligns with their strategy. Just blind, panic-driven execution. And this is what happens when PMs aren’t given the right to critical thinking.

And engineers? Oh man. I’ve seen way too many teams treat engineers like human API endpoints.
"Here’s the spec. Just build it."
That’s not engineering. That’s assembly-line work. A great engineering lead isn’t just someone who writes clean code. They’re a technical partner—someone who thinks about feasibility, scalability, and why something should (or shouldn’t) be built. They should be challenging ideas, proposing better solutions, and helping shape the roadmap. Not just waiting for tasks to be assigned.

Same goes for design. People love to quote Steve Jobs on design, but half of them don’t actually understand what he meant.

"Design is how it works."

Yet, somehow, designers are still treated like the “make it pretty” team. No. Design isn’t just UI. It’s the entire experience—information architecture, user flows, interaction patterns, system thinking. Half of great design is invisible to the user, but if it’s done wrong, they feel it immediately. A great designer isn’t just decorating the product—they’re making sure it actually makes sense for real people.

The Extended Team: The “Cousins” Who Enable, Not Block

Beyond this core trio, you’ve got the supporting roles—the cousins of the product team. Super valuable. But the moment they start creating roadblocks instead of momentum, you’ve got a problem.

• Data Analysts & Data Scientists – Helping teams make decisions based on actual insights, not gut feelings.

• User Researchers – Making sure teams aren’t just guessing what users want, but actually validating it.

• QA Engineers – Not just gatekeepers, but integrated into the process so quality isn’t a last-minute panic.

• Product Marketing Managers (PMMs) – Not just launch managers, but bridging the gap between product and market fit.

And let’s be real—some roles just shouldn’t exist in empowered teams. Case in point: Product Owners. I know, some people swear by them, but let’s be honest. Splitting discovery and delivery into two separate jobs is a recipe for dysfunction. When PMs focus only on “strategy” and POs are left to “execute,” teams end up shipping things no one actually needs.

The Best Product Teams Don’t Wait for Instructions

A great product team doesn’t sit around waiting for a backlog to be handed to them. They figure it out. They push back when something doesn’t make sense. They pivot when things aren’t working. And they measure success not by how many features they ship, but by whether what they built actually mattered.

But for that to happen, they need:

• Ownership – Real accountability, not just marching orders.

• Context – Understanding the why, not just the what.

• The ability to challenge and shape ideas – Not just follow directives from the top.

When those elements are missing, teams default to safe, incremental shipping. No big bets. No meaningful impact. Just endless features piling up in Jira that no one actually cares about.

At the End of the Day, It’s Not a Product Problem—It’s a Team Problem

Most companies don’t have a product problem. They have a team structure problem. You can’t expect groundbreaking products to come out of teams that are just executing top-down orders. If PMs don’t own their problems, if engineers aren’t part of decision-making, if designers are sidelined, you don’t have a product team—you have a feature factory.

So yeah. If you want great products, fix the team first. Not just by hiring smart people, but by actually giving them the space, trust, and autonomy to do what they were hired to do. Otherwise? You’ll keep playing the same broken game—frustrated teams, meaningless features, and a never-ending backlog of things no one actually asked for.