“Would you use an app that fixed this?” is an unusually generous question. It allows someone to support your ambition without changing anything about their life.
A better interview begins with the last time the problem happened.
Reconstruct the episode
Ask what the person was trying to do, where they were, what they used and what happened next. Let them show the workflow if they are comfortable. Avoid collecting private records you do not need.
For a hypothetical shared-shopping problem, useful questions include: Who added the item? Who went to the store? When did the mismatch become obvious? How did you resolve it? What did the mistake cost in time, money or irritation?
These questions reveal circumstances that a generic feature request often hides.
Ask about the existing solution
Find out what they have already tried and why they stopped or stayed. “Nothing” is informative too. A problem can be annoying without being important enough to solve.
Ask what they currently pay, if anything, and what would make switching difficult. Do not suggest a price and interpret politeness as willingness to pay.
Introduce the concept late
After understanding the episode, show a narrow prototype or describe one proposed workflow. Ask them to attempt the task, explain confusing parts and identify what would prevent adoption.
If appropriate, offer a real next step: a pilot, a paid trial with clear terms, or another session using their own workflow. Behavior at that step is stronger evidence than a compliment.
Record contradictions. The person may praise your concept while demonstrating that the existing workaround is faster. That is a useful result, even if it makes the interview less flattering.
Your objective is not to collect permission to build. It is to discover whether a repeated, consequential problem exists and whether your proposed solution fits the day on which that problem actually occurs.