Go see, ask why, show respect –Taiichi Ohno
Ohno was the father of the Toyota Production System (TPS) and Lean manufacturing.
This commandment is deceptively simple because it asks the team to do something basic but often neglected: leave the comfort of specifications, conference rooms, and test benches, and look at the customer’s reality directly. Along with a disciplined approach, Go and See is one of the foundations of effective product development, because discipline tells us how to work, while observations at customer sites tell us whether the work is pointed at the right problem.
Observe at the actual place of use
A successful product must add value to customers, improve their personal or professional experience, and in general improve their “feel good” factor. To achieve this, product development teams must understand the real needs of customers, including needs that are specified and needs that remain unstated. Unfortunately, most product requirement documents fail to capture these real needs. They make sense only when the team already understands the customer’s context. Asking customers is therefore not enough. Interviews with intended user groups are useful, but nothing works better than observing users at the place where the intended product will actually be used. The Japanese call this place “Gemba” 現場.
Customer Value
Customers may not always describe their real needs. Sometimes they may not know those needs themselves, or they may not imagine that the work can be done differently. Ultimately, however, customers recognize value when they can do something that was not possible earlier, do it with less effort or cost, or improve the quality of their work and life.
Keen observations at the place of usage provide pointers to the real needs, and whether the proposed product will indeed add value to whatever the customers are doing.
The Real Place
“Gemba” means “the real place” in Japanese. For a product development team, it is the place where the product under development is likely to be used. By observing that real place, teams can gain invaluable insights into customer needs and pain points. Going to the Gemba reveals two things: latent needs, or what users wish they could do, and unspoken constraints, or the physical, operational, and environmental realities that no Requirement Document ever remembers to list. To benefit from a Gemba Walk, the team must remember a few things.
First, the development team must be clear that the visit is for the team’s education, not for the users’ education. The team should do its homework and decide what it wants to find out. It is better to observe more and internalize carefully. A few questions may be useful, but they must never sound challenging. The famous 5W1H framework—Who, What, When, Where, Why, and How—can be used when required. However, one must be careful with “Who” and “Why.” The target of “Who” is not a person, but a role. Do not use “Why” to challenge something or someone, but to understand the genuine reason when it is not clear.
Onboarding
Whenever a new development engineer joined the lab, I made it a point to let him visit the place of actual use. This could mean joining a site installation with service engineers, observing the handover of an installation to the customer’s maintenance department, or participating in requirement gathering at a new site.
Over the years, my teams have been involved in very diverse customer sites. These included steel plants, power stations, railway marshalling yards, food processing units including a chocolate factory, pharmaceutical manufacturing units, hospitals, doctors’ clinics, large pathology labs and diagnostic centres, a virus research institute, a rocket launching station, and military installations. Each site taught us that the same engineering discipline has to survive very different realities.
New domain
When we were asked to develop a new product line, I made it a point to visit a representative site where the product would be used, observe the work that users were doing, and speak with potential users. Our customers were very cooperative and ensured that we were exposed to representative locations. Some of these were sensitive locations and required special clearances. That extra effort was worthwhile because a new domain cannot be understood only through documents and internal discussions.
Deep in the coal mine
Before embarking on the development of a communication system for deep-shaft coal mines, I visited a facility nearly six hundred meters underground to experience the environment firsthand. What a revelation!
Our Industrial Design team had originally promised sleek, contoured, modern ergonomics. But standing in the shaft made the flaw instantly clear: within a day, black coal dust will fill those sleek grooves and fine crevices. I had to convince our designers to give up the fancy aesthetics and embrace rugged reality: a smooth, black, wipe-clean housing with just two large, sealed pushbuttons that coal dust could not jam. Those units were not just for daily communication; in an emergency, they were a miner’s only link to the surface. You cannot design for an environment you have not stood in.
Work with the users
Sometimes, I also encouraged key members of the development team to participate in the users’ work so that they could understand the real need. Once, we were developing computer software for managing inventory in the stores of a pharmaceutical manufacturing company. I convinced key members of the software development team to work like apprentices in the plant’s stores to understand the pain points and identify where the new software could add value. Normally, stores follow two issue strategies: First In First Out (FIFO) or Last In First Out (LIFO). After observing the importance of raw-material expiry dates in the plant, one of the developers proposed a different issue strategy: First Expiry First Out (FEFO). Though FEFO is a well-known concept in pharma and food processing, no one in the plant had told us about it. They were not even sure that software could handle it. Eventually, the plant saved significant money by reducing losses from expired material.
Summary and key takeaways
The final commandment, “Go and See,” is the bridge between the controlled environment of the laboratory and the unpredictable reality of the user’s world. Requirement documents provide a necessary skeleton, but they often miss the flesh and blood of the actual experience. True innovation is found in the Gemba—the real place where the work happens. By observing users in their natural environment, development teams can move beyond fulfilling a specification and create genuine value by uncovering the unspoken needs, hidden constraints, and subtle frustrations that no questionnaire can fully capture.
- Documents are Not the Territory: Recognize that requirement documents are a filtered version of reality. They often capture only what is easily visible and measurable, leaving the most impactful unstated needs for you to discover through direct observation.
- The “Learner” Mindset: A Gemba Walk is an exercise in humility and education. You are there to learn from the user’s environment. Avoid the temptation to “educate” the user or defend your design; instead, listen, observe, and internalize.
- Discovering Latent Needs: Customers often develop “workarounds” for problems they don’t even realize they have. Keen observation allows you to spot these inefficiencies and design solutions that provide a “feel-good” factor the user didn’t know was missing.
- Respectful Inquiry: Use the “5W1H” framework—Who, What, When, Where, Why, and How—to guide your learning. Be particularly careful with “Who” by targeting the role, not the person, and with “Why” by seeking the genuine reason rather than challenging someone’s competence.
- Contextual Validation: A product that performs perfectly on a test bench may struggle in a crowded hospital ward or a vibrating factory floor. Seeing the “Real Place” ensures your design is robust enough for the actual conditions of use.
- Value is the Ultimate Goal: Ultimately, a successful product must improve the user’s quality of life or professional efficiency. If you cannot see how your product adds value in the Gemba, it is time to rethink the design.
Closing Remarks
With this final commandment, we complete our journey through The Ten Commandments of Product Development:
Commandments 1 to 5 form the foundation of mindset, discipline, and teamwork:
1. Follow a Disciplined Approach: Our bedrock for turning ideas into lasting business assets.
2. Embrace Uncertainty: Learning to navigate evolving requirements as clarity emerges.
3. Maintain a Sense of Urgency: Tackling hard problems early to buy time for detail later.
4. Collaborate and Ask for Help: Remembering that product development is fundamentally a team sport.
5. Apply Portable Knowledge: Institutionalizing lessons learned so every project builds on the last.
Commandments 6 to 9 establish Technical and Engineering Rigor:
6. Conquer Fear and Experiment: Empowering teams to innovate without the paralysis of failure.
7. Prototype Everything: Building early and often to make concepts tangible.
8. Pay Obsessive Attention to Detail: Locking in upstream quality on the drafting table and test bench.
9. Never Ignore Development Failures: Investigating every anomaly, inviting stress cases, and learning from the “troublemakers”.
Commandment 10 completes the circle:
10. Go and See: Completing the circle by validating disciplined engineering in the real world, so that our work delivers true value to human beings.
Thank you for following along with the Concept to Concrete series. I invite you to share your thoughts, critiques, or personal experiences in the comments. In upcoming posts, I look forward to sharing more real-world case studies, historical engineering anecdotes, and reflections on the craft of product development.
“Innovation is seeing what everybody has seen and thinking what nobody has thought.”
— Albert Szent-Györgyi