Continuous discovery when your users can't articulate what they need
There's a moment in every customer interview that experienced PMs recognize: the user pauses, looks slightly frustrated, and says something like "I just want it to be... better." Or "I don't know exactly what I want, but this isn't it."
That moment used to be a dead end. Now it's the whole ballgame.
As products get more complex and AI introduces capabilities that users haven't encountered before, the gap between what people can articulate and what they actually need is widening. Traditional discovery techniques were designed for a world where users could describe their problems, even if they couldn't design solutions. We're moving into a world where users can't always describe their problems either.
Why articulation is getting harder
Several things are converging to make user articulation more difficult.
Products are doing more. When a tool does one thing, users can tell you if it's doing that thing well. When a tool does fifty things and uses AI to connect them, users struggle to isolate what's working and what isn't. They have a general feeling about the experience, but they can't pinpoint the specific friction.
AI introduces unfamiliar capabilities. When you show someone an AI feature they've never seen before, they don't have a mental model for evaluating it. They can't tell you if the summarization is good because they've never had automated summarization. They can't tell you if the recommendation is helpful because they don't know what alternative they'd compare it to. The reference point doesn't exist yet.
Expectations are shaped by consumer AI. Your users are interacting with ChatGPT, with AI features in their phone, with generative tools in consumer products. These experiences create expectations that they can't always articulate. "Why isn't your AI as good as ChatGPT?" is a question that reveals a mismatch in expectations without surfacing the actual need.
Workflow problems are hard to self-diagnose. Many of the most valuable product improvements address workflow inefficiencies that users have adapted to. They've worked around the problem for so long that they don't see it as a problem anymore. Asking them "What's frustrating about your workflow?" misses these adapted-to problems entirely.
The implication here is significant. If 80% of the insight lives below the waterline, and your entire discovery process is built on asking people questions, you're systematically missing the most valuable problems. That's not a technique problem. It's a paradigm problem.
Discovery techniques that work below the surface
Teresa Torres' continuous discovery framework is still the right foundation here, but some of the specific techniques need to be adapted for this context. Here's what I've found works when users can't tell you what they need.
Observation over interviews. Watch people work. Actually sit with them (or screen-share) and observe their workflow for 30-60 minutes. Don't ask them to narrate. Just watch. You'll see workarounds, repeated actions, context switching, and dead ends that they'd never mention in an interview because they've normalized them.
I watched a customer success manager spend 12 minutes every morning copying data from one tool into another to prepare for her daily standups. When I asked her about pain points in her workflow, she didn't mention it. It was invisible to her. When I pointed it out, she said "Oh yeah, I've just always done that."
That 12 minutes times 250 workdays is 50 hours per year. Multiply that by every CS manager in the company. That's the kind of problem you find through observation that you'd never find through interviews.
I've seen this pattern repeat in different forms. A sales team at a B2B SaaS company was manually building prospect summaries by opening LinkedIn, their CRM, and the company website in three separate tabs, then writing a blended summary in a Google Doc before every call. Nobody flagged this in discovery interviews because it was "just part of the job." It took an observation session to see that this ritual consumed 15-20 minutes before every sales call and that the information being synthesized was exactly the kind of structured aggregation that AI handles well. That observation became the seed for a pre-call intelligence feature that measurably shortened sales cycles.
Prototype testing over concept testing. When users can't imagine a capability, don't describe it to them. Build quick prototypes of AI features and put them in front of users. Don't ask "Would this be useful?" Ask "When would you use this? Walk me through your day and show me where this would fit." The difference matters. "Would this be useful?" gets you polite agreement. "Walk me through where this fits" gets you honest reactions. If they can't find a natural place for it in their workflow, the feature doesn't solve a real problem, regardless of how impressive the technology is.
Behavior analytics as discovery input. Your product analytics tell a story about what users are actually doing, which is often different from what they say they're doing. Look for patterns: where do users drop off? What features do they access but never return to? Where do they switch to a different tool? These behavioral signals point toward problems worth solving. Pair this with session recordings if you have them. Quantitative data tells you what's happening. Session recordings help you understand why.
Comparative testing over open-ended preferences. Give users two options and ask which one they prefer. A/B testing does this at scale, but you can also do it qualitatively in interviews. Show two different versions of an AI feature and ask them to compare. People are much better at choosing between options than describing what they want from scratch. Marty Cagan makes this point well: users are better critics than creators. Use that.
The assumption mapping technique
One approach I've developed specifically for AI product discovery is what I call assumption mapping. It works like this.
Before you talk to users, write down every assumption your team is making about the AI feature you're considering. Be thorough. Common assumptions include: "Users will trust AI-generated recommendations," "Users will understand what the AI is doing," "This saves users meaningful time," "The AI output quality is good enough for the use case," "Users will change their workflow to incorporate this feature."
Then rank these assumptions by two dimensions: how critical the assumption is to the feature's success, and how confident you are that the assumption is true.
The assumptions that are highly critical and low confidence are your discovery priorities. Design your user research specifically to test those assumptions. This is more focused than general discovery because you're not trying to understand the whole problem space. You're trying to reduce the risk of specific bets.
For example, if your team wants to build an AI feature that auto-generates reports for executives, your riskiest assumptions might be: "Executives will trust AI-generated reports enough to share them with their boards" and "The report quality is high enough that executives don't spend more time editing than they save." Testing those assumptions requires putting prototypes in front of real executives and watching how they react, what they edit, and whether they'd actually send the output to their board.
Making assumption maps actionable. The technique only works if you're disciplined about what happens after the mapping. I've seen teams do the exercise and then ignore the results because the riskiest assumptions were the hardest to test. That's the whole point. The hard-to-test, high-risk assumptions are precisely the ones that sink features six months after launch. For each assumption in that critical quadrant, assign an owner and a deadline. Define what "tested" means concretely: how many users you'll expose to the prototype, what signals would confirm or disconfirm the assumption, and what decision you'll make based on the result. If you can't define what would make you kill the feature, you haven't actually de-risked anything. You've just done a workshop.
Teresa Torres talks about assumption testing as the core of opportunity solution trees. I think she's exactly right, and I'd add that for AI products specifically, you should weight trust and comprehension assumptions more heavily than you would for conventional features. Users will tolerate a slow feature. They won't tolerate a feature they don't trust or don't understand.
When "just ship it and see" is the right call
I want to be fair about this. Sometimes the fastest path to learning is shipping something and watching what happens. This is especially true when the cost of building is low (AI makes many prototypes cheap), the risk of failure is contained (it's a low-stakes feature that won't damage trust), and you're testing behavior, not just preference.
The key distinction: "ship and see" works when you have clear success criteria and a plan for measuring them. It doesn't work when you're shipping into a vacuum and hoping adoption metrics will tell you something. You need to know what you're looking for.
I've seen teams use "ship and see" as an excuse to skip discovery entirely. They say "we're lean" or "we're data-driven" when what they really mean is "we didn't do the upfront work to understand the problem." That's not lean. That's lazy. Lean methodology assumes you've defined a hypothesis. If you're shipping without a hypothesis, you're not running an experiment. You're just guessing with production code.
And "ship and see" should be a complement to the deeper discovery work, not a replacement for it. It's one technique in the toolkit, not the whole toolkit.
Building discovery into team rituals
The uncomfortable truth is that most product teams aren't good at the kind of discovery I'm describing. They can run a customer interview. They can send a survey. But observation-based research, prototype testing with real workflows, and assumption-driven experiments require skills that many teams haven't developed.
If that's where your team is, start small. Commit to one observation session per week. Build one prototype per sprint and test it with three users. Write down your assumptions before you build anything and test the riskiest one before committing resources.
For teams building AI products specifically, I'd recommend embedding discovery into your existing ceremonies rather than treating it as a separate workstream. Here's what that looks like in practice:
Sprint planning. Before committing to any AI feature work, spend ten minutes as a team listing your top three assumptions and how you'll test at least one of them during the sprint. This doesn't require additional meetings. It's a question you add to the planning conversation you're already having.
Weekly syncs. Dedicate a standing slot for sharing one observation or behavioral insight from the past week. It can be a session recording, a quote from a customer call, or an analytics anomaly. The goal isn't to be exhaustive. It's to keep the team connected to real user behavior so that when you're making product decisions, you're drawing on recent evidence rather than month-old assumptions.
Retrospectives. Add one question: "What did we learn about our users this sprint that we didn't know before?" If the team can't answer that, it's a signal that discovery isn't actually happening, regardless of what's on the roadmap.
Demo days. When you demo AI features internally, don't just show the happy path. Show the prototype to someone unfamiliar with the project and watch their reaction live. Internal demo days are an underused discovery opportunity because you already have the audience and the prototype. You just need to shift from "look what we built" to "watch someone use what we built."
Cross-functional discovery pairing. One practice I've seen work particularly well for AI products is pairing a PM with a data scientist or ML engineer during observation sessions. The PM sees the user's problem. The engineer sees the technical feasibility of potential solutions in real time. That pairing compresses the loop between "here's a problem worth solving" and "here's what might actually work" from weeks to minutes. It also builds shared empathy for the user across disciplines, which pays dividends when the team is making tradeoff decisions later.
The muscle builds over time. And in a world where AI is creating products that users can't yet imagine needing, the teams with the strongest discovery skills will have the biggest advantage. The gap between teams that practice continuous discovery and teams that ship based on intuition has always existed. AI is widening it.
This article is part of a series on product management in an AI-transformed landscape.