Something shifted in how teams work, and most people are describing it wrong.
The common version: AI is automating jobs. Designers are worried. Developers are worried. Everyone's recalibrating. That story is real, but it's not the interesting part.
Here's the thing: the interesting part is what happens to the work when execution stops being a discipline and starts being a default.
For 23 years I was "the designer" on teams. The person who knew how to make things look right, work right, feel right. That role had value because the craft was difficult and the tools were complex. Teams hired me because they couldn't do it themselves. They needed the expertise.
They don't necessarily call on me for that anymore.
It's not that they stopped caring about quality. It's that the execution barrier dropped far enough that a founder with taste and an afternoon can produce something that works. Figma, AI tools, better templates – the gap between professional output and self-service output closed faster than most practitioners want to admit.
That market is gone. And something more interesting replaced it.
The teams I work with now – the larger ones, the ones where the work is genuinely complex – they're not dealing with an execution problem. They're dealing with a clarity problem.
Product managers, developers, designers: the lines between those roles are dissolving. Not because anyone is less skilled, but because the questions that matter most don't belong to any single discipline, and we're all essentially just becoming "builder" or "members of technical staff".
Now we ponder deeply on the following questions:
- What is worth building?
- What does success look like before we build anything?
- What problem are we actually solving, and is it the right problem to solve in the first place?
Those questions don't get answered by executing faster. They get answered by thinking better – together, before the build starts.
This isn't PM versus design versus engineering. This is a different kind of work.
Not design. Not product. Not engineering. Judgment.
The good news is "Design Thinking" prepared us for this all along. It's what intentional design is all about.
I've watched enough projects fail to know the pattern. It's almost never an execution failure. The team shipped on time, the design was solid, the code was clean. The product failed because it solved the wrong problem, or solved the right problem in a way nobody actually wanted, or launched into a market that wasn't waiting for it.
The question that would have caught it was never asked. Or it was asked too late, after six weeks of build, when changing course felt too expensive.
Here's what I learned: the most valuable thing an outside perspective provides isn't design skill. It's the willingness to ask hard questions before anything gets built – and the experience to know which questions matter.
The execution collapse didn't make expertise less valuable. It made the right expertise more valuable.
Ask better questions. Build less. Ship what matters.