Técnicas de Priorización: Si todo es urgente, nada es urgente

Product Management

Técnicas de Priorización: Si todo es urgente, nada es urgente

Ya que nuestros recursos, tiempo y capacidad son finitos, es importante que nos enfoquemos que lo que realmente importa. Y aquí viene entonces “la gran pregunta”: ¿Cómo podemos priorizar el trabajo, las iniciativas de proyectos, los requerimientos, funcionalidades o atributos de un producto a fin de enfocarnos en lo que realmente importa? El día de hoy te comparto un compendio de técnicas de priorización, imprescindible para todo Scrum Master, Agile Coach (si quieres profundizar un poco sobre este rol, puedes leer un artículo que escribí sobre el marco de competencias del Agile Coach (link: https://leonelzapien.com/blog/scrum-master-o-agile-coach text: aquí)), Project Manager, Product Owner, Product Manager, y etcétera y etcétera: Como dicen mis amigos españoles: Vamos al lío con esto (vamos al punto, al grano, como decimos acá en México). # 1. MoSCoW (image: moscow-must-should-could-wont-metodo-priorizacion.webp) Es un acrónimo que nos ayuda a definir qué atributos, características o iniciativas son un Must (Debe de hacerse), Should (Debería hacerse), Could (Podría hacerse), y Won't (No se hará, o no en este momento). • **Must (Deben de estar): **Requerimientos o características absolutamente críticas e imprescindibles, deben de ir. • **Should (Deberían estar): **Aspectos que son importantes también, pero no imprescindibles. Deben realizarse de ser posible, o en futuras entregas (próximos sprints, o próximas liberaciones o releases). •** Could (Podrían estar): **podrían incluirse si no se afecta nada más de lo que es Must o Should, o si alcanzamos con la capacidad, tiempo o presupuesto que tenemos. • **Won’t (No estarán): **Se pueden excluir por no ser relevantes, no merecen la inversión, no aportan beneficio o no son necesarios en este momento (se podrían considerar más tarde). # 2. Método RICE (image: rice-metodo-priorizacion.webp) RICE un acrónimo que establece cuatro criterios para obtener un índice de prioridad numérica, a mayor alto el índice, mayor la prioridad del elemento que se está evaluando. • **Reach (Alcance):** El alcance que tendrá si se lleva a cabo esta característica, funcionalidad o iniciativa (número de personas que utilizarán nuestra funcionalidad o producto, o personas a las que se alcanzará). • **Impact (Impacto):** El valor que se estima tendrá nuestra funcionalidad o producto (bajo/medio/alto, o bien una escala numérica de menor a mayor). • **Confidence (Confianza): **Grado de certeza de que nuestra funcionalidad, producto o iniciativa tendrá éxito (bajo/medio/alto, o escala numérica de menor a mayor). • **Effort (Esfuerzo para realizarlo o construirlo): **El trabajo que se estima será requerido para realizarlo, dependiendo de su complejidad (bajo/medio/alto, small/medium/large o S/M/L). Índice RICE = ( R * I * C ) / E A un índice más alto, mayor la prioridad. **Nota:** Para esta técnica, al igual que varias que revisaremos más adelante que tienen un factor numérico, el definir una escala, por ejemplo, del 1 al 10, o alto/medio/bajo, para un elemento, es en realidad una estimación, por esto la importancia de definir de manera conjunta y bajo consideraciones cocreadas el cómo definir este número, escuchando a todas las voces de acuerdo con el contexto correspondiente (a los especialistas en el tema, al área de negocio, al área técnica, a quienes tienen trato con el cliente y/o usuario, etc.). Es cierto, a final de cuentas es una estimación, por lo cual debemos de apoyarnos en información necesaria y no olvidar el trabajar en ciclos cortos de inspección y adaptación para obtener retroalimentación lo más rápido (y barato) posible. # 3. Valor de Negocio vs Esfuerzo (image: valor-de-negocio-vs-esfuerzo-metodo-priorizacion.webp) Proporciona un índice numérico de manera sencilla, dividiendo el valor estimado de negocio que proporcionará una determinada funcionalidad, característica o iniciativa, entre el esfuerzo de realizarla (este esfuerzo puede ser un número proporcional definido por el equipo, por ejemplo: bajo/medio/alto, una escala numérica, o bien puntos de historias de usuario). El valor esperado de negocio debe ser definido por el Product Owner / Product Manager, especialistas del área de negocio. El esfuerzo estimado lo define el área técnica que va a realizar el trabajo. Valor de Prioridad = Valor de Negocio / Esfuerzo A un índice más alto, mayor la prioridad. Ejemplo: (image: ejemplo-valor-de-negocio-esfuerzo.webp) # 4. WSJF (Weighted Shorted Job First) (image: wsjf-weighted-shorted-job-first-safe-tecnica-priorizacion-product-development-flow.webp) WSJF es un acrónimo que significa algo como “El trabajo más corto ponderado primero” (Weighted Shortest Job First, en inglés). Aunque WSJF es ampliamente utilizado en marcos como (link: https://scaledagile.com/ text: SAFe (Scaled Agile Framework)), fue popularizado por Donald Reinertsen en su libro (link: https://www.amazon.com/-/es/Principles-Product-Development-Flow-Generation/dp/1935401009/ref=sr_1_1?__mk_es_US=%C3%85M%C3%85%C5%BD%C3%95%C3%91&crid=3E042CQEK3E1M&dib=eyJ2IjoiMSJ9.q13iir53VvwNucBi1JIKpgA-PBXMglGvtroO321F8KAcKCYRwXg_9y1QR8zj9gUEUWSYuysIMteJeazccOpqPUpDvw9e_Cf7zw-HVpWm7TIRF2S5WLAdP02uhZXa9C4ZbMTO6wct_yUwRYrKr7X3D9-qtPuBgU8IlVsJAWrwLL4s9Mz0wHc8cah7gTsYHfoHnTvrdjnOsr01aiTiPhebACfNfJQ9R36LUtk5sa3gpcY.bEV3NWySRJgPfMwapzkT8qqgchkI3rSwa0gyZPbzwnU&dib_tag=se&keywords=The+principles+of+Product+Development+Flow&qid=1741144879&sprefix=the+principles+of+product+development+flow%2Caps%2C185&sr=8-1 text: “Los principios del Flujo de Desarrollo de Productos (The principles of Product Development Flow)). WSJF estima varios elementos, y se calcula resultando en un índice numérico (similar a las técnicas 2 y 3 anteriores), solo que considera más elementos, por lo que el resultado es una matriz un poco más compleja que las anteriores, pero también más completa. Considera para el cálculo de este índice de prioridad: • Valor de negocio • Criticidad en el Tiempo para entregarlo • Riesgo de no hacerlo u Oportunidad de hacerlo • Tamaño del trabajo Índice WSJF = ( Valor + Tiempo + Riesgo|Oportunidad ) / Tamaño del Trabajo. A un índice más alto, mayor la prioridad. Ejemplo: (image: ejemplo-wsjf.webp) # 5. Matriz de Lean Inception (image: matriz-lean-inception-paulo-caroli-product-discovery-priorizacion.webp) (link: https://caroli.org/es/lean-inception-5/ text: Lean Inception) es un taller colaborativo, creado por (link: https://www.linkedin.com/company/caroli-org-en-espanol/posts/?feedView=all text: Paulo Caroli), para alinear a un grupo de personas sobre una propuesta de solución a construir, finalizando con una secuencia de prioridades para un **Producto Mínimo Viable (MVP)**, y comprende una secuencia de actividades de varios días para promover la alineación, estrategia y el alcance del producto. A manera de contexto y cultura genera, Lean Inception toma sus bases en **Design Thinking** y en la filosofía **Lean**, principalmente en el enfoque de la reducción de desperdicios y en la definición de un Producto Mínimo Viable (MVP), lo cual es un aspecto fundamental de Lean Startup (si quieres profundizar un poco sobre **Lean Startup**, puedes leer un artículo que escribí sobre este tema (link: https://leonelzapien.com/blog/el-metodo-lean-startup-producto-minimo-viable-mvp text: aquí)). Esta tabla de priorización que comparto es solo una de las actividades realizadas durante un taller de Lean Inception, prioriza en base a Valor de negocio, esfuerzo y experiencia del usuario (User Experience o UX), los cuales se evalúan en una escala de 1 a 3 o bajo/medio/alto: (image: ejemplo-lean-inception.webp) Personalmente, me encanta lo poderosos y encantadores que resultan los talleres Lean Inception, siempre surgen conversaciones sumamente enriquecedoras. El cómo realizar este tipo de talleres los explica Paulo Caroli en su libro: (link: https://caroli.org/es/livro/lean-inception-creando-conversaciones-hacia-un-producto-exitoso/ text: Lean Inception: Creando conversaciones hacia un producto exitoso.) # 6. Modelo de Kano (image: modelo-de-kano-tecnica-priorizacion-product-management.webp) El modelo Kano para el desarrollo de productos y satisfacción del cliente, creado por el profesor Noriaki Kano, nos ayuda a comprender la satisfacción del cliente con las características del producto y depende del nivel de funcionalidad que proporciona. Ayuda a priorizar las características, atributos del producto o funcionalidades, con respecto a la satisfacción del cliente. Este modelo clasifica las características de un producto en: **• Factores atractivos o de entusiasmo: **Generalmente son atributos que no se esperan los clientes, por lo que cuando están presentes lo que se busca es crear una sorpresa de agrado en el consumidor. **• Factores lineales o normales: **Las características principales del producto, por las cuales el cliente elige una u otra marca. **• Factores imprescindibles, básicos o que “deben estar”: **Se da por sentado que están presentes, y si no lo están crean insatisfacción en el consumidor. Suelen ser las características básicas inherentes del producto y si están no me producen satisfacción (ya que damos por hecho que están incluidas), pero si no están, generan insatisfacción. **• Factores indiferentes: **Se refiere a los atributos que no son percibidos como ni buenos ni malos, se pueden eliminar (para reducir costos). **• Factores de rechazo: **Cuando están presentes el cliente los percibe como negativos, además del costo que implica implementarlos. # 7. Dinero de Monopoly (Comprar una funcionalidad o “Buy a Feature”) (image: monopoly-money-buy-a-feature-tecnica-priorizacion.webp) Para esta técnica se presentan las funcionalidades, características (también pueden ser las Historias de Usuario) que se tienen en consideración, y a los principales interesados o stakeholders se les proporciona dinero ficticio (o del famoso juego Monopoly), que representa el presupuesto total disponible. Enseguida, se le asigna un “precio” a cada funcionalidad o historia y una cantidad de dinero determinada a cada stakeholder para que, con este dinero, cada uno decida cuánto “invertir”. (image: buy-a-feature-monopoly-money-game-priorizacion.webp) Una clave de esta técnica es que un stakeholder no pueda comprar todas las funcionalidades (se debe determinar adecuadamente los precios y el presupuesto), con esto, las conversaciones y la priorización entran en juego basándose en el valor percibido y prioridad de cada funcionalidad (lo cual es muy similar a la realidad, con recursos finitos). Las funcionalidades o elementos que más dinero “hayan recaudado”, es decir, aquellas que compraron más stakeholders, son las más prioritarias. P.D. Acá en **México**, hace ya unas décadas, fueron muy famosos unos billetes ficticios de un personaje llamado (link: https://www.chocomilk.com/es-us/conoce-a-pancho-pantera/ text: “Pancho Pantera”) (personaje de la marca (link: https://www.chocomilk.com/es-us/ text: ChocoMilk)), y estos billetes se llamaban “Pancholares”. También se podrían utilizar los Pancholares en esta técnica de priorización, sería un estilo muy mexicano. (image: monopoly-dinero-pancholares-01-chocomilk-pancho-pantera-02.webp) # 8. Técnica de los 100 puntos (image: 100-puntos-tecnica-priorizacion-dean-leffingwell-02.webp) Esta técnica fue creada por (link: https://framework.scaledagile.com/about text: Dean Leffingwell) (el mismísimo creador de (link: https://scaledagile.com/ text: SAFe)) y Don Widrig, y la esencia es la misma que en la técnica anterior: Priorizar recursos finitos a funcionalidades o elementos en base a su valor percibido. Se otorgan al cliente un total de 100 puntos, y a cada funcionalidad, historia de usuario o elemento a priorizar se le asigna un costo en puntos. La idea es que cada stakeholder al tener una cantidad de puntos asignados proporcione una clara visualización de sus prioridades, y no solo seleccionar todas las características como importantes. Las funcionalidades o elementos que más puntos obtengan son las más prioritarias. # + Bonus: Método de Priorización Spice Girls Aclaro desde este momento que esta técnica “bonus” es una broma, se trata de una sátira muy creativa del equipo de (link: https://www.linkedin.com/in/thevisualagilecoach/ text: Olina Glindevi), de Estocolmo, cofundadora de (link: https://www.linkedin.com/company/the-visual-agile-coach/posts/?feedView=all text: The Visual Agile Coach), que dice lo siguiente: - ¡He tenido suficiente de luchas con modelos de priorización!, ahora simplemente uso el Método Spice Girls. - Oh, ¿Cuál es ese? - Solo les pregunto “So, tell me what you want, what you really really want” (aquella famosa canción de las Spice Girls: “Dime lo que quieres, lo que realmente realmente quieres”). (image: prioritization-spice-girls-tell-me-what-you-want-visual-agile-coach.webp) Imagen de Olina Glindevi, puedes ver el post original en LinkedIn (link: https://www.linkedin.com/feed/update/urn:li:activity:7161632788746649601/ text: aquí.) # Conclusiones Un punto importante que debes tener en cuenta que **hablamos de complejidad, así que no existe una fórmula mágica para priorizar**. Pero dos puntos súper relevantes que puedo compartirte y que son imprescindibles para que estas técnicas funcionen, son los siguientes: • Las matrices, escalas de estimación, índices numéricos y todo lo que se captura en un tablero físico o virtual, no son la respuesta, ya que a final de cuentas hablamos de estimaciones e hipótesis en un determinado sentido (por cierto, si te interesa profundizar sobre este tema de cómo formular **Hipótesis de Negocio**, puedes leer un artículo que escribí sobre este tema (link: https://leonelzapien.com/blog/innovacion-mvp-disenar-y-probar-hipotesis-de-negocio text: aquí)). Lo verdaderamente enriquecedor son las conversaciones que surgen. • Ya que lo enriquecedor son las conversaciones, como menciono en el punto anterior, es un requisito imprescindible (ahora sí que es un elemento “MUST”, si habláramos de la técnica MoSCoW), es que estos espacios donde se realiza la priorización sean **cocreados**, que todas las voces sean escuchadas y haya la diversidad mínima necesaria, es decir, que haya personas de todas las áreas involucradas (especialistas tanto de negocio como del área técnica). • Finalmente, no nos olvidemos de la importancia de adoptar un enfoque experimental:** Inspeccionar y Adaptar **continuamente, obtener retroalimentación lo más pronto (y rápido) posible. ## ¿Conocías estas técnicas de priorización?, ¿Cuáles vas a comenzar a probar con tus equipos?

7 de marzo de 2025

MVP, Product Management, Innovación

Innovación & MVP - Diseñar y probar hipótesis de negocio

“No cometas el error de ejecutar ideas de negocio sin evidencia: Prueba tus ideas, sin importar qué tan bien luzcan en teoría” – David J. Bland & Alex Osterwalder. # Hipótesis de negocio ¿Tienes una idea de un nuevo producto o servicio?, ¿Una nueva funcionalidad que piensan agregar para tu usuario o cliente?, para pasar de una idea de negocio a un elemento validado, se debe de probar de manera rápida y lo más barato posible (en el artículo pasado hablamos sobre el **Producto Mínimo Viable o MVP**, Minimum Viable Product en inglés, puedes leer el artículo completo (link: https://leonelzapien.com/blog/el-metodo-lean-startup-producto-minimo-viable-mvp text: aquí)). Pues bien, está chévere esta idea de que un MVP nos invita a validar ideas de negocio con experimentos antes de ir a mayor escala. Pero ¿Por dónde empezar si quiero hacer un experimento para probar una idea?, ¿Por dónde inicio? Lo primero que necesitamos asentar es que una **idea de negocio** es en realidad una **hipótesis** (ya sé que esto suena muy del ámbito científico, pero en realidad así es). Hasta que se valide obteniendo un resultado (se cumple y por lo tanto es correcta, o no se cumple), solo entonces dejará de ser una hipótesis. “El objetivo de un MVP es probar las hipótesis fundamentales del negocio, es sólo un primer paso en un proceso de aprendizaje.” – Eric Ries (The Lean Startup) # Probar ideas de negocio: Un proceso iterativo El ciclo Diseño-Prueba es un proceso iterativo, creado por David Bland & Alex Osterwalder, tiene dos grandes áreas: Diseño & Prueba, veamos cada una a detalle: (image: design-test-innovacion-strategyzer-leonel-zapien-lopez-ideas-agilidad-guadalajara-mexico.webp) **Diseño:** Es la actividad de llevar ideas vagas o dispersas, a proposiciones de valor, que después puedan concretarse como modelos de negocio. **Prueba:** Necesitamos descomponer una idea de negocio en hipótesis pequeñas y fáciles de validar mediante experimentos que proporcionen evidencia que ayuden a decidir los siguientes pasos. # Diseño En este primer paso el objetivo es generar la mayor cantidad de opciones como sea posible (debemos evitar enamorarnos de nuestra primera idea, no es personal, solo son negocios), basándose en la intuición, observación o en lo que se conozca sobre los clientes. (image: design-test-innovacion-strategyzer-01-leonel-zapien-lopez-ideas-agilidad-guadalajara-mexico.webp) Las ideas locas, irreverentes, aquellas que retan el Status Quo, son más que bienvenidas (de hecho, eso es lo que buscamos). En este punto, no es el momento de empezar a desmenuzar el modelo de negocio y cuestionar la validez o potencial éxito en el mercado de una idea. No aún. **Queremos que el equipo diseñe como si tuviera razón**, ¿Tenemos sobre la mesa alguna idea de negocio innovadora? **Pregunta para llevar: ** ¿El equipo está “empujando” los límites?, o ¿Están jugando a lo seguro y manteniéndose cerca de lo que la empresa hace actualmente? # Prueba Una vez estemos satisfechos con lo realizado en la etapa de diseño, es hora de pasar a las pruebas. (image: design-test-innovacion-strategyzer-02-leonel-zapien-lopez-ideas-agilidad-guadalajara-mexico.webp) El primer paso en el ciclo de prueba es definir y priorizar las hipótesis de negocio. Si la hipótesis es muy grande, la dividimos pequeñas partes comprobables. Aquí lo esencial es la palabra “comprobable”, para esto debemos cocrear (de verdad, es increíble el poder de la crear de manera colaborativa), seleccionar y ejecutar experimentos adecuados que nos proporcionen información que respalde y nos ayuden a validar (o desechar) nuestras hipótesis. En pocas palabras, necesitamos **evidencia**. # Tarjeta de Prueba o Test Card Aquí te comparto una herramienta muy útil, desarrollada por Strategyzer, que nos ayuda a definir un experimento para probar una idea: (link: https://www.strategyzer.com/library/validate-your-ideas-with-the-test-card text: La Tarjeta de Prueba (Test Card)). Aquí veremos brevemente cómo llenar esta tarjeta: (image: test-card-strategyzer-leonel-zapien-lopez-ideas-agilidad-business-hypholesis-s.webp) 1. **Hipótesis:** Define la idea de negocio que se cree que es verdadera. **Ejemplo: **“Creemos que las personas están interesadas en un curso en línea sobre bordar manteles navideños con punto de cruz.” 2. **Prueba:** ¿Qué experimento (o experimentos) ejecutarás para determinar obtener información que permita validar si hipótesis es verdadera o falsa? **Ejemplo: **“Para verificar esto, nosotros agregaremos un breve video sobre el curso y un botón de en nuestro sitio web.” 3. **Métrica:** ¿Qué vamos a medir para validar la hipótesis?, la idea es que sea una medida específica, objetiva, no ambigua, binaria (cumple o no cumple) y reproducible. **Ejemplo:** “Y lo mediremos por el número de personas que ingresan a nuestro sitio web y hacen clic en el botón de .” 4. **Criterio: **Definir el resultado esperado respondiendo a la pregunta ¿Cómo es el escenario ideal que en nuestro contexto nos dice que la hipótesis ha sido exitosa? **Ejemplo: **“Y sabremos que tenemos éxito si se registran al menos 1,000 ‘compradores de pre-venta’ en la primera semana.” Este último punto es crítico ya que ayuda a responder la pregunta: ¿Qué necesita ser cierto para que esta idea de trabajo funcione? En este ejemplo, la definición de éxito que esta empresa de cursos en línea espera (de acuerdo con su contexto especifico, como costos fijos, retorno de inversión esperado, cobertura de mercado actual, etcétera), son 1,000 “compradores” registrados, pero ¿En cuánto tiempo?, para ellos ese bloque de tiempo es en la primera semana de correr el experimento. ¿Lo más importante?, el producto en este ejemplo, el curso en línea no ha sido creado aún, por lo que probar esta hipótesis es relativamente muy barato (y rápido). # Aprender El último paso es aprender de los experimentos que realizamos. ¿La evidencia recabada apoya o refuta nuestras suposiciones?, Eso que acabamos de obtener es aprendizaje, de hecho, es lo que Eric Ries (el creador del **Método Lean Startup**, puedes leer el artículo que hice sobre este tema (link: https://leonelzapien.com/blog/el-metodo-lean-startup-producto-minimo-viable-mvp text: aquí)) llamó **Aprendizaje Validado**, pues se basa en evidencia. ¿Este aprendizaje validado nos indica que debemos de continuar por este mismo rumbo, o pivotar y explorar un nuevo camino? Para validar el aprendizaje, aquí comparto, al igual que en el punto anterior, una herramienta propuesta por Strategyzer: (link: https://www.strategyzer.com/library/capture-customer-insights-and-actions-with-the-learning-card text: La tarjeta de Aprendizaje o Learning Card). Hemos realizado un experimento para tratar de validar una hipótesis de negocio, debemos de rescatar e identificar el aprendizaje obtenido y aplicarlo lo más pronto posible, pues el aprendizaje tiene una “fecha de caducidad”. ¿A qué nos referimos con aplicar el aprendizaje obtenido?, a aplicarlo en la toma de decisiones informada, identificar los siguientes pasos: ¿La hipótesis de negocio era correcta, y debemos continuar por este camino?, o ¿Debemos de cambiar el rumbo, partiendo de una nueva hipótesis? (esto último, se conoce como hacer un “**pivote**”). Retomando el ejemplo que revisamos en la Tarjeta de Prueba (Test Card), continuamos con el ejemplo para llenar ahora la Tarjeta de Aprendizaje: (image: learning-card-leonel-zapien-lopez-ideas-agilidad-business-hypholesis-s.webp) 1. **Hipótesis: **Define la idea de negocio que se creía verdadera. **Ejemplo: **“Creíamos que las personas están interesadas en un curso en línea sobre bordar manteles navideños con punto de cruz.” 2. **Observación: **¿Qué pudimos observar después de realizar el experimento? **Ejemplo: **“Observamos que solo un 1.2% de los clientes potenciales esperados hicieron clic en nuestro botón de en nuestro sitio web.” 3. **Aprendizajes e ideas clave:** El aprendizaje validado que se ha obtenido de la observación. **Ejemplo:** “Dado que esperábamos 1,000 clics de compra en pre-venta durante la 1ra semana y solo obtuvimos 12 clics (1.2%), este curso en línea no genera el interés esperado.” 4. **Decisiones y acciones:** Ahora que se ha visto si la hipótesis de negocio era válida o no, determinar los siguientes pasos que se realizarán a partir de este punto. **Ejemplo:** “No dedicaremos más recursos a esta hipótesis. Replantearemos nuestra idea de negocio y haremos un pivote a una nueva hipótesis que está por definirse.” En este caso de ejemplo, la hipótesis de negocio no era válida, ¿Lo más importante?, el producto en este ejemplo, el curso en línea sobre bordar manteles navideños con punto de cruz, nunca fue creado: No se dedicaron semanas o meses de trabajo a un producto que se creía que se vendería como pan caliente, pero que el experimento demostró que no había interés. Probar esta hipótesis fue relativamente muy barato y rápido. ¿Y cómo procedemos una vez se confirma el resultado de una hipótesis?, se pueden hacer varias 3 cosas: 1.** Perseverar: **Quiere decir que vamos por buen camino, y debemos de continuar por este rumbo. No es el caso en este supuesto, solo sucedería si la hipótesis resultara válida. 2. **Pivotar: **Hacer un cambio de rumbo, lo que Eric Ries en su libro “The Lean Startup” llama un “Pivote”, comenzar a explorar otros caminos y formular nuevas hipótesis. 3. **Descartar: **Tal vez, después de explorar varias hipótesis, negocio decide no continuar explorando este camino (y probablemente ningún otro similar o alineado con este camino). Continuando con este ejemplo, ¿Qué tal si a la gente no le interesa aprender a bordar manteles navideños, pero se acerca el Día de Star Wars, y bordar manteles temáticos de Star Wars es algo que las personas están buscando con singular alegría?, uno nunca sabe. ¿Cómo lo sabremos?, formulando una nueva hipótesis. (image: hipotesis-de-negocio-star-wars-copy.webp) # ¿Qué sigue después? En el centro del ciclo Diseño-Prueba se encuentra “Decidir”, se debe de decidir sobre este modelo de negocio que el equipo está probando. El objetivo final es comprobar **si el modelo de negocio es viable**, los equipos de innovación deben evaluar en este punto y reflexionar sobre su progreso hacia la búsqueda de un modelo de negocio rentable que funcione. Al evaluar la solidez de la evidencia que respalda cada componente básico del modelo de negocio, los equipos pueden identificar si aún hay incertidumbre y existen componentes que aún deben probarse, ¿Deben realizarse nuevos experimentos? Cuando se aprenden nuevas lecciones, se puede actualizar el modelo de negocio, identificar nuevas hipótesis y ejecutar el siguiente conjunto de experimentos. Esta es la razón por la que los equipos que pueden recorrer rápidamente el ciclo descubren más rápido si su idea de negocio es viable. Hasta aquí, ya tenemos información de la hipótesis de negocio mediante los experimentos realizados, ahora, muy recientemente en este último par de párrafos hemos comenzado a hablar de un “Modelo de negocio”. Para esto, el equipo de Strategyzer han creado también el (link: https://www.strategyzer.com/library/the-business-model-canvas text: Business Model Canvas, o Lienzo de Modelo de negocio), el cuál es el siguiente paso para ayudar al equipo de innovación a determinar la validez de su modelo. Aquí te presento el Lienzo de Modelo de Negocio, pero creo que este artículo ya es algo extenso, así que en un próximo artículo conversaremos específicamente sobre este Canvas. Por lo pronto, hemos visto cómo probar y validar ideas de negocio. (image: business-model-canvas-modelo-de-negocio-leonel-zapien-lopez-ideas-agilidad-guadalajara-mexico.webp) # Conclusiones La **apertura para experimentar** es esencial para desarrollar una **cultura de innovación** en cualquier organización. Las herramientas que hemos visto el día de hoy no son solo un par de tarjetas para prueba y aprendizaje, o un canvas con un modelo de negocio, son en realidad recordatorios de conversaciones enriquecedoras y poderosas que deben de suceder. Una tarjeta o un canvas como tal no resolverán ningún problema ni nos llevará al valle dorado de la innovación. Debemos fomentar los espacios para los individuos y sus interacciones, como dice el **Manifiesto Ágil** (puedes leer el artículo que escribí sobre el Manifiesto Ágil (link: https://leonelzapien.com/blog/23-aniversario-n-manifiesto-agil text: aquí)). Así mismo, la experimentación y la innovación son unos músculos que deben de ejercitarse, es posible que a tu equipo le tome algunos ciclos el comenzar a entrar en calor, a agarrar ritmo, y a perder el miedo a experimentar (y para esto último se requiere un adecuado **liderazgo** y sólidos cimientos de **Seguridad Psicológica** en tu organización y equipo). Lo importante de la experimentación es obtener aprendizaje validado, con esto, el ciclo Diseño-Prueba se ha completado, de manera rápida y lo más barata posible. En este ejemplo, no fue viable continuar con el producto, así que el ciclo vuelve a iniciar, esta vez, con una nueva hipótesis de negocio. ¡Nunca dejemos de experimentar y aprender! **¿Cómo validas tus ideas de negocio?** ## Nota final #01 Las herramientas sobre las cuales hemos conversado hoy, Tarjeta de Prueba, Tarjeta de Aprendizaje y el Canvas de Modelo de Negocio, los puedes descargar en su versión original del sitio de (link: https://www.strategyzer.com/ text: Strategyzer), o en su defecto, los puedes descargar en una versión traducida a español, aquí en mi sitio web en la sección de (link: https://leonelzapien.com/recursos text: Recursos para descargar). ## Nota final #02 Existen varios canvas o lienzos que apoyan para crear modelos de negocio, hace unos meses hablé sobre el **Tablero de la Visión del Producto o Product Vision Board,** creado por Roman Pichler, escritor y todo un master Jedi en Agile & Product Management. Este canvas es muy útil para cocrear una visión compartida del producto (lo que se conoce como “envisioning”), y puede de igual manera apoyar como siguiente paso, ya que es similar al Business Canvas Model en algunos aspectos. Si quieres leer sobre el Tablero de la Visión del Producto, puedes leer el artículo que escribí sobre el tema (link: https://leonelzapien.com/blog/como-iniciamos-el-tablero-de-vision-del-producto text: aquí). ## Nota final #03 De verdad que existe el “**Día de Star Wars**”, millones de fans a lo largo y ancho de toda la galaxia lo celebramos el día 4 de mayo. ¿Por qué el 4 de mayo?, por el juego de palabras de la frase: “Que La Fuerza te acompañe”. En inglés se dice “May the Force be with you”, lo cual es un juego de palabas y cuando se dice en voz alta casi-casi como “May the Fourth be with you”… o sea “Que el 4 de mayo te acompañe”, y de ahí derivó que cada 4 de mayo se celebre el Día de Star Wars (Sí, debo de reconocer que nos buscamos cualquier pretexto para ese tener un día para usar sables láser y ponernos el casco de Darth Vader). **Referencias:** • Testing Business Ideas. David J. Bland & Alex Osterwalder. • Business Model Generation. Alex Osterwalder & Yves Pigneur. • El método Lean Startup: Cómo crear empresas de éxito utilizando la innovación continua. Eric Ries.

2 de junio de 2024

Product Management, MVP, Innovación, Lean

El Método Lean Startup & Producto Mínimo Viable (MVP)

“Si estamos creando algo que nadie quiere, no importa si lo hacemos en tiempo y dentro del presupuesto” – Eric Ries El creador del método Lean Startup, Eric Ries, menciona que “demasiados planes de negocio parecen diseñados para planificar cómo lanzar un cohete: Prescriben los pasos que hay que dar y los resultados esperables con un gran nivel de detalle en cada paso, lo establecen todo como si cada minúsculo error en las asunciones o suposiciones pudiera llevar a un resultado catastrófico.” Eric Ries lo deja muy en claro: No podemos prever todos los posibles pasos (por más análisis de Fortalezas y Debilidades, de riesgos, estimaciones, simulaciones, y una larga lista de etcéteras), no podemos preparar cada detalle, nunca podremos concebir todos los posibles escenarios. Es por esto que Eric Ries, propone: **El Método Lean Startup**, que se basa en una premisa simple pero fundamental: En lugar de hacer planes complejos basados en muchas suposiciones, se pueden hacer ajustes constantes mediante un ciclo de retroalimentación llamado **Crear-Medir-Aprender**. (image: leonel-zapien-lopez-ideas-agilidad-eric-ries-metodo-lean-startup-mvp-producto-minimo-viable-guadalajara-mexico-01.webp) En el artículo de hoy, hablaremos sobre Lean Startup, el ciclo Crear-Medir-Aprender, y sobre el poderoso enfoque del **Producto Mínimo Viable** (**MVP**, por sus siglas en inglés, Minimum Viable Product). # El caso de IMVU: Un error garrafal que llevó a la gran epifanía de Eric Ries IMVU, una gran empresa dedicada al desarrollo de software, decidió entrar en el mercado de mensajería instantánea. Era el año 2004, y este mercado en aquel tiempo tenía centenares de millones de usuarios a nivel mundial. Empresas como AOL (America On Line), Microsoft y Yahoo! dominaban el mercado. (image: leonel-zapien-lopez-ideas-agilidad-eric-ries-metodo-lean-startup-mvp-producto-minimo-viable-guadalajara-mexico-02.webp) IMVU llega con una nueva idea: Mundos y juegos virtuales a través de avatares 3D personalizables, que pueden agregarse a las aplicaciones de mensajería instantánea ya existentes. Si el mercado de mensajería instantánea tenía cientos de millones de usuarios, entrar con esta propuesta que complementaba a las aplicaciones de mensajería, sonaba como un gran éxito. El equipo de IMVU, liderados en aquel tiempo por Eric Ries, estuvo más de 6 meses trabajando intensamente para desarrollar este producto, haciendo pruebas, discutiendo qué elementos o funcionalidades agregar y cuáles remover, poniendo muchísimo esfuerzo en la calidad, trabajando durante meses, jornadas hasta altas horas de la noche y fines de semana. Finalmente llegó el gran día del lanzamiento. Eric Ries menciona al respecto lo siguiente: **“Y entonces, ¡no pasó nada! Resultó que nadie probó nuestro producto”** **“Nuestra propuesta de valor estaba tan desencaminada de lo que los clientes querían, que ni siquiera lo probaban**, y, por lo tanto, no llegaban a descubrir lo malas que habían sido nuestras elecciones sobre el diseño. Los consumidores no descargaban nuestro producto.” El equipo de IMVU optó por hacer mejoras al producto, introducir nuevos cambios, uno que otro cliente llegaba a descargar su producto (Eric Ries reconoce que al inicio eran principalmente amigos y familiares de ellos mismos), y a pesar de tantas mejoras y retrabajo, pronto se quedaron sin amigos que quisieran probar su producto, y con unos ingresos mensuales de poco más de $300 dólares al mes. **“Estábamos mejorando el producto día a día, pero el comportamiento de los consumidores no cambiaba: todavía no querían probarlo.”** # Momento de hacer las cosas de manera diferente Para que el equipo de IMVU intentara hacer las cosas de manera distinta a partir de este punto, influyeron fuertemente dos factores: Un poco tuvo que ver la frustración de estar trabajando en un producto que nadie compraba, y un poco más tuvo que ver que se estuvieran quedando sin dinero para continuar operaciones. Hay un dicho: “La desesperación es la madre de la inventiva”, así que en este punto Eric Ries y todos en IMVU estaba bastante desesperados. ¿Qué hicieron ahora? **Comenzaron a hablar con los clientes** (verdaderas conversaciones, de esas que son cara a cara). Llevaban a clientes a sus oficinas, los entrevistaban, les mostraban pruebas de su producto, hacían ajustes en base a sus comentarios, y después volvían a mostrarles más pruebas. El equipo de IMVU tenía una idea en mente de su producto: Un avatar 3D que se puede personalizar, que se agrega como complemento a la aplicación de mensajería instantánea de preferencia del usuario, se enamora del producto, después invita a todos sus amigos a usarlo, y se vuelve viral. No suena nada mal. La cuestión es que después de docenas de entrevistas y pruebas con clientes reales, directo en sus oficinas, se dieron cuenta que su concepto de “mensajería instantánea complementaria” estaba destinado al fracaso desde un inicio, a nadie le interesaba eso. # Ok, y entonces ¿ahora qué? Era momento de reconocer que el trabajo de más de 8 meses no le interesaba a nadie. Trabajo tirado a la basura. ¿Cuál fue la razón de que el equipo de IMVU durara tanto para construir su producto?, habían estado trabajando en hacer un producto de alta calidad, que fuera compatible para todas las redes sociales o aplicaciones de mensajería de aquella época… y cuando hicieron todo esto, se dieron cuenta que a nadie le interesaba. # Es hora de hacer redirigir el rumbo: Pivotar (image: leonel-zapien-lopez-ideas-agilidad-eric-ries-metodo-lean-startup-mvp-producto-minimo-viable-guadalajara-mexico-03.webp) Eric Ries menciona que Pivotar es detenerse, hacer una pausa y evaluar si merece la pena seguir por este camino. En este caso de IMVU, al reconocer finalmente que la respuesta de los clientes no era positiva, la decisión fue abandonar la estrategia inicial, **tomar un nuevo camino** lanzando un nuevo producto (hacer un pivote), y validar lo más pronto posible su nueva propuesta, directamente con los clientes. El objetivo de estas conversaciones directas y (ahora más frecuentes) que querían tener con los clientes era ayudarles a **identificar conforme iban construyendo su producto**, qué funcionalidades les gustaban a los clientes (aportan valor), y cuáles no (lo cual se considera como un desperdicio o despilfarro). La idea es obtener esta retroalimentación lo más pronto posible y no ya que el producto está totalmente terminado, 8 meses después, y descubrir que fueron 8 meses de trabajo tirado a la basura. No se trataba de adivinar lo que los clientes querían, ni de decirles lo que deberían de querer, sino de entenderlos, ver cómo utilizaban la propuesta de producto, y en base a la retroalimentación obtenida directamente de su experiencia con el producto, lo que Eric Ries llamó **Aprendizaje Validado**, ahora sí, mejorar el producto. “Cuando pivotamos a partir de la estrategia inicial (después de escuchar a los clientes), todo empezó a cambiar […] no porque estuviéramos trabajando más duro, sino porque lo hacíamos de una forma más inteligente, **a partir de escuchar las necesidades reales de nuestros clientes.**” # Ciclo Crear-Medir-Aprender Lo que el equipo de IMVU comenzó a hacer a partir de su experiencia anterior, fue plantearse una **hipótesis de negocio:** (sí, ya sé que esto de "hipótesis" suena muy del ámbito científico, pero en realidad así es, ya que es algo que creemos pero hasta que no lo validemos, no sabremos si es cierto o no). La hipótesis en este ejemplo era: Creemos que los jóvenes están interesados en un avatar 3D para sus aplicaciones de mensajería instantánea. Basados en esta hipótesis, en vez de construir durante 8 meses un producto que fuera compatible para todas las aplicaciones de mensajería, y que tuviera todas las funcionalidades, determinaron **construir un experimento que les permitiera validar su hipótesis lo más pronto posible.** (image: leonel-zapien-lopez-ideas-agilidad-eric-ries-metodo-lean-startup-mvp-producto-minimo-viable-guadalajara-mexico-04.webp) **Crear **un producto que no fuera malo en cuestiones de calidad, pero no algo muy robusto ni sofisticado, solo las funcionalidades básicas y que pudiera utilizarse, por ejemplo, en vez de que fuera compatible con todas las aplicaciones de mensajería, elegir una sola, la de mayor uso (de esta manera, se requeriría relativamente muy poco tiempo en construirlo). Esta primera versión del producto es lo que se conoce como **Producto Mínimo Viable** (**MVP** por sus siglas en inglés, Minimum Viable Product), un producto con las mínimas funcionalidades que requerimos, solo las necesarias para probar si a la gente le aporta valor o no. Obtener información es el siguiente paso, a fin de poder **medir**… ¿Cómo medimos?, cara a cara con el cliente: Observándolo con nuestro producto o servicio, ¿Qué funcionalidades o características utiliza y cuáles no?, ¿Es fácil e intuitivo que lo utilice o tenemos que explicarle cómo hacerlo?, ¿Cuáles son sus comentarios después de utilizar nuestro producto?, ¿Le gusta?, ¿Realmente resuelve su necesidad o le hace la vida más fácil?, ¿Descargan nuestra versión del producto?, ¿La recomiendan? La idea es obtener información relevante, **métricas accionables** que nos ayuden a determinar cómo vamos. **Aprender **es el último paso de este ciclo. En base a la información recabada, ¿Cómo vamos?, ¿Cuál es el aprendizaje validado después de correr este pequeño experimento?, aquí la cuestión fundamental es: La hipótesis de negocio que habíamos considerado de manera inicial, ¿se cumple?, si la respuesta es positiva, podemos continuar por este rumbo con un producto o servicio que sabemos que tiene aceptación de parte de los clientes, tal vez agregando o removiendo algunas funcionalidades o características, haciendo algunos ajustes. Por otro lado, tal vez la respuesta es negativa y a nadie le interesa este producto o servicio, si es el caso, se debe de evaluar si es necesario hacer un **pivote** y ajustar el rumbo: **Plantear una nueva hipótesis de negocio y volver a correr el ciclo Crear-Medir-Aprender.** # El Método Lean Startup Así nace el método Lean Startup, creado por Eric Ries. Pero a todo esto, **¿Qué es el Método Lean Startup? La aplicación del pensamiento Lean (reducir el desperdicio o despilfarro) al proceso de Innovación.** (image: leonel-zapien-lopez-ideas-agilidad-eric-ries-metodo-lean-startup-mvp-producto-minimo-viable-guadalajara-mexico-05.webp) En el método Lean Startup, un experimento es más que una simple investigación teórica; también es un primer producto. Un **Producto Mínimo Viable o MVP**, que ayude a empezar con el proceso de aprendizaje lo más pronto posible. El MVP no es necesariamente el producto más pequeño que se pueda imaginar; es la forma más rápida de entrar en el ciclo de retroalimentación **Crear-Medir-Aprender** con el mínimo esfuerzo (y lo más barato posible). El objetivo de un MVP es probar las hipótesis fundamentales del negocio, es sólo un primer paso en un proceso de aprendizaje. A lo largo de este proceso, tras muchas iteraciones, se puede descubrir que algún elemento del producto o estrategia es erróneo y decidir que ha llegado el momento de cambiar, un pivote, a un método diferente para alcanzar la visión. # ¿Y es factible construir ese MVP? Ok, esa idea de MVP suena bien... pero ¿Ya existe la tecnología de Star Trek para teletransportar a una persona, o hacer maleable el adamantium?, aquí la palabra clave es si este MVP es **factible **de construirse. De acuerdo con **Paulo Caroli**, famoso escritor y desarrollador de **Lean Inception **(sí, lo sé. Parece que todos se han puesto de acuerdo para agregar la palabra “Lean” como prefijo a todo lo nuevo), el error más común en la creación de un MVP es el pensamiento unilateral: Pensar solo en el desafío tecnológico, o solo en lo que le encantaría al usuario, o simplemente en lo que valida el negocio. (image: leonel-zapien-lopez-ideas-agilidad-paulo-caroli-lean-inception-mvp-producto-minimo-viable-guadalajara-mexico-06.webp) Un MVP adecuado, de acuerdo con Paulo Caroli, se encuentra justo en la intersección de: 1. Lo que es valioso para el usuario. 2. Es utilizable. 3. Es técnica y económicamente factible construirlo. (image: leonel-zapien-lopez-ideas-agilidad-paulo-caroli-lean-inception-mvp-producto-minimo-viable-guadalajara-mexico-05.webp) # Conclusiones Es imposible predecir cómo responderá un cliente a un producto o servicio que se lance al mercado. La mejor manera de entonces de actuar es escucharlo directamente, cómo responde y cuáles son sus necesidades reales. Para esto, la mejor aproximación es partir de experimentos, un producto mínimamente viable que nos ayude a validar una hipótesis de negocio de manera rápida y barata, antes de proceder a construir un producto o servicio a mayor escala y detalle. Para esto nos podemos apoyar en el ciclo Crear-Medir-Aprender, y cada vez que completemos una vuelta a este ciclo, determinar la forma en que habremos de actuar en base al **aprendizaje validado** que hemos obtenido. Eric Ries menciona que “la cantidad de tiempo que una empresa puede mantenerse como líder del mercado para explotar sus primeras innovaciones se está reduciendo y esto crea un imperativo. Incluso para las empresas más afianzadas: invertir en innovación”, y ¿Cómo podemos hacer esto?, creando algo “barato”, midiendo con los clientes o usuarios finales, aprendiendo, determinar si es necesario ajustar, y volver a iniciar. Añadiría un elemento más a lo anterior: Aprender divirtiéndonos durante el proceso, disfrutar el viaje por el ciclo Crear-Medir-Aprender, si hacemos lo que hacemos con pasión, la experiencia (además de enriquecedora), será totalmente memorable. **¿Habías escuchado hablar antes del Método Lean Startup?, ¿Cómo te ha ido experimentando con MVPs y obteniendo aprendizaje validado de tus productos o servicios?** ## Referencia: • El método Lean Startup: Cómo crear empresas de éxito utilizando la innovación continua. Eric Ries. • Lean inception: Creando conversaciones hacia un producto exitoso. Paulo Caroli.

6 de mayo de 2024

Product Management

¿Cómo iniciamos? El Tablero de Visión del Producto

. La visión del producto es un sólido cimiento para la toma de decisiones relacionadas con el producto, para buscar maximizar el valor entregado a clientes y usuarios, así como a la organización. **Roman Pichler**, escritor y todo un master Jedi en Agile & Product Management, es el creador del **Tablero de la Visión del Producto**, un canvas muy útil para ayudar a cocrear una visión compartida del producto (lo que se conoce como “envisioning”). . # Las 6 cualidades de una Visión de Producto Roman Pichler, en su libro **Agile Product Management with Scrum** (Gestión de Productos Ágil con Scrum), menciona que una visión de producto efectiva contiene 6 cualidades: 1. Inspiracional 2. Es compartida 3. Ética y ofrece un producto que realmente proporciona un beneficio 4. Concisa y memorable 5. Grande y ambiciosa 6. No está amarrada a una solución específica . # El Tablero de la Visión de Producto (Product Vision Board) El Tablero de Visión de Producto de Pichler es muy poderoso, pero no es la única herramienta, es solo una de las tantas que existen para el proceso de crear una visión compartida o “envisioning”. Algo que es súper relevante mencionar, es que su fuerza no radica en el propio tablero, sino en las conversaciones que genera (como con cualquier canvas o radiador de información), por lo cual, es necesario que todas las personas relevantes para el producto formen parte de este envisioning: **Debe de ser un proceso colaborativo**. Hay un punto clave que menciona Roman Pichler y que siempre me ha parecido relevante: Evitar tratar de crear un producto que guste a todo-el-mundo o que satisfaga todas las necesidades. Hay una cita de **Steven Blank** a este respecto que dice: **“Crea un producto para unos pocos”**, es decir, enfocado a un nicho, a un cliente objetivo. La visión del producto es el punto de partida, guía a la organización, a los equipos y a las personas hacia donde se quiere ir. Sin embargo, es crítico no confundir esta visión con un plan para seguir ciegamente un camino predefinido. Gran cantidad empresas caen en la trampa de construir hacia una visión como “acto de fe” en lugar de adaptar en caso de ser necesario. ¿Es que entonces, la visión de un producto puede cambiar? Claro, pero en lo personal me gusta más el sentido de la palabra “evolucionar” que solo “cambiar”, porque evolución implica que hay aprendizaje y adaptación conforme a diversas variables del entorno. **La visión de un producto puede (y en muchos casos debe) evolucionar. ** Ahora bien, como herramienta para crear esta visión, Roman Pichler propone dos versiones de su tablero de Visión de Producto, una estándar y una extendida, que son en realidad el mismo tablero solo que el extendido incluye más elementos a considerar. En su sitio web puedes descargar ambas versiones en formato PDF ((link: https://www.romanpichler.com/tools/product-vision-board/ text: te comparto el link aquí)). Esta es mi versión del tablero de Roman Pichler. Platiquemos uno a uno los elementos que lo conforman y las preguntas a las que debe de responder: (image: product-vision-board-web-version-para-el-blog-02.webp) (Los primero 5 elementos son la versión estándar del tablero, los elementos 6 al 9 forman parte de la versión extendida). **1. Visión**: ¿Qué cambio positivo debería proporcionar? ¿Cuál es el propósito de crear el producto? Personalmente, me parece súper poderoso comenzar respondiendo esta pregunta, se alinea totalmente a lo que menciona Simon Sinek en su libro: “**Empieza con el porqué* (Start with Why)*”, que no indica que debemos de comenzar con el propósito o el fin en la mente. **2. Grupo Objetivo:** ¿A qué mercado o segmento de mercado está dirigido el producto? ¿Quiénes son los clientes y usuarios objetivo? **3. Necesidades:** ¿Qué problemas resuelve el producto? ¿Qué beneficio proporciona? **4. Producto:** ¿Qué producto es este? ¿Qué lo hace destacar? ¿Es factible desarrollar el producto? **5. Objetivos de negocio:** ¿Cómo va a beneficiar el producto a la organización? ¿Cuáles son los objetivos de negocio a los que aporta este producto? (Versión extendida) **6. Competidores:** ¿Quiénes son los competidores principales? ¿Cuáles son las fuerzas y debilidades? **7. Flujo de ingresos:** ¿Cómo se puede monetizar el producto y generar ingresos? **8. Factores de costo:** ¿Cuáles son los principales costos de desarrollar, llevar al mercado, vender y proporcionar servicio de este producto? **9. Canales:** ¿Cómo se llevará al mercado y venderá el producto? ¿Los canales existen actualmente? ¿Cómo llenar este tablero? Cuando he colaborado con equipos donde ha sido necesario crear esa visión, en los casos que hemos utilizado este tablero, reconozco que ha habido ocasiones en que al inicio es fácil identificar ese escepticismo y cierta renuencia a colaborar, es hasta cierto grado normal. Pero después de ir recorriendo el tablero, de ir avanzando a través de dinámicas, las personas terminan enganchándose y se detona un proceso creativo y colaborativo muy poderoso. . # Algunos tips poderosos para facilitar la cocreación de una visión Aquí te comparto unos tips que me han funcionado: **1. **Es necesario invitar a los interesados relevantes o stakeholders clave. **2. **Que los asistentes sea un grupo que incluya personal de todas las áreas implicadas y, de diversos niveles jerárquicos (ventas, marketing, desarrollo, etcétera). Es supremamente relevante escuchar los diversos puntos de vista, y por lo general siempre surgen ideas que a nadie se le habían ocurrido inicialmente. **3. **Si es una **facilitación en un espacio físico**, promueve que se sienten revueltos entre áreas o departamentos (no todos los de sistemas juntos, y los de ventas al otro lado de la sala de juntas), busca **fomentar conversaciones más diversas**. **4. **Si es una **facilitación remota**, puedes apoyarte de grupos pequeños en algunos momentos, combinando a personas de distintas áreas (la idea es la misma que el punto anterior: No envíes a un grupo pequeño a todos los de sistemas y a otro grupo pequeño solo a los de ventas).** Buscamos la diversidad**. **5.** Todas las ideas son bienvenidas, todas las ideas se escriben y son consideradas de manera inicial. Después habrá que conducir las conversaciones necesarias para converger, para reducir de manera natural las opciones (eso viene después), pero de entrada: **Todas las ideas son bienvenidas!** **6. **Si no se tiene una respuesta, pueden crearse** hipótesis** que necesiten ser validadas mediante **experimentos**. Súper interesante! ¿Quién se sumará a estos experimentos? Busca a esos innovadores y/o adaptadores tempranos que de manera natural les interese experimentar en esta etapa, así la resistencia al cambio será un factor mínimo de impacto negativo. **7. **Facilita las dinámicas necesarias para cada situación que pueda surgir: para ayudar al grupo a divergir, priorizar, descartar, converger, concluir, identificar accionables, cocrear, y etcétera y etcétera… pero, antes que directores o gerentes o desarrolladores, recuerda que estás tratando primeramente con personas, por lo tanto, facilita dinámicas para **que el grupo se divierta durante el proceso** (no por ser algo importante debe de ser algo serio y aburrido, mientras más memorable, mejor). . # Conclusiones Termino este post mencionando que, a pesar de tener una visión que haya sido cocreada, compartida, ética, concisa, memorable, ambiciosa, inspiracional, factible, pegajosa, rimbombante, trendy, chévere, bacán, bacana, y etcétera y etcétera... un producto puede fallar, ese tipo de historias están a la vuelta de la esquina. Entonces, ¿De qué sirve hacer una visión?, bueno, el contar con una visión adecuada no garantiza el éxito, si embargo minimiza mucho la probabilidad de un daño catastrófico. En este sentido, una visión abordada desde el enfoque de la Agilidad puede hacer la diferencia (un ejemplo es el ciclo crear-medir-aprender de** Eric Ries**, que este autor menciona en su libro **The Lean Startup**), tan es así que Roman Pichler concluye en su libro:** “Haz una entrega o liberación rápida de la primera versión de tu producto, muéstrala a clientes y usuarios. Escucha sus respuestas para saber si estás vas por el camino correcto. Entonces Inspecciona y Adapta.”** . # Un tip final, postdata, un plus, extra, o como decimos acá en México: “Un pilón”: No subestimes el poder de una **visión cocreada y compartida**, como menciona **Peter Senge** en su libro La quinta disciplina: **“Cuando las personas comparten verdaderamente una visión, estas personas conectan y crean un lazo que los guía juntos hacia una aspiración común”**, y esto, una aspiración común de un grupo de personas, crea un efecto muy poderoso y positivo. ¡Imagina si llevas esto a tu organización! (y no hablo solo para el envisioning de un producto, sino el poder de la cocreación en todos los aspectos). ¿Qué opinas sobre la importancia de una visión y el poder de una visión cocreada y compartida? ¿Qué te parecieron estos tableros de Visión del Producto de Roman Pichler? .

30 de agosto de 2023

Product Management

Outputs, Outcomes & Impact - (Salidas, Resultados e Impacto)

# Una vieja historia conocida, nuevos actores Un equipo Scrum con el cual colaboré hace un par de años, estaba pasando por una situación: Habían terminado un nuevo producto (en este caso era un software para uno de sus clientes), habían construido todas las funcionalidades y características solicitadas “al pie de la letra, con puntos y comas” por este cliente, les daba retroalimentación, y en base a eso terminaron un producto… cuando llegó el usuario final, resulta que para la forma “real” en que él trabajaba y sus necesidades, este software no le ayudaba. No aportaba un beneficio mayor, un valor real, finalmente no utilizaba el nuevo, flamante (y costoso) programa. ¿Te suena conocida esta historia? Se entregaron las nuevas características tal como las solicitó el cliente, así como en el tiempo y costo definido en el contrato. En este caso un punto importante es que el cliente y el usuario no eran la misma persona, quien pagó por el producto (el cliente) no era quien realzaba las operaciones del día a día, quien daba la cara al cliente, no era quien iba a usar el producto (usuario). El equipo puso todo el enfoque y empeño en entregar, esto es lo que se conoce como **enfoque en “salidas” (outputs)**, es decir, cumplo al entregar en las condiciones estipuladas: tiempo, costo, las funcionalidades tal cual se solicitaron. Una vieja historia conocida de terror contemporáneo, es La-Pesadilla de las pesadillas, es algo que tristemente aún continúa cobrando a los equipos horas y horas de trabajo / miles líneas de código / documentos infinitamente extensos… trabajo que, desde el punto de vista Lean, termina siendo un desperdicio. **El epitafio de este producto diría algo: “Aquí yace un producto construido impecablemente, que nadie compra”** ☹ # ¿Hay algo más en qué debo de poner el enfoque? ¡Claro!, lo que buscamos es un impacto positivo, resolver el problema del usuario, hacerle la vida más fácil. Para poder llegar a generar un impacto, primeramente, debemos de enfocarnos en algo que se puede traducir como “resultados” (outcomes). Hay una definición de outcomes que en lo personal me gusta mucho, propuesta por su **Joshua Seiden** en su libro **“Outcomes over Outputs: Why customer behavior is the key metric for business success” (Resultados sobre Salidas: Por qué el comportamiento de los usuarios es la métrica clave para el éxito del negocio)**, nos dice que: **“Un outcome (resultado) es un cambio en un comportamiento humano que conduce a un resultado de negocio.”** Esta definición me parece muy poderosa, porque nos transmite que un outcome no tiene que ver con solo “construir o entregar algo”, sino en un cambio en una conducta o comportamiento del usuario/cliente que conduce a un valor positivo para el negocio. En el caso de este equipo Scrum que mencionaba al inicio de este artículo, ellos hicieron entrega de un producto, funcionaba perfectamente (no tenía errores), inclusivo era visualmente muy mono (se veía re-bonito, hasta tenía unas animaciones muy chéveres), y “lo más importante” es que lo entregaron en el tiempo y presupuesto acordado… suena como un producto perfecto, ¿no?... pero aún así, no producía ningún cambio en la forma en que el usuario final realizaba sus actividades porque sencillamente no le ayudaba en la realidad de su día a día, no facilitaba sus tareas, sus operaciones, no le hacía la vida más fácil. Para asentar un poco el enfoque en outcomes (y finalmente en el impacto en la vida del usuario final), al leer el libro de Seiden me encontré con este modelo que me encantó y estaba muy emocionado por escribir sobre él, o como decimos acá en México: **Se me quemaban las habas** por compartirlo. Este modelo y ejemplo que Seiden plantea en su libro, este se llama: **Program Logic Model o Modelo lógico de programa** (creado por W.K. Kellogg Foundation). Este modelo es muy simple: (image: modelo-01.webp) El enfoque en los outcomes en vez de outputs no es nada nuevo, de hecho, es muy conocido. Sin embargo, el agregarle ese enfoque final en el** impacto** me pareció poderoso y creo que aporta muchísimo valor. Claro que en la realidad, en el día a día, en nuestros equipos y organizaciones buscamos ese impacto final con la entrega de un nuevo producto o servicio, pero al menos personalmente nunca lo había definido con una palabra concreta, impacto, por lo cual este modelo me pareció muy alineado con lo buscamos con puntos como **“La meta del Producto” o Product Goal** que define La Guía Scrum, o con el famosísimo **“Porqué”** (sí, así pegado y con acento) que menciona Simon Sinek en su libro** “Comienza con el Porqué”**, esa razón de ser que nos guía. Así que, ya sin tanto rollo, el ejemplo para explicar este modelo es el siguiente: Una fundación tiene como propósito ayudar a mejorar la calidad de vida de una pequeña comunidad que vive en una zona alejada y sin servicios básicos. La gente de esta comunidad dedica buena parte de su día en caminar hasta un río para acarrear agua. En base a la observación, una hipótesis de la fundación es que, si la comunidad contara con un pozo de agua en el centro de su villa, no dedicarían tanto tiempo en acarrear agua desde el río, y este tiempo que se “ahorren” podrán dedicarlo a realizar otras actividades que les permitan mejorar su calidad de vida (tal vez aprender nuevos oficios, mejorar sus viviendas, cultivar más, o cosas como de ese estilo). En este caso, construir un pozo para la comunidad es el entregable que la fundación pretende entregar, la salida **(output)**. El resultado **(outcome)** que esta salida genera es que las personas toman agua de aquí y ya no van hasta el río todos los días. Esto cumple con la definición que nos comparte Seiden, porque** hay un cambio positivo en el comportamiento de las personas** que usan el pozo. El impacto que se busca, que las personas dediquen más tiempo a realizar otras actividades que mejoren en la calidad de vida de la comunidad, debe de observarse para determinar si se logra. # ¿Cómo garantizar que se obtenga el impacto deseado? Este es un tema que da para mucho, de esas charlas largas y apasionantes acompañadas de un buen café o mate (en lo personal prefiero un té verde). Siempre le he batallado con esto: ¿Cómo garantizas que se obtenga el impacto deseado?, ya que en la universidad no cursé la materia o asignatura llamada **“Ver el futuro en una bola de cristal”** :D Ya hablando en serio, hablar del impacto es hablar de **complejidad**, de cuestiones que no se pueden predecir (en la realidad existen infinitas variables que pueden influir en el impacto, y no siempre es posible identificar una correlación lineal o directa entre estas variables). ¿Cómo garantizar entonces el impacto? La verdad es que no es posible, ¿Entonces? Aquí lo importante es abordarlo con un enfoque de experimentación y plantear este impacto como una **hipótesis**. Para ver si esta hipótesis es correcta, se pueden correr experimentos pequeños, controlados, baratos, que nos den retroalimentación sobre la factibilidad de los outputs y outcomes para el impacto buscado. En este caso de ejemplo, supongamos que es factible llevar camiones o pipas de agua que abastezcan a la comunidad durante un periodo de tiempo que se considerará como un muestreo, y durante este tiempo se puede observar los cambios en las conductas o comportamiento de las personas y una “muestra” del impacto, a fin de validar si la hipótesis es correcta, antes de avanzar más… pero este solo punto, como mencionaba, es tema charlas mucho más profundas, o al menos de otro artículo particular (de hecho lo voy a abordar en un video que está en proceso de edición, próximamente lo compartiré por aquí: Pinky promise). El modelo de este ejemplo quedaría algo como: (image: modelo-02.webp) ¿Cómo te parece el modelo de este ejemplo? # Conclusión Para cerrar, me gustaría mencionar nuevamente la definición de outcomes que nos propone Seiden: “Un outcome (resultado) es un cambio en un comportamiento humano que conduce a un resultado de negocio.” El definir primeramente impacto que se espera en función a outcomes, es decir, en función del comportamiento de los clientes/usuarios, sirve como guía para ayudar a fomentar una cultura centrada en ellos, los clientes y usuarios, lo cual puede ayudar a que la organización obtenga también el impacto esperado: Valor de negocio. **P.D.** No olvidemos también a nuestro equipo, a las personas: Que construyan el producto o servicio en un ambiente de bienestar es, como se dice: un MUST, o sea que es imprescindible. ¿En qué se enfocan en tu equipo u organización actualmente? ¿Aún en outputs? ¿En outcomes, pero solo en esto? ¿O ya están centrados en los Impactos?

12 de julio de 2023

El bloc de notas de un Agilista Jedi