Research Isn’t a Stage Gate — It’s a Strategy Choice

Two weeks ago, a founder said something to me that I haven’t been able to shake.

“We’re doing research next month,” she told me. “After we lock the roadmap.”

She said it casually, like that order of operations was obvious. Strategy first. Research second. Validation third. Launch fourth.

If you spend enough time around product teams, you start to hear this pattern everywhere. Research as a checkpoint. Research as proof. Research as something you do once the real decisions are made.

And lately, the conversations across the product design and research community have circled the same tension: Are we using research to learn — or to legitimize?

That question isn’t academic. It shapes roadmaps. It shapes budgets. It shapes trust inside teams. And most importantly, it shapes what users end up living with.

When Research Becomes a Receipt

One of the more honest threads I saw this week described user research as “expensive validation for decisions already made.” It stung because it’s not entirely wrong.

I’ve been in that room.

A PM walks in with a deck. The feature is already scoped. Engineering has estimates. Marketing has draft messaging. What they need now is “some quick research” to de-risk the launch.

Notice the language. Not explore. Not understand. De-risk.

In those situations, research becomes a receipt — documentation that the decision was responsible.

There’s a structural reason for this. According to the 2023 State of User Research report by User Interviews, 62% of researchers say they’re brought in too late to influence product direction. By the time research starts, the question isn’t “What should we build?” It’s “How do we make this land?”

That shift in timing changes everything.

When research enters late:

• The scope is fixed.
• The solution is assumed.
• The only acceptable outcome is minor refinement.

And researchers feel it. They start shaping studies around safe questions. They moderate more cautiously. They present insights in ways that won’t derail momentum.

I don’t say that as criticism. I say it as someone who has felt the same pressure from the other side of the table.

Because here’s the uncomfortable truth: sometimes we don’t want discovery. We want reassurance.

The Real Cost of Late Learning

There’s another thread circulating right now: “Cut 80% of useless features before you build.” It’s catchy. It’s optimistic. And it’s directionally right.

The Standish Group’s CHAOS Report has shown for years that roughly 45% of product features are rarely or never used. Pendo’s Product Benchmarks Report found similar patterns, with a significant portion of features driving little to no engagement.

But those statistics aren’t just about waste. They’re about timing.

When research happens after roadmap decisions are emotionally and politically committed, the cost of changing direction skyrockets.

Not just financially.

Politically.

Psychologically.

Organizationally.

I worked with a B2B SaaS company last year that had invested six months in building a complex permissions system. On paper, it solved a real enterprise requirement. In sales conversations, it sounded impressive.

In usability testing, something subtle happened.

Users didn’t reject it.

They avoided it.

They defaulted to workarounds. They limited access manually. They hesitated before clicking into advanced settings. The system wasn’t broken. It was burdensome.

By then, engineering had sunk thousands of hours into it. Leadership had pitched it to investors. Pulling back felt like admitting a mistake.

So instead, they layered on tutorials. Tooltips. A redesign.

The core issue wasn’t usability. It was misaligned problem selection.

If the research had come earlier — not to validate a permissions system, but to understand how customers thought about control and risk — the solution would have looked very different.

Research didn’t fail them.

Sequence did.

Research as a Strategic Choice, Not a Ritual

We talk about research as if it’s a craft question. Methods. Sample sizes. Moderation techniques.

But the deeper question is strategic: When are we willing to let learning change our minds?

In my experience, there are three distinct modes teams operate in.

1. Confirming Mode

The decision is largely made. Research is used to refine, message, or mitigate risk.

This is not inherently bad. Sometimes you genuinely need signal before scaling. But let’s call it what it is.

The danger is pretending this is discovery.

2. Exploring Mode

The problem space is defined, but the solution is not. Research shapes direction within constraints.

This is where many teams think they are. Sometimes they are. Often they’re closer to confirming than they realize.

3. Choosing Mode

The team is still deciding which problems deserve to exist on the roadmap at all.

This is where research becomes strategic.

This mode is uncomfortable. It slows visible progress. It creates ambiguity. It can invalidate weeks of thinking.

But it’s also where disproportionate leverage lives.

A McKinsey study found that companies integrating user research early in product strategy see up to 32% higher revenue growth compared to peers. Not because they run more tests. Because they place smarter bets.

