Bottleneck or Bisect: AI-Assisted Coding Will Change Product Management
Product Management Will Be Split Between ‘Slow Platform’ and ‘Fast App’ Modes
When OpenAI announced they were building a consulting service staffed with “forward deployed engineers” — a term Palantir popularized1 — the AI ecosystem took notice.
The FDE trend is a symptom with two underlying causes.
First, onsite dev is an expected capacity for companies selling new categories, where you have to teach your customers how to use your product after they buy it (ideally, before the contract runs out).
Second, and more significant for the broader software industry, FDEs represent a workaround for a growing problem. AI-assisted engineers can code 2-5x faster, but product management work hasn’t accelerated at the same pace. Rather than wait for traditional PM processes, organizations are empowering hybrid engineer-PMs to build directly with customers. To maintain relevance and continue to help their companies ship stable, safe, successful products, product managers and organizational structures need to adapt.
Let’s look at both these causes, in order.
1. Businesses Building New Categories Have to Teach
Every product falls into one of two categories: those that sell into existing budget lines and those that must create new budget lines.
If you’re a startup with a product in the former category, your playbook is relatively simple. Your product must outperform the incumbent – with better features, services and/or reduced cost – while your go-to-market team needs to deploy marketing and sales tactics to break through the noise and close deals.
If your product falls into the latter category, your task is much trickier. No budget line exists for your product, which means one has to be created. You need to cultivate a champion at your prospective customer, someone who is going to either do the hard work of justifying the new budget (if you’re going bottom-up) or an executive who is going to add the budget line by edict (if you’re going top-down). When I was at PlaceIQ, we utilized both approaches.
To find your champions, you need to market your new category, defining and proving its value.
And the hard work doesn’t end after you create a budget line and close the deal. Now you have to teach your customer how to use your product. For simpler products, this can look like textbook customer success services. But for more complicated products, especially those customers use to build something with (like AI APIs), this looks like high-touch consulting.
If this weren’t hard enough, there’s a time limit for success. You gotta help them build value before the contract runs out.
OpenAI’s enterprise products are clearly in the latter of our two buckets. They, and all enterprise AI vendors, can’t count on their customers to build innovative applications with AI. They’re going to have to help them. Which is why there’s plenty of new “Forward Deployed Engineer” openings.
2. AI Reshapes Product Management Because it Speeds Up Development Iteration
To understand how AI redefines the product management role, let’s first look at how AI-assisted coding is changing our development cycles.
Of course: standard caveats apply. AI-assisted coding is unevenly distributed. Many companies are slow to adopt these new tools. Many engineers haven’t had the time or motivation to explore and learn new AI development patterns. Models are great at some languages and tasks, and bad at others.
Yet: every startup I’ve met that has built products in the agentic era demonstrate the following:
- AI makes coding faster. My anecdotal experience and observations align with Simon’s, “I’ve estimated that LLMs make me 2-5x more productive on the parts of my job which involve typing code into a computer, which is itself a small portion of that I do as a software engineer.”
- AI makes prototyping faster. The product managers and engineers I know who’ve embraced AI will quickly develop frontend demos rather than multipage specs. As we learned during the Agile era, giving collaborators, customers, and users something to react to results in better and more efficient feedback.
- Iteration is faster. This is a result of the previous two bullets. Faster iteration builds better products. Teams that ship more win
When you ship more, you have more opportunities to learn. Your rate of improvement increases and you accelerate away.
But it’s the coding that is driving this speed. Everything else is seeing much smaller, if any, acceleration from AI.
At a recent Y Combinator Startup School, Andrew Ng put his finger on this dynamic:
While engineers are becoming much faster, I don’t see product management work – designing what to build – becoming faster at the same speed as engineers. I’m seeing [the product management to engineering] ratio shift.
Literally yesterday, one of my teams came to me, when we’re planning headcount. This team proposed to me not to have 1 PM to 4 engineers but to have 1 PM to 0.5 engineers. I still don’t know if this proposal is a good idea, but it’s a sign of where the world is going. And I find that PMs that can code or engineers with some product instincts often end up doing better.
With the pace of coding accelerating, product has become the new bottleneck.
Teams are now chasing hybrids – product managers who can code and engineers with product instincts. The explosion in Forward Deployed Engineer roles demonstrates this. FDEs are essentially product-minded engineers – hybrids who can both build and understand customer problems. Their rapid emergence isn’t just about teaching new categories; it’s early proof that organizations are gravitating toward these dual-skilled roles.
While we’re seeing FDEs emerge at AI labs, this shift will affect every software company leveraging AI-assisted coding – whether they’re building AI products or traditional applications with AI-enhanced development cycles. The catalyst isn’t AI products themselves, but AI tools that dramatically accelerate the coding portion of product development. By embedding these incredibly valuable hybrids with domain experts, you increase the surface area of your fast iteration loop.
So do product managers go away?
No, there’s still plenty of product work to be done to graduate a product from a rapidly assembled app or feature to a robust service: research, compliance, sales ops, product marketing, and more. Further, a FDE focused on building for one client doesn’t have the time to take in the bigger picture, both qualitatively and quantitatively. And if companies over-optimize for speed, skipping traditional product management steps, they’ll eventually get burned.
Take last week’s GPT-5 launch, where OpenAI had to manage a mountain of upset 4o users who had developed an emotional attachment to GPT-4o’s tone. Instrument ChatGPT all you want – analyze and sort consumer queries into buckets of use cases – and you’d still miss that a chunk of users related to 4o as a friend.
Rather than go away, I think the function of product management will get bisected into two domains:
- Application Product Managers: These roles work closely with customers or partners, and are often “hybrids”: product-minded engineers or product managers who code. They rapidly absorb domain expertise and use it to rapidly iterate products and features. This is product management and engineering, blended with customer success and consulting.
- Foundation Product Managers: These roles build the core platform upon which Application Product Managers build. They design the APIs, data structures, and core business logic. Further, these core teams productize innovations developed by application product manager teams, handling compliance, security, QA, and more.
Naturally, the amount of definition between these two domains is dependent on the size of the company and the nature of the product. But this set up attempts to preserve the speed of AI-assisted development, the need for traditional product management functions, and any need to teach customers how to use your product.
But at larger orgs, there will be many pods of forward-deployed engineers and application product managers. They’ll optimize for speed and customer utility, tossing back innovations that find traction to foundation product teams, who prepare them for wider use. The core platform, that powers the FDEs, is maintained by centralized, slower foundation teams. These core product management teams will effectively negotiate the speed difference between the fast app teams and everything else.
The speed gains from AI-assisted development and the need to teach companies how to use AI-powered products dictates that technology companies embrace forward-deployed work. Product management is going to have to evolve to support speedier engineers, not be a bottleneck, and help their organizations ship stable, safe products.
This adaptation may look like the divide I detail above, or it may look like adoption of new, AI-powered tools that grant speed buffs to traditional product work. Currently, my money’s on the former.