What Makes a “Good” AI Product Manager?

What Is an “AI Product Manager” (And Why Are They in Demand)?

After what appeared to be a shocking drop in product manager job listings starting in 2023, openings for product titles apparently increased 42% in 2025. Why is product management making a comeback?

Could it be that after a few years of teams using AI codegen tools to churn out large quantities of code faster, they’re re-learning important lessons about how the best products address customer pain points and provide a user experience that solves customer problems (and ideally delights them in the process) rather than “just doing things”?

Meanwhile, an emerging job title is the “product engineer,” which reportedly saw growth up to 400+ listings and counting for the previous year. Product engineers are expected to combine engineering analysis with product design,

We checked in with development veterans across the Heavybit community to dig into why product management is seemingly making a comeback in the age of AI, and what it means to be a good AI product manager or product engineer.

More Resources on AI Products & Startups

• Video: The GitHub Copilot Launch Story with Alyss Noland
• Article: Driving Productivity from AI Tools for Eng Teams with Laura Tacho
• Article: The Future of Software Documentation in the Age of AI with Heidi Waterhouse

Amit Eyal Govrin: The Future of AI PMs Is Blurry

Amit Eyal Govrin is the co-founder of Kubiya and a veteran of both the DevOps ecosystem and developer-focused go-to-market. He has previously served tours of duty at AWS, Cloudyn, and Panaya.

In the Age of AI, Context May Matter More Than Your Job Title

Govrin suggests that in the grand scheme of things, as more software products are built by AI tools, the skill that may come to matter most is not coding in a particular language, but rather, being able to utilize AI models properly. “When it's all said and done, there will only be one skill that matters: Context engineering. We know that LLMs are statistically based: Garbage in, garbage out. So if you have poor context, you’ll ship poor code, and you're going to have poor code quality.”

“We've worked with organizations that claim to be ‘AI native’ and sure enough, they wanted us to review and fix their broken code. Before, they were moving slower and were shipping X amount of code. Now, they have 10x or 20x more code, but it’s bad code.” The founder suggests that not being able to contextualize prompts for AI tools will simply lead to a bigger mess and a larger productivity drag as teams spend more time trying to fix garbage code outputs.

Amit Govrin discusses the need for engineering teams to evolve with AI on TheCube. Image courtesy SiliconAngle

Reflecting on what makes a “good” AI product manager vs. a “good product engineer,” the founder suggests that the semantics of job titles may not even matter in a few years. “I think the main cutoff is not going to be: ‘Did you come from the front end or back end or product?’ It's going to be your ability to be a context engineer and know how to instruct AI and delegate to it.”

“I actually think that a lot of the lower-level engineering roles, the juniors, are going to go away entirely if they don't know how to adapt across the stack. I think product managers who know how to prompt with context and know what they're asking for will become unbelievable engineers and replace entire engineering teams.”

Brian Douglas: Why AI Might Turn Us All into Product Managers

Brian Douglas is a veteran software engineer and developer advocate who has served tours of duty at Netlify, GitHub, and CNCF. He is also a longtime open-source software enthusiast, having previously founded OpenSauced and also hosts the Open Source Ready podcast.

Is Prompting An AI Like Writing a Product Spec?

Douglas reflects on how using AI every day has prompted him to rethink his own role, and how AI may be quietly removing the divide between being an engineer versus being a product manager. “As a former founder, I sometimes feel I'm ‘working myself’ into product management even when doing day-to-day engineering.”

The engineering veteran suggests that while using AI, building anything requires more product specs up front to properly guide models in the right direction. “I do way more planning and specs and GitHub issues. There’s more talking about the ideas, and getting the ideas on paper, because I know the AI will do so much better if you have a plan and you have a really well scoped-out task. But the AI would also do a better job if you had a design.”

