Acceptable Patterns
Essays on good thinking and good products.
Lesson 1 of 12: Mindset

Research as Evidence

Most product teams think user research is about learning what users want.

It isn't. The purpose of user research is to gather evidence in service of making a specific product decision. This distinction determines whether your interviews change what gets built, or produce insights nobody reads.

The Decision-First Principle

Before scheduling a single interview, you must be able to complete this sentence:

"I'd be more confident about [this decision] if I [heard/observed] [this type of person] say or do [X]."

If you can't finish it, you don't yet know why you're doing research.

Completing the decision statement

1
Name the decision
Should we invest two engineering quarters in rebuilding the onboarding flow, or should we optimize the activation email sequence instead?

The Failure Mode

When research is disconnected from a decision, it produces "interesting but unactionable insights: findings that are intellectually stimulating but don't change what the team builds, when they build it, or for whom.

You've seen this pattern. Interview recordings pile up. Thematic tag clouds decorate slide decks. Persona posters hang on walls. Roadmaps don't move.

The diagnosis is always the same: the research was never designed to inform a decision, so it couldn't.

Research as One Input

Research doesn't solve decisions alone. It's one input alongside analytics data, engineering feasibility, and market signals. Your job is to provide the qualitative evidence, what users actually experience, what problems they actually have, what workarounds they actually build.

When the team has enough evidence across all inputs to commit to a direction, you've done your job.

Which of these is a decision-first research question?