A strong technology is only the beginning.
For Pierre-Olivier Gourmelon, building a successful product means connecting engineering rigor with customer value, economics, manufacturability, and the ability of a team to deliver consistently.
Q1. As your career has evolved from engineering into product and operational leadership, what has changed most in the way you think about building a successful product?
Early in my career, I naturally viewed product development primarily as an engineering problem: understand the requirements, identify the constraints, and create the best technical solution possible. I still believe deeply in engineering rigor, but my definition of a successful product has broadened considerably.
A strong technology is only the beginning. It must solve a problem that matters, create enough value to justify the cost and disruption of adopting it, and be supported by an organization capable of delivering it consistently. That means understanding not only performance, but also reliability, manufacturability, integration, economics, customer behavior, and the many forms of risk that stand between a promising concept and real-world impact.
Moving into product and operational leadership also taught me that products are ultimately built by teams, not individuals. My role is increasingly to create clarity: to connect customer outcomes to product requirements, place ownership with the people best suited to carry it, and ensure the team has the priorities, resources, and decision-making structure needed to succeed. Sometimes that has meant stepping into a leadership gap; at other times, it has meant stepping back and empowering someone else.
Today, I think of product leadership as the disciplined process of turning uncertainty into confidence—technical confidence, customer confidence, and ultimately confidence that the organization can create lasting value.
Q2. In engineering-driven companies, what helps technical teams and business teams work effectively together without losing the strengths of either side?
The most important factor is creating a shared definition of success without expecting everyone to think in the same way.
Technical teams should not be reduced to simply executing commercial requests, and business teams should not be treated as a source of interruptions or unrealistic deadlines. Both perspectives are necessary. Engineering protects technical truth and long-term product integrity; the business side ensures that the work remains connected to customers, economics, timing, and the realities of adoption.
The bridge between them is traceability. A customer need should translate into a measurable outcome, that outcome into product requirements, and those requirements into technical work. In the other direction, technical constraints and discoveries must be translated into their implications for customer value, cost, schedule, and risk. When that chain is visible, disagreements become productive discussions about priorities and tradeoffs rather than conflicts between departments.
Leadership also matters. I have always tried to put the team and the project first, assign ownership based on aptitude and fit, and give people both the responsibility and authority to succeed. Good collaboration does not require eliminating tension.
It requires trust, intellectual honesty, clear accountability, and a willingness to let the strongest idea win regardless of where it originated.
Q3. Looking across your experience in engineering, product development, and operations, what principle has remained most important when trying to bring a new technology into broader real-world use?
The principle that has remained most important is to stay anchored to the real problem while continuously reducing the risks that prevent the technology from solving it at scale.
New technologies often attract attention because of what they can do under ideal conditions. Broader adoption depends on everything surrounding that capability: whether it remains reliable, economical, manufacturable, understandable, and useful in the customer’s actual environment. Progress therefore comes from identifying uncertainty honestly, assigning ownership for resolving it, and learning systematically from testing and deployment.
That approach has been reinforced throughout my career, from engineering complex tools intended for demanding environments to helping develop and commercialize new electric-machine technology. In each case, the work required more than invention. It required translating technical potential into customer value and then building the people, processes, and partnerships needed to deliver it.
My personal philosophy has been similar: put the team and the project first, step into leadership when the situation requires it, and remain committed to continual self-improvement. No individual begins with every capability needed to bring a new technology into the world.
The important thing is to keep learning, recognize what the project needs next, and help the right people take ownership of it.
For Gourmelon, bringing new technology into the real world is ultimately about reducing uncertainty — turning technical potential into customer value while building the teams, processes, and partnerships needed to scale.