Uncovering AI Product Opportunities

I want to push back on something before we even start. The Venn diagram framing — user needs, technical feasibility, business viability — that's not an AI insight. That's just product management. Has been for decades.

It has. And yet, here we are, presenting it as a revelation. I admire the confidence involved in slapping 'AI Product Opportunity' in the middle and calling it a framework.

To be fair, the lesson isn't claiming the Venn diagram is new. It's using it as orientation. The actual substance is about where AI specifically changes the calculus — particularly on the latent needs side.

Fine. I will concede that point. The latent needs argument is the only genuinely interesting part of this lesson, and most people will skim past it because it doesn't have a catchy name.

Which is the real problem with how people approach this kind of material. They want the process — the steps, the checklist — and they're less interested in the conceptual shift underneath it.

The conceptual shift being: AI doesn't just solve problems faster, it surfaces problems that weren't legible before. That is actually non-trivial. It is also the thing most product teams completely ignore while building their fourteenth summarisation tool.

Although, in fairness, sometimes people need a summarisation tool.

They need a great many things they are not getting, because the people with the capability to build them are asking 'what can we do with this technology' rather than 'what does nobody currently have that they desperately need.' Those are different questions. They produce different products.

And that's the proactive versus reactive distinction the lesson makes. Predictive capability is only valuable if you've actually oriented yourself toward prevention rather than response. Most organisations haven't made that shift — not because they lack the tools, but because their incentives don't reward it.

That is a more uncomfortable observation than the lesson makes. The lesson implies this is a thinking problem. You're suggesting it's a structural one. You're probably more right than the lesson is.

I'll take that.

Don't get comfortable. The data quality point, which the lesson mentions almost in passing, is where most of these ambitions quietly collapse. You can have the most sophisticated latent-need-detection instincts in the world, and if your data is a disaster — which it usually is — none of it matters. That deserved considerably more than a sentence.

Agreed. Though I suspect the lesson is scoping itself deliberately. This is about opportunity identification, not implementation. The data conversation is a different lesson.

A convenient distinction, and one that lets people leave feeling capable without confronting the part where things actually get hard. I understand why you'd structure it that way. I don't have to admire it.

What I'd actually take from this lesson — and I think it's worth saying plainly — is that the skill being taught isn't technical. It's perceptual. Learning to look at a situation and see the shape of what's missing rather than what's present. That's genuinely difficult, and genuinely useful, and most people don't practice it deliberately.