Direct the ship, don’t row it
An extract from an internal post at Atlassian I wrote to our product management team:
A few months ago, I thought I had a clear view on what AI meant for the product triad. Product Managers, Designers, and Engineers were converging. Roles were merging into what the Valley seems to call the “AI Builder”. For the purposes of this article, I’m going to loosely define this as someone who does PM, Design and Engineering roles and spends most of their time vibing the code to make the product better.
The picture is more nuanced as I’ve been learning from what we’re doing inside Atlassian across our crafts and from the rest of the world. I think the popular framing — “these roles are merging into one” — is leading a lot of teams toward the wrong conclusions in most contexts. I do think there is a clear role emerging that is the AI builder, but that’s not going to be for the vast majority of product folks. Instead of merging, it’s expanding.
Everyone thinks the other craft is in trouble
There’s a joke that lands every time I give this talk internally.
You speak to a designer and they say: “PMs just write documents all day. They’re in trouble.” You speak to a PM and they say: “Designers? I built a prototype this morning. They’re in trouble.” Pick any craft and you’ll find someone confidently pointing the finger at the other one.
There’s some truth in that. And a lot of nuance we’re skipping.
The truth is: with AI, everyone can do more. A PM can now generate design concepts. A designer can now draft a product strategy. An engineer can ship a feature in a day that used to take a week. The capability expansion is real across all three crafts.
But the conclusion most people are drawing from that — that the roles are therefore converging into one — is where I think we’re getting it wrong and lacking a lot of nuanced thinking.
Two worldviews. One Venn diagram.
Here’s the mental model that’s driving most of the conversation right now.
If PM and design (and engineering) can each do the other’s job with AI, then the circles in the Venn diagram start to overlap more and more, until eventually… it’s just one circle. One role. One person. The AI builder.
I get the appeal of that model. In startups, it’s genuinely compelling. When you’re small and you need to move fast, one person who can design, build, and define the product is extraordinary. That’s a real role, and I think it will continue to grow as a known job title.
But here’s where I’ve landed: for the vast majority of product managers and designers working in medium or large-sized organisations — that model isn’t the right one. And pushing toward it is not the best use of their time.
The model I find more useful: bigger circles
Instead of circles merging, I think about circles expanding and getting a bit of a colour tint from the other craft.
The PM circle gets bigger. The design circle gets bigger. And as they expand, they can take more work on (increase throughput), and yes even naturally take on a little more of each other’s colour. PMs do more prototyping, more data science work, more design thinking. Designers do more strategy, more product framing, more of what used to sit squarely with the PM.
That’s different from saying the roles are the same.
This is the mental model I find most actionable. Not “you’re all one role now” but “your circle has grown — go use it.” Engineers are getting a lot more throughput, and left and right of code is where the bottleneck is. Could you spend your time coding? Yep, is that the best use of your time when more of the bottleneck is happening in your area? Possibly not. Don’t get me wrong, the overlap is real and healthy. The convergence to a single circle is a different, much bigger claim.
The large org vs. startup split
This is where I think the AI builder narrative gets genuinely confused, because it’s talking about two very different contexts at once.
In a startup: yes, you probably want people who can span everything. Get the job done. Ship. The smaller the org, the more this makes sense. That was the case prior to the generative AI wave, and is even more the case today. In a very small (and autonomous) team within a large organisation: Yes, I could see this happening there as well.
In a large organisation with hundreds of engineers, high dependencies between teams, this calculus feels completely different.
I was listening to a podcast with Amol Avasare, Anthropic’s head of growth and he made a point that I’ve been making internally: in an org where you already have high engineering throughput, the best use of a PM’s time is not building. It’s directing.
Think about it. If AI is effectively doubling your engineering team’s output — you’ve gone from 1,000 engineers to the throughput of 2,000 — what do you need more of? More code? Or clearer direction on what to build and why?
Learning this inside Atlassian
I want to share two relevant things we’ve been learning across our organisation that point to similar conclusions:
Learning 1: We must use AI to increase PM throughput and avoid becoming a bottleneck for engineering teams.
At Atlassian, we have roughly ~450 product managers. PM-to-engineer ratios, already high, now approach 1:15 in most product teams and 1:20 in most platform teams. With AI, PMs report these ratios feel like 1:30 or 1:40. So, what is the key issue? Is it about adding a PM to that 40, or making the existing 1:40 feel like 1:20 again? We must consider both PM and engineering ratios growing, with engineering growing faster due to advances in models. In this context, a PM writing code isn’t addressing the right problem. The ship moves faster than ever. The priority is ensuring it points in the right direction.
Learning 2: We need to use AI to help more of the team steer, not just to add another person rowing the boat.
There are some squads at Atlassian that are spending more time having their PMs and Designers doing more coding — this is awesome. Great way to learn empathy, get quick changes in, increase velocity etc. I’m not against it at all. At the very least doing it to build empathy and understand the process is something we should all do. What’s interesting is chatting to some of these folks, one common thread comes back: PMs / Designers come back with the learning that the best thing they can do for their team is to work out how to enable each of them to steer — because everyone’s rowing faster. How can I enable my team so that they all think like a PM?
This is what the two learnings point to: building a shared brain is key
In 2019, I wrote about one big misconception of the product management craft — that they make all the decisions. The conclusion I reached back then is that isn’t the case, but if you think about it as their responsibility to ensure they own the velocity of decision making the team has as it pertains to the product vision, customer problems, business context and opportunities then you get far better outcomes — teams scale well. Everyone in your team can wear a bit of the product management hat if they have all the context you do.
The best PMs spent time building a shared brain with their team about these contexts, not necessarily doing the work (especially in larger team contexts).
I think this applies to every leg of the triad, not just PM.
The best designers I’m seeing today aren’t the ones racing to produce more designs faster with AI. They’re the ones asking a different question entirely — how do I enable my team to make great design decisions without me? They’re investing in the shared vocabulary: the visual design principles, the content patterns, the interaction standards that mean an engineer or a PM can make a decent design call in the moment, and a specialist can course-correct when it matters. They’re lifting the taste of the whole team, not just executing at the top of it.
The irony — and I mean this genuinely — is that we’ve always known this. The best PMs made everyone a PM. They empowered the team with context, customer knowledge, a clear point of view.
The circles are getting bigger. Use that extra reach to improve your quality and create more leverage. But don’t confuse a bigger circle with no circle at all.
Afterward: Engineering is a different conversation
I think conflating PM/Design overlap with PM/design/engineering overlap is where more confusion often happens.
PM and design getting closer together? That’s one conversation. PM, design, and engineering all merging into one role? That’s a much bigger claim, and I think it needs a different frame.
The reason is product engineers.
When I joined Atlassian in 2009, I was the only product manager on Confluence, engineering team was about 15–20 people. So what did the engineers do without a PM? We had a lot of product engineers: engineers who engaged deeply with the “why” not just the “how.” They had a shared brain on the vision, the customer and problems they’d solve for them and how they’d get there. They’d seek out customer contact, triage feedback, advocate for specific problems to solve. They were, in practice, doing the PM and design thinking as well as writing the code.
Back then there was no shared frame of reference to talk about this — I felt the need to spend time to help codify the term product engineers.
Product engineers are, in many ways, the original AI builder. They always spanned the venn diagram. And with AI, that capability expands even further — a great product engineer today can move faster and cover more ground than ever before.
But here’s the thing: product engineers are rare. In most squads, you might find one. And their primary job is still coding. That’s not a limitation. That’s the point. Their engineering depth is precisely what makes their product thinking so valuable. They can feel in their hands what’s elegant versus fragile, what’s a clever hack versus a sound foundation. That judgment comes from being a practitioner, not from wearing three hats equally.
So yes — the engineering venn diagram is coming together for product engineers specifically. But the percentage of engineers who are genuine product engineers is small, and while we could always be striving to grow that cohort, we also need many other kinds of engineers to build successful products. What you want is to recognise and empower the product engineers you already have — and make sure the rest of your engineering team has enough direction and context to do their best work.
