Seamos honestos sobre producto
La realidad sobre el desarrollo de producto
En este artículo vas a encontrar un artículo escrito por Mariano Morera sobre las capacidades para el desarrollo de producto. Tiempo estimado de lectura 7 minutos.
Seamos honestos sobre producto
‘Product is hard’
Este es el primer enunciado que encuentras al acceder a uno de los principales recursos para aprender sobre cómo crean productos las grandes startups del sur de Estados Unidos, el Silicon Valley Product Group (SVPG).
Al teclado Marty Cagan, quien también está detrás de algunos de los libros más influyentes en el ámbito del producto, Inspired y Transformed, y cuya obra me inspira a diario, pues establece las bases de un modelo de colaboración entre los factores que hacen producto y el que él denomina ‘four big risks’.
- Artículo original de 2017: Four Big Risks
Este modelo operativo simplifica la ecuación de Agile y sus derivados, como SAFe, pasando de un enfoque flexible a uno más líquido, del sprint a ‘shipping fast’, y configura una serie de roles y mecanismos de colaboración entre ellos, capítulo que comentaremos al final del artículo.
Ahora, seamos honestos. ¿Es realmente difícil hacer producto?
Personalmente, no me gustan las calificaciones de fácil o difícil, y mucho menos en el contexto de producto. Siempre prefiero hablar en términos de valor, como una ponderación mínima entre el impacto de la solución o funcionalidad y el esfuerzo o complejidad que conlleva llevarla a cabo con los recursos disponibles.
Veámoslo con perspectiva…
Si extrapolamos el calificativo de “difícil” a otros contextos, como jugar al ajedrez, podría decir que para mí es difícil porque apenas he jugado una decena de veces en 33 años, o al menos más difícil que para Ishaan de Khatalguri, que con 14 años lleva jugando 10 años y compite a nivel nacional en India.
El desarrollo de software, al igual que el ajedrez y muchas otras disciplinas, se basa en la creación de conocimiento bajo ciertas reglas, y el efecto compuesto en el conocimiento es crucial: cuanto más practicas, mejor eres en ello.
Con el avance de la inteligencia artificial, diría que nos quedan unos 3,5 años para que estos agentes sustituyan el trabajo de un PM general. Así que propongo ver producto como algo difícil divertido y valioso mientras dure.
Breve historia sobre producto
¿De dónde viene todo esto de producto?
Hace unos días me preguntaban en la oficina por una recomendación de libros para aprender sobre producto. Más allá de libros semi-académicos que recomiendo leer como los citados anteriormente de Cagan, mi recomendación número uno a este primer libro para aprender sobre producto es clara: Jobs, Isaac Walterson.
Me gusta pensar que Jobs definió un equilibrio entre ingeniería, diseño y negocio mucho antes que nadie, y que ese enfoque sigue impregnando la filosofía de producto actual, aunque el concepto de "producto" ya existía antes.
En 2007, Apple lanzó el primer iPhone 2G, que marcó el inicio de la línea de smartphones de Apple. Para 2011, cuando Apple anunció que había alcanzado los 100 millones de iPhones vendidos, el modelo "estrella" en el mercado era el iPhone 4, que se presentó en junio de 2010.
En resumen, Apple rompió la barrera de los 100 millones de usuarios en 4 años, creando un nuevo paradigma en la industria tecnológica y generando nuevas categorías de productos "universales" desde cero.
El resto es historia.
Si comparamos este periodo con el que tardaron las innovaciones de la primera y la segunda revolución industrial, con la producción textil y el ferrocarril respectivamente, que tomaron unos 120 años y aproximadamente 50 años, la diferencia es abismal.
El tiempo que le tomó a ChatGPT alcanzar los 100 millones de usuarios (gratuitos) fue de solo 3 meses en 2022.
En resumen, llevamos al menos desde el siglo XVIII innovando en productos desde una perspectiva comercial. Y si comparamos el tiempo necesario entonces con el de hoy, al alcanzar los 100 millones de usuarios, la diferencia es superior al 600%.
El cocktel de metodologías
El baile de metodologías es uno de los factores clave que hacen que producto sea difícil de entender. Agile, lean, glin, fan…Bromas a parte, la bibliografía es extensa por lo que vamos a repasar algunas metodologías clave que en mi opinión han marcado la manera de hacer producto hoy y son contenidos valiosos para revisar:
Durante la primera mitad del siglo XX, se dieron los primeros hitos de gestión de proyectos en el contexto industrial en las fábricas de Toyota TPS con ejemplos como Kanban, JIT o Kaizen. Este avance no se dio del día a la mañana, sino más bien como una reacción natural ante la necesidad de reinventar su modelo de negocio con recursos limitados tras la Segunda Guerra Mundial.
En la segunda mitad del siglo, los proyectos de defensa de EEUU y la carrera espacial aceleraron el desarrollo de aplicaciones y proyectos complejos, a menudo sin estructura ni precedentes, como el sistema SAGE (Semi-Automatic Ground Environment) y otras iniciativas de software en la NASA.
Esto llevó a sobrecostos y al surgimiento de lo que se conocería como la ‘crisis del software’ al final de la década de los 60.
Como primera respuesta a esta crisis, Winston Royce definió en los 70 el modelo Waterfall, que descomponía el proceso de desarrollo de software en diferentes etapas, desde la toma de requisitos hasta la implementación y el mantenimiento.
Ante las limitaciones de Waterfall, en los años 90 Jeff Sutherland y Ken Schwaber comenzaron a explorar enfoques más flexibles y colaborativos en el proceso de desarrollo.
Así nació Scrum, una metodología que fomenta ciclos de desarrollo más cortos, revisiones frecuentes y la capacidad de ajustar el rumbo del proyecto según el feedback recibido.
De hecho, muchos de los artefactos utilizados hoy en día en los ciclos de desarrollo de producto provienen de Scrum, no de Agile.
Entonces, ¿qué es Agile?
Agile es un big bang, un evento paradójico y único en el que 17 ingenieros de software se reunieron en Snowbird para filosofar y definir las pautas del nuevo desarrollo de productos, centrado en valores y principios frente a requerimientos rígidos. Las pautas están recogidas en: Manifesto Agile.
Agile no es solo una metodología, a mí me gusta verlo como una manera de pensar, que define una mejor estructura para los procesos de desarrollo de software y un enfoque centrado en el cliente, colaborativo y resiliente frente al cambio.
Aquí fue donde ocurrió el “click”:
Los productos centrados en el cliente tienen mayor probabilidad de éxito en el mercado.
Una mayor colaboración y comunicación entre los equipos de ingeniería y negocio mejora el clima laboral.
El software funcionando es el resultado clave.
Producto es el nuevo Agile
Agile despertó un apetito global por seguir optimizando los procesos de innovación, ahora desde una perspectiva de negocio más que de ingeniería.
Metodologías como Lean Startup y Design Thinking buscan, en mi opinión, minimizar el riesgo de adopción de nuevos productos o servicios mediante ejercicios que nos obligan a ponernos en los zapatos del usuario y a realizar ciclos más cortos, sin necesidad de desarrollos complejos o sofisticados en las primeras versiones.
El objetivo es aprender y fallar rápido, pero barato.
Aunque Agile hace un esfuerzo encomiable por influir en la comunidad de desarrollo de software con un enfoque más flexible y eficiente para el control y la colaboración, no resuelve completamente el desafío del producto. ¿Os imagináis a Jobs trabajando mano a mano con un Agile Coach o Scrum Master en el lanzamiento del iPhone 4?
Bromas aparte, en mi opinión, Agile no resuelve el producto porque a menudo complica la ecuación con frameworks como el Scaled Agile, mientras que las dinámicas de producto tienden a simplificarla, quizás en exceso.
El producto combina negocio, diseño y tecnología en un solo enfoque con espacio para pensar, construir, diverger, converger, hablar de problemas, soluciones, estrategia y operaciones. Y más que un proceso de ingeniería, especialmente en las fases iniciales de concepción, el producto se ve así:
Es por eso que, inspirado en Marty Cagan, me gusta entender la anatomía del producto basado en las siguientes dimensiones o grandes riesgos — de los cuales excluyo el value, pero eso lo dejaremos para otro artículo:
Viabilidad: el ROI del producto/proyecto, ¿es económicamente viable?
Usabilidad: la interacción con el cliente, ¿resuelve sus necesidades?
Factibilidad: la solución técnica, ¿podemos hacerlo con los recursos actuales?
Construir producto es difícil porque requiere combinar una mentalidad divergente (exploración de ideas) con una convergente (ejecución y entrega), a veces en un mismo día. Es difícil porque a veces hay que renunciar a una idea que nos apasiona cuando los datos indican que no tiene el impacto deseado. Es complicado priorizar la calidad sobre la rapidez de lanzamiento, y esas batallas entre departamentos que siguen ocurriendo, pero es precisamente en superar esas dificultades donde reside el verdadero valor del producto. Esto no va de metodologías, sino de “clicks” que te indican por dónde ir en un plano de alta incertidumbre.
Si quieres saber más sobre cómo hacemos producto en Igeneris, escríbenos en comentarios.
Recomendaciones
🎙️ Emprendimiento e innovación en el sector financiero en México con Fernando Padilla y Grupo Alifin
Un episodio en el que traemos a un gran empresario, emprendedor y educador del mundo financiero, Fernando Padilla, fundador de múltiples empresas financieras que conforman el Grupo Alifin, enfocadas en ayudar al empresario mexicano.
📰 It’s the End of the Web as We Know It (And I Feel Fine)
El artículo de M.G. Siegler en Spyglass discute cómo la creciente adopción de modelos de lenguaje de inteligencia artificial está transformando radicalmente la búsqueda en la web y la publicación de contenido, desafiando el modelo tradicional.
#JoinIgeneris 🤝
Igeneris sigue creciendo. Si estás interesado en alguna de nuestras ofertas o conoces a alguien que pueda encajar, ¡no dudes en contactar con nosotros!
En la oficina de Madrid buscamos:
En la oficina de Portugal buscamos:
En la oficina de México buscamos: