Nampoina Rakotoniaina, Head of Product y Coach de Producto en Thiga, acaba de tener su primera experiencia dentro de una empresa que diseña productos físicos. Un choque cultural que comparte para construir puentes entre dos mundos tan diferentes y, sin embargo, tan cercanos. Aquí está su historia.
Abril 2023. Ya llevo 10 años trabajando en el mundo digital, y ahora me encuentro en un grupo internacional cotizado en bolsa con más de 135.000 personas: Schneider Electric. Es mi primera vez trabajando como Product Coach para un especialista en equipos electrónicos. Me veo rodeado de interruptores, circuitos eléctricos, sensores sensoriales o disyuntores y me pregunto: “Producto físico vs producto digital... ¿Hacemos el mismo trabajo? ¿Qué podemos aprender unos de otros?”
Aunque algunos productos incorporan software, este mundo es totalmente desconocido para mí. ¿Mi misión? ¡Construir puentes! ¿Mi objetivo? Apoyar la transformación ágil de un equipo de 70 personas, en su gran mayoría en el extranjero. Aún recuerdo ese viaje a Zlín, en la República Checa, solo unas semanas después de mi llegada. Conocí a personas bienintencionadas pero también algo desconfiadas, especialmente en el tema de la agilidad.
🤔 Lección 1: "Nuestro trabajo es dudar"
Como ya he dicho, los comienzos están lejos de ser cómodos. Por un lado, para los equipos que deben cuestionar su forma de trabajar y pensar. Pero también para mí, que debo aprender sus especificidades y cuestionar mis convicciones.
Ya lo sabía, pero esta experiencia resalta una obviedad: la duda es una parte integral de nuestro trabajo. Dudamos de los comentarios de los usuarios o de las soluciones encontradas. Aquí, dudo de las metodologías ágiles del software aplicadas en un entorno de hardware. ¡Con esta pregunta persistente al principio: "¿Tendré credibilidad ante sus ojos?"
Pero nuestro rol consiste precisamente en trabajar para reducir progresivamente esta incertidumbre. En este caso, cuestionando fuertemente el "por qué" en nuestras prácticas respectivas, intentando comprendernos unos a otros y encontrando puntos de convergencia entre nuestros dos mundos.
🍕 Lección 2: "¡Olvídate de los 'Pizza Teams!"
Para un producto digital, no es sorprendente tener tareas que pueden dividirse entre desarrolladores. Ya sea en backend o en frontend, a menudo hay una noción de full stack que permite avanzar eficientemente.
La fabricación de un producto físico a veces requiere conocimientos muy específicos que intervienen en momentos muy precisos del diseño del producto: ingenieros electrónicos, diseñadores mecánicos, compradores, responsables de certificación... Si falta uno de ellos, todo el proceso se detiene. Además, la autoorganización, el desarrollo de competencias y la mejora continua de un equipo en el modelo cíclico de Scrum no es tan simple para los equipos de hardware, y es fácil darse por vencido.
Si vienes del entorno digital y no adaptas tu perspectiva, vas de cabeza al precipicio…
Sin embargo, está surgiendo una tendencia: pensar en el trabajo en equipos, alrededor de un "módulo" (un conjunto de componentes que ofrecen valor al usuario, como el sistema de suspensión y frenado de un coche, que proporciona seguridad, confort, estabilidad) en lugar de dejar que una persona trabaje sola en un componente (el pedal de freno).
Para más información: descarga nuestro libro Las Claves del Product Management
⏱️ Lección 3: "Un marco temporal diferente del Go Product Roadmap"
En el mundo digital, cuando pensamos en "roadmap", buscamos obtener visibilidad. Primero en el "ahora" (el horizonte de tres meses), luego en las iniciativas que vendrán "después" (el horizonte de 6-9 meses), y finalmente en las que necesitan ser refinadas pero que eventualmente llegarán en el "futuro" (9 meses y más). Al llegar al universo del producto físico, nos dicen: "¡En tres meses no hacemos nada!" La temporalidad es diferente para un producto digital y un producto físico. Este último sigue un ciclo de fabricación muy lineal: un tiempo de diseño, luego un tiempo de industrialización y finalmente un tiempo de distribución, con plazos a veces incompresibles. Nuevamente, si vienes del mundo digital y no adaptas tu perspectiva, vas de cabeza al precipicio...
Además, en hardware, un "error" no se resuelve simplemente modificando una línea de código en producción: la resolución no se mide en días sino en semanas, si no es en meses, con a veces múltiples y significativas consecuencias: retiro de todos los productos vendidos en tiendas, revisión en fábrica del diseño físico de una parte o incluso del producto completo... Además, algunos conceptos son invisibles o insignificantes en software. Pienso en cuestiones de seguridad, certificación, pero también y especialmente en costos, por ejemplo.
A diferencia de lo digital, como el producto se integra en un hogar, una oficina o incluso una fábrica, debe adherirse estrictamente a normas de seguridad física muy estrictas, que pueden variar según el país o la región. Y algunas de estas reglas a veces se aplican a los prototipos: no se puede probar todo bajo cualquier condición. Si a esto añadimos el costo de las pruebas de fiabilidad y rápidamente se entiende que debemos repensar (sin abolir) la noción de proximidad con el usuario durante todo el diseño del producto. Esta complejidad explica el horizonte temporal mucho más largo en hardware.
🧗 Lección 4: "Iteraciones más complejas..."
Asegurar una colaboración permanente entre los usuarios y los equipos es más complicado en hardware. Las frecuencias de iteraciones son completamente diferentes. Pienso en las pruebas que debemos hacer de un prototipo: a menudo son demostraciones para clientes basadas en prototipos muy avanzados. Todo lo contrario de lo digital, donde a menudo probamos una parte del producto desarrollada durante la iteración anterior.
El desafío es, por lo tanto, un cambio cultural en el hardware, alentando a iterar tan a menudo como sea posible. Como me confió una coach Agile de Schneider Electric, "también se trata de saber aceptar poner a prueba prototipos imperfectos". Lo importante no es el resultado (el prototipo en sí mismo), sino el resultado final (lo que aprendemos del prototipo, su manipulación, su uso). Una filosofía que resuena en un Head of Product IoT competidor: "Si no hubiéramos tenido cerca de 400 embajadores para probar uno de nuestros productos a lo largo del proceso de diseño, no habríamos tenido tanto feedback sobre ciertos problemas. Ahí, los detectamos antes de lanzar la producción en masa."
📚 Lección 5: "No sucumbir al 'by the book'"
El agile según las reglas nunca es garantía de éxito: si esto es cierto en digital, ¡lo es aún más para un producto físico! Debes adaptarte constantemente a tu entorno. De lo contrario, significa que no has entendido tu trabajo como Product Manager.
A medida que avanzaba mi misión, siempre trataba de cuestionar la pertinencia de los modelos a desplegar. Esta interrogación se materializa especialmente en la implementación de los OKR. Generalmente, este concepto está relacionado con el impacto que quieres tener. Sin embargo, como hemos visto, poner un producto físico a disposición del mercado lleva más tiempo, porque debe estar "terminado". Para productos conectados, siempre se puede actualizar el software o anticipar una evolución eligiendo bien los componentes. Pero sigue siendo complejo "renovar" el valor agregado del producto, ofreciendo mejoras de forma periódica, como ocurre con el software.
Por eso, en lugar de encerrarme en una visión rígida, decidí dejar de lado lo que había aprendido en términos de buenas prácticas, adoptando un enfoque de OKR a veces orientado hacia resultados y no únicamente hacia impactos. Todo esto manteniendo una visión estratégica de 5 años con un objetivo común para todo el equipo. ¿El objetivo? Alinear a los stakeholders, tomar perspectiva y que todos tengan en mente el beneficio final para el cliente.
Al final de mi misión de 5 meses, logramos plantar una semilla Agile en este terreno de hardware. Suficiente para ofrecer a los equipos una mejor capacidad de adaptarse, pensar en resultados y beneficios en lugar de resultados y funcionalidades. En resumen, para permitirles ser más efectivos y entregar mejores productos.
Esto también me enseñó mucho sobre mis propias prácticas como Product Manager. En lugar de quedarme en mi zona de confort, tuve que adoptar un enfoque práctico: volvimos a la esencia de la agilidad basándonos en sus principios fundamentales, no con dogmatismo, sino con flexibilidad, subordinándolos a la realidad material. Por ejemplo, haciendo concesiones sobre el ritmo de entrega o el trabajo diario con los usuarios. Las reglas son buenas, pero el pragmatismo ¡a veces es mejor!
Sobre todo, me di cuenta de que, en el fondo, nuestros trabajos no son tan diferentes. Estrategia, discovery y delivery siguen siendo los tres pilares de nuestras disciplinas. Las herramientas y las formas de llegar a ellas divergen, pero los principios y la ambición permanecen. Sin duda, tenemos cosas que aprender unos de otros. Solo necesitamos tener la humildad de cuestionar nuestras prácticas...
Para más información: descarga nuestro libro Las Claves del Product Management
