For twenty years, my job was figuring out what should get built. The role of “product leader” looked very different at every stage of my career.

At Mailigen, I was the product. I did the customer research, designed the workflows, prioritized the roadmap, worked directly with engineers, and shipped the features myself. Founder mode. Hands on every part.

At Pipedrive, I had to unlearn that. Scaling from 700 to 1,000 people through a PE transition meant leading through other product leaders. I stopped writing specs. I started shaping how my leaders shaped their teams. The work was upstream — strategy, hiring, organizational design.

At Aerones, I tried to go further. Not handing teams what to build — handing them problems to solve. Empowered teams running their own roadmaps. As a VP Product, telling teams what to build is the wrong thing to do. My job was setting direction, raising the quality bar, and getting out of the way.

Three companies. Three different ways the role looked. One thread running through all of them: the further I scaled, the less I touched the building directly.

And then the game changed again.

When AI compressed the cost of building to near-zero, the value chain shifted. The scarcest resource wasn’t engineering time anymore. It was judgment — knowing what’s worth building and creating the conditions for dozens of people to build the right things simultaneously.

My job stopped being “decide what to build.” It became: design the system that ensures the right things get built.

Chaos without meaning

Here’s what happens when you don’t make this shift.

You give everyone AI tools. Product Builders start shipping. Citizen Builders start solving internal problems. Engineers start building utilities. Everyone’s productive. Everyone’s building.

Within three months: five versions of the same dashboard. Three conflicting data models. Features nobody asked for. Internal tools creating security holes.

I watched this start to happen at Aerones before the operating model was in place. The tools don’t create the transformation. The system design does.

Speed without direction is the most expensive kind of waste. And the faster your team can build, the more expensive undirected building becomes.

Four hats

After going through this transformation myself — the identity crisis, the reinvention, the last six months at Aerones building the operating model in real time — I’ve landed on four modes that define the job:

1. Architect. Define domain boundaries. Decide which problems belong to which team. Design how products connect — interfaces, data flows, integration contracts. When six Product Builders are shipping simultaneously, someone needs to hold the whole system in their head. Not every feature detail — but the structure of how everything relates. At Aerones, our two-hub architecture (Performance Hub + Operations Hub) gave every domain decision a structural home.

2. Strategist. Portfolio prioritization. Which domains get focus this quarter? How much capacity does each get? Where do we invest, maintain, or cut? These are the hardest decisions in product leadership, and AI makes them harder because everyone can now execute on everything. The strategist makes the call: “Customer-facing core gets 60% capacity this quarter. Internal ops tools get 20%. Experiments get 20%.” Without that clarity, the loudest voice wins.

3. Orchestrator. Cross-domain coordination. Dependency management. Launch sequencing. When a feature requires two domain teams to collaborate, someone needs to coordinate timing, integration contracts, and shared deadlines. The operating cadence: weekly Product Builder + Technical Partner syncs, bi-weekly cross-domain alignment, monthly adoption reviews. Not more meetings — better meetings.

4. Coach. Building Product Builders. Teaching judgment, taste, and problem framing. Reviewing discovery work, challenging assumptions, catching scope creep. Not telling people what to build — teaching them how to decide. A Product Builder is judged by learning speed and impact, not by feature count. The coach creates the conditions for that kind of growth.

There’s a fifth responsibility that doesn’t fit cleanly into a hat, but matters more as the model spreads: raising the bar on software development across the entire company.

When Citizen Builders start building internal tools — and the strongest ones eventually contribute to core products through the graduation path — the product leader becomes responsible for software quality far beyond the customer-facing product. Internal tools that handle real workflows. Automations that touch real data. Side projects that quietly become load-bearing.

Without orchestration, this is where chaos gets expensive. Five teams build five different scheduling tools. Three Citizen Builder prototypes hit production with no instrumentation. Someone ships an internal tool that creates a security gap.

The product leader’s job is to set the standard — what good looks like, what guardrails apply at each tier, when something needs to graduate, when it needs to be retired. Not to police it. To make the path from “rough internal tool” to “production-grade software” visible and repeatable, so the energy across the company compounds instead of fragments.

LinkedIn’s CPO Tomer Cohen, in his conversation with Lenny Rachitsky, identified three pillars for making the Full Stack Builder model work: platform, agents, and culture. His conclusion: culture matters most. The tools are table stakes. The culture of ownership, judgment, and continuous learning — that’s what the product leader creates.

The “more PMs” counterargument

