AI

Your Approach to AI Depends on Your Approach to Product Development

On August 27th, 2026, renowned author, product management expert, and founder of the Silicon Valley Product Group, Marty Cagan, was interviewed for a well-attended Webinar on the subject of “AI First.” If you haven’t, I cannot recommend highly enough that you and your team take an hour to sit down and watch the entire interview available on Enterpret’s Web-site. Cagan was interviewed for about 40 minutes by Jack Divita, Head of Customer Success at Enterpret. And afterward, Cagan fielded a few questions from some online attendees.

Mr. Cagan is one of my most admired thought leaders on the subject of effective product organizations and I am the proud owner of two very dog-eared copies of each edition of his highly influential book, ‘Inspired.’ I quote him often in the case studies I present on this Web-site. To me, this interview was required reading.

In a time of mass disruption in the software business, in which everyone wants to operationalize AI in the most effective way possible, it is obvious as to why they would seek out the wisdom of Cagan, one the most influential voices in our field.

What does he think? That’s what everyone gathered wanted to know. And he gave us all a real earful.

Effectively, Cagan’s take boils down to this. That how you operationalize AI depends very much on which of the two most prevalent models of product development you’re embracing. These are what Cagan refers to as the ‘Project Model,’ and the ‘Product Model.’

In the more ubiquitous Project Model, the one we’re all most familiar with, a product team receives what amounts to requirements from leadership ( and just as often design direction ). They want this feature now because it’s next on a roadmap that is being driven by clients and sales cycles. And the team is expected merely to execute on the request. In this model, the emphasis is on building to earn. What prototypes are created get judged by how quickly they can be turned in to production code. The goals are output and time to market. When AI is added to this model, the blurring of roles gets supercharged. Engineers are designing, designers are coding, and product managers are either disappearing or being reduced in status to glorified project managers.

Conversely, in the Product Model, the emphasis is on build to learn. Prototypes are used for discovery and testing. Testing not just with stakeholders and users, but with developers to ensure they can build it. With your legal, financial, sales, marketing, and customer success teams to ensure your approach comports with the overall goals of your company (and doesn’t put it at risk for unintended consequences). The goals in the Product Model are centered around outcomes, not output. As in, does this solution actually solve our client’s problem? Or does it just check a box in some salesperson’s PowerPoint? And goals are centered around time to money, as opposed to time to market. As in, the focus is on product outcomes that will demonstrably drive revenue as opposed to market position. When AI is added to this model, roles stay more or less defined. Designers mostly design. Coders mostly code. And product managers retain their vital position in the product org. What changes is that more and better protoypes get generated. And faster.

So in short, your AI strategy depends on which of these models you embrace.

If it is the Project Model, the next question you may want to ask yourself is whether or not there is any evidence to suggest that adding an AI-First approach to the mix is going to solve your problems.

So far the answer, in a word, is no. Rather the opposite.

Both McKinsey and Atlassian have written recently on what is coming to be referred to as the “AI Productivity Paradox.” In Atlassian's State of Teams 2026 Report, 89% of executives said AI increased the speed of work but only 6% felt confident pointing to specific, organization-wide ROI. Which is a fancy way of saying that much more of the wrong kind of work is getting done, and very little of it is affecting the bottom line.

In one memorable exchange during the QA portion of the Webinar, someone asked whether it was preferable to integrate an AI tooling stack into the product development lifecycle or just up the number of Chat GPT licenses across the team. Cagan’s answer was extremely instructive. “Well, I mean, I have to be a little careful here. The framing of that question is very problematic. In other words, you do not want a single integrated AI stack. That would be, I would argue, a really bad move.

First of all, build to learn and build to earn are completely different activities with very different goals, with very different skills of the people operating it, very different context. So, the idea of this single thing -- now don't get me wrong, that's not the first person that says, ‘oh, I want to buy this.’ It's amazing how people are so hungry for structure, they're hungry for frameworks, they just want to know what the next step is. Give me a playbook, give me a recipe. And I try to explain -- and now this is going to sound like tough love -- so a lot of people don't want to hear this: Successful product is all about thinking. And what was just described implicitly in that framing was I don't want to think. Bad move.”

I myself, as usual, found Cagan’s words exceptionally persuasive. Did you watch the Webinar?

What were your thoughts?

Drop me a line and let me know.