Emerging Roles in Software

The software industry is changing fast. Anybody who's been paying attention can feel it.

As the founder and longtime CEO of Brandcave, a design-driven product design agency, I've had a front row seat to how quickly the nature of product design has been shifting. I've watched the strain land on people doing the work.

In the last year, I've spoken to multiple smart, experienced product owners who have been laid off and are actively looking for work. Meanwhile, we're hiring product designers at Brandcave, and we're clearly the exception that proves the rule, because my inbox is full of applicants who've been job-hunting for months.

I'm seeing the trend just like everybody else, and here's my read on it: the market still wants designers and product people. It's just stopped paying a premium for single-function work, because the roles required to build great software are collapsing into each other.

AI has rapidly changed what's possible, and it continues to do that. In the process it's eroding the boundaries between owner, designer, and engineer. Today, a product owner with the right AI tooling can ship in a week what five years ago would have taken a whole team months.

Some teams are already adjusting to this shift. Most haven't started.

How a company builds software heavily depends on the team and what it's building. A product whose growth depends on people discovering it, signing up, and using it without talking to a salesperson earns its keep on user experience. That's called product-led growth, and it pairs well with design-driven development.

A product that grows through demos, long enterprise sales cycles, and human relationships can have a rougher user experience and still succeed. Ditto with software where the user has no choice, like internal tooling, or where the scope is narrow enough that people just need to see data and move on. The product decides the methodology.

I want to make that distinction clear before going further. Everything I've written here is written for design-driven teams whose product is won on user experience. If you use an engineer-led software strategy, plenty of what follows won't apply to you, and that's fine. You do you.

For design-driven teams whose market rewards a great user experience, the way your team is structured matters now much more than it used to.

If the product decides the methodology, the team composition is determined by, well, however the team happened to form. In over a decade in this industry, I've never seen two software companies that operate the same way. Team composition depends on the chemistry of the people who are there. Even companies making over $10M in revenue sometimes run with no head of product at all. At that size, they'll almost always have a CTO, but they don't always have a CPO.

There are team shapes that show up often enough to recognize. A common one is a product owner running a group of developers, responsible for turning an initiative into shipped work. That structure is known as a pod. Sometimes that pod has a dedicated user experience designer. More often the design team is smaller than the number of teams that need it, so one designer supports several pods and spreads their attention across all of them.

Then there's the engineer-led team, where an engineer makes the product decisions and calls on UX only when something needs it, which is sometimes never. PostHog runs their product management this way, with the engineer as the product owner. Flip that model and you get the design-led version, where the product designer calls the shots and the engineer builds to those specs. And plenty of teams lean on offshore work, pairing project management on one side with a build team that just ships code on the other.

Their common theme is the handoff. The work gets divided among specialists and passed from one to the next. That division created a real limit on how much work a single person could do, and on how well two different divisions could collaborate.

Let's talk about the biggest bottleneck facing design-driven teams in traditional product discovery and design spaces. This is something I spend a lot of time thinking, speaking, and writing about. I call it the Two Planets problem.

In traditional product development, the product designer and the product engineer work on the same thing, but they live on different worlds. Each world has its own tools, language, and way of working. The designer lives on Planet Figma. The engineer works from Planet IDE. They work, from their separate planets, on the same screen, but describe it in different ways. Because they're so isolated, every handoff feels like a rocket launch.

The designers on Planet Figma package their designs and ship them to the other planet, hoping their work survives the trip. Once that rocket lands on Planet IDE, it's now up to the engineer to interpret the designer's work and translate it into Planet IDE's language, tools, and workflows.

A lot can get lost in translation. Sometimes the build matches the design intent. Sometimes it doesn't, and you only find out after the original work has finished making the round trip. Every round of feedback starts the trip over.

I've been leading product teams for over a decade. I've lived all of this. I've built the best prototypes Figma can build. I've stretched that tool as far as it can go. Every time, the actual test comes when a real person uses the real product.

That's when we can recognize fully what the deficits are: the incorrect assumptions that we made internally, the gaps, the bugs. All that discovery waits until the end, which is the most expensive place for it to be.

AI takes everything we've learned about the traditional UX design process and chucks it out a third-story window. It operates on an entirely different scale. A feature that would have taken a team three weeks in 2018 now takes three days. A screen that took an afternoon takes ten minutes.

