← Back to portfolioProduct Management

How to Do Market Research Before Building AI Products

Most AI product teams skip this step entirely. The ones that don't build very differently.

May 2026·6 min read

I spent years evaluating technical book proposals at Packt. The job was a repeated exercise in market research: given a proposed topic, an author, and a moment in time, is there a real market for this? Will developers want to learn this skill in 18 months, when the book actually ships?

Get it right and you commission a category-leading title that sells for years. Get it wrong and you've spent nine months and significant money on a book nobody buys. The feedback loop is long and brutal. It makes you rigorous.

When I moved into AI product management, I was surprised to find that most teams building AI products skip market research almost entirely. They have a technical capability — a model, an API, a dataset — and they build features around it, assuming demand will follow capability. Sometimes it does. Often it doesn't.

Why AI product teams skip research

Part of it is pace. AI is moving fast enough that teams feel research is a luxury — by the time you've validated demand, someone else has shipped. This is sometimes true. It's used as an excuse more often than it's actually true.

Part of it is a genuine belief that AI capability creates its own demand — that if the technology is impressive enough, the market will figure out what to do with it. This is almost never true for enterprise products, and only occasionally true for consumer ones.

What good AI product market research looks like

Start with the problem, not the technology. The question isn't "what can we build with this model?" It's "what are people trying to do that they can't do well enough today?" Talk to ten potential users — not about AI, but about their work. Where do they spend time on tasks that feel repetitive or slow? Where do they wish they had better information faster? The answers are your market. AI may or may not be the right solution.

Read what practitioners are complaining about, not what they're excited about. Developer forums, community Slack groups, Reddit threads, conference talk abstracts, job postings — these are full of signal. The complaints are especially valuable. If ten people in a community are asking the same frustrated question, that's a gap. At Packt, I tracked GitHub repositories, Stack Overflow question volumes, and conference schedules obsessively. The same approach applies to AI product research.

Map the competitive landscape honestly. Most AI product teams do competitive research that confirms their thesis. The useful questions are: why are existing solutions inadequate, specifically? What are users doing as a workaround? Is the inadequacy a fundamental limitation of current approaches, or a gap that a well-resourced incumbent could close in six months? If the answer is six months, your window is narrower than you think.

Validate demand before you validate the solution. A compelling demo is not market validation. Users saying "that's impressive" is not market validation. Users changing their behaviour, paying money, or telling you they'd be frustrated without it — that's market validation. This is especially important in AI, where demos are easy to make impressive and adoption is hard to earn.

The research habit worth building

The most valuable habit I developed at Packt was keeping a running list of topics I was tracking but not yet ready to commission — not because they weren't interesting, but because the timing wasn't right. That list forced me to think about markets as things that move, not things that exist in a fixed state.

A topic that was too early in 2019 was right on time in 2021. A category that looked wide open in 2020 was crowded by 2022. AI product teams need the same habit. Not just "is there a market for this now?" but "where is this market in its cycle, and what does that mean for when and how we build?"

The teams that get this right don't just build faster. They build things that people actually needed — and they understood why before the first line of code was written.

← More writingLet's connect →