Nampoina Rakotoniaina, Head of Product and Product Coach at Thiga, has just had his first experience within a company that designs physical products. A cultural shock he shares to build bridges between two worlds so different yet so close. Here’s his story.
April 2023. It's already been 10 years since I've worked in the digital space, and now I've been thrust into an international, publicly traded group with more than 135,000 people: Schneider Electric. Working on assignments for a specialist in electronic equipment, such as push buttons, switches, electrical circuits, sensory sensors, or circuit breakers, is a first for me as a Product Coach. I wonder: “Physical product vs digital product... Are we doing the same job, and what can we learn from each other?”
While some products do incorporate software, this world is entirely unfamiliar to me. My mission? To build bridges! My goal? To support the agile transformation of a team of 70 people, mostly based abroad. I still remember that trip to Zlín, in the Czech Republic, just a few weeks after my arrival. I met well-meaning but also somewhat wary people, especially regarding Agility.
🤔 Lesson 1: "Our Job is to Doubt"
As I said, the beginnings are far from comfortable, for the teams who must question their ways of working and thinking, but also for me, who must learn their specifics and question my own beliefs.
I already knew this, but this experience reminds me of something obvious: doubt is a major part of our job. We doubt user feedback or the solutions we find. Here, I doubt the Agile methodologies of software applied in a hardware environment! With this nagging question at the beginning: "Will I be credible to them?"
But our role is precisely to gradually reduce this uncertainty. Specifically, by strongly questioning the "why" in our respective practices, trying to understand each other, and finding points of convergence between our two worlds.
🍕 Lesson 2: "Forget 'Pizza Teams'!"
For a digital product, it's not surprising to have tasks that can be divided among developers. Whether backend or frontend, there is often a notion of full stack that allows for efficient progress.
The manufacture of a physical product sometimes requires very specific expertise that intervenes at very precise moments in the product's design: electronic engineers, mechanical designers, buyers, certification officers... If one of them is absent, the whole process stops. Moreover, self-organization, skill development, and continuous improvement of a team on the cyclical model of Scrum is not so simple for hardware teams, and it's easy to give up.
If you come from the digital world and do not adapt your perspective, you’re heading straight for disaster…
However, a trend is emerging: to think of work in teams around a "module" (a set of components delivering value to the user, like the suspension and braking system of a car, providing safety, comfort, stability) rather than leaving one person alone to work on a component (the brake pedal).
For more information: download our Product Management Toolkit
⏱️ Lesson 3: "A Different Temporality from the Go Product Roadmap"
In the digital world, when we create a roadmap, we seek to gain visibility. First on the "now" (the three-month horizon), then on the initiatives that will come "next" (the 6-9 month horizon), and finally on those that need to be refined but will eventually arrive in the "later" (9 months and beyond). Just having arrived in the world of physical products, we are told: "In three months, nothing can be done!" The temporality is different for a digital product and a physical product. The latter follows a very linear manufacturing cycle: design time, then industrialization time, and finally distribution time, with sometimes unavoidable delays. Again, if you come from the digital world and do not adapt your perspective, you’re heading straight for disaster...
Moreover, in hardware, an "error" is not simply resolved by modifying a line of code in production: the resolution is not measured in days but in weeks—if not months—with sometimes multiple and significant consequences: recalling all products sold in stores, reviewing the physical design of a part or even the entire product in the factory... Furthermore, some concepts are invisible or negligible in software. I think of safety, certification, but also and especially cost issues, for example.
Unlike digital, because the product integrates into a home, office, or factory, it must strictly adhere to very stringent physical safety standards, which can vary by country or region. And some of these rules sometimes apply to prototypes: you can't test everything under any conditions. Add to that the cost of reliability tests, and it quickly becomes clear that we must rethink (without abolishing) the notion of proximity with the user throughout the product's design. This complexity explains the much longer timeline in hardware.
🧗 Lesson 4: "More Complex Iterations..."
Ensuring permanent collaboration between users and teams is more complicated in hardware. The frequencies of iterations are entirely different. Just think of the tests that must be performed on a prototype: these are often customer demos based on very advanced prototypes. The complete opposite of digital, where we often test a part of the product developed during the previous iteration.
The challenge is therefore a cultural change in hardware, encouraging iteration as often as possible. As an Agile coach at Schneider Electric told me, "It's also about knowing how to accept putting imperfect prototypes to the test." The important thing is not the output (the prototype itself) but the outcome (what we learn from the prototype, its handling, its use). A philosophy echoed by a rival IoT Head Of Product: "If we hadn't had nearly 400 ambassadors to test one of our products throughout the design process, we wouldn't have had as much feedback on certain problems. That way, we detected them before going into mass production."
📚 Lesson 5: "Do Not Succumb to Doing Things By the Book"
Agile by the rules is never a guarantee of success: if this is true in digital, it is even more so for a physical product! You must constantly adapt to your environment. Otherwise, it means you haven’t understood your job as a Product Manager.
As my mission progressed, I always tried to question the relevance of the models to be deployed. This questioning is particularly evident when implementing OKRs. Generally, this concept is linked to the impact you want to have. However, as we have seen, putting a physical product on the market takes more time because it must be "finished." For connected products, you can always update the software or anticipate an evolution by choosing the right components. But it remains complex to "renew" the added value of the product, offering, as in software, improvements very regularly.
This is why, instead of locking myself into a rigid vision, I decided to set aside what I had learned in terms of best practices, adopting an approach of OKRs sometimes oriented towards output and not solely outcome. All while keeping a strategic vision for 5 years with a common goal for the entire team. The goal? Align stakeholders, take a step back, and keep in mind the final benefit for the customer.
At the end of my 5-month mission, we managed to plant an Agile seed in this hardware soil. It was enough to offer teams a better ability to adapt, to think outcome and results rather than output and features. In short, to enable them to be more effective and deliver better products.
It also taught me a lot about my own practices as a Product Manager. Instead of staying in my comfort zone, I had to adopt a practical approach: we went back to the essence of Agility by relying on its main principles, not with dogmatism but with flexibility, subordinating them to the material reality. For example, we did so by making concessions on the delivery rhythm or daily work with users. Rules are good, but pragmatism is sometimes better!
Above all, I realized that fundamentally, our jobs are not so different. Strategy, discovery, and delivery remain the three pillars of our disciplines. The tools and ways to achieve them diverge, but the principles and ambition remain the same. We certainly have things to learn from each other. One must still have the humility to question their practices...
For more information: download our Product Management Toolkit
