Great things in business are never done by one person. They’re done by a team of people.
– Steve Jobs
Product Development Is a Team Effort
Product development is fundamentally a team effort. A development team typically includes people with different expertise, skills, and experience, such as electronics hardware engineers, firmware engineers, software engineers, mobile application developers, UX/UI designers, and mechanical engineers. Not every team member will be assigned full time to the project; some may be shared across multiple teams. Each person usually has a defined area of responsibility, but there will inevitably be situations where ownership is unclear. In such cases, the team must resolve the ambiguity quickly so that someone takes responsibility and drives the issue to a logical conclusion.
The Ego Trap: Why We Stop Progress
Earlier, we discussed maintaining speed and a sense of urgency. Yet, I often see talented developers stall their own progress because they are stuck in the “Ego Trap.” They repeat the same unsuccessful experiment for hours, hoping that persistence alone will yield a different result. Persistence matters but repeating the same action without learning rarely produces a different result. In such situations, collaboration helps the team break the loop, explore new ideas, and move toward a solution more effectively.
In the lab, persistence without adaptation is not a virtue—it is a bottleneck.
If you have been stuck on a problem for more than a few hours, you are no longer “working hard”; you are spinning your wheels. Asking for help is not a personal failure or a sign of incompetence. It is a professional strategy. A fresh pair of eyes is often the most valuable tool in your development kit.
Collaboration Requires the Right Mindset
Collaboration isn’t just a process; it’s a mindset. Your team must first accept that success is a collective outcome, not an individual one. This starts by de-stigmatizing the act of asking for help. When you encounter a technical or functional roadblock, don’t let it fester—identify it early and actively solicit input from teammates or cross-functional experts. True collaboration requires an open mind: you must be willing to seriously consider, and perhaps adopt, a perspective that differs from your own.
The “Fresh Mind” Advantage
Collaboration is more than just delegating work; it is about shifting perspectives. A colleague from a different project or function can often spot a solution that you, being too close to the problem, have overlooked.
I have found that the most innovative teams are those that foster a culture where:
- Asking for suggestions is encouraged as a sign of technical maturity.
- “Stalling out” is immediately flagged as a signal to invite a fresh perspective.
- Cross-pollination between teams is seen as the quickest path to a “eureka moment.”
Lessons from the Field: Speak the Same Language
Collaboration must extend beyond the development lab to include domain expertise.
I once consulted for a startup developing software for optical microscopes to analyze metal samples. The team had incredible software engineers who met every documented requirement, yet the customer remained unsatisfied. They were technically “correct,” but they didn’t understand the context. They were speaking “code,” and the customer was speaking “metallurgy.”
The fix wasn’t more software; it was hiring a metallurgical engineer to translate the problem. Within a month, the gap closed, and the development progressed smoothly.
The takeaway? Do not start building a solution for a domain you don’t understand. If you lack the usage-domain expertise, find it—either within your organization or through an external consultant. Your product is only as good as the problem it solves.
With this learning, we were able to successfully expand into software projects in cutting‑edge domains such as mass spectrometry, gas and liquid chromatography, genomics, proteomics, electron microscopy, and molecular biology.
Cross-Functional Synergy
Finally, bring in “the real world” early. Nominate representatives from Manufacturing, Procurement, and Quality to join your review loops. Integrating these functions early ensures that your product isn’t just “functional”. It is also viable, sustainable, and ready to be delivered to a customer. Use these cross-functional teams for Gate Reviews to identify hurdles in your Phase-Gate process before they become expensive roadblocks.
The cross-functional review team can review the progress of the product development project not only against schedules, but also against technical milestones and key achievements, while alerting the development team to anticipated risks or constraints.
Equally important is deep knowledge of the product’s usage domain. This expertise may come from a domain expert within the organization, from the customer’s team, or from an external specialist, and is critical for ensuring that real‑world use cases and constraints are properly addressed.
Key Takeaways
- Own the “Gray Areas”: If a task falls between roles, don’t wait for permission. Own it and solve it.
- Break the Loop: If you’re stuck, pivot. Collaboration is your primary tool to break the cycle of ineffective repetition.
- Translate Context: Technical perfection is irrelevant if you don’t understand the user’s domain. Hire or consult for the expertise you lack.
- Gate Review Wisdom: Use cross-functional partners as “early warning systems” to spot risks that you might be too close to see.
This commandment is about Teamwork and Collaboration, the next one is about making sure you do not re-invent the wheel, re-using available knowledge. In the next post in this series, I will cover Commandment 5: Apply Portable Knowledge
I would appreciate hearing from you, how your team handles domain knowledge
“Collaboration is the fuel that allows common people to attain uncommon results.”
— Anonymous