Why Most Product Teams Fail (And the Jazz Band Secret That Changes Everything)
My conversation with Ahmet Acar revealed the uncomfortable truth about cross-functional teams, and why the best ones operate like jazz bands, not military squads
Futurist AJ Bubb, founder of MxP Studio, and host of Facing Disruption, bridges people and AI to accelerate innovation and business growth.
I’ve spent years walking into product organizations with the same routine. I sit down with engineering, then design, then product one by one and just listen. What they tell me reveals everything. The gaps, the misunderstandings, the places where communication falls apart completely.
My recent conversation with Ahmet Acar, who’s spent 30 years building products at Google, McKinsey, and AWS (where we first met), made something click. We’ve been doing this wrong. Really wrong.
Five Things That Actually Matter
Here’s what we figured out:
1. Great teams are jazz bands, not military squads. The best product teams don’t need conductors, project managers, or agile coaches. They’re professionals who listen, improvise, and pass the lead back and forth. The whole military squad thing we’ve been pushing? It’s backwards.
2. You need integration, not just collaboration. When you just nod and say “whatever you think” to your designer or engineer, you’re wasting them. Real breakthroughs happen when you actually mix insights across disciplines, not just coordinate handoffs.
3. Iterations beat hours, every time. Traditional teams might squeeze out 2-3 iterations per quarter. Autonomous teams? 30-40. That’s not just faster - it means you learn more. Simple math: try more things, something will work.
4. Most teams have no idea what they’re building. Put five team members in separate rooms and ask them what they’re building. You’ll get eight different answers. Without a clear vision, you’re just churning out features.
5. Focus beats multitasking. Companies spread teams across five products, thinking they’re being efficient. They’re not. Do one product per month with full focus. You’ll ship more than trying to juggle everything at once.
Let me walk you through how we got here.
The Problem We Keep Ignoring
Cross-functional teams have been around for at least 5,000 years. Think about the pyramids, all those different specialists trying to work together. The same problems existed back then.
Here we are in 2025 with all our fancy tools, and we’re still fighting the same battle: getting people from different backgrounds to actually work together. You’d think we’d have figured this out by now. But I see the same mess everywhere I go.
When Everything Flipped
We started talking about agile coaches and scrum masters. I always thought of them as translators, people who knew enough about each discipline to bridge the gaps.
That was a mistake from the start. A good product team doesn’t need an agile coach or a project manager.
A good product team is more like a jazz band. You have four or five six people, and they’re just jamming. There’s no conductor. They all know their thing. They’re listening to each other, figuring out where it’s going, and then they groove with it.
I had to stop and think about that. We’ve been obsessed with control and coordination of military squads, rowing teams, with someone barking orders. But that’s not how great teams work.
Jazz musicians don’t need someone telling them when to play. They’re pros who choose to play together. The lead passes around naturally.
Beyond Just “Working Together”
It goes deeper than collaboration. It’s really about mixing different types of knowledge. Taking insights from different areas and creating something new. That’s what makes something great.
Consider this scenario: if you’re just listening to the designer say where to put the button, and you respond with “whatever, I trust you,” you’re not getting anything from having a designer. Why not just use an AI tool at that point?
That’s the difference. Good teams coordinate. Great teams actually blend what they know. You need to understand enough about what the other person does to build on it.
When I look at teams that work versus teams that struggle, this is it. How many people actually want to understand what their teammates do? How many just stay in their lane?
The Vision Problem
Here’s a brutal test: Take your team members. Put them in different rooms. Ask each one what they’re building. If you have five people, you’ll get eight answers.
I’ve seen this so many times. It’s not about unclear requirements. It’s that nobody actually knows where they’re headed.
We talked about the PR/FAQ approach from Amazon (we both dealt with those). Instead of listing requirements like “as a customer I do this, as a user I need that,” you write it like the product already exists. You’re describing the future.
Think about the Apollo mission. By the end of this decade, we will put a man on the moon and bring them back safely. That’s clear. You can see it.
When you have that kind of vision, your team can make decisions on its own. They know the goal. How do they get there? That’s up to them.
The Numbers Don’t Lie
It’s not about hours. It’s about iterations. Same with products. More iterations, better results.
Here’s what that looks like in practice: In a typical SAFe environment, maybe two or three tries per quarter. In a focused product team where everyone works on one thing? Thirty, forty, fifty tries in the same time.
Simple math. Try more things, something’s going to work.
I can always tell when a product’s peaked. The app update is “new colors and a new icon, fresh look.” That’s it. And knowing how these places work, entire teams and approval processes went into picking that icon. Nobody’s experimenting anymore.
The Structure Problem
I’ve seen teams where three people designer, an engineer, product manager, had a project manager, an agile coach, and a release train engineer managing them. They were overcrowding the actual team.
The overhead is bigger than the work.
But most leaders can’t just blow up their org structure. So what can you actually do?
Do things one at a time. If you’re managing four products, do them sequentially. Full team on one product for a month. You’ll hit your targets. Juggling everything at once? Won’t work.
Here’s the irony: companies spread people across five projects to “maximize efficiency.” But every project has overhead meetings, admin, and context switching. Maybe 20% per project. Five projects? You’re just managing. Nothing’s actually moving forward.
What Makes Someone Great
Here’s what separates good team members from great ones: they care less about their own reputation or their career than they care about the product and the customer.
I’m always pushing people on this: when you pick something up, you own it. All of it. You don’t get to say “I’m blocked, it’s with legal, nothing I can do for six days.” No. What’s your follow-up? Where’s the meeting? What are you doing to push this forward?
I heard about a designer who had the confidence to walk away if people didn’t respect the work. That designer could find another job the next day because the quality spoke for itself.
You need people who’ll fight for what’s right. When you have someone like that in every role, you’ve got something strong. Hard for anyone to push around.
What Leaders Should Do
Be ruthless about priorities. Most companies are trying too many things at the same time.
Every company I’ve seen is doing this. Too much, all at once.
You’re not launching those 10 apps this year. Launch three good ones. Do the next three next year.
This connects to the one-way door, two-way door idea from Amazon. Three releases per year? You’re not learning fast enough. That’s a one-way door; you’re 10 months in before you know if it worked. Four experiments per month? You learn, pivot, try again. Those are two-way doors.
The problem is that companies treat everything like a one-way door. Even the tools. You’re at an early discovery? You shouldn’t be using Jira to manage development. Use something simple. Later, when you’ve got a massive mature product, then switch to the complex stuff.
What It Comes Down To
Get good, experienced people who have opinions and care about the product and customer. Then just remove the blockers. One by one. Or find ways around them.
Most of the time, teams don’t need to learn how to communicate. If they’re experienced, they already know. They don’t need help with that. They need someone to clear out the dysfunction so they can work.
That’s the truth nobody wants to hear: we’ve built systems that stop good people from doing good work. More process doesn’t fix it. More coordination doesn’t fix it. More overhead doesn’t fix it.
What fixes it? Letting talented, opinionated people work like jazz musicians listening, responding, creating together.
The question isn’t whether you can build great product teams. It’s whether you’re willing to get out of their way.
Based on my conversation with Ahmet Acar, who has spent 30 years building products at Google, McKinsey, and AWS. Watch the full conversation on our webcast about humanity, technology, and product development.