There's a belief acting as an accelerant across thousands of product roadmaps right now: that users want more AI. That if they don't have it, they feel underserved. That whichever competitor integrates it first wins. The problem is that this belief, in most cases, has no empirical basis whatsoever.
Users don't ask for AI. They ask not to waste time searching for a file they've already attached three times. They ask not to have to repeat their context to the support agent on duty. They ask that the form not force them to choose between 47 options in a dropdown when only three make sense for them. AI can solve those frictions. Or it can be yet another layer that complicates them. That difference isn't decided by the technology — it's decided by the intent behind the design.
What we see frequently in product teams isn't bad faith, but a sequencing error: the solution (AI) is chosen before the problem has been defined with precision. And when the solution arrives before the diagnosis, what gets built isn't a smarter product — it's a more complicated one with better marketing.
AI integrated without prior diagnosis generates new friction disguised as convenience.
Real integration is invisible: the user completes their task faster and doesn't know why.
The user's mental model must be the starting point, not the available technical capability.
The Problem: When Features Go Looking for Their Use Case
There's a principle taught in first-year UX courses that gets forgotten in production: design for users' existing mental models, not the ones you'd like them to have. When a team adds a conversational assistant to a flow the user already resolves in three clicks, they're not improving the experience. They're adding one more decision: do I use the chat or do what I always did?
That decision friction has a cost. One that doesn't show up in adoption rate dashboards during the first few weeks, when novelty still acts as motivation. It shows up two months later, when the user has decided the assistant doesn't save them time and has returned to the old flow. Or worse: when they've left the platform because it feels like it keeps getting more complicated instead of simpler.
The pattern repeats itself: a product team receives pressure to "integrate AI," interprets that pressure as an instruction to add a conversational interface (because it's the most visible thing), and ships a feature that works technically but that nobody uses sustainably. In that scenario, AI hasn't failed. The design process that arrived at it without first asking what concrete job it was solving has failed.
An AI feature nobody uses isn't an adoption problem. It's a definition problem. Nobody adopted something they didn't need.
We explored this when we analyzed why chat is not the universal answer for every AI interface: modality matters as much as capability. But modality is a consequence of understanding user context, not of the model's capability catalogue.
The Diagnosis: JTBD as the Antidote to Feature Theater
Jobs-to-be-Done isn't a standard UX research methodology. It's a way of framing questions that avoids solution bias. The question "would you like an AI feature that summarises this document?" carries an implicit bias: it already assumes the problem is document length and the solution is a summary. The correct JTBD question comes earlier: "what are you trying to do with this document and what's stopping you from doing it right now?"
The answer might be "I need to extract the three action points at the end," in which case a generic summary is useless. Or it might be "I need to share it with my team without them having to read the whole thing," in which case the problem isn't comprehension but internal communication. Or it might be something entirely different that has nothing to do with AI at all.
Three diagnostic questions before any AI feature
In the product audit processes we run at Room 714, before evaluating whether an AI capability makes sense in a specific flow, we ask three questions that act as a filter:
What is the observable friction, not the perceived one? Not what the user says bothers them in a survey, but what we see them doing (or not doing) in behavioural data. Surveys say "I'd like a summary feature." Data says 80% of users abandon the document before the third scroll.
Does that friction have a root cause AI can eliminate, or only mask? If the document is hard to consume because it's poorly structured, an AI summary doesn't solve the problem — it postpones it. The solution is to redesign how the content is generated or presented. AI might be part of that, but not the patch on top.
Can the user complete the job without knowing there's AI behind it? If yes, the integration is probably good. If the user has to learn a new interaction paradigm to access the value, the adoption cost may outweigh the benefit.
The form and dropdown case
A concrete example that illustrates the tension: dropdowns. They're one of the most overused components in complex interfaces. Nielsen Norman Group has spent years documenting that their misuse generates high error rates and abandonment in conversion flows. The modern reaction from many teams is to replace them with natural language fields processed by AI: "type your sector and we'll detect it." That can work — or it can generate a new layer of uncertainty for the user ("did it understand correctly? should I be more specific?").
The JTBD solution doesn't start with the component. It starts with the question: why does the user have to select their sector at this point in the flow? Is it necessary to personalise what comes next, or is it data collected because it always has been? If the latter, removing the field beats replacing it with AI. The most elegant technology is sometimes the absence of technology.
Real Integration: Invisible by Design
The hallmark of good AI integration in a product isn't the user saying "great AI on this app." It's the user saying "this is so easy" without identifying any technological cause. Invisibility isn't a design defect — it's the goal.
There are examples that have worked this way for years without anyone calling them "AI products": Google Search autocomplete, predicting queries with language models since 2004. Gmail's spam detection, filtering millions of emails daily with classification models without the user making any decision. Spotify's recommendation system building Discover Weekly every Monday, which users describe as "it seems to know me," not "it has good AI."
None of these cases required users to learn a new interaction paradigm. They integrated into existing flows, at moments where the user was already making a decision, and AI reduced the cognitive cost of that decision. That's real integration.
AI shouldn't ask anything of the user. It should take things away: steps, decisions, repetitions, wait times.
The contrast with many current AI features is striking. An assistant that appears in a modal over the main flow and asks the user to "describe what you need" is inverting the relationship: instead of removing work, it's adding a new task. The promise of convenience becomes one more item on the list.
This connects directly to something we developed when examining UX improvements that improve nothing: optimising a part of the flow that isn't the real bottleneck doesn't move the needle. Adding AI to a step that isn't the user's problem doesn't either.
The Real Cost of "More AI": Experience Debt
There's a type of debt product teams don't account for in their roadmaps: experience debt. It's the accumulation of features that work technically but cognitively overload the user. Every interface element requiring a decision, every assistant that needs configuration, every automatic suggestion that might be wrong and needs verification: all of it consumes the user's cognitive energy.
That debt doesn't show up in model performance metrics. It shows up in churn. In NPS. In user interviews when someone says "it's just too much" without being able to point to anything specific, because the problem isn't any individual feature but the sum of all of them.
The teams suffering most from this phenomenon right now are those who've added AI capabilities cumulatively: first a summary, then a chat assistant, then inline suggestions, then an "insights" panel. Each one had its business justification individually. Together they create an interface where the user can't tell what's the product and what's the copilot.
The experience architecture question that should precede each new AI feature isn't "can we build it?" or "do we have the data?" It's: "at what cognitive cost to the user, and does that cost justify the value delivered?"
That kind of analysis requires rigorous qualitative research — not post-launch satisfaction surveys. It requires observing real users completing real tasks, identifying where confusion appears, where they stop, where they click on the wrong thing. And it requires the organisational willingness to undo what was built if the diagnosis calls for it, which is the hardest part. As we explored in our analysis of why user research dies when it becomes a deliverable, the problem isn't the research itself — it's that its conclusions rarely reach product decision moments with enough force.
The Way Forward: Fewer Features, Better Integrated
The direction that works isn't more AI, but more precise AI. A single integration point that eliminates a real friction is worth more — in terms of experience and retention — than five features that demonstrate technical capability without solving any concrete user job.
The process we recommend has three phases that can't be skipped or reordered. First, a real friction map based on observed behaviour, not roadmap assumptions. Second, identification of the two or three jobs where AI can invisibly reduce cognitive cost. Third, minimum viable implementation, measurement of impact on behaviour (not feature adoption), and an informed decision on whether to scale or discard.
That process is slower than "adding AI to the product." It's also the only one that avoids building experience debt that later has to be paid back through costly redesigns and users who won't give a second chance.
If your team is evaluating where and how to integrate AI capabilities into an existing product — or if you sense that the current roadmap is accumulating features without a clear experience logic — that's exactly the intersection where Room 714 works. Not to tell you how much AI you need, but to help you find where it makes sense, and where you're paying a cost nobody's telling you about.
