Doing User Research for a Feature That Nobody Has Used Before

Traditional user research relies on people describing their problems and imagining a solution. AI features break that. Users can't describe a workflow they've never seen, and their imagined solutions almost always aim at the wrong ceiling.

At Augere Labs we've helped teams do user research for AI features that eventually became core parts of their product. The techniques that work are a bit different from the standard playbook. This is what we'd tell a founder starting fresh.

Why the usual questions fail

"What would make your work easier?" gets you a list of features the user has already imagined. For AI, that list is often small — automate my emails, summarize this, generate that. Real breakthroughs live in tasks the user doesn't yet think of as solvable.

Ask a project manager what they'd want AI to do and you'll get "write my status updates." Watch them work for an afternoon and you'll see six higher-value tasks they didn't mention — because those tasks are so annoying they've stopped noticing them.

What actually works instead

Observe the work, not the wishlist

Ride-alongs matter more than interviews. Ninety minutes watching a target user do their actual job will surface more feature ideas than three interviews. Look specifically for moments where they context-switch, copy-paste between tools, or defer a task because it feels heavy.

Ask about the boring parts

The interesting AI opportunities usually live in the boring parts of someone's day. "What's the most repetitive thing you did this week?" outperforms "what would you want an AI to do?" almost every time.

Prototype in the interview

Bring a rough prototype — a Figma flow, a Loom, or a demo that half-works. Show it in the interview and ask "when in your workflow would this show up?" The answer is often not where you assumed.

The three types of user you need to talk to

The power user

They've already built their own workaround — spreadsheets, macros, Zapier flows. Their workaround tells you exactly what a good AI feature would replace. In projects like these, the power user is where the sharpest feature ideas come from.

The average user

They accept the tool as-is and put up with the friction. They'll never ask for an AI feature by name, but they'll adopt one that quietly saves them time. This group tells you what the mainstream ceiling looks like.

The reluctant user

They don't fully trust AI. Talking to them protects you from shipping features that scare off half your audience. Their objections shape guardrails, defaults, and rollout choices.

Mistakes teams make in AI user research

Leading with "AI"

Users trained on demo videos will tell you they want AI for everything, because they think that's what you want to hear. Frame questions around outcomes, not tech. "How do you decide which leads to follow up with?" is better than "would you use AI to prioritize leads?"

Small research pool of internal users

Employees will tell you the product is great because you sign their paychecks. External users complain freely. Prioritize interviews with people who don't work for you, even when it's harder to schedule.

Skipping the "won't use it" segment

Every AI feature has a segment that will refuse to adopt it — sometimes 20–40% of your users. Talking only to enthusiasts hides this and leads to overinvestment.

Confirming instead of learning

Once a team has decided to build a feature, research often becomes confirmation-seeking. If your last five interviews all "loved the idea," you're probably nodding at the users nodding at you.

A four-week discovery pattern that works

Week 1 — Observe

Five 60- to 90-minute sessions watching real users do the tasks in scope. No pitching, no prototype. Just watch and take notes. Cluster the friction points afterwards.

Week 2 — Prototype the top two

Pick the two biggest friction points. Build a demo that looks real for each — Figma with a scripted click-through is fine. Doesn't have to work end to end.

Week 3 — Test the prototype

Show it to five to eight users. Watch reactions. Ask when they'd use it, what would kill their use, and what they'd need to trust it. Grade adoption intent — but weight action harder than words.

Week 4 — Pick one, kill the other

Better to ship one feature that clearly wins than two that "seem fine." Kill the weaker prototype openly and move all effort behind the winner. Our post on writing an AI product spec covers what happens next.

A real example

A CRM company we worked with wanted to add AI features. The obvious ask from leadership was "AI email drafting." We did ride-alongs with eight sales reps. Email drafting was on the list, but three tasks ranked higher: identifying accounts that had gone quiet, summarizing what happened across recent conversations, and prepping for calls with fragmented notes.

The "prep for calls" feature turned out to be the winner. It shipped in six weeks and had significantly higher usage than the email drafting feature would have. Not because email drafting is a bad idea — because it was the second-best idea in the same workflow.

Trade-offs to accept

User research takes weeks. Executives get impatient. The pressure to skip discovery and ship something visible is real. The trade-off is a lower hit rate on features and a lot of quietly abandoned AI experiments.

Research doesn't guarantee success either. It shifts the odds, and it prevents the biggest failure mode — shipping the feature that leadership wanted but nobody uses.

Common misconceptions

"We can just ship it and see what happens." Sometimes you can. If the feature is small, cheap to build, and easy to remove, ship-to-learn works. For features that need real engineering investment, research is cheaper.

"Analytics tells us what users want." Analytics tells you what users do inside your existing product. It's silent on what they'd do inside a product that doesn't exist yet.

"Interviews aren't quantitative." That's the point. You use interviews for direction and prototypes for signal, then quantify with usage data after you ship.

Frequently Asked Questions

How many users should I interview for an AI feature?
Five to eight in the observation phase, five to eight more when testing prototypes. Past that, returns diminish sharply.

Should I record interviews with AI transcription?
Yes, with permission. But make sure someone on the team also takes notes live — the moment you notice matters more than the transcript.

Do I need a UX researcher for this?
Helpful, not essential. A senior product person or founder can run this if they follow the discipline of observing before pitching.

What if the research contradicts leadership's favorite idea?
That's the highest-value outcome. Bring the evidence, not just the conclusion — the specific quotes, the observed workflows, and the alternative that outperformed it.

Where to go next

Pair this with how to run an AI proof of concept and writing an AI product spec. Discovery, POC, and spec are three separate steps and each protects the next from wasted effort.

Working with us

We help teams do discovery, prototype, and ship AI features that hold up in production. Our AI product engineering practice starts many engagements with a two- to four-week discovery block for exactly this reason.