Anthropic’s Head of Growth Amol Avasare recently argued on Lenny’s podcast that companies might need MORE product managers, not fewer. His logic: AI tools like Claude Code make engineers 2-3× more productive, but team sizes stay the same. So PMs and designers are now managing what effectively feels like 15-20 engineers instead of 5. They’re “absolutely squeezed.”

He’s describing the problem accurately. The squeeze is real.

But his solution — hire more PMs — only works if you keep the handoff model intact. More PMs managing more engineers through the same spec→design→build pipeline.

The Product Builder model takes a different path. Instead of adding people to manage the growing output, restructure so each pair produces complete value end-to-end. The PM isn’t squeezed because there IS no PM in the traditional sense. There’s a builder who owns the problem and the solution.

Both approaches acknowledge the same reality: AI changed the math. They reach different conclusions. Avasare’s works at Anthropic’s scale and growth rate. For the 95% of SaaS companies that aren’t adding $6B ARR per month, the builder model is more practical.

What stays, what goes

Here’s what I want to say to every product leader going through this.

Your skills didn’t become irrelevant. Problem framing, user empathy, strategic thinking, stakeholder alignment, market intuition — these are MORE valuable now, not less. They’re the exact capabilities that AI can’t replicate.

What’s going away is being the person who does the work. The product leader who writes every spec, approves every design, reviews every launch plan — that person can’t scale when twenty parallel builders are shipping into core products, internal tools, and personal utilities all at once. Without a system, they all build whatever they want. With a system, they build what compounds.

What replaces it is being the person who designs the system and develops the people.

Claire Vo — three-time CPO, founder of ChatPRD, and host of How I AI — said something provocative: she believes strategic thinking as a differentiated human value is itself likely to be disrupted by AI. I partly disagree. AI can synthesize information and generate options, but it can’t hold the context of your specific company, your specific market, your specific team dynamics, and make the call that balances all of them. That’s judgment. That’s the product leader’s superpower.

But Claire’s challenge is worth sitting with. If you’re a product leader whose only value add is “I think strategically” — without building the system, coaching the builders, and ensuring architectural coherence — then yes, that gets compressed.

The leaders who combine strategic thinking WITH system design AND builder development will be irreplaceable. The ones who only have one of those will feel the pressure.

The operating rhythm

I’ll be honest — at Aerones, I was the Portfolio Manager. We didn’t have a separate role yet. So this isn’t a description of what I did. It’s what I’d recommend now, especially when the model scales to 20+ builders across core products, internal tools, and Citizen Builder programs. The goal: maximum throughput, minimum bottlenecks, with the product leader operating at altitude rather than getting pulled into every decision.

Here’s the rhythm I’d design:

1. Monday: Strategic sync with Portfolio Manager. Portfolio health, upcoming cross-domain initiatives, capacity adjustments. 45 minutes.
2. Tuesday-Wednesday: Office hours, not standing 1:1s. Builders book time when they need a sounding board, a stuck decision unblocked, or coaching on a tricky discovery. Pull-based coaching beats push-based check-ins at scale.
3. Thursday: Cross-domain prototype reviews with Design Ops. Consistency, UX quality, pattern sharing. Plus Gate 2/3 reviews when escalated.
4. Friday: Customer insight synthesis. Themes from sales, support, field feedback. Feed back to builders async — short Loom or written brief, not a meeting.
5. Monthly: Adoption + KPI review. Release planning. Architecture review with engineering lead. Citizen Builder graduation reviews — which prototypes earned their way into core?

Notice what’s not there: writing specs, reviewing mockups, approving backlogs, attending sprint demos. Builders own those. The leader owns the system.

The bottleneck risk isn’t capacity — the leader can scale to 20+ builders if the structure is right. The bottleneck risk is decisions. Every decision routed through the product leader is a queue forming. The Portfolio Manager exists to absorb most of those. Decision rights documents exist to absorb the rest. The leader’s calendar should be designed for the decisions only they can make.

The career shift of our generation

The way we build products is changing faster than most people realize. And the roles are changing with it.

The shift from “product manager” to “product leader who enables builders” is the most important career transition of our generation in product.

Not because the old role is dying overnight. Traditional PM roles will exist for years. But the companies moving fastest, building the best products, attracting the best talent — they’re moving toward builder models.

The product leaders who figure out how to be architects, strategists, orchestrators, and coaches — while letting go of being the one who does the work — will thrive.

The identity crisis is uncomfortable. The other side is worth it.

---

This is the final article in the Product Builder series. I’ve shared the model, the operating system, the human challenges, the Citizen Builder program, and the product leader’s new role — all from building this at Aerones since fall 2025.

If any of this hit home — if you’re in the middle of this transformation or about to start — I’d love to talk. This is the work I care about most.

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