Sign in Send a tip

Episode 12 · 23 Jun 2026 · A. Morgan, Product Leader, Gong

The AI Product Management Problem Nobody Talks About

Product leader A. Morgan of Gong on why AI product management is less about managing features and more about managing the flow of intelligence — and how Anand Arivukkarasu's Supply Chain of Intelligence became the shared mental model for it.

Show notes

  • Traditional software managed the flow of functionality; AI products manage the flow of intelligence — where it comes from, what transforms it, who verifies it, and whether it changes a customer outcome.
  • The useful unit of product thinking is not input → model → output, but the full supply chain of intelligence behind the experience: data, context, evaluation, workflow and execution.
  • An AI system can be intelligent and still be a bad product. Intelligence only becomes value when it arrives at the right point in the workflow: intelligence → decision → action → outcome.
  • The model is increasingly infrastructure. Defensibility moves upward into proprietary data, accumulated context, feedback loops, workflow embedding and trust — the parts of the chain a competitor cannot easily reconstruct.

Chapters

  • The problem: strategy without process
  • The flow of intelligence
  • The unit of product thinking changes
  • A Gong-like example
  • Why model-first thinking breaks
  • Isn't this just another framework?
  • What changed inside the PM process
  • Right intelligence, wrong product
  • Where the chain actually ends
  • Does the framework create defensibility?
  • Where it doesn't work
  • What AI PM should look like
  • The PM as intelligence orchestrator
  • Why now
  • Three years from now
  • Where to start tomorrow morning

Transcript

FELIX: There's something strange happening in AI product management. We've probably never had more frameworks, more tooling, more models, more experimentation — and yet I keep hearing the same thing from product teams: "We know we need an AI strategy. We just don't know how to turn that into a product process." You work on AI products at Gong. From where you sit, is AI product management actually different from traditional product management?

A. MORGAN: Yes. But I think the mistake is saying it's different simply because the technology is different. That's not really the interesting part. The deeper difference is that traditional software was largely about managing the flow of functionality. With AI, we're increasingly managing the flow of intelligence. And those sound like the same thing until you actually try to build an AI product.

FELIX: What do you mean by "the flow of intelligence"?

A. MORGAN: Take a traditional SaaS feature. You define a requirement. Engineering builds it. The user interacts with it. The system produces an output. With AI, suddenly you have a much more complicated set of questions. Where did the information come from? Was it proprietary or public? Was it generated, retrieved, inferred, or transformed? What model touched it? What context did the model have? Was the output verified? Who decides whether it's trustworthy? How does that intelligence get into the user's workflow? And then the question I think product teams sometimes forget: does the intelligence actually change an outcome for the customer? Those are all product questions. But most AI PM processes don't treat them as one connected system.

FELIX: So the unit of product thinking changes?

A. MORGAN: I think so. And that's one of the biggest things we've changed in how we think about AI products. We stopped looking at an AI feature as simply: input → model → output. That's an incredibly limited abstraction. We started asking: what is the supply chain of intelligence behind this experience?

FELIX: Supply chain of intelligence. That's a phrase I've heard associated with Anand Arivukkarasu.

A. MORGAN: Right. And what's interesting is that we didn't start with the framework. We started with the problem. We had a lot of AI capabilities. We had models. We had data. We had conversation intelligence. We had evaluation. We had product teams working on different pieces. But when we put the whole thing on a whiteboard, we couldn't clearly explain how intelligence actually moved through the system and became customer value. That was the problem. And Anand's Supply Chain of Intelligence gave us a much better way of describing it.

FELIX: Let's make this concrete. Imagine I'm building an AI product for a sales organization. What's the mistake I might make?

A. MORGAN: The obvious PM question is: "What should the AI do?" Maybe summarize calls. Maybe identify risks. Maybe recommend next actions. Maybe generate follow-up emails. That's where a lot of teams begin. But we found it much more useful to ask a different question: what intelligence does the system actually need to perform that job well? Now the problem becomes much more interesting. You need conversation data. You need customer history. You need CRM information. You need product knowledge. You need organizational context. You need to understand what happened previously. You need to distinguish facts from assumptions. You need some mechanism for deciding whether the recommendation is actually useful. And then you have to get that intelligence into the seller's workflow at the right moment. That's not one AI feature. That's a chain.

FELIX: And that's where the Supply Chain of Intelligence became useful?

