A year ago, if somebody walked into your engineering organization and proposed that you should hire two product managers for every one engineer, you would have laughed them out of the room. I would have, too.
Andrew Ng — a British computer scientist who knows a thing or two about how teams actually ship — isn't laughing. And the teams that have figured this out aren't laughing either. They're quietly pulling away from their competition.
I'm Lance Dacy with Big Agile, and I help product organizations and their leaders build the kind of teams that can actually keep up with how work is changing — and it's changing quite a bit. This week I want to talk about what I'm calling the role blur: the collapse of the lines between product management, design, and engineering, and specifically what to do about it. Not as a passing trend, but as a structural reality I'm seeing in nearly every organization I walk into.
The Lanes Are Not the Problem. The Lanes Are the Symptom.
A few weeks ago I was on an engineering onsite at a Fortune 500 company. Smart leader, great team — I loved working with him. But he had just spent three weeks rewriting job descriptions to clarify the boundaries between his product managers, his engineers, and his testers.
His exact words to me were, "Lance, I just need everyone to stay in their lane. They're tripping over each other. I need to do a RACI chart or something."
That is the response I see most often from leaders, and to me it's exactly the wrong move.
When a product manager is now expected to prototype before refining, when an engineer is being asked to evaluate AI output instead of writing every line themselves, when a designer needs to understand delivery economics — the friction between those roles is not insubordination. It's the operating model trying to update itself.
The role blur isn't a cultural problem. It's a structural one. And policing it just slows down the people you most want to keep. I promise you that.
The Three Shifts Happening in Real Organizations Right Now
These aren't predictions. They're documented in the research, and I'm seeing them play out on the ground every week.
Shift 1: Product Managers Are Becoming Outcome Orchestrators
Product managers are no longer feature factories or backlog managers — at least, the good ones aren't. They're outcome orchestrators. People who move quickly between user evidence, hypothesis, and validation.
It's almost like what a Scrum Master does for a Scrum team — a product manager does for a stakeholder team in discovery.
Andrew Ng has publicly talked about teams proposing product-manager-to-engineering ratios that would have sounded absurd a year ago. Some teams are now flipping from one PM per four engineers to two PMs per one engineer. You can read more about this in the Product School 2026 PM Trends report.
Why is this happening? Because AI is compressing the time between "we think we should build this" and "it exists." The constraints have moved upstream. It's no longer "can we build it?" — it's "should we build it, and how do we know when we have?"
That's product work. And it's becoming the bottleneck.
Shift 2: Engineers Are Becoming Intent Validators
Engineers are spending less time writing every line of code and more time evaluating the output of AI agents and teammates, course-correcting, and judging whether what got built actually matches what was intended.
That's not a downgrade. That's closer to senior engineering thinking applied to every task — not just to whoever happens to be the senior engineer in the room.
High-performing teams already know that speed without judgment creates failure rates that wipe out the speed advantage. The DORA 2024 report shows this clearly: throughput without stability is a tragedy, not a win.
Engineers who can move fluidly between writing code, reading AI output, and joining a customer call are the most valuable people in product organizations right now. That's not a hot take. That's what the hiring data is showing.
Shift 3: Designers Are Moving Upstream
Designers are moving upstream — not just into wireframes, but into the strategic conversation. Because when you can prototype an interface in two hours, the question stops being "what should this look like?" and becomes "should this exist at all?"
That question used to live with the product manager. Now it lives at the table where design, engineering, and product sit together.
We used to refer to this as three amigos refinement. Now I'm seeing organizations scrap their associate product manager programs entirely and replace them with something called a product builder program — generalists working across product, design, and engineering. I like that name. And it's not a one-off. It's becoming a trend.
We used to say it all the time on engineering teams: cross-functional teams blurring the skills so we don't have a bottleneck. Well, those bottlenecks have moved up into product. They're creating queues.
The Builder Check: A Three-Question Diagnostic
So how do you tell whether your team is actually operating this way, or whether you're just calling it "cross-functional" while quietly running a relay race inside the iteration?
Here's a simple diagnostic I'm calling the Builder Check. Three questions you can ask your team this week.
Question 1 — Discovery: Who Sat in the Last User Conversation?
Quietly ask your team this. If the answer is "only the product manager," your team is still operating in handoff mode. The PM hears the user, translates the user, writes a story. By the time it reaches the engineer, the texture is gone.
In a builder team, the engineer who's going to influence the build is in the user conversation too. Sometimes asking questions. Sometimes just listening. But present.
Question 2 — Direction: Who Can Change the Spec When New Evidence Comes In?
This is the test of whether you're operating as builders or as a feature factory dressed up in modern words.
In a builder team, anyone who sees evidence that invalidates the current direction can call it out. That requires psychological safety. The engineer who notices an API constraint breaking an assumption. The designer who sees a user struggle in moderated testing. The PM who hears the second customer contradict the first. All three should be able to raise their hand and change direction.
If only one role gets to change the spec, you're running a relay race.
Question 3 — Done: Who Decides Whether the Outcome Was Achieved?
This is the one most teams fail at. Done usually means deployed — story closed, PR merged, demo happened. But if no one on the team is responsible for asking "did this actually change the behavior we expected?" then you're still measuring output, not outcomes.
Outcomes over outputs is a hard idea to operationalize. It feels fuzzy. But it's not — it just requires a different ownership model.
On a Scrum team, the Product Owner prioritizes the backlog, sure. But the sprint is a granular focused effort. I'm talking about the long runway — the roadmap plan. A lot of people think "agile" means we don't plan. That's incorrect. We spend more time planning in agile than in any other process. It's just progressive and shifting.
A Product Owner can delegate many of their responsibilities. The only thing I really don't want them to delegate is being the single voice of priority to the team. But that doesn't absolve them from working with stakeholders, talking to users, and making real decisions. And it doesn't absolve the whole team from owning the did this work? question after the work ships.
In a builder team, whether the experiment worked is owned by everyone — not just the product manager alone. Engineers care. Designers care. PMs care. Because they all participated in the experiment.
Run those three questions in your next retrospective. If the honest answer to any of them is "just one role," then you might have just gotten the RACI chart you asked for.
Overlap Has to Be Designed In and Fought For
Here's the part leaders miss: this overlap doesn't happen by itself. It's not an inherent behavior, particularly in engineers. We've trained them for decades to want the dark corner where they can think. We told them to leave them alone, they need to focus.
Well, that's exactly why you might be headed for disaster these days.
This is not about flattening expertise. The product manager still has different judgment than the engineer. The designer still sees things the engineer doesn't. That doesn't go away. But all three are now operating on the same evidence, working toward the same outcome, against the same definition of done.
That's what I mean by moving the three amigos out of refinement and into delivery itself. Backlog refinement, by the way — Scrum has been quietly telling us to do this for years. It's just that everyone struggles to put their finger on what backlog refinement actually is. It's not a once-a-week meeting. It's ongoing, progressive planning of the important things — which are going to change. That's not scope creep. That's adapting to a hyper-competitive market.
This is also where Team Topologies (Skelton and Pais) becomes relevant: when you design teams around the flow of work rather than around functional silos, the role blur isn't something you have to defend against. It's something the team structure naturally supports.
What to Try Next Week
So what can you do next week? Here's the move.
When you start your next discovery effort, don't invite engineering as a resource. Invite engineering as a co-host. Just brand them a co-host.
A resource shows up to answer technical feasibility questions. A co-host runs half the conversation. They prepare the questions. They take notes. They share the synthesis afterward. And they're accountable to you for the outcome.
Why does this work? Because the moment an engineer is accountable for what gets built — not just how it gets built — they've started operating as part of a builder team. You haven't announced anything. You haven't rewritten any job descriptions. You've just changed who shows up and what they're responsible for.
After that first session, take it one step further. Ask whoever co-hosted to frame the experiment for the team. Watch what happens. The conversation gets more honest, and faster. And yes — they're not sitting down writing code. But what code? We don't even know what we're building yet. This is the work that decides whether the build is worth doing in the first place.
The Role Blur Is the New Way to Build
The lanes you're policing and the RACI charts you think will help — they're slowing down the people you most need to keep.
The role blur isn't a trend you ride out. It's the new way to build tech products, at least for the foreseeable future. The organizations that redesign their rituals to allow for overlap will measurably be ahead of those still trying to enforce separation.
If you're leading a product organization and trying to navigate this shift, this is exactly the kind of work we do at Big Agile. We run certification training, group workshops, and one-on-one coaching for leaders working through these structural changes in real time. Sometimes a neutral set of eyes is all you need to see what's actually blocking your teams. Explore our upcoming classes and consulting engagements.