This dedicated role studies end-users in their environment to understand needs and constraints before development begins. This preempts building features that are easy for developers but wrong for users, mitigating the risk of creating unused or ineffective software, framing user research as a key risk mitigation strategy.

Related Insights

Even roles far from the customer, like engineering, make countless micro-decisions. Without an intuitive understanding of customer pull—what they're trying to achieve and why they're blocked—these decisions will likely miss the mark, even when just following a requirements document.

Tock rejected traditional focus groups and instead embedded its software engineers directly into restaurants to work shifts as hosts. This forced immersion gave the engineering team firsthand experience with the end-user's pain points, leading to a far more intuitive and effective product than surveys could produce.

Customers describe an idealized version of their world in interviews. To understand their true problems and workflows, you must be physically present. This uncovers the crucial gap between their perception and day-to-day reality.

Users aren't product designers; they can only identify problems and create workarounds with the tools they have. Their feature requests represent these workarounds, not the optimal solution. A researcher's job is to uncover the deeper, underlying problem.

Large companies often identify an opportunity, create a solution based on an unproven assumption, and ship it without validating market demand. This leads to costly failures when the product doesn't solve a real user need, wasting millions of dollars and significant time.

Early demos shouldn't be used to ask, "Did we build the right thing?" Instead, present them to customers to test your core assumptions and ask, "Did we understand your problem correctly?" This reframes feedback, focusing on the root cause before investing heavily in a specific solution.

Historically, resource-intensive prototyping (requiring designers and tools like Figma) was reserved for major features. AI tools reduce prototype creation time to minutes, allowing PMs to de-risk even minor features with user testing and solution discovery, improving the entire product's success rate.

The temptation to use AI to rapidly generate, prioritize, and document features without deep customer validation poses a significant risk. This can scale the "feature factory" problem, allowing teams to build the wrong things faster than ever, making human judgment and product thinking paramount.

Even at SpaceX, many engineers first heard from customers during a company all-hands. This feedback revealed the setup process was a huge pain point, leading to a dedicated team creating first-party mounting options. This shows that fundamental user research is critical even for highly technical, 'hard tech' products.

The misconception that discovery slows down delivery is dangerous. Like stretching before a race prevents injury, proper, time-boxed discovery prevents building the wrong thing. This avoids costly code rewrites and iterative launches that miss the mark, ultimately speeding up the delivery of a successful product.