Product designers know that every finished product involves countless compromises and constraints that must be considered during development. Constraints—and the “facts” that accompany them—are the lifeblood of development. Designers do not only create new solutions; they also solve product problems. Solving product problems is pragmatic work grounded in facts. But are all those constraints really valid?
The Realities of Solving Product Problems
Over the course of my design career, I specialized not only in product design but also in solving product problems. However effective the processes may be, problems still arise—and they must be resolved quickly to keep the consequences and risks under control.
Once a product is on the market, every error can create uncontrolled risks and financial liabilities. Prevention is therefore essential. But if the damage has already occurred, the race against time begins.
Case: Gearbox Bearing Damage
As a young designer, I was once given an assignment by my supervisor: “A customer has asked us to help solve a problem. Jaakko, take a look at this case next.” He remembered that I had once mentioned knowing something about the subject. Pitting corrosion had been detected in the bearings of a machine’s gearbox.
Pitting was familiar to me from my mechanical engineering studies and materials engineering laboratory work. I had also gained practical experience repairing heavy-equipment gearboxes, where bearing failures were commonplace—usually because of excessive loads or contaminants in the lubricant.
The Search for Facts Begins
After studying the documentation, I quickly realized that the problem was widespread. Damage had occurred in several different types of gearboxes, so I did not believe that a single design or dimensioning error could explain it.
I approached the problem pragmatically and analytically. I gathered every available fact, categorized the information, and created cause-and-effect tables. I also involved colleagues so that I would not become blind to my own perspective. Although I had tentatively ruled out a design error, I kept it on the list of possibilities.
The Root Cause and the Obvious Solution
Together with the development team, we concluded that condensation was causing the pitting. Water accumulated at the bottom of the gearbox, where the bearings rotated—and water is known to cause pitting. The obvious solution was to prevent water from entering the gearbox.
I examined the solutions the customer used to prevent water ingress. I found nearly 150 different versions—most of them variations of one another—but not one was completely watertight, literally.
I developed a new solution that would prevent condensation more effectively and replace as many of the old versions as possible. We tested prototypes, and the results looked promising: condensation was almost entirely eliminated. Production began, and retrofit kits were shipped around the world.
No Water—Yet the Damage Continued
Our relief was short-lived: the damage continued. Water was no longer the problem, but the bearings were still failing. We were baffled.
At the same time, our quality department received a notice from a world-leading German bearing manufacturer: a batch of its bearings had a hardening defect. A sensor failure on the hardening line had caused the wrong temperature, resulting in a quality defect that could manifest as pitting.
We checked the codes—and yes, those defective bearings were installed in the damaged gearboxes. The root cause was not water but faulty bearings. We had developed the obvious solution—and solved the wrong problem.
I do not know whether the obvious solution I developed on “false grounds” is still in use, but in my opinion, it became an excellent solution. It met the requirements, addressed the assumed problem, and replaced numerous older solutions. In this case, the “false prophet” was a product from a world-leading bearing manufacturer—something no one thought to question during the project. Had we questioned it, the project would have been very different.
The ABCs of Identifying False Prophets
Question everything:
The biggest mistake is blindly believing in “facts” that have not been properly verified. Every assumption is a potential source of error.
Sacred cows:
Every product contains parts that are considered untouchable—even when it is obvious that the solution is outdated. This is particularly common in cost-reduction projects. Sometimes the reason is that the solution was developed by a person or organization whose work is considered beyond criticism. Everything must be open to scrutiny.
Involvement:
“False prophets” are most effectively identified through teamwork. Working alone makes it easy to be misled and less likely that assumptions will be challenged sufficiently. A strong team filters out flawed conclusions more effectively.
The Moral of the Story
When we finally uncovered the real cause, we had a good laugh. We had been completely misled, and it had never occurred to us to question the core assumption. The same has probably happened to other designers. The most important lesson I have followed throughout my career ever since is this:
Constructive skepticism is essential in product design. The obvious solution is not always the right one. Do not believe everything. Do not assume. Healthy questioning is one of a designer’s most important tools. Surround yourself with people who enable you to do this.
LINK is a pioneer in integrated development, focusing on product and service design challenges by combining the digital and physical worlds. We offer strategic partnerships in product and service development, focusing on both user and business needs. The article’s author, LINK CEO Jaakko Anttila, has worked in integrated development throughout his career.
