Fall 2025. I watched our applied AI engineer rebuild an internal tool from scratch in a couple of weeks. A tool that replaced a third-party vendor solution costing us €100,000 a year. One engineer. Business-minded, technically brilliant. Done.

The rest of the engineering team thought it was a party trick. Nice demo. Won’t scale. Doesn’t apply to real products.

So we ran a pilot.

Here’s the thing — I’ve been leading software product development for twenty years. I am not a developer. Never have been. My background is product strategy, product design, and company building. I’ve worn the product and design hats my entire career.

But I partnered up with that same engineer, brought my product and design thinking, and within one week we delivered a fresh new module inside a core client-facing product at Aerones. Not a side tool. Not a prototype. A production feature inside our legacy product stack.

Our team’s estimate for that same work? Three months.

That week changed everything for me. I saw what I cannot unsee.

The identity crisis nobody talks about

I want to be honest about something that most product leaders won’t admit publicly.

After that pilot, I had a genuine professional identity crisis. For twenty years, I’d been building my craft — product discovery frameworks, design thinking practices, stakeholder management playbooks, prioritization models. My entire professional identity was wrapped up in tools and methods I’d spent two decades collecting.

And in one week, I watched the world shift underneath all of it.

Not because the skills don’t matter — they do, more than ever. But because the way those skills get applied changed completely. The product person who writes specs and hands them off? That person is disappearing. The product person who can frame a problem, prototype a solution, build it alongside a technical partner, and drive adoption end-to-end? That person is the future.

I had to rediscover what I actually bring to the table as a product leader, CPO/VP Product. And I believe I found it: in this new world, a real product leader is an architect, a strategist, an orchestrator, and a coach. Because when you give people the power to build — and I mean everyone, not just engineers — you need someone making sure they’re building things that matter and they get successfully rolled out and the value extracted by your customers.

That fall of 2025 is when I came up with the Product Builder role and the Citizen Builder program. Not from theory. From living through the transformation myself.

The model that’s dying

The PM→Designer→Engineer pipeline made perfect sense when building was expensive. Three+ handoffs. Clear roles. Predictable cadence. Also: 12-16 weeks from idea to shipped feature.

And three handoffs meant three+ places where context got lost, it depends on software engineers involved in the project. The PM’s understanding of the customer pain got compressed into a spec. The designer’s intent got simplified into components. The engineer built what was described — which was often not quite what was needed.

Just this week, Anthropic’s Head of Growth Amol Avasare confirmed the same pressure from a different angle on Lenny Rachitsky’s podcast. His take: AI tools like Claude Code make engineers 2-3× more productive, but team sizes stay the same. A team that was 5 engineers with 1 PM now effectively operates like 15-20 engineers with the same 1 PM. His words: PM and design are “absolutely squeezed.” Anthropic’s response is to hire more PMs. That works if you’re Anthropic — growing from $1B to $19B ARR in 14 months. For everyone else, there’s a different answer.

Claire Vo, three-time CPO and founder of ChatPRD, put it well: building solo increases quality and velocity because you’re short-circuiting the translation loop between product, engineering, and design. When one person plays all those roles, you stop losing fidelity.

And here’s the part that should worry every product leader: most companies responded to AI by giving their teams better tools while keeping the same structure. Faster coding inside the same handoff pipeline. The results? Marginal. McKinsey found that while 80% of companies are using AI, only 5% see meaningful bottom-line impact. Because you can’t get 10× by doing the same thing slightly faster. You get 10× by restructuring how work flows.

What a Product Builder actually is

A Product Builder is not a PM who learned to code. And it’s not an engineer who learned to talk to customers. It’s a fundamentally different role.

What a Product Builder owns:

1. A domain — not a feature list, but a complete problem space with clear boundaries
2. The customer problems in that domain — through direct discovery, not secondhand specs
3. The solutions — UX, workflows, implementation, built with their own hands
4. Shipping AND adoption — features that don’t get used are failures, not launches
5. The success metric — measured after shipping, not assumed before it

The distinction that matters: a PM who codes is still thinking in specs and handoffs. A Product Builder thinks in problems and shipped outcomes. They don’t write a PRD and throw it over the wall. They frame the problem, map the workflow, prototype a solution, build it (or most of it), and make sure users actually adopt it.