Research, at its best, is not a stage gate. It’s a bet-shaping tool.

Public Roadmaps and Private Certainty

Another trend I’ve been watching: the rise of public roadmaps in SaaS.

On the surface, this is about transparency. Trust. Customer alignment.

But it introduces a new dynamic.

When your roadmap is public, your ability to change your mind becomes visible.

And changing your mind publicly is hard.

So what happens?

Teams feel pressure to conduct research that confirms the announced direction. Feedback is interpreted in ways that preserve commitments. Negative signals are reframed as edge cases.

I’ve seen teams say, “We’ve already told customers this is coming.” As if that alone transforms an assumption into a necessity.

Public roadmaps can be powerful. They create dialogue. They invite collaboration. But they also increase the emotional cost of early research that contradicts plans.

Which means if you’re going to operate transparently, you need to be equally transparent about uncertainty.

One company I advised added a simple label to their roadmap: “Exploring,” “Building,” “Shipping.”

Only “Building” and “Shipping” were commitments. “Exploring” explicitly meant: we might learn something that changes this.

That small distinction protected the team’s ability to think.

The Human Dynamics We Don’t Name

It’s tempting to frame all of this as a process flaw. But most of the time, it’s emotional.

Product managers are measured on momentum.

Designers are measured on clarity and craft.

Engineers are measured on delivery.

Researchers are measured on insight.

These incentives don’t always align in the messy middle of ambiguity.

I’ve watched researchers hesitate to present hard findings because they didn’t want to be “the blocker.” I’ve watched PMs downplay ambiguous signals because they needed a clean story for leadership. I’ve watched founders override research because the runway didn’t allow another iteration cycle.

No one wakes up wanting to ignore users.

But everyone feels pressure.

If we’re honest, research often becomes expensive validation not because teams don’t care — but because they care about different risks:

• Researchers fear irrelevance.
• PMs fear delay.
• Leaders fear missed growth.
• Engineers fear rework.

So we default to what feels safer: incremental change instead of directional questioning.

Naming this dynamic matters. Because once you see it, you can design around it.

What Changes When Research Shapes Strategy

In the healthiest product teams I’ve worked with, research shows up before the roadmap doc is polished.

Not as a presentation.

As a conversation.

Here are a few practical shifts that make that possible:

1. Frame research around decisions, not artifacts

Instead of asking, “Do users like this feature?” ask, “Should we prioritize this problem over these alternatives?”

Tie studies to forks in the road.

2. Make invalidation a visible success

Celebrate the feature you didn’t build.

I once worked with a team that documented “avoided builds” in quarterly reviews — ideas that research disproved early. They estimated engineering hours saved and made it part of performance conversations.

It changed the emotional tone around discovery.

3. Separate exploration from commitment in planning

If everything on the roadmap is treated as a promise, research will always be pressured to confirm. Create clear stages where change is expected.

4. Bring engineering into early learning

When engineers hear raw user language and see friction firsthand, the conversation shifts from “rework” to “right work.” It becomes shared ownership, not correction.

None of these tactics are revolutionary. But they require discipline.

And discipline, in product work, is often the quiet differentiator.

The Question Beneath the Question

When I zoom out from all these conversations — validation vs. discovery, early vs. late research, public roadmaps, feature waste — I see a deeper tension.

It’s not about methods.

It’s about identity.

Do we see ourselves as builders executing a plan?

Or as decision-makers shaping bets under uncertainty?

Research only becomes strategic in the second frame.

In the first, it will always be downstream.

I think that’s why these debates feel charged right now. Building is getting faster. AI tools reduce friction. Prototypes can be spun up in days. Experiments can be launched in hours.

When building is easy, it’s tempting to treat learning as a formality.

But speed amplifies consequences.

If 45% of features go unused in a slower world, what happens when shipping accelerates further?

We don’t need more validation.

We need more courage earlier.

The courage to ask, before we commit: Is this the right problem?

And the humility to let the answer change us.

Research isn’t a stage gate at the end of thinking.

It’s a choice about when we’re willing to let reality shape strategy.

That choice — more than any method — is what determines whether we’re building responsibly.

And whether our users feel heard, or handled.