I think most modern product teams can agree that user research is valuable.

It helps teams understand user better so we can design something they love and use. You have to understand their needs, behaviors, and friction points - so you can make something that ultimately solves their problems.

And using data to guide the direction of the design - just makes sense.

But user research gets a bad rap.

The haters say: "it's slow. It takes too long. It just confirms what we already know. We don't have time to do research."

They make an argument that it's better to "just-go-fast" and build. And the researcher just wants to make sure we're focusing on the right thing and making good decisions along the way.

Both are right.

Both are just focused on different needs.

The researcher is focused on the user's needs and informing design.

The just-go-fast mentality is focused on business-driven needs and informing stakeholders.

How can these two mentalities co-exist?

First. Both must acknowledge that they play a critical role in supporting the company's mission.

The "just-go-fast" can create momentum to get things done and the user researcher can help the team make better decisions along the way.

The researcher must figure out how to get out in front of the roadmap and be embedded or float inside individual teams. This way research can increase the velocity of some upfront foundational work and move quickly into evaluative testing during the design phase.

If they work together the company becomes a killer force.

The clash

A clash sometimes happens when the "just go fast" has upfront decision-making power and makes prescriptive directions. They tend to skip over the design process.

The researcher wants time to validate those assumptions and understand the problems better. They push back against the "just-go-fast's" arbitrary decisions.

This creates tension.

The deeper fundamental problem here is that the just-go-fast types see design as an afterthought. It's the polish to the idea. Assumptions, anecdotes, and stakeholder ideas tend to drive their decision-making because their job is to get things done.

The researcher has to respect that research can't take too much time. They have to find the sweet spot of how much research is enough to go on. There's a good book called, "Just Enough Research" by Erika Hall on the topic of research.

So how do you align these two on a unified front?

The alignment

Product teams that include a design team, engineering, and product managers all have to align around a common set of operating principles.

Questions Before Design

I have this thing that I start on every design project. I call it Question's Before Design (QBD) session which can improve team alignment and decision-making from the start.

It's a time for the team to align on some fundamental questions before decisions are made on project directions. It's a time for the team to ask questions and prioritize the most important ones to answer, for both the user and the business.

The session can happen in 30-60 minutes and includes product, design, and engineering. As well as some internal experts that have more context, such as customer support. The team can use their favorite whiteboarding tool. We use FigJam, Miro, or an actual whiteboard.

Each person can add questions to the board. Then we go through some rounds of categorizing it into various buckets. Usually, they fall into, User questions, Business questions, and technical questions.

Then we prioritize each group and look for questions that relate across the group.

This cross-perspective allows the team to understand each other's goals and needs - and sets a direction to figure it out in design.

Shifting to the "How do we know?" mindset

By starting with questions, it gets us out of the mindset of "I know best".

As Ray Dalio would say to his team at Bridgewater Capital, "How do we know we're right?"

This put the team in the direction of figuring out whether the solutions we're making, work.

It puts us into a prototyping mindset and looks at things through the lens of fast experimentation to guide our decisions along the way.

When projects start out this way it just feels like we're in it together figuring it out.

Measuring the right metrics

Each type seems to be focused on different metrics of success.

The "just-go-fast" tend to focus on vanity metrics. Vanity metrics are data points that look impressive on the surface but don't necessarily correlate to the success or health of a product. This could be things like the number of downloads. Having a large number of downloads for an app might seem positive, but if the majority of those users aren't using the app after the initial download (low retention rate), then the high download numbers are more of a vanity metric.

And for researchers and designers, it's important to outline metrics that build context into user behavior and satisfaction. Measuring usability metrics like time on task, task success rate, and error rate. Engagement metrics like daily active users, frequency of use, and session length times. And also look closely at retention rates and customer satisfaction score (CSAT).

Final thoughts

In conclusion, the apparent tension between the fast-paced nature of product development and the meticulous process of user research need not be a point of contention, but rather an opportunity for deep collaboration. By aligning on key principles through initiatives like "Questions Before Design" and adopting a "How do we know?" mindset, teams can harmonize business velocity with deep user understanding.

This balance not only fosters innovation but ensures products meet both market demands and user needs with precision.