Homepage New Product Development Why Technically Correct Products Still Fail Users

Why Technically Correct Products Still Fail Users

A product can meet its specifications, pass its safety checks, and complete every stage of the NPI process, yet still frustrate customers once it reaches the market.

That is because technical validation confirms whether a product performs as designed. It does not always reveal whether the product feels intuitive, comfortable, responsive, or easy to use in real-world conditions.

Adrian and Paul Adams examine the gap between engineering compliance and user experience. They discuss how packaging can accidentally activate a product, why a safe surface temperature may still feel uncomfortably hot, and how controls, materials, setup instructions, and response times can make a technically sound product feel faulty.

The episode also explains why product teams should test early prototypes with independent users, observe how they interact with the product, and continue using it long enough to uncover frustrations that a specification or checklist may never capture.

Listen to the audio here or on Apple Podcasts · Spotify · Amazon Podcasts · Deezer · iHeartRADIO · TuneIn.

Table of Contents

Episode Summary

00:00:45 – How can a technically correct product still fail users?
A product may meet every specification and pass all its technical tests while still feeling awkward, confusing, uncomfortable, or unreliable to the customer.
Users do not experience engineering reports or test results. They experience how the product responds, how it feels in their hands, and whether they can understand and operate it easily.
00:02:02 – A specification is a checklist, not the complete product experience
Specifications are effective for measurable requirements such as dimensions, voltages, timings, tolerances, and material hardness.
However, requirements such as whether a grip feels comfortable, whether a product seems too heavy, or whether a control feels intuitive are much more subjective. These qualities cannot always be captured accurately with a single number.
00:03:27 – When packaging made a working product appear faulty
Paul describes a battery-powered product that operators accidentally switched on while placing it into its packaging.
By the time customers opened the box, the battery could be depleted. Their first impression was that the product was defective or had not been charged properly, even though it had functioned correctly during production.
00:04:35 – When the first solution created another usability problem
The initial solution was to require users to hold the power button for two seconds.
This prevented accidental activation during packing, but test users then reported that the product would not turn on. They expected it to respond immediately, as similar products did.
The technical requirement had been met, but the behavior did not match user expectations.
00:05:40 – Fixing the packaging instead of compromising the product
The team restored the short press required to turn on the product and instead modified the packaging.
By removing two of the finger openings, operators and users could only lift the product from positions away from the power button.
This prevented accidental activation without making the product feel unresponsive.
00:06:38 – Passing a safety requirement does not guarantee comfort
A product may remain well below the maximum external temperature permitted by its safety specification but still feel unpleasantly hot during normal use.
Paul gives the example of a kitchen product designed to remain at approximately 40°C, despite a permitted limit of 60°C. The product has a significant safety margin, but someone carrying it across a kitchen may still become uncomfortable and want to put it down.
The product passes the requirement, but the experience may still be poor.
00:09:13 – Why usability is harder to validate than engineering
Engineering problems often have clear answers. A circuit works, or it does not. A component is within tolerance or outside it.
Usability is less clear. A product may feel comfortable to one user, too light or flimsy to another, and too heavy for someone else.
The intended users, environment, physical abilities, expectations, and method of operation all influence whether the design provides an acceptable experience.
00:11:57 – Why user experience is underinvested during NPI
Usability testing is often neglected because it can be difficult to specify, measure, budget, and validate.
Companies developing new products may be willing to invest in engineering tests with objective pass-or-fail results, but hesitate to spend money creating early prototypes for subjective user trials.
As a result, products may progress through development without enough evidence that intended users can operate them comfortably and intuitively.
00:14:13 – Why usability feedback often arrives too late
Many teams wait until tooling, fixtures, and pre-production builds are complete before placing realistic products in users’ hands.
At this stage, changing the shape, material, weight, controls, packaging, or internal design can be expensive and may delay production.
A product can therefore pass every NPI checklist and phase gate while still failing when customers begin using it.
00:15:50 – Do not rely only on the people who designed the product
Product owners and engineers already understand how the product is intended to work. This knowledge can prevent them from noticing instructions, controls, or behaviors that would confuse a new user.
The product should be given to people who have never seen it before, ideally without detailed guidance.
Observing what they try to do, where they hesitate, and what they misunderstand provides more useful evidence than asking the development team to evaluate its own design.
00:16:21 – The intended user changes what “good” means
A powerful cordless vacuum cleaner may work extremely well but still be too heavy for an elderly user to lift, store, or operate.
Similarly, Paul recalls a technically successful smartphone that was so smooth and slippery that he repeatedly dropped it and replaced it after a month.
Neither product necessarily failed its specification. The problem was that its physical design did not suit the real user or operating conditions.
00:18:26 – What product teams should examine during usability testing
Paul identifies several areas where technically compliant products commonly create a poor experience:
– Response timing and delays
– Missing or unclear visual and audible feedback
– Buttons that are difficult to find or press
– Controls that cannot be used while wearing gloves
– Labels and serial numbers that are difficult to locate or read
– Setup processes that are not intuitive
– Instructions that assume too much prior knowledge
– Materials, shapes, and weights that become uncomfortable during use
These details may look minor during development but can strongly influence customer satisfaction and product reviews.
00:20:25 – Feedback must be clear, appropriate, and noticeable
A product may beep, flash, or display a signal exactly as specified, but that feedback may still be ineffective.
The sound may be too loud, too quiet, too high-pitched, too long, or simply irritating. A light may be difficult to see, and a delayed response may make users believe that nothing happened.
Product feedback should be validated with representative users rather than selected only according to the development team’s judgment.
00:24:01 – Setup should be intuitive, and instructions should be easy to follow
New or innovative products may not behave like products users already understand.
The setup process should therefore be intuitive, or the instructions should explain it in language that ordinary customers can follow without specialist knowledge.
Sending early products and draft instructions to independent users can reveal confusing steps before the product reaches the market.
00:25:33 – Product owners need to live with the product
Using a product briefly is not enough to understand its complete user experience.
Product owners should use realistic prototypes repeatedly and over an extended period. Daily use reveals frustrations that may not appear during a short test, including inconvenient controls, awkward storage, confusing routines, unnecessary delays, or features that become irritating over time.
Other representative users should also live with the product because the product owner may be biased by their knowledge of the design.
00:27:35 – Test realistic prototypes as early as possible
Early prototypes do not always need to contain every final feature.
A prototype may be created specifically to test weight, grip, controls, setup, packaging, or another important aspect of the experience.
The earlier these questions are tested, the more freedom the development team has to improve the design before tooling and production make changes expensive.

The Main Lesson

Technical specifications are essential, but they cannot fully define whether a product will be comfortable, intuitive, reassuring, or enjoyable to use.

A product may perform exactly as designed while still appearing faulty because its response is too slow, its feedback is unclear, its packaging activates it accidentally, or its controls do not behave as users expect.

It may also comply with safety limits while still feeling uncomfortable, or provide strong technical performance while being too heavy, slippery, difficult to set up, or inconvenient for its intended users.

These problems are difficult to identify using engineering reviews and checklists alone. Product owners and engineers already know how the product works and may unconsciously compensate for confusing behavior.

You should therefore test realistic prototypes with independent, representative users (or live with them themselves) as early as possible. They should observe users without providing unnecessary instructions and examine response timing, feedback, controls, labeling, setup, materials, weight, accessibility, and prolonged daily use.

The goal is not simply to prove that the product works.

Product teams need to feel it, use it, and live with it before approving it for production.

Why Technically Correct Products Still Fail Users