In Q2, about half of our Product and Engineering contributors shipped production code on their own, including every PM and designer who took part.

Here’s the framework that convinced us to try it.

Clayton Christensen described three kinds of innovation:

Efficiency innovations help you do the same work with fewer resources. They free up capital, but they don’t create growth.

Sustaining innovations make good products better for the customers you already have. They keep you competitive, but the market stays roughly the same size.

Disruptive innovations are the ones most directly tied to growth. They open a technology to people who could never engage with it before, usually because of cost or access. In a real sense, they democratize it.

At a recent conference, I saw this framework play out in how engineering organizations adopt AI.

Some leaders only see the efficiency play: equip a few engineers with AI, get more output per person, reduce headcount. Nothing else changes, just the SDLC.

Others take the sustaining path: keep the team, upgrade every engineer with AI, and substantially increase output. The leaders furthest along change the PDLC too; PMs and designers use AI to keep pace with engineering.

Disruptive engineering is different in kind, not degree. Engineers stop being the people who work on the product and become the people who build the tooling, rules, skills, and pipelines that let non-engineers ship production code themselves, safely.

That’s what our Q2 experiment tested. But the tooling was only half of it. The other half was cultural: a build-first, do-and-show mentality we had been moving towards on our AI journey. Builders didn’t bring an idea to a kickoff meeting, they built first. Production-grade work moved at the speed of prototyping, so Builders walked into their first stakeholder conversation with something working to react to. Communicating an idea in words is hard. Giving feedback on something concrete is much easier.

Our PMs already had the stakeholder-management skills. Add the agents, the harness, and the build-first habit, and they solved problems that had been stuck for years:

One PM won cross-departmental buy-in for a feature that had been discussed for years and died on the vine every time. This time, she showed up with it built and stacked approval throughout the org.

A senior PM built two new service offerings herself, earning approval through constant demo-and-feedback loops. Another, while still learning what git is, did work that a full team had been planning to spend the rest of the year completing.

We learned what’s already easy, what needs more scaffolding, and what’s still aspirational. But the clearest takeaway: give PMs the ability to bring their own ideas to life, and they will.

(If the framework is new to you: The Innovator’s Dilemma defines sustaining vs. disruptive; The Prosperity Paradox adds the efficiency category. Both are worth your time.)

What the record shows

Written up after the fact, from our roadmap and issue-tracking systems.

One product manager owned 14 of the 38 roadmap items our flagship product shipped that quarter — 37% of the delivered output, while carrying ten other items alongside the work described above.

A stalled workstream moved from a pod to a single builder and finished in about a third of the time. The pod spent 136 days on an intake-form revision, one migrated notification, and a set of vendor webhooks. Moved to one PM working directly with agents, the replacement capability landed in 47 days. Worth noting: that pod was itself AI-assisted and already behind schedule, so this is not a comparison against a team working the old way.

The most useful result wasn’t the speed. Approaching the problem as a builder rather than a specifier surfaced something the integration work had obscured — that a third-party contract could be retired instead of extended. Deeper integration with that vendor shipped on 25 March. The capability that removed the need for it shipped on 16 April, three weeks later.

That last one is the argument for this whole approach. Speed is the visible result. Changing who is close enough to the problem to notice it is the real one.