Once the industry figured out what AI can do, it completely changed expectations from all sides. Buyers see products adding features every week, so they expect that from the products they pay for, too. Executives see teams that can do more with fewer people, so they start expecting that from their own teams.

What looked remarkable a year ago, and impossible five years ago, is the floor now. That's the new normal, so every team gets held to that baseline. That puts a lot of pressure on your team to ship more features, faster, with fewer bugs, and to keep pace as the standard climbs.

You'll need more than just an AI subscription to meet that demand. Your existing workflow was shaped by old tools, back when a designer could only draw a screen and an engineer had to build it from scratch. If you drop faster, better tools into that same workflow, you get the same problematic process, but slightly faster. The disconnect between the designer planet and the engineering planet still exists.

So we have to change the structure, along with the tools. Take Figma. Its role in the pipeline was to represent the web app in a form the engineer could build from. It provided a detailed picture of the software, but a picture is all it is.

Versions of this are already pretty common. Claude Design can stand up screens for you based on a conversation. It's good for modeling ideas fast. I use it to build information architecture diagrams and to get ideas out of my head quickly. That's the floor right now for designers who want to move faster. It definitely clears the old bar of producing flat prototypes for handoff.

Once a designer can produce something real, instead of a picture of something real, the separation between the designer planet and the engineer planet starts to give way. The designer and the engineer are getting closer to being able to live on the same planet.

Your first real move is to build a working web app in place of a prototype. A real, running version someone can click through, with actual screens and behavior. Because it actually runs, everyone downstream can work from the real thing.

Take the engineer. When the prototype and the production app get built from the same parts, the handoff doesn't need translation. Say the prototype uses a front-end library like shadcn, and the production app uses shadcn too. The screens the designer built use the same primitives as the real app will ship.

The engineer copies that code into the production application, has AI adapt it to fit, and spends their time on the backend that the prototype couldn't provide. You could still write a spec, but the need for one drops. Intent is more clear because they can work from code that already does most of the job.

The product manager also stands to gain from this process. They're the business mind gluing the two together, translating initiatives into tickets. With a Figma file, that means grabbing screenshots and reconstructing intent by hand. Doing that work from a running app is a totally different job. The manager can pull the repository, introspect it with their favorite LLM, and write the tickets.

I watched this happen on a recent client call. A project manager stopped before he left the call to tell the room that moving from Figma into a working application prototype, what we call the playground, has made his job so much easier. He doesn't have to dig through Figma for screenshots or fight the Figma MCP to write his tickets. In his own words, it made his life better, and helped him move faster.

But the biggest shift is for the designer, working inside the codebase itself. I'm doing this right now on a project for a company building a financial infrastructure platform for construction. We started by building a prototype app. Now we're contributing to the real web client, building screens, refactoring the ones that need it, and standing up new ones with seed data.

We basically work the way an engineer works. We create branches tied to specific tickets, finish the design side of the work, and hand it to an engineer to build the backend. They take the screen, wire up the real API endpoints, finish the work, and ship it. It moves the whole team faster than any handoff ever did.

As the old roles collapse, new ones form to take their place. I want to discuss four I think are really worth understanding.

First, you have the UX Designer. That title applies to someone who designs an interface without doing much product thinking or getting involved in product decisions. They're taking a defined problem, and they turn it into screens, and that's what they're good at.

A UX designer who refuses to evolve past this role is in trouble, and that's not going to get better anytime soon. There's no real place for them in the AI-forward software development lifecycle (SDLC). AI tooling is nearly as capable of producing a screen, but it's cheaper and faster.

Above the UX designer you have the Product Designer. That's how I refer to a UX designer who's good at product thinking. They don't just draw the solution to a problem in Figma. They work through a specific business problem, actually solve it, and translate that into the interface they're designing.

The value a product designer creates is in their judgment. They can assess problems, problem-solve independently, and execute high-level product thinking.

The Design Engineer is a craft-focused designer, just like a UX designer, but they don't do production art in Figma. Instead they can stand up real screens in a live application. They're not necessarily doing a ton of product thinking, but they're shifting their tooling and the way they work within the SDLC to create real interfaces in a real web app.