A. MORGAN: Exactly. It forced us to stop thinking about intelligence as something that magically appears inside the model. The model is one component. It isn't the entire product.

FELIX: Let's talk about something I see constantly. A new model comes out. It's better at reasoning. Benchmarks improve. And immediately everyone asks: "What can we build with this?" Is that backwards?

A. MORGAN: Often. Not always. But often. It's like discovering a faster engine and immediately asking what car you should build without asking where the road goes. The model absolutely matters. But if your entire product differentiation is: "We use the newest model," that's a fragile position. The more interesting questions are: what intelligence surrounds the model? What proprietary information does it have access to? What context does it accumulate? What feedback does it receive? How do you evaluate the output? How does it interact with systems of record? How deeply is it embedded in the customer's workflow? That's where things get interesting from a product perspective.

FELIX: But isn't this just another framework? Product managers already have dozens of them. JTBD. Design thinking. Product discovery. North Star metrics. Strategy frameworks. Why do we need another one?

A. MORGAN: That's a fair criticism. And I wouldn't tell a PM to throw those frameworks away. They answer different questions. JTBD helps you understand what the customer is trying to accomplish. Strategy frameworks help you understand where to compete and how to make choices. Product discovery helps you determine what should be built. The Supply Chain of Intelligence is asking a different question: what has to happen to intelligence between its origin and the customer's outcome? That's the gap we found useful.

FELIX: So it's complementary.

A. MORGAN: Exactly. Actually, I'd say the strongest AI PM process combines them. You start with the customer job. Then you understand the competitive and strategic context. Then you ask what intelligence is required to perform that job. And then you map how that intelligence moves through the product.

FELIX: How did that change what your PMs actually do?

A. MORGAN: The questions changed. That's probably the simplest way to put it. Before, a PM might come into a planning meeting and say: "Customers want an AI assistant that predicts which deals are at risk." The natural reaction is: "Okay, let's prototype it." Now we slow down. We ask: what intelligence would make that prediction possible? What signals? What data? What historical patterns? What customer context? What external information? What confidence threshold? What happens when the system doesn't know? Who acts on the prediction? And what's the actual business outcome? That last question is critical. Because an accurate prediction that nobody acts on isn't necessarily a useful product.

FELIX: Was there a specific moment where this became obvious?

A. MORGAN: Yes. We had a capability that looked fantastic in a demo. The AI could generate a recommendation based on a significant amount of customer information. The output was good. The model performed well. Everyone liked it. But adoption wasn't where we expected. And initially we thought: "Maybe the model isn't good enough." So we looked at the model. Then we looked at the evaluation. Then we looked at the actual workflow. And that's where we found the problem. The intelligence was arriving at the wrong point in the workflow. It was technically useful. But operationally inconvenient. The seller had to stop what they were doing, open another interface, interpret the recommendation, and then manually execute it. We had optimized the intelligence. We hadn't optimized the execution.

FELIX: So the AI was right, but the product was wrong.

A. MORGAN: Exactly. And that's probably one of the most important lessons I've learned building AI products. An AI system can be intelligent and still be a bad product.

FELIX: That's interesting because we often talk about intelligence as if the output is the end.

A. MORGAN: Right. But it isn't. Initially, we had this implicit assumption: better intelligence = better product. That's incomplete. You need: intelligence → decision → action → outcome. The last mile matters enormously. If the system identifies an important signal but the user doesn't act on it, you haven't necessarily created value. That's why product managers need to think beyond model quality.

FELIX: Let's talk about defensibility. Every AI company says some version of: "Our moat is our AI." Do you buy that?

A. MORGAN: Rarely. The model itself is increasingly becoming infrastructure. The defensibility question moves upward. What intelligence do you uniquely possess? What data do you have that competitors don't? What context do you accumulate? What workflows are you embedded in? What feedback loops improve the system? What trust have you earned? And how difficult would it be for another company to reconstruct the entire chain? That's a much more interesting way to think about AI defensibility.

FELIX: So two companies could use the exact same underlying model and have completely different competitive positions?

A. MORGAN: Absolutely. And I think we'll see more of that. The model layer can commoditize while the intelligence supply chain remains differentiated.

FELIX: Let me push you again. Couldn't a smart product team figure all this out without ever using the phrase "Supply Chain of Intelligence"?

