The 17x Advantage: OpenAI's Product Builder Gap

TL;DR

• OpenAI's enterprise data shows non-engineering roles (Finance, Marketing) increased coding-related AI usage by 36% in six months
• The top 5% of users send 17x more coding requests than the median, and the gap between "Builders" and "Browsers" is enormous and widening
• Users who work across multiple task types (coding, analysis, writing) report 5x the time savings of single-task users

---

The day after I wrote about the rise of the Product Builder and the shift toward vibe coding, OpenAI dropped their 2025 State of Enterprise AI report.

The timing was coincidental. The alignment was not.

The data in this report doesn't just back up the theory that the PM role is evolving into something more hands-on. It quantifies the economic divide that's already formed between the people who are building with AI and the people who are browsing with it.

Three numbers from the report deserve your attention.

1. The Shadow Engineer is real

Technical work is bleeding out of the engineering department.

Coding-related usage by non-engineering roles (Finance, Marketing, Operations) jumped 36% in just six months. And 75% of workers report they can now complete technical tasks they previously couldn't touch.

Read that again. Three quarters of the workforce now considers itself capable of work that used to require an engineer. They didn't learn to code. The tools changed what "technical work" means.

This is the democratisation of building that every product leader should be paying attention to. When your marketing team can spin up a data pipeline, when your finance team can write automation scripts, when your product managers can prototype features, the traditional boundaries between "technical" and "non-technical" roles dissolve.

The implications for product organisations are significant. The PM who can build a prototype isn't just faster at their own job. They're operating in a world where their peers in other departments are also becoming builders. The bar for what it means to be "technical enough" is rising across the entire organisation, not just in product and engineering.

If you're a product leader still defining your role as the translation layer between business and engineering, this stat should alarm you. The translation layer is getting thinner by the month.

2. The 17x Advantage

The gap between the Builders and the Browsers is not subtle.

The top 5% of users (OpenAI calls them "Frontier Workers") are sending 17x more coding-related requests than the median user. Usage of Custom GPTs and Projects has exploded 19x year-to-date.

These aren't power users in the traditional sense. They're not people who figured out one clever trick and repeat it. They're people who have woven AI into how they work. They're building custom tools, creating reusable workflows, and shipping things that didn't exist before they sat down.

The 17x gap is important because it tells you something about the distribution of AI value capture. This isn't a bell curve. It's a power law. A small number of people are extracting dramatically more value from the same tools that everyone has access to.

For product leaders, this raises uncomfortable questions about team composition and enablement. If the top 5% of your organisation is generating 17x the output, what are you doing to identify those people, remove their blockers, and scale their patterns to the rest of the team?

Most organisations are doing nothing. They're treating AI as a uniform capability: everyone gets a ChatGPT license, everyone gets the same training session, everyone figures it out on their own. The data says this approach produces a massive capability gap, not a uniform uplift.

3. Breadth beats depth

The third number hits the bottom line.

Users who engage across a wider range of distinct tasks (coding, analysis, writing, research) report 5x the time savings of those who stick to the basics.

The compound effect matters more than any single use case. The person who uses AI only for email drafting gets marginal value. The person who uses it for prototyping, data analysis, content creation, and workflow automation gets transformational value. Same tool. Same cost. Five times the return.

This is the clearest argument against the "start small" approach to AI adoption that most enterprises are running. Starting small doesn't just slow you down. It structurally limits the value you can capture. The data shows that breadth of usage, not depth in any single task, is the strongest predictor of impact.

For product builders, this validates the full-stack approach. The PM who can prompt, build, and eval, moving fluidly between writing a spec, prototyping a feature, analysing usage data, and writing the launch comms, captures compound value that a specialist never will. The three skills that now define the modern PM all lean on this breadth.

The enablement question

If you read about vibe coding last week and thought it was just a buzzword, look at the numbers.

We are past the pilot phase. The Builders in your organisation aren't waiting for permission. They're already using these tools, often outside your sanctioned channels, because the productivity gain is too large to ignore.

If you're blocking your team from using these tools because of Shadow IT fears, you are actively suppressing your high performers. Yes, governance matters. Yes, data security matters. But governance should be an enablement function, not a gatekeeping function. The goal is to give your Builders the infrastructure to ship safely, not to prevent them from shipping at all.

The top 5% of your workforce is already building the future. The only question is whether you're giving them the rails to do it at scale, or forcing them underground where you can't see, govern, or learn from what they're creating.

---

Frequently Asked Questions

How should leaders respond to the "Shadow Engineer" trend?

Embrace it with guardrails. The instinct to shut down unsanctioned AI usage is understandable but counterproductive. Instead, build enablement infrastructure: approved tools, clear data policies, shared prompt libraries, and channels for Builders to share what they've created. Make the sanctioned path easier than the shadow path.

Is the 17x gap a problem or an opportunity?

Both. It's a problem if you ignore it: you'll end up with a small group of hyper-productive people and a majority getting marginal value from the same investment. It's an opportunity if you study what your top 5% are doing and systematically enable the next 20% to adopt similar patterns. The gap is not about innate talent. It's about behaviour and habits that can be taught.

Does breadth of AI usage really matter more than depth?

The data suggests yes, for time savings. This doesn't mean depth is irrelevant. Deep expertise in AI-assisted coding or analysis is valuable. But the compound returns from applying AI across multiple task types appear to exceed the returns from going deep in one area. For product builders especially, breadth is the natural mode of operation.