The feature trap
Most product teams default to the same move when growth slows down: add something. A new button, a new setting, a new integration. It feels like progress because there is something to ship and something to announce.
The problem is that a feature is an answer. If nobody has agreed on the question, the feature is just a guess dressed up as a decision. Teams end up with products that are crowded with capability and thin on clarity, because every addition solved somebody's assumption about the user rather than something the user actually said or did.
A better question costs less than a new feature and often saves you from building the wrong one.
Start with what the user is actually trying to do
Before any discussion of what to build, it helps to write down, in plain language, what the person on the other end is trying to get done. Not what they click, what they want.
This sounds obvious. It rarely happens. Meetings about product direction tend to jump straight to solutions because solutions feel productive. Questions feel like stalling. But a team that cannot state the underlying goal in one sentence is not ready to design for it.
A useful test: can you describe the problem without mentioning your own product? If the answer only makes sense in terms of your interface, you have described a feature gap, not a human need.
Ask questions that can be wrong
A question worth asking is one where you could genuinely be surprised by the answer. "Do users like this?" is not that question, because almost everyone will say something polite. "Where does this break down for them, and what do they do next?" has room for an answer you did not expect.
Eric Morrison, a User Experience Research Lead who has led research at companies including Google, TikTok, and Disney, has spoken about the discipline of framing questions that can actually be disproven, rather than ones designed to confirm what the team already believes. That distinction matters more than the research method chosen to answer it. A well-designed survey built around a weak question still produces a weak answer.
Common signs a team is feature-first instead of question-first
- The roadmap is a list of things to build, not problems to solve.
- Success criteria get written after the feature ships, not before.
- Nobody can say what would have to be true for the feature to fail.
- User feedback gets treated as praise or complaint, not as data about behavior.
- The same feature request keeps getting reprioritized without anyone asking why it keeps coming back.
If two or three of these sound familiar, the fix usually is not more research. It is a different order of operations: question, then evidence, then feature.
How to build the habit
Write the question down before the meeting, not during it. A question drafted on the spot tends to be shaped by whoever is in the room. A question written in advance forces the team to agree on what they are actually trying to learn.
Make the question falsifiable. Instead of "will people use this," try "how many people complete this task without help, and where do they get stuck." One produces a yes or no that nobody trusts. The other produces something you can act on.
Separate the question from the solution you already have in mind. It is tempting to write a question that quietly assumes the answer. "How much do users want a faster checkout" assumes speed is the issue. A cleaner question is "where does the checkout process lose people, and why."
Revisit old questions before writing new ones. Teams often ask a fresh round of questions every quarter without checking whether last quarter's questions were ever actually answered. Half the value of a good question is following it through.
What this looks like in practice
A team that starts with a strong question usually ends up building less, not more. They cut a feature that was solving a problem nobody had, and they invest more in a smaller change that removes a real point of friction. The output looks modest next to a roadmap full of shiny additions, but it tends to move the numbers that matter: completion, retention, repeat use.
The instinct to build is not wrong. It is just early. A team that gets good at asking sharper questions before they open a design tool ends up shipping fewer things and explaining fewer of them after the fact, because the ones they do ship were built to answer something real.