For example, as front-end engineering becomes more AI driven, Douglas suggests that front-end projects may be driven more by AI-focused technical professionals who can direct AI tools with basic design sensibilities. “So there’s actually also design thinking. Where the boxes go, and what happens above the fold. All that stuff. For our Mission Control product, the front end was basically vibe coded by our CTO (who's not a designer).”

“Another engineer basically cleaned it up and made it mobile friendly because that wasn’t even considered at first. (Most folks who do front-end would start mobile-first, with ‘things in the box’ being the things we can use. And the desktop version only pulls from what the mobile version can actually give you.)”

Brian Douglas discusses open-source software strategy. Image courtesy Fintech DevCon.

AI Prompts: A Forcing Function for Thinking Like a PM?

Douglas suggests that in some cases, AI tooling may be reversing the typical sensibilities of building front-end products. “But when you do the inverse, you might just tell your AI to make something work. ‘Put stuff on the page and then we'll figure it out later.’ Any front-end engineer would tell you: ‘No, don’t do that. We're going to end up with some weird tech debt. Let's think about this stuff first.’”

The veteran dev notes that relying on AI tooling can feel like a forcing function that leads builders to consider foundational product considerations, including performance and security. “I’ve used some of the Chrome-based MCP tools, for instance. When you reach the Chrome console you hit the recorder. It'll tell you your largest contentful paint (LCP), your First Contentful Paint (FCP)...all stuff that you're supposed to be doing anyway.”

“Usually when you need to ship something, you don't really think about it because you're just trying to get it out the door. But now, this is becoming more of a process in which we’ll ask: ‘Before we go live, did we run it through the Chrome MCP? Did we get things like the page load speeds to see if we have any regressions?’”

Douglas compares shipping products using AI tools to GitHub Actions’ intended purpose of providing CI/CD for projects. “Before you hit push, you could actually have the stuff all run. So we're now seeing a shift where you’ll start thinking of things you wouldn’t have before: Security, speed, and performance. You can think about that before you push. Now after your agents are done, they’re introducing themselves into quality assurance and checking.”

Alexandr Kurilin: Engineers Should Already Have Product DNA

Alexandr Kurilin is a longtime software engineer, investor, and serial startup founder. He started his career as an engineer at Microsoft, then went on to co-found startups such as Freckle (acquired by Renaissance), ConceptualHQ, and now DoubleDusk.

Product Manager Thinking Has Always Been a Best Practice for Builders

Kurilin suggests that engineers with a product focus have always been important. “This has been a motif in my hiring process for a long time. I want very ‘product-y’ engineers. This might be a hot take, but let’s just say...there are firms that have a lot fewer PMs than you would expect. And that trend is only going to continue with engineering AI augmentation and the merging of previously separate disciplines.”

The founder suggests that regardless of any changes AI may be making to engineering, the best engineers tend to care more about the big picture. “For me, personally, I would never hire an engineer who simply doesn’t care about how the user feels about what they’re doing, how it impacts them, where the modules they implement will be used, and the context of it all. Why? You have to care about the layer next door, be that other engineers using your interfaces or the user.”

“It would be valuable for you, as a back-end engineer, to understand not just what the front-end folks are doing, but why they're doing it. And if you understand really well what use case, what job-to-be-done they're trying to solve, you can work together much better on actually solving what the user ultimately needs instead of just being given a spec and blindly executing. As an engineer, you're not just a coder. You're supposed to be a kind of psychologist, thinking about humans whose problems you're trying to solve.”

I would never hire an engineer who doesn’t care about how the user feels about what they’re doing. You have to care about the layer next door.” -Alexandr Kurilin, Founder/Double Dusk

How AI Is Changing Engineering and Product-Based Thinking

The founder notes that AI-driven change for software development may be the same change we’ve seen for years. “It’s about moving up the abstraction chain, which is just what computing has been doing for the last century. We’re just trying to give more and more leverage to software developers to worry less about implementation details and go higher up the value chain to get closer to the human problems they're trying to solve.”

“We’re at the beginning of the next evolutionary step: We don't care about the implementation details of individual code modules as long as we can verify that these black boxes are doing what we expect them to. If the coding agent can prove through tests and type systems that the module will behave according to spec, we don’t actually need to peer inside. If all of our validations pass, and the agent can keep maintaining that isolated blob of logic in perpetuity, why worry about the internals?

However, Kurilin notes with interest the rise of the “AI engineer” job title, and what it might mean in the age of LLM-powered products. “On some level, like with a lot of things in Silicon Valley, people are rebranding something already well-established. At one point, and at some companies, ‘AI engineer’ meant an ML and data scientist who moved into more of a product engineering role.”

“I actually don't think that's true anymore. I think for some companies that just means a ‘product engineer,’ who mastered how to wrangle LLMs into the product to add useful AI functionality for the end-user. It’s now all about iterating on the optimal prompts, curating evals, context management, tool calling, model selection, caching, cost management and much more.”