How AI Is Changing Product Management: What PMs Need Next
AI is making it easier to turn an idea into a working prototype. For product managers, that raises the stakes of an enduring question: what is actually worth building?
In Enterpret’s webinar, The Future of Product Management: What Will PM Look Like in 2027?, Aakash Gupta joined Varun Sharma, Enterpret’s cofounder and CEO, to discuss how product work is changing.
Their conversation returned to a consistent theme: faster execution increases the value of customer understanding and product judgment. PMs have more ways to build, test, and investigate ideas. Their responsibility is to use those capabilities to solve the right problems.
Here are the shifts product teams should prepare for.
1. Deciding what to build becomes the central bottleneck
Aakash opened with an important distinction: progress in generating code does not mean every challenge in software engineering has been solved. Infrastructure, reliability, deployment, and production systems still require expertise.
But as teams can create prototypes and implement ideas more quickly, product discovery becomes an increasingly important constraint.
As Aakash put it, “the bottleneck has become figuring out what to build.”
For PMs, the opportunity is to spend more time understanding customers and testing assumptions. Work that previously consumed much of the week—drafting documents, answering routine stakeholder questions, and preparing updates—can take less time.
That creates room for a tighter discovery loop: identify a customer problem, develop a hypothesis, put a prototype in front of users, and use their response to decide what happens next.
The benefit comes from learning earlier, before a team commits to building something customers do not need.
2. Product impact needs to be measured beyond shipping velocity
If AI helps a team produce more features, counting those features becomes an even less useful measure of product success.
During the discussion, Aakash argued for measuring what he called a “product output metric.” His example was improved day-30 usage retention following the introduction of a new part of the product.
That distinction helps teams separate delivery from impact. Launching a feature tells you that work was completed. Understanding whether it changed customer behavior tells you whether it worked.
Product managers should define that expected change before development begins. What problem should the feature solve? Which behavior would indicate success? How will the team evaluate the result?
Business metrics still matter. Later in the conversation, Aakash emphasized connecting product analytics to revenue impact. The point is to understand the chain from what the team builds to what customers experience and, ultimately, what the business achieves.
3. There is no universal PM-to-engineer ratio for the AI era
One of the most practical parts of the webinar focused on team composition.
Aakash’s answer began with the company’s bottleneck. A developer tool, a consumer app, and an enterprise product may need very different combinations of engineering, design, and product expertise.
For a consumer product, the limiting factor might be how quickly the team can test and improve the user experience. For a product operating at significant scale, infrastructure and reliability may require more engineering investment.
In B2B software, another challenge can emerge: the people closest to buyers sit in sales and customer success, while the product team receives that knowledge indirectly. Aakash described the resulting burden as a “coordination tax.”
The implication for product leaders is to diagnose the work before changing the org chart. Where is the team struggling to learn, decide, deliver, or scale? Which expertise would address that constraint?
AI changes what people can accomplish. Team design still depends on the problems they need to solve.
4. PMs working on AI products need access to evaluations and traces
Building prototypes is only part of the expanding PM skill set.
For PMs working on AI products, Aakash emphasized access to evaluations and traces—the evidence needed to understand how a system behaves.
An evaluation helps assess the quality of an AI system’s output. A trace shows the sequence behind a particular interaction: which model was called, which tools it used, what context it received, and what happened before the result reached the customer.
That detail matters when a quality score changes. An aggregate metric can reveal a problem, but a specific trace can help explain it. Did the system choose the wrong tool? Miss relevant context? Pass an incomplete instruction to another agent?
Aakash also argued for read access to the codebase, alongside product analytics and business intelligence. Varun added customer feedback and customer intelligence to that picture.
Together, those sources help PMs connect system behavior with customer experience and business outcomes.
5. Customer context needs to be available where work happens
Varun described a change in how some Enterpret customers access customer intelligence: increasingly, they bring that context into their AI tools and agent workflows.
The underlying need remains familiar. Product teams need to understand customer conversations across support tickets, sales calls, reviews, and other sources. The challenge is preserving enough structure and nuance to make that information useful.
Varun described how some teams had tried building their own systems before discovering the difficulty of turning messy, varied conversations into reliable insights.
For product teams adopting AI, this creates a practical requirement: make customer evidence accessible in the tools people use to investigate problems and develop ideas.
An agent can help a team move faster. Its usefulness depends in part on the quality of the context it receives.
6. Product documents will change, while discovery and experimentation endure
In the webinar’s lightning round, Aakash predicted a lighter product requirements document: a prototype, a hypothesis, links to evaluations, and a plan for measuring results.
He also argued that roadmap communication, user interviews, and A/B testing remain valuable.
Those views fit together. AI can reduce the effort involved in producing an artifact, while the underlying work still needs to happen. Teams need a shared direction. Customers need opportunities to reveal what the team has misunderstood. Important product changes need evidence from real usage.
For product leaders, the same expectation extends to their own work. Aakash argued that leaders need time to build with AI tools and learn directly from colleagues using them effectively.
What product teams can do now
The conversation suggests a practical starting point:
- Define the customer outcome before committing to a feature.
- Use faster prototyping to test assumptions earlier.
- Choose team structure based on the product’s actual constraints.
- Give PMs working on AI products access to the evidence needed to investigate behavior.
- Bring reliable customer context into everyday product workflows.
- Keep investing in user interviews and real-world experimentation.
The PM role is expanding. Building, investigating, and testing ideas are becoming more accessible, and product teams have more opportunities to act on what they learn.
The advantage will come from connecting those capabilities to a clear understanding of customers—and making better decisions about what deserves to be built.
Watch the full conversation with Aakash Gupta and Varun Sharma →