The pair that makes it work

Product Builders don’t succeed solo. I learned this the hard way.

The PBs who had a Technical Partner from day one thrived. The ones who tried to go it alone got stuck in bugs, deployment issues, and that painful last stretch that separates a prototype from production.

Think of it like a startup co-founder duo. The Product Builder owns the problem space, the user relationships, the domain — they build roughly 70% of the final product with AI tools. The Technical Partner handles the remaining 30% — architecture, deployment, quality, the engineering depth that AI tools still can’t match.

The Technical Partners loved it. In the old model, they’d receive a spec, build it, get notes, rebuild it. In the new model, they’re co-creating from day one. Partners, not ticket-takers.

This isn’t a fringe idea

LinkedIn’s CPO Tomer Cohen, on Lenny Rachitsky’s podcast, described scrapping their Associate Product Manager program entirely and replacing it with an Associate Product Builder program. He created a formal “Full Stack Builder” title and career ladder — anyone from any function can now take products from idea to launch. His diagnosis of the old model: organizational bloat slows features to a six-month cycle.

Lovable, the AI-powered development platform, hit $10M ARR in 60 days with 15 people, $400M in 2 years with 100 people. Their founder Anton Osika’s take: the biggest bottleneck is shifting from “who can build it?” to “who knows what to build?”

Pipedrive — where I was VP Product before Aerones — is moving the same direction. AI champions in engineering, pairing on real tasks, weeks becoming days. And of course Aerones, where I led the introduction of the role and structure with lot’s of triels and errors, but reacehd a state that shows the future.

Same pattern. Different companies. Different industries. Same conclusion.

The 15× math

Here’s where I need to be precise, because claiming 15× sounds like hype. It’s not — but it requires honesty about what the headline studies are actually measuring.

When you hear “developers are 56% faster with AI” — that’s one person completing one coding task faster. Useful. But it completely misses the structural shift. Industry surveys measure AI within the old model. Same handoffs, same pipeline, slightly faster coding.

The real gains come from two observable factors:

1. Cycle compression (5-8×). A feature that took our team 8-12 weeks in the old model — idea through spec through design through build through launch — now takes a PB+TP pair about 1 week. That compression includes everything: eliminated handoffs, AI-assisted building, faster user feedback, thinner slices. Using 5× as the conservative floor.
2. Parallelization (3×). One tribe/team/squad restructured into three PB+TP pairs. Three features shipping simultaneously instead of one pipeline feeding sequentially.

3 × 5 = 15×. At maturity it’s higher. Claiming 15× is the honest floor, not the ceiling.

One pipe delivering in weeks. Three pipes delivering in days. At Aerones, this is what we saw at maturity. Early pairs won’t hit this on day one — expect 1-2 weeks per feature during ramp-up. Mature pairs hit 3-5 day cycles. The compound effect is real.

The infrastructure nobody talks about

Two things have to be true before this works.

You need a change agent inside engineering. At Aerones, we had a strong applied AI engineer who built the AI development toolkit, piloted it, taught the first builders. Without this person driving enablement from the bottom up, the transformation doesn’t happen or is very challenging. You can’t mandate your way into AI-first development.

You need CEO-level sponsorship. Using the ADKAR framework — Awareness and Desire come from the top. Knowledge and Ability get built from the bottom up. Both directions, simultaneously.

Without either one, you get politics instead of progress. The tools alone do nothing. The system redesign is everything.

The bet

Small, accountable domain teams + clear strategy + strong judgment will outperform large, process-heavy organizations.

That was the bet we made at Aerones. It paid off. The companies that figure this out in the next 12-18 months will pull ahead.

It’s not about AI replacing people. It’s about AI changing what work looks like so fundamentally that the org chart has to follow.

---

I spent 6 months building the Product Builder operating model at Aerones — operating loops, quality gates, onboarding playbooks, decision rights, and the Citizen Builder program for non-engineers. If you’re a an engineering leader, VP Product, CTO, or CEO figuring out how to restructure for AI-first development, I’d love to compare notes.

DM me on LinkedIn or reach out at operatingleader.com.

---

Next in this series: How One Team Achieves 15× Value Delivery — the operating model, decision rights, and quality gates that make it work.