The roles of product designer and design engineer existed before AI. But at the time, these were considered exceptional roles for exceptional individuals. These days, they're table stakes, and a new exceptional role has emerged.

When the product owner, designer, and frontend engineer are one person, that person is what I call a Product Design Engineer. They own the outcome of the project, shape the experience, and ship the interface.

If you want to thrive in this new world, this is the role you need to be hiring for. This is the role that UX designers in the space need to work toward adopting. A product designer working in Figma won't cut it in design-driven development anymore. We need designers who can also think like a product owner, and work like an engineer.

Product engineers and product designers sold at a premium for years. In 2020, before AI developed into what it is now, a good product engineer could sometimes make as much as $250,000 to $400,000 a year. That's just as a contributor, with no leadership title. Just the work. Even nowadays, a good product engineer can clear $200,000.

At that time, the premium was on output. The work of writing code and producing screens commanded a high value because it was hard, slow, and few could do it well.

That's no longer the case.

When AI can stand up a screen or write quality code in a fraction of the time it took before, the market stops paying a premium for that work. That once-valuable work gets commoditized and priced down to whatever the fastest, cheapest source will charge.

Commoditization is coming for anybody who clings too hard to the old ways of the craft. Plenty of designers out there want to ignore AI and keep working the way they always have. They feel that the craft, Figma prototype and all, is the whole point. Those designers are the same ones who will end up watching their work get priced like a commodity while faster, more open-minded people ship more. Eventually they'll find themselves having to look for a new career.

So the product engineer who wants to make $200,000-plus in their contributor role today needs to realize what's changed. 80% of the value they generated in their job used to be in the code that they produced. That 20% that used to be their leadership, their thought, their direction, their protection over the codebase and the product, that's actually the 80% now.

If you are a company that follows design-driven development wanting to move faster and produce more and better output with AI, you need to start by seriously evaluating the role of the product designer.

Consider what you have. If you have a product manager running a UX designer who mostly produces UI, that designer's role will need to change. Maybe you do this by pushing them toward the design engineer role and have them stand up working screens in an app.

If, instead, you have a product designer already leading initiatives and doing the UI work, they might transition well into being a product design engineer. They do the product thinking, the design work, and ship the front-end screens themselves.

The project manager is the role that ends up getting squeezed. On small teams, they can slow the process down more than they add, and you can find yourself running without one. On larger engineering teams that require a lot of coordination and lack ownership, the project manager keeps their value.

The role a team needs depends on its stage of growth. A non-technical founder, full of Dunning-Kruger confidence, can now stand up an MVP from their garage alone. They can do it all themselves, whereas before they would have needed to hire offshore developers or engineers, or go looking for a CTO. Today, all those roles can condense into one person. That person can carry a minimum viable product a long way, to market, through validation, and into real revenue, with no one else.

Now take companies past MVP, in the $2M to $10M range. If you have solid product design engineers and product engineers, you can run at that stage without a project manager. Past $10M, when coordinating people gets genuinely tough, a project manager or product manager might earn their seat again.

We have a client in the CRM vertical, a $4M company in that growth stage. One product designer, part-time. One fractional CPO. Then a group of product engineers, who we call product engineers because they own their own work. We don't write their tickets, but we do hold them accountable to the outcomes of the business. We tell them to work with the product designer to get what they need to do it well.

Every shift outlined here does the same thing. It puts fewer heads on the same amount of work. Roles collapse enough that people can own more work. A team that used to need a dozen specialists starts to run on a handful, each carrying a whole outcome.

Let me be clear here about what I'm not saying. UX designers won't completely disappear in the next decade. Product designers won't, either. A team's makeup decides what role it needs, and there will still be teams that need these roles for years to come.

Here's what I am saying. On any team, in any configuration that utilizes design-driven development, the product design engineer will emerge as the most valuable role. That's what you need to be structuring for, planning for, and hiring for. That's the person who does the product thinking, designs the product, and ships the interface. They hold more value than anyone out there doing one of those jobs alone.

This is totally attainable, by the way. The product design engineer already exists. I'm one of them, and I work alongside them every day. This is a real, existing role that real people are filling right now. It's entirely in reach in this software era we're already in.

Your choice here is whether or not to join us. You can build toward this role, in yourself and in the people you hire. Or you can defend the job descriptions you already have. That's up to you, but I can tell you this: