We’re All Doing The Same Job Now

I was a designer for over twenty years, and for most of that time, when someone asked what I did, the honest answer was: I made ideas concrete. I took the fuzzy, ambiguous mess of what a product could be and I turned it into something you can see, click, argue about. That was the job. To paraphrase Herb Simon, I changed existing situations into preferred ones. That was the job. Not the only part of the job, but the part that justified my seat at the table. The PM could describe what a good solution needed to accomplish; I could show you five ways it might work and explain the tradeoffs of each at the level of strategy, interaction, and pixel (and occasionally mm).

That distinction is dissolving, and it’s dissolving from both sides at once.

A product manager with good AI can now do the thing that used to be my exclusive territory: make things concrete, fast, and at reasonable quality. They can generate UI mockups, write working code, build prototypes, create user flows. The PM who once had to wait for my availability can now go from “We need to reduce churn in onboarding” to a clickable prototype in an afternoon. They can generate twenty layout options where I might have carefully Sketch’d/Figma-d five. And while each of those twenty lacks the refinement I’d bring, the sheer breadth of exploration surfaces ideas that a more craft-conscious process might miss.

I don’t blame PMs at all. They’re doing something genuinely valuable. They’re holding business context, technical constraints, and customer data in their head while generating the artifact, rather than translating all of that into a brief and hoping nothing gets lost in the handoff. That’s not a lesser version of design. In some contexts, it’s a better one.

But before designers panic (or before PMs get too comfortable), the knife cuts the other way too.

A designer with AI can now do most of what made PMs essential. Data analysis, strategy frameworks, prioritization matrices, competitive analyses, stakeholder communication artifacts… all of it is increasingly templateable, and AI is very good at templateable. The designer who used to have to ask for data can now just get it. The one who couldn’t write a solid PRD can now generate strategic scaffolding that would’ve taken a PM a week. A designer who understands users and the market deeply and can also synthesize business data and generate a business case? That person doesn’t need a PM much at all.

Now add engineers to the picture, and it gets worse for everyone.

The traditional product team was a triangle. The PM decided what to build. The designer decided how it should work and look. The engineer decided how to actually build it and then, you know, built it. Each role existed in part because the other two couldn’t do their job. The designer needed the engineer to make the design real, production-grade, performant, scalable. The PM needed the engineer to know what was technically feasible and how long it would take. And the engineer needed the other two because, left to their own devices, most engineers will build something that works perfectly and that nobody wants to use or pay for. (That last bit is a gross generalization but go with it.)

AI is collapsing this triangle the same way it’s collapsing the designer-PM demarcation. A designer with AI can now produce working code, not just prototypes. Not production-quality code, necessarily, but functional enough to test, to demo, to prove a concept without filing a ticket and waiting three sprints. The gap between “clickable prototype” and “shipped feature” is shrinking. A PM with AI can do the same: go from idea to working software without ever opening a design tool or talking to an engineer.

And engineers? Engineers with AI can now generate interfaces that are, if not well-designed, at least competent. They can run their own usability analyses, write their own copy, make their own product decisions. The engineer who used to say “just give me the spec” can now generate the spec, build the thing, and ship it. The full stack just got a lot fuller.

So where does that leave the engineer? In the same place as everyone else, it turns out.

For some people, this is a shrug. They’ve taken on and done many roles in the process for their entire careers. But based on the hair-on-fire reaction of many, they’re in the minority. We’re all doing the same job now! Ahhhh!

Durable Advantages

So what’s left, for any of these roles? I keep coming back to three things.

For the designer, the durable advantage seems to be judgment. Not craft execution (“taste”), which AI is rapidly commoditizing and is being shared open source style, but the knowledge of what good looks (and feels!) like in context. Knowing which of those twenty generated options is actually good. Knowing that the spacing is slightly off in a way that undermines trust. Knowing when to break a convention and when breaking it will just confuse people. Seeing what’s almost right and knowing exactly how to push it the rest of the way. That judgment is built from years of making things and watching people use them; you can’t shortcut it, and AI doesn’t have it. For new designers, education will help, both formal and informal.

For the engineer, the durable advantage might be systems thinking. Not writing code; AI writes code. Not knowing a framework; AI knows every framework. The engineer’s real value is understanding what happens when ten million users hit this thing simultaneously, when the database migration goes sideways at 2 a.m., when two microservices disagree about the state of the world. It’s knowing where the system will break before it breaks. That kind of architectural judgment is built the same way design judgment is: slowly, painfully, by living through the failures that teach you what the textbook can’t. And like junior designers, new SEs will benefit from advanced schooling and mentorships.

For the PM, the durable advantage is organizational power. Someone has to own the outcome in a way the business recognizes: make the call when the data is ambiguous, take the blame when it’s wrong, fight for resources, say no to the executive who wants their pet feature. Designers love to talk about “killing your darlings,” but knowing something should be cut and having the authority to cut it are very different things. The PM can walk into a roadmap review and kill a feature. The designer can only advocate for it. That gap isn’t about willingness or even judgment; it’s about to whom the org chart hands the knife.

Side note: The best PMs are also often skilled in organizational navigation, to work cross-disciplinarily to get things done. I would argue, however, this is a skill that is shared with the best PMs and the best engineers, and not solely theirs, unlike organizational power invested in them.

Organizational power is (as the name suggests) held by the organization, not inherent in any individual. If the organization decides that someone else or some other role should have it, it goes there. In other words, an engineer or designer could be imbued by the organization to have this power. Ergo, the PM role could be most vulnerable, although hiring numbers would suggest otherwise.

I don’t know where this lands. I’m not sure anyone does yet. But I think the honest version is this: all three roles were always partially defined by the limitations of the other two. AI is removing those constraints. The lingering question isn’t whether AI replaces designers or PMs or engineers. It’s whether the three-role product team was always a workaround for a problem that technology is now solving. Or was it a necessary method of distributing the collective intelligence and cognitive burden of designing, managing, and building products? I guess we’ll see.

Hat tip to Nik Martelaro who made this smarter.