A product manager volunteered to become one of our first Product Builders at Aerones.

He was great at discovery. Sharp problem framing. Clean workflow maps. Solid stakeholder communication. His specs were some of the best I’d seen.

But he wouldn’t build.

He kept writing specs and handing them to engineers. Same pattern as before, just with a new title. “I’ve done the discovery,” he’d say. “Here are the requirements.”

Nothing changed.

Then something shifted. He picked up the hammer. Started building himself. Clunky at first. Lots of bugs. But working software, in users’ hands, with real feedback coming back.

The energy unlocked. I watched it happen in real time. He rediscovered the beauty of the craft — not just thinking about what should exist, but actually making it exist. The gap between idea and reality collapsed from weeks to hours.

You can’t spec your way into being a builder. You have to pick up the hammer.

And here’s something worth noting: the PM who started building wasn’t becoming a worse version of an engineer. He was becoming a new kind of builder — leveraging domain knowledge, user empathy, and design instinct that engineers don’t have, amplified by AI tools.

The kings and queens

And then there’s the other side. The harder side.

For as long as software has existed, engineers have been the ones who make things real. Nothing happened without them. That’s power. That’s identity.

Now suddenly, non-engineers can build working software with AI tools.

Last month, your engineers were the kings and queens of the product org. This month, a product manager shipped a feature without them.

I watched this happen at Aerones. Some engineers were skeptical. Some dismissed AI code as “vibe coding.” Some were quietly scared.

The tension is real — and it’s widespread. Most developers are experimenting with AI tools, but trust in the outputs is actually declining. They’re using the tools because the promise is obvious. They’re skeptical because they’ve seen what the tools get wrong.

And here’s what makes this complicated: the skeptics are partly right.

The honest truth about AI-built software

Software built by non-developers with AI tools will not be as good as an experienced engineer-crafted solution. Even with AI assistance.

The architecture won’t be as clean. Edge cases will be missed. The code won’t be as maintainable. I need to say this clearly because the hype cycle doesn’t.

This is precisely why the Product Builder model pairs every builder with a Technical Partner from day one. The PB builds 70%. The TP handles the 30% that matters most for long-term system health — architecture, deployment, data model integrity.

When I saw this work well at Aerones, it was always the pairs. The builder brings speed, domain knowledge, and user empathy. The TP brings engineering depth, system thinking, and quality standards. Together they ship fast AND well.

When I saw it fail, it was always one of two patterns: a builder trying to solo it and getting stuck, or a TP brought in too late to rubber-stamp a decision they should’ve co-made from the start.

The identity crisis is universal

What I didn’t expect: the crisis hit everyone.

1. Engineers shifted from “I build everything” to “I ensure everything is built well.” From sole creator to co-creator and architecture guardian. For the best engineers, this was a gift. For those whose identity was wrapped up in being indispensable, it was terrifying.
2. Product Managers shifted from “I decide what to build” to “I build what I decide.” The PM at Aerones only transformed when he stopped specifying and started making.
3. Designers shifted from “I design every screen” to “Builders prototype, I ensure consistency.” Some became incredible Product Builders. Others found their highest value in Design Ops.
4. Product leaders — including me — shifted from “I control the output” to “I design the system.” Twenty years of craft, repositioned to a higher altitude.

Every single person going through this transformation faces the same question: “If the thing I was known for is changing, who am I now?”

How to actually manage this

The change management is harder than the technology. Six things that worked at Aerones:

1. Start with volunteers, not mandates. The people who raised their hands were self-selected for curiosity. Forcing someone to become a builder creates resentment, not transformation.
2. Pair early, pair tight. Every builder got a Technical Partner from day one. This solved two problems: builders got engineering support, and engineers stayed involved and valued.
3. Expect the first pilots to be met with skepticism. Even after we shipped a core module in one week, people didn’t believe it would scale. Don’t argue. Run the next pilot. Results compound faster than arguments.
4. Create a change agent inside engineering. At Aerones, our applied AI engineer built the toolkit and taught the first builders. He was seen as radical at first. But he built the path from the inside.
5. Get CEO-level sponsorship. Use ADKAR framework: Awareness and Desire from the top. Knowledge and Ability from the bottom up. Both directions, simultaneously.
6. Don’t skip product thinking. Problem discovery, workflow mapping, jobs-to-be-done, user validation. Before anyone touches AI tools. The builders who skip straight to “vibe coding” build the wrong things fast.

The energy on the other side

I want to end with this because the identity crisis story can sound heavy.

Every person at Aerones who made it through — every PM who became a builder, every engineer who became a TP — said the same thing.

It was the best professional growth of their careers.

Not because it was easy. Because it was real. They went from talking about building to actually building. From specifying outcomes to creating them.

The world is moving this direction. The people who go through the identity crisis now will be the ones who define what “product” means in five years.

The identity crisis is real. And the other side of it is worth the discomfort.

---

I’ve navigated this transformation personally and led it at Aerones. If you’re a product or engineering leader trying to figure out the human side of this shift — the technology is the easy part. DM me on LinkedIn or reach out at operatingleader.com.

---

Next in this series: The Citizen Builder — the second layer nobody’s talking about, where non-engineers across your company start solving their own problems.