Research gets cut from timelines more than any other part of the product process, usually with the same justification: we already know what users want. Sometimes that's true. Far more often, what a team "knows" is what the loudest stakeholder in the room believes, which is a different thing entirely — a bias UX practitioners have a blunt name for: the HiPPO problem, the Highest Paid Person's Opinion quietly overriding what users actually do.
The Double Diamond, Not a Straight Line
The UK Design Council's Double Diamond model, published in 2005 and still one of the most widely taught frameworks in the field, splits product work into four phases across two diamonds: Discover and Define (understanding the right problem) followed by Develop and Deliver (building the right solution). The shape matters — each diamond widens before it narrows, meaning teams are explicitly expected to explore broadly before committing. Most rushed projects collapse both diamonds into a single narrow line: jump straight to a solution, skip the divergent thinking entirely, and find out during user testing that the problem was framed wrong from the start.
You Don't Need Hundreds of Users
The most persistent myth about research is that it requires a large, statistically significant sample to be worth doing. Jakob Nielsen's widely cited usability research found that testing with just five users typically surfaces around 85% of a product's usability problems — because most serious usability issues aren't rare edge cases, they're the same friction points nearly everyone hits. The marginal value of a sixth, seventh, and eighth user testing session drops off fast for qualitative usability work; that budget is often better spent on a second round of testing after changes are made, rather than a bigger first round.
Qualitative Tells You Why, Quantitative Tells You How Much
The two research types aren't competing, they answer different questions. Analytics and A/B tests can tell you that 40% of users abandon a signup flow at step three — but not why. A handful of moderated usability sessions can tell you exactly why (a confusing label, a missing field, an unclear error state) but can't tell you whether fixing it will move the number. Product teams that only do one or the other end up either shipping fixes for problems they can't prove matter, or optimizing metrics without understanding what's actually broken underneath them.
From first flow to final component — products people use, not just products that were fun to design, comes from treating that research phase as load-bearing rather than optional.