The Best AI Engineers Are Product Managers
Why the skills that make great PMs are the same skills that unlock AI productivity for engineers
You hired a brilliant engineer. Top of their class, fluent in multiple coding languages. A full-stack developer who can optimize a database query in their sleep. Truly someone who communes with the machine. And you have provided them with access to the best AI coding tools money can buy.
Six weeks later, they're frustrated. "The AI writes terrible code. It produces garbage. It hallucinates. It ignores instructions." Meanwhile, a product manager down the hall (with a computer science minor from fifteen years ago) is creating impressive POCs for new concepts, and is actually shipping features that work.
What's happening here isn't about intelligence or technical skill. It's about using a completely different capability set to get the most from the tools...a skillset that engineering programs rarely teach, and which many experienced engineers have learned, slowly, second-hand (and sometimes begrudgingly), across many projects. This special set of skills is one that product managers practice every single day.
The Product Manager's Secret Weapon
Product managers live in the gap between what stakeholders want and what engineers build. Their job is translation. To vastly oversimplify, PMs are often responsible for the "What" and the "Why", while Engineers are responsible for the "How" and the "When".
Let's say a stakeholder says "make it faster." The PM figures out what "faster" means (page load? transaction throughput? time to value?), why it matters, documents the constraints, defines success criteria, and communicates all of this clearly enough that engineers can actually estimate how long it will take to build, and can implement the right thing. The PM speaks enough user to thoroughly understand the need, and enough tech to thoroughly convey an accurate definition of what success looks like and how to test whether it's been achieved.
This is exactly what working with AI requires.
When you prompt an LLM, you're not writing code. You're writing requirements. You're specifying outcomes. You're providing context about constraints, goals, edge cases, and quality bars. You're doing product management for an audience of one very capable, very literal executor.
The core PM skills that transfer directly:
Engineers trained to receive specifications may struggle when they must write them. Product managers have been writing them for years.
The Older Worker Advantage
Every previous technology wave followed a predictable pattern: younger workers adopted faster, older workers struggled to keep up. Email, smartphones, social media, cloud computing. The kids got it first. The veterans played catch-up (sometimes successfully, sometimes not).
The data indicates that AI-assisted development inverts this pattern (and our personal and anecdotal experience support this).
Studies consistently show that older developers extract more value from AI tools than younger ones. This baffles people until you understand what's actually happening. It's not about comfort with technology. It's about accumulated management and product experience.
A developer with fifteen years of experience has likely spent time as a tech lead, mentored junior engineers, worked closely with product managers, or stepped into PM-adjacent roles. They've learned (often painfully) that "make it work" isn't a specification. They've debugged communication failures. They've written design docs. They've translated business requirements into technical approaches.
They've been practicing the skills AI requires without knowing it.
A developer fresh from a bootcamp or CS program has deep knowledge of syntax, frameworks, algorithms, and modern coding languages. What they lack is experience specifying work for others. They've been the one receiving specifications, not writing them. When they sit down with an AI assistant, they try to collaborate like they would with a peer (vague, implicit, assuming shared context) rather than delegate like they would to a capable but context-free junior (explicit, structured, assumption-free).
That set of older developers who are more productive AI users treat the AI like a new hire who needs onboarding. That set of less-productive younger developers treat it like a peer who should just "get it." Only one of these approaches works.
Why Pure Engineering Skills Hit a Wall
Technical excellence is necessary but insufficient.
The engineer who thinks in code often prompts in code (or at least, in code-adjacent terms). They focus on implementation details before clarifying requirements. They assume the AI shares their mental model of the system (a classic explanation of what software engineering is suggests that the best engineers build the best mental models of the systems on which they're working...and that building a new feature successfully depends on expanding that mental model). An engineer who has been trained to talk to engineers who already have their own mental model of the codebase may get frustrated when the AI doesn't intuit what they meant from what they said...because it can't. It doesn't have the same mental models.
This is the same failure mode that derails engineers who become managers without learning management skills. Technical brilliance doesn't automatically translate to giving clear direction, providing useful feedback, or setting appropriate context.
Signs an engineer is struggling with the PM gap:
Every one of these maps to a common failure in human collaboration too. The AI just makes these patterns visible faster, because it has no ability to fill in gaps with tribal knowledge or read between the lines.
The PM Skills Nobody Talks About
Requirements writing gets all the attention. It's the obvious parallel. But the PM-to-AI skill transfer runs deeper than most people realize.
Research on product management consistently highlights a set of competencies that rarely appear in prompt engineering guides. Every one of them maps directly to AI effectiveness.
Prioritization and decomposition. Great PMs don't hand engineers a monolithic epic and say "build this." They break complex problems into tractable pieces, sequence them intelligently, and scope each one so it's achievable independently. AI work demands exactly the same discipline. "Build me an e-commerce platform" is not a prompt. It's a prayer. The PM instinct to decompose, sequence, and scope is the difference between a productive AI session and an afternoon of mounting frustration. This is one of the most frequently cited PM skills across the literature, and one of the least discussed in AI contexts.
Managing ambiguity. Product managers live in ambiguity. Requirements are incomplete. Stakeholders contradict each other. The market shifts mid-sprint. Good PMs don't freeze. They make progress with imperfect information, adjust as they learn, and stay comfortable with "good enough for now." AI outputs are inherently uncertain. The engineer who demands perfection on the first attempt will reject output after output. The PM who treats each response as a data point (useful, even when imperfect) will iterate toward a solution three times faster.
Influence without authority. This is the defining challenge of product management: you own the outcome but not the resources. You can't order engineers to build something. You persuade, frame, constrain, and guide. Working with an AI is structurally identical. You cannot command an LLM to produce excellent code any more than you can command a cross-functional team to ship a perfect product. You shape the conditions. You provide the right constraints. You guide without micromanaging. PMs do this instinctively. Engineers accustomed to direct control over their own code often struggle with this indirect mode of working.
Product taste. Elad Gil calls this "insights and intuition to understand customer needs." It's the gut sense that makes a PM look at a mockup and say "something's off here" before they can articulate why. In AI-assisted development, product taste is what lets you look at syntactically correct, functionally adequate AI output and recognize that it's solving the wrong problem. Or solving the right problem in a way that will confuse users, or is just plain awkward or ugly. The code compiles. The tests pass. And yet: it's not right. Product taste catches what automated checks miss.
Storytelling. PMs don't just write specs. They explain why something matters. Who it's for. What pain it relieves. What success looks like from the user's perspective. This turns out to matter enormously for AI quality. "Build a login form" produces generic output. "We're building a login form for elderly users who find complex authentication intimidating. Simplicity and accessibility matter more than feature richness. This is the first thing they see, and it determines whether they trust the application" produces dramatically better output. The narrative shapes the result. PMs frame narratives for a living.
Data-driven evaluation. Good PMs don't ship on vibes. They instrument features, measure outcomes, and make decisions based on evidence. This same discipline applies to evaluating AI outputs. Did the generated code actually improve performance, or does it just look cleaner? Does the refactored module pass the same edge cases as the original? The PM instinct to define metrics before building, then actually check them afterward, prevents the slow drift toward accepting "looks right" when you should be verifying "is right."
These aren't secondary skills. Across the major PM competency frameworks (from Product School's eighteen competencies to Ravi Mehta's twelve-competency model to Elad Gil's High Growth Handbook), these capabilities appear with remarkable consistency. They're what separate PMs who manage products from PMs who shape them. And they're what separate AI users who get acceptable output from those who get exceptional output.
The Engineering Foundation Still Matters
Before product managers reading this get too smug: technical skills remain essential.
An excellent PM without engineering background can specify requirements beautifully. They can articulate what the software should do, how users should experience it, and what constraints apply. But when it comes to guiding how the software should be built (architecture decisions, performance trade-offs, security considerations, technical debt management) they may be flying blind.
AI-assisted development amplifies this gap.
The AI will happily implement whatever architecture you describe (or don't describe). It won't push back when your approach creates scaling problems unless you have clearly outlined scalability as a key consideration. It won't warn you that your data model will cause pain in six months. It won't suggest a better pattern unless you ask the right questions.
Where engineering knowledge becomes critical:
A pure PM using AI can build a feature. An engineer-PM hybrid can build a feature that doesn't collapse under its own weight.
The ideal AI engineer isn't a pure engineer or a pure PM. It's someone who combines product thinking (clear requirements, good context, iterative refinement) with technical judgment (architecture sense, security awareness, performance intuition). The best AI results come from people who can specify what they want AND evaluate whether what they got is actually good.
Building the Hybrid Skillset as an Engineer
If you're an engineer (who wants to get better at AI-assisted development), the prescription isn't more prompting tutorials. It's product management fundamentals.
Learn to write requirements. Not code specs. Business requirements. User stories. Acceptance criteria. Practice articulating what should happen without specifying how.
Practice giving feedback. When something isn't right, don't just reject it. Explain why. What was wrong? What would right look like? This is a skill. It requires practice.
Develop context awareness. Before you start, ask: what does someone who knows nothing about this project need to know? Write it down. That's your AI briefing document.
Study iteration. Products improve through feedback loops. So does AI output. Expect three or four rounds, not one-shot perfection.
Learn to decompose. Before you prompt, break the problem into pieces. What depends on what? What can be done independently? What's the right sequence? If you're writing a single prompt longer than a paragraph, you probably need to split the work into smaller tasks.
Develop product taste. After the AI produces output, don't just check whether it runs. Ask: would I ship this? Would a user be confused by it? Is this solving the actual problem, or a convenient simplification of it? Train your gut by reviewing more code, not just writing it.
Get comfortable with ambiguity. Your first AI response won't be perfect. That's not failure. That's information. Treat early outputs as rough drafts, not finished products. The PM mindset is "what did I learn from this?" not "why didn't this work?"
Tell the story. Before you specify what to build, explain why it matters. Who benefits. What problem it solves. Give the AI the same context you'd give a new team member on their first day: not just the task, but the purpose behind it.
Building the Hybrid Skillset as a Product Manager
If you're a product manager who wants to leverage AI for development, the prescription is technical fluency.
Learn to read code. You don't need to write it fluently. You need to spot problems. Does this look reasonable? Is it doing what you asked?
Understand architecture basics. Databases, APIs, caching, authentication. Know enough to ask good questions.
Develop security intuition. Where do vulnerabilities live? What should you check?
Build your technical vocabulary. When the AI suggests an approach, can you evaluate it? Can you ask follow-up questions that matter?
Measure, don't assume. Define how you'll evaluate success before you ask the AI to build anything. Then actually check. Run the code. Test edge cases. Compare outputs. The gap between "looks good" and "is good" closes only with evidence.
The Organizational Implication
If PM skills predict AI effectiveness, companies face an interesting challenge.
Most organizations train engineers in engineering and PMs in product management. The roles are complementary, but training for the two tracks rarely intersect. But AI effectiveness requires both skill sets in the same person.
This suggests a few interventions:
The Bottom Line
The best AI engineers aren't the ones with the deepest technical knowledge. They're the ones who can think like product managers while retaining technical judgment.
They specify clearly. They decompose intelligently. They provide context (and purpose) generously. They iterate patiently. And then they evaluate outputs with product taste and engineering rigor.
The skills aren't new. They're the same skills that make humans effective at collaborating with other humans. AI just makes the gaps more visible and the penalties more immediate.
What's your experience? Are you seeing the PM-engineering hybrid outperform specialists in AI-assisted work? Have you found ways to build these skills in your teams?
#AI #ProductManagement #SoftwareEngineering #Leadership #TechLeadership #AIDevelopment #EngineeringManagement #FutureOfWork
Excellent article Keith MacKay; the necessity for the hybrid mindset is spot on.
This is a dramatic shift Keith .. when feedback cycles are hours instead of weeks, the traditional product manager → engineer → sprint demo model isn’t fast enough. That means PMs need to build some technical chops and rely on Claude for the rest.