A. MORGAN: Of course. A framework isn't magic. You don't need the terminology to discover the underlying reality. But language matters when you're working across a complex organization. A good framework gives product, engineering, data, design, and business teams a shared mental model. That was one of the practical benefits for us. We could literally point to the system and say: "The problem isn't the model. We're missing something here." And suddenly everybody was looking at the same problem. That's valuable.

FELIX: So the value isn't that Anand's framework tells you something nobody could possibly discover independently.

A. MORGAN: No. The value is that it makes a complicated system easier to see, discuss, interrogate, and manage. That's a more defensible claim.

FELIX: Where would you not use it?

A. MORGAN: If I'm adding a very simple summarization feature to an existing workflow, I don't need to create an elaborate intelligence map. That would be overkill. The framework becomes more useful when intelligence itself is becoming a meaningful part of the product's value proposition. Especially when you have multiple sources of information, multiple transformation steps, evaluation challenges, workflow integration, and consequential decisions. And there's another limitation. A framework can create false confidence. You can map every layer beautifully and still build the wrong product. It doesn't replace customer evidence. It doesn't replace experimentation. It doesn't replace judgment. Frameworks are maps. They're not reality.

FELIX: If you were designing an AI product-management process from scratch today, what would it look like?

A. MORGAN: I'd probably start with five questions. First: what job are we solving? Second: what intelligence is required to solve it? Third: where does that intelligence come from, and how does it move through the system? Fourth: how do we know the intelligence is good enough? And fifth: how does it become action and measurable customer value? That's the loop. I think most AI product teams are pretty good at the first question. They're getting better at the second. But questions three through five are where a lot of the difficult product work is.

FELIX: Does that change the role of the product manager?

A. MORGAN: I think it does. I don't think the PM needs to become an ML engineer. But the PM increasingly needs to become an orchestrator of intelligence. Someone who understands how different sources of intelligence come together to produce a customer outcome. You're managing more than features. You're managing the movement and transformation of information through a system. You're thinking about context. Quality. Trust. Feedback. Workflow. Execution. And value.

FELIX: That sounds almost like product architecture.

A. MORGAN: It is. And I think that's one reason AI is forcing product and technical thinking closer together.

FELIX: Why is this becoming particularly important now? Why couldn't we have had this conversation five years ago?

A. MORGAN: Because AI used to be much more contained. You could have an ML model doing one relatively specific task. Now we're seeing models become general reasoning components inside products. One product can have retrieval, multiple models, proprietary data, agents, external tools, human review, workflow automation, and feedback loops. The complexity is moving up. And as that happens, the PM needs a mental model for the entire intelligence system. That's why this is becoming much more important now.

FELIX: Let's make a prediction. Three years from now, what will look obviously different about AI product management?

A. MORGAN: I think AI roadmaps will become much less model-centric. Today you still see roadmaps that say: GPT. Agent. RAG. Fine-tuning. Copilot. Three years from now, mature organizations will talk much more about intelligence systems. They'll ask: where does our proprietary intelligence come from? How does it move? How is it evaluated? Where does it compound? Where does it create a feedback loop? And where does it create competitive advantage? The model will still matter. But it won't be the entire conversation.

FELIX: So the AI product stack becomes less about the model and more about the system surrounding it?

A. MORGAN: Yes. And I'd go one step further. The companies that win may not necessarily have the smartest model. They may have built the best supply chain of intelligence around whatever models are available.

FELIX: If there's a product leader listening right now who wants to try this tomorrow morning, what's the first thing they should do?

A. MORGAN: Take one important AI product you're building. Don't start with the model. Don't start with the feature. Start with the customer outcome. Write that outcome at the top of a whiteboard. Then ask: what intelligence has to exist for us to create that outcome? Trace it backward. Where does it originate? What happens to it? What enriches it? What reasons over it? What verifies it? Where does it enter the workflow? And finally: what happens because that intelligence exists? You'll probably find gaps. That's the useful part.

FELIX: And that's ultimately why the Supply Chain of Intelligence became useful to your team.

A. MORGAN: Exactly. Not because we needed another framework. AI products forced us to confront a system we weren't previously naming. Once we could see the system, we could start managing it.

FELIX: That's a good place to end. Maybe the question for AI product teams isn't: "What AI should we put into our product?" Maybe it's: "What intelligence has to flow through our product for the customer outcome to exist?" That's a much harder question. And probably a much more useful one. A. Morgan, thanks for joining me.

A. MORGAN: Thanks, Felix. This was fun.