The question that kills bad product assumptions before you build them

Most bad product decisions don’t happen in code review. They happen in the assumptions that never got questioned before anyone wrote a line.

We’ve been building StareBrain — an on-device AI agent for Android — for long enough now to have made a few of those assumptions and paid for them. The one that cost the most time wasn’t a technical decision. It was a research question we asked wrong.

The wrong question

Early on, we asked potential users: “Would you use an AI agent that could control your phone for you?”

Almost everyone said yes.

That answer told us almost nothing useful.

“Would you use” is a hypothetical. It costs the person nothing to say yes. It requires no memory, no specificity, no commitment. It’s the lowest-friction possible signal, which means it’s also the least meaningful.

We had a lot of yeses. We had no idea whether we had a real problem.

The question that changed our research

The shift came when we started asking: “Walk me through the last time you had to do something on your phone that felt like it should have been automatic.”

That question:

Forces a real memory, not a hypothetical
Surfaces the actual friction, not the imagined one
Shows you the workaround they’re already using
Reveals whether the problem happens often enough to matter

The answers were specific in a way the first question never produced. People described the exact sequence of steps — open this app, copy this, go back, paste here, navigate to this screen, re-enter this information that the phone already knows. The friction wasn’t abstract. It was a particular four-app chain they’d done so many times they’d stopped noticing it was annoying.

That’s the kind of answer you can build from.

The follow-up that filters even further

After the story question, we added one more: “Have you ever paid for anything to make this easier, or spent real time trying to fix it?”

`// This is what we're trying to eliminate:
// User intent: "book a cab to the airport"
// Current reality:
fun userDoesManually() {
    openApp("Maps")
    searchFor("airport terminal")
    copyAddress()
    openApp("CabApp")
    pasteAddress()
    checkCalendarForFlightTime()
    switchBackToCabApp()
    confirmBooking()
}

// What StareBrain handles:
fun agentHandles(intent: String) {
    val plan = planner.decompose(intent)
    plan.steps.forEach { step ->
        dispatcher.execute(step, requiresConfirmation = step.hasIrreversibleSideEffect)
    }
}`

If someone has spent real time or money trying to solve this — searched for an app, tried a shortcut, paid for a tool — that’s a confirmed problem. They already voted with behavior.

If they said “yeah that’s annoying” but never tried to fix it, the pain might not be sharp enough to drive adoption. That’s useful to know before you build.

What this changed in practice

We stopped validating features with “would you use this?” entirely. Every research conversation now starts with a story prompt and ends with a spending or effort question.

The story prompt tells you the problem is real. The spending question tells you the problem is worth solving.

Between those two, you can filter out a huge amount of building-for-an-imaginary-user before you ever open Android Studio.

The code is the easy part. Getting the question right is what makes it worth writing.