The Cost of Not Knowing: What Skipping Real Research Actually Means

Product teams budget carefully for development, design, and launch. Research is rarely treated the same way. It should be.

Every year, product teams make the same calculation. The research phase feels expensive — in time, budget, and calendar pressure — and the product needs to ship. So research gets shortened, skipped, or substituted with internal assumptions about what users want. The thinking is that you can always course-correct after launch.

That thinking is expensive. More expensive, in most cases, than doing the research properly in the first place.

The purpose of this article is not to argue that research is valuable in the abstract. You already know that. The purpose is to put a number on what skipping it actually costs — in product failures, in rework, in lost revenue, and in the compounding disadvantage of building on bad assumptions.

Skipping research doesn’t eliminate uncertainty. It just makes you pay for it later, at a much higher rate.

The Baseline: Most New Products Fail

Start with the broadest number. Estimates on new product failure rates vary by industry and methodology, but the range is consistently alarming. Harvard Business School research puts the figure at roughly 75-95% of new consumer products. Nielsen’s 2023 data found that 85% of consumer packaged goods fail to survive their first 12 months. Even more conservative analyses settle at 40% of all developed products failing to make it to market viability.

The number varies. The direction doesn’t. The majority of new products do not succeed.

What causes them to fail? Poor market research and unclear customer targeting are consistently among the top reasons, according to Harvard Business Review. Not underfunding. Not poor execution. Not bad timing. Not knowing the customer.

This is worth sitting with. The leading cause of product failure is an information problem. Teams built the wrong thing, for the wrong person, in the wrong way — because they didn’t know enough about who they were building for. Research is the direct answer to that problem. It is not overhead. It is the input that determines whether the product is worth building.

The 1:10:100 Rule: When You Find the Problem Determines What You Pay

In quality management, there is a principle called the 1:10:100 rule. It describes the relationship between the cost of identifying and fixing a problem at different stages of development. The numbers are not precise to the decimal — they are order-of-magnitude estimates that have been validated repeatedly across industries. For product and UX development specifically, Forrester Consulting’s 2025 Total Economic Impact study produced a version of this that is worth quoting directly.

Stage	Relative cost	What this looks like
During research / design	$1	Adjusting a screener question, updating a prototype, redirecting a feature concept
During development	$5–10	Refactoring built code, rescheduling sprints, delaying other work to fix the problem
After launch	$30–100	Emergency patches, customer support escalation, reputation damage, lost users

Source: Forrester Consulting Total Economic Impact Study, 2025

The implication is direct. Finding a problem during research costs a dollar. Finding the same problem after you’ve built and shipped costs thirty to one hundred dollars. This is not a small difference in outcome. It is a fundamental difference in the economics of product development.

Organizations that embedded usability research into their product process saw, according to the same Forrester study, a 415% ROI over three years, avoided an average of $2.5 million in developer rework, and reached payback in under six months. Those are not rounding errors in a budget. That is the financial case for research, in plain numbers.

What “Not Knowing” Actually Costs in Practice

The abstract numbers are useful. What they describe in practice is even more clarifying.

When a product team skips or shortens the research phase, they typically make one of a few specific errors, each of which carries a price tag.

• They develop a product nobody needs. The tooling, the materials, the production run — all of it was real. The product hits shelves or gets presented to buyers, and it doesn't move. Now the organization is carrying inventory, managing a SKU that isn't earning its place, and eventually absorbing the cost of discontinuing it.

• They build the right concept in the wrong execution. The underlying idea is sound, but something about the product — the form factor, the size, the way it works in actual use — doesn't match how people live with it. Returns come in. Reviews flag the same frustrations. Fixing it means retooling, reformulating, or redesigning, all of which costs more than getting it right the first time.

• They solve a problem the target user doesn't actually have. The product works exactly as intended. It just isn't intended for the right person. This is the hardest failure to catch from inside an organization, because the product performs in testing and makes sense on paper. The reality only surfaces when real consumers encounter it in the real world — and pass.

• They launch something that damages the brand. A product that disappoints — that feels cheap, that doesn't do what it implied it would, that falls short of the experience the marketing set up — doesn't just fail on its own. It borrows against the trust consumers have in everything else the brand makes. That debt takes time to repay, and it rarely shows up in the post-mortem on the product that caused it.

IBM’s internal research has found that fixing a bug in post-launch software can be 30 times more expensive than fixing it during the design phase. American Airlines found that fixing usability problems during development — rather than after launch — reduced the cost of those fixes by 60-90%. MacAfee, after making usability fixes to one of its products, saw a 90% decrease in technical support calls. These are not unusual outcomes. They are what happens when user problems are caught before they become user experiences.

The Compounding Problem: Bad Assumptions Build on Each Other

There is a cost to skipping research that doesn’t show up in a single line item. It is the cost of building on bad information.

When a product team makes decisions based on assumptions about users rather than evidence, those assumptions become embedded in the architecture of the product. The next decision builds on the previous one. By the time the product ships, dozens of choices — about what features to include, how the interface should work, what terminology to use, what the onboarding flow should look like — have been stacked on a foundation that was never verified.

This is why post-launch research so often produces a disturbing finding: the product works exactly as designed. The design was just wrong. And because the error was baked in at the foundational level, fixing it isn’t a matter of changing one thing. It requires reconsidering many things, often simultaneously.

Formative research — the kind done during design and development, before commitments are made — is specifically designed to prevent this. It catches the foundational errors while they are still cheap to fix. It does not guarantee a successful product. But it dramatically changes the odds.

The Research Budget vs. the Rework Budget

Research teams are often asked to justify their budgets. The better question is whether the organization has accounted for the cost of not researching.

Most product budgets include development, design, QA, and launch costs. Few explicitly budget for rework, for missed-opportunity cost, or for the customer support burden of a product that didn’t get validated before it shipped. Those costs are real. They just get absorbed into other line items, or attributed to execution problems rather than information problems.

The economic argument for research is not complicated. Research reduces uncertainty. Uncertainty, when it persists into development and launch, is expensive. Reducing it early — before engineering hours are committed, before the product is in users’ hands, before expectations are set — is consistently less costly than resolving it later.

The question is not whether your organization can afford to do research. The question is whether it can afford the alternative.

A Note on What Kind of Research Produces These Returns

Not all research is equal in this analysis. The studies and data cited here are overwhelmingly about formative research — the kind conducted during product development and UX design, with real users who genuinely reflect the target population. This distinction matters.

Research conducted with the wrong respondents — people who don’t actually represent the users of the product, or who are habituated to research sessions and produce conditioned rather than authentic responses — does not reliably produce these returns. It produces data. Data and insight are different things. Insight requires that the people in the room are the right people: fresh, representative, and genuinely naïve to what the research is looking for.

This is where respondent quality is not a detail of the research process. It is a determinant of whether the research produces value. A study conducted with panel veterans who have learned how to perform in a research session tells you what those people say in research sessions. It does not reliably tell you what your actual users will do with your actual product.

The economics of research only hold if the research itself is sound. Cutting corners on who is in the room is one of the most common ways teams undermine findings without realizing it — and one of the most expensive.

The Real Cost Calculation

The cost of doing research properly is knowable in advance. It is a line item in a budget, with a timeline and a deliverable.

The cost of not doing it — or of doing it badly — arrives later, spread across rework cycles, support escalations, missed revenue, and products that get pulled before they ever find their footing. By the time those costs are visible, the decisions that caused them are history.

The research budget is not an insurance premium against failure. It is the cost of making better decisions earlier, when decisions are still cheap to make.

Every dollar spent finding the right answer during design saves ten in development and thirty after launch. That’s not an argument for research. That’s a description of how product economics work.