Skip customer discovery, and an engineering team can spend months building a technically impressive product and still discover that customers do not consider the problem worth solving.
The technology may work. The business case may not.
Perhaps the problem is less urgent than the team assumed. Perhaps the solution requires too much disruption. Or perhaps it solves one factory’s unusual situation while adding complexity for everyone else.
My approach to customer discovery is to speak with at least eight to ten potential customers before locking the product specification.
That number is a rule of thumb, not a formula for market validation. The purpose is to hear enough different perspectives to begin distinguishing a recurring operating problem from an isolated request.
Customer discovery starts with the problem people already have
I came from a services background, where understanding the customer’s needs comes before designing the answer. That experience shaped how I approach industrial technology.
Before becoming attached to a product idea, I want to understand what is creating pain, what customers have already tried, and why the problem remains unresolved.
In manufacturing, those questions need to reach beyond the inspection station.
If a factory struggles with inconsistent inspection, what happens next? Does production stop? Do quality engineers spend hours reviewing disputed results? Does unnecessary rework consume capacity? Does the problem reach the customer?
The operating consequence tells us why the problem matters. It also helps us judge whether solving it deserves the engineering effort, capital, and organizational attention involved.
Interest alone is not enough. I want to understand whether customers are prepared to commit resources to addressing the problem.
“The customer” is more than the buyer
The person approving an investment may have a different view from the person living with the result every shift.
Both perspectives matter.
An operator may know which conditions change after a changeover. A quality engineer may explain why two visually similar marks require different decisions. A manufacturing engineer may recognize that a proposed camera position interferes with normal line operation.
Those conversations can change the specification before an expensive assumption becomes part of the design.
I often think about the person facing the heat every day because of the problem. That person may not have the most senior title, but they will quickly recognize whether a proposed solution removes work or creates another workaround.
Their knowledge belongs in the discovery process.
Look for repetition without promising every request
Customer discovery requires judgment.
One manufacturer may request a feature that addresses a highly specific situation. Another may describe a need that appears across several factories.
Those requests should not automatically carry the same weight.
A customer request is evidence. It becomes a product requirement when the team understands the underlying problem and decides it belongs within the product’s purpose.
I look for repeated needs, shared constraints, and operating consequences that matter across customers. I also look for differences that could make an apparently common problem harder to solve consistently.
Listening closely does not require turning the product into a separate custom system for every customer.
Customer discovery doesn’t end at the specification
Discovery does not end when development begins.
At Lincode, production taught us to evaluate imaging, intelligence, infrastructure, integration, validation, and support as one system. Glossy surfaces challenged imaging assumptions. Sustained production volume challenged capacity assumptions. Factory environments challenged hardware choices.
The factory gets a vote. It is the same reason AI inspection pilots fail after a successful demo.
When production evidence disagrees with the design, the team needs to investigate which assumption no longer holds, make the appropriate change, and validate it.
Each deployment should improve the questions we ask during the next one.
Customer discovery with eight to ten customers cannot remove uncertainty. It can help a team recognize important uncertainty before committing to an elegant answer.
The objective is to build something the factory can operate, support, measure, and improve.
For more on this customer-first approach, read Chapter 20, “Build What the Factory Will Use,” in my bestselling book, Teach the Factory to See. Get it on Amazon.
