EP109 — Growth Hacking + A/B Testing con Roberto Moraga

otras plataformas

RespuestasAgiles: ¿Cuál es la diferencia entre Producto Mínimo y Producto Mínimo Viable (MVP - Minimum Viable Product)?

Encontrando el MVP con un Roadmap y el Mapa de Afinidad

Hola a todos

Realizando talleres Producto Mínimo Viable - MVP (Minimun Viable Product), he encontrado que para cierto tipo de equipos les da dificultad emplear la técnica del User Story Map de Jeff Patton, para estos equipos he ideado esta técnica basada en el Roadmap y el Mapa de Afinidad, espero les guste y también les sirva con sus equipos.

Saludos Ágiles

Bienvenido el Feedback
Jorge H. Abad L.

Encontrando el MVP con un Roadmap y Mapa de Afinidad from Jorge Hernán Abad Londoño

Unos tips y preguntas poderosas para encontrar el MVP

A continuación a compartir algunos tips y preguntas que hemos encontrado con varios Agile Coaches (Lucho Salazar @LuchoSalazarC, Pablo Mejía  @pmejia73) que te pueden ayudar a en

• Siempre busque paretos, cual es el 20% del sistema que generaría un 80% de valor o impacto en el negocio.
• Identifique cuál o cuáles son los criterios claves para la selección del MVP (4)
• ¿Si me voy del proyecto qué es lo mínimo que quiero dejarle?
• si es una migración o reconstrucción de un sistema
•  ¿cuales son las funcionalidades que registran más uso del sistema? 
• ¿agrega valor volver a construir lo que se dejó de usar o lo que nunca se ha usado?
• Imagine el dinero es suyo, o que le darán un premio por invertir la menor cantidad de dinero
• ¿Cual es la mínima funcionalidad que comienza a resolver el problema de negocio?
• ¿Y si le recortaran el dinero al proyecto a la mitad?¿y la mitad de esa mitad?
• ¿que sería lo mínimo que usted podría dejarle al proyecto si quiere dejar una gran impresión pero tiene esta restricción de dinero?
• ¿Y si le recortaran el tiempo al proyecto a la mitad?¿y la mitad de esa mitad?
• ¿que sería lo mínimo que usted podría dejarle al proyecto si quiere dejar una gran impresión pero tiene esta restricción de tiempo?

Hasta acá este pequeño compartir
Bienvenido el feedback


Saludos Ágiles
Jorge Abad

Notas, Referencias, Comentarios, Aclaraciones

1. Minimísimo Producto Viable - PRAGMA - Pablo Mejía - Mínimo producto viable - ágil - https://es.slideshare.net/PabloMejaArbelez/minimisimo-producto-viable-pragma-pablo-meja
2. How to Split a User Story - http://agileforall.com/resources/how-to-split-a-user-story/
3. Sí, Mínimo Producto Viable ¿Pero en qué contexto? - http://www.lecciones-aprendidas.info/2016/10/si-minimo-producto-viable-pero-en-que.html
4. Criterios de Selección del Mínimo Producto Viable - http://www.lecciones-aprendidas.info/2018/01/criterios-de-seleccion-del-minimo-producto-viable.html

Algunos Criterios o Patrones de Selección del Mínimo Producto Viable

Muchas veces elegir o encontrar el Mínimo Producto Viable (MVP - Minimun Viable Product) no es un ejercicio fácil para el Dueño del Producto y sus interesados (o stakeholders), en ocasiones se deben revisar criterios de negocio, criterios técnicos, o tal vez se requiera de un análisis multi-objetivo que ayude a determinar cual es el valor que se quiere entregar en la primera versión del producto. A continuación les comparto algunos criterios:

1. Validar una hipótesis de negocio con el mercado. Es la común para las startups, buscando obtener el máximo aprendizaje.
2. Validar un pedazo riesgoso de una solución
3. Primero lo más barato
4. Lo que menos cuesta
5. Lo que implique el mayor ahorro en el proceso
6. Primero una una tecnología específica y luego el resto, ejemplo primero construir la solución para Android y luego para iPhone
7. Automatizar una parte del proceso y luego el resto
8. Lo que me comience a resolver el problema de negocio más rápidamente
9. Primero ciertos roles claves y luego otros
10. Las reglas de negocio de mayor impacto primero y luego las otras
11. Primero el camino feliz y luego las excepciones
12. Construir para una segmentación de datos y luego para los otros, ejemplos: compradores frecuentes y luego compradores de ciertos productos.
13. La operación del sistema que me permita obtener mayor valor
14. (Si el criterio es performance) Primero construir la solución con desempeño normal y luego llevarla al alto desempeño
15. Eliminando el riesgo regulatorio o minimizando su impacto
16. Minimizar multas o sanciones
17. Lo que más ingresos me produzca
18. Lo que mínimo que me permita igualar uno o varios servicios de mi competencia.
19. En una migración: lo más usado y luego lo menos

Hasta acá este pequeño compartir, si encuentran más criterios no dudes en hacer su aporte en la zona de comentarios, los citaré respectivamente.

Bienvenido el feedback

Saludos Ágiles
Jorge Abad

Notas, Referencias, Comentarios, Aclaraciones

1. Minimísimo Producto Viable - PRAGMA - Pablo Mejía - Mínimo producto viable - ágil - https://es.slideshare.net/PabloMejaArbelez/minimisimo-producto-viable-pragma-pablo-meja
2. How to Split a User Story - http://agileforall.com/resources/how-to-split-a-user-story/
3. Sí, Mínimo Producto Viable ¿Pero en qué contexto? - http://www.lecciones-aprendidas.info/2016/10/si-minimo-producto-viable-pero-en-que.html

[Scrum] El Valioso "NO" del Product Owner

Hola a todos

Según la Guía de Scrum(1), el Dueño de Producto o Product Owner (PO). lo define como:

• El responsable de maximizar el valor del producto y el trabajo del Equipo de Desarrollo (2)
• Es la única persona responsable de gestionar la Lista del Producto (Product Backlog)
• Expresa claramente los elementos de la Lista del Producto;
• Ordena los elementos en la Lista del Producto para alcanzar los objetivos y misiones de la mejor manera posible;
• Optimiza el valor del trabajo que el Equipo de Desarrollo realiza;
• Asegura que la Lista del Producto es visible, transparente y clara para todos y que muestra aquello en lo que el equipo trabajará a continuación;
• Asegura que el Equipo de Desarrollo entiende los elementos de la Lista del Producto al nivel necesario.
• Es una única persona, no un comité. El Dueño de Producto podría representar los deseos de un comité en la Lista del Producto, pero aquellos que quieran cambiarla prioridad de un elemento de la Lista deben hacerlo a través del Dueño de Producto.
• Para que  pueda hacer bien su trabajo, toda la organización debe respetar sus decisiones
• Durante el Sprint el alcance puede clarificarse y renegociarse entre el Dueño de Producto y el Equipo de Desarrollo a medida que se va aprendiendo más.
• Solo el Dueño de Producto tiene la autoridad para cancelar el Sprint
• El Dueño de Producto hace seguimiento de este trabajo restante total al menos en cada revisión de Sprint.
• Decide si libera o no el incremento

Lo anterior podríamos parafrasearlo un poco como

• Es alguien con empoderamiento y capacidad de decisión sobre el producto
• Es el responsable del  ROI -return on investment-
• Es voz del cliente ante el equipo
• Define, refina y prioriza el Product Backlog
• Esta disponible para el equipo
• Hace seguimiento del avance y la construcción del producto
• Decide cuando cancelar el sprint 
• Decide cuando salir a producción.

Pero este post se enfoca en que le corresponde Product Owner respecto al producto y al alcance decir

• qué se hace 
• y qué se posterga para próximas versiones (un NO PARCIAL, o sea hoy te digo que NO, mañana tal vez lo hagamos)
• y qué definitivamente NO SE HACE

Esto se alinea perfectamente con el décimo principio ágil (3) en donde se refleja el pensamiento Lean:

la simplicidad o el arte de maximizar la cantidad de trabajo no realizado es esencial

Decifrando este juego de palabras podemos parafrasearlo diciendo para el mundo del software

Nos esforzaremos al máximo en NO crear ni software, ni alcance, ni trabajo de desperdicio o que no sea necesario (o hacer algo que terminará siendo inútil)

Por lo tanto, es clave que el Product Owner aprenda de a DECIR NO, y al negociar con sus interesados para ciertas funcionalidades les dirá:

• eso NO se puede hacer aún, 
• es que necesitamos generar valor con lo mínimo posible
• eso va para otra versión o release
• eso aun NO tiene prioridad
• eso NO agrega valor
• eso definitivamente NO se hará

Es decir la misión del PO es mantener el Backlog de cada release lo mas pequeño posible de forma que se genere valor con la menor cantidad de alcance requerido y de esa manera se alcance prontamente el máximo ROI.

Cerrando

Un buen PO sabe:

• Que cada sprint tiene software funcionando y potencialmente liberable (punto a favor del PO y de la organización)
• Pero que si se permite decir que SÍ todas las funcionalidades que se le ocurran tanto a el como al negocio, NUNCA va a salir a producción, pues a mayor alcance más cantidad de sprints se van a requerir para salir a producción, y a mayor tiempo menor ROI (un peligroso circulo vicioso)
• Que si se demora mucho en salir a producción el impacto en el ROI y en el negocio puede ser nefasto dado lo disruptivo y cambiante del entorno actual.

Recuerdo mucho una frase que le escuche a Ángel Medinilla.

NUESTRO TRABAJO NO ES HACER SOFTWARE, ES HACER LA MENOR CANTIDAD DE SOFTWARE POSIBLE QUE MAXIMICE EL VALOR DE NEGOCIO DE NUESTROS CLIENTES.

Por lo tanto cuando vayas a escoger a un PO, cerciórate de que el o ella tienen claro los siguientes aspectos respecto al alcance:

1. Que conoce que problema de negocio está resolviendo
2. Que tiene claro cual es la solución que debe entregar al negocio para resolver ese problema
3. Que dice NO, pues esta interesad@ en salir a producción lo antes posible
4. Que comprende que el NO es de las mejores formas de controlar el ROI

Bienvenido el Feeback

Saludos ágiles

Jorge Abad

Notas, Aclaraciones, Comentarios y Referencias

1. Guía de Scrum - clic aquí para descargarla. De igual forma les recomiendo leerla encontrarán elementos que de seguro estaban ocultos a su primer entendimiento (como me pasó a mí).
2. El nombre del Equipo de Desarrollo crea por lo general confusión en la industria del software, se debería llamar Equipo Solucionador
3. Principios ágiles - http://agilemanifesto.org/iso/es/principles.html
4. Este post está altamente relacionado con: La Ilusión del Control o ¿Cómo Hago para Controlar un Proyecto Ágil?

Algunas Frases para Product Owners

Cliente créeme,

suelta el ALCANCE y yo te daré en cambio el VALOR, nos va a ir mejor a todos.#Agile #Scrum #ProductOwner #ScrumMaster

— Jorge Hernán Abad L. (@jorge_abad) November 12, 2016

---

Having more features doesn't mean the same as having a competitive advantage

— Guilherme Motta (@gfcmotta) December 19, 2016

---

Lo escuche hoy
"En #Scrum no esta claro todo el trabajo que tiene que hacer un #ProductOwner para traer una historia de usuario a un equipo"

— Jorge Hernán Abad L. (@jorge_abad) September 26, 2016

---

"la gente no va a extrañar lo que no tiene" @camilohenao1 #lean #agile #ProductOwner #scrum #mvp

— Jorge Hernán Abad L. (@jorge_abad) September 22, 2016

---

#PreguntaPoderosa de @pmejia7 sobre #MVP

"¿Cómo puedo resolver progresivamente el problema de negocio del #ProductOwner?" #agile

— Jorge Hernán Abad L. (@jorge_abad) September 21, 2016

---

"¿Si la organización no realizara este proyecto / producto, que impacto tendría?"@pmejia73 #ProductOwner #PreguntaPoderosa #AgileInception

— Jorge Hernán Abad L. (@jorge_abad) June 29, 2016

---

En #Agile no nos centramos en construir alcance, nos valemos del alcance para resolver problemas de negocio, lo que es bien diferente.#lean

— Jorge Hernán Abad L. (@jorge_abad) January 20, 2017

---

"todo agilista debe preguntarse cada día
¿si hoy se interrumpe el proyecto, que producto de valor le dejé al negocio?" @pmejia73

— Jorge Hernán Abad L. (@jorge_abad) June 29, 2016

---

Estrategia para generar VERDADERO VALOR DE NEGOCIO

Solución + #lean + #Agile pic.twitter.com/bRuEXgP11H

— Jorge Hernán Abad L. (@jorge_abad) June 28, 2016

---

En últimas no importa ni la velocidad ni la estimación del equipo #scrum, lo que realmente importa es entregar software de valor cada Sprint

— Jorge Hernán Abad L. (@jorge_abad) June 10, 2016

---

Si no es ni colaborativo, riesgo compartido, gana-gana y entregas de valor frecuente, no es #ContratoAgil https://t.co/j5deVJzNiB #Scrum

— Jorge Hernán Abad L. (@jorge_abad) May 12, 2016

---

¿Qué preferimos que nos cumplan: con el plan o que nos entreguen valor? @jorge_abad @AgilesColombia @AgilesMedellin #ContratosÁgiles

— Lucho Salazar (@luchosalazarc) May 7, 2014

---

Uno de los factores de éxito de un proyecto #Scrum es:#ProductOwner que sabe decir que NO#Agile #FactorExitoScrum

— Jorge Hernán Abad L. (@jorge_abad) January 26, 2017

Inceptions, con Lucho Salazar

¿Cómo nacen los productos grandiosos? De esos cuyos componentes hacen resonancia entre sí e impactan el 'modus vivendi' de quienes los usan o consumen.

¿Cómo defines su alcance?

¿Cómo estableces el Producto Mínimo Viable - MVP?

¿Cuáles son las distintas técnicas y prácticas ágiles para hacer Inceptions de gran calidad y que motiven al equipo a empezar un trabajo fabuloso?

¿Qué es eso del Elevator Pitch?

¿Y el Product Box?

Además:

El User Story Mapping

+ El plan de entregas

+ El plan de iteraciones

+ Otras técnicas y herramientas que nos ayudan no solo a entender lo que queremos construir (lo que quieren nuestros usuarios o clientes), sino también a lograr consenso entre los miembros del equipo y los interesados en el proyecto y producto o servicio que queremos diseñar y construir.

Estas y algunas otras cuestiones son las que compartí con mi gran amigo Lucho Salazar, con ejemplos concretos y prácticos, durante el Webinar del mismo nombre. El video lo pueden encontrar en:

Pueden descargar la presentación de:

Inceptions from Luis Antonio Salazar Caraballo

Nota:
Este post lo podrás encontrar también en el blog de mi estimado amigo c@LuchoSalazarC (Inceptions, con Jorge Abad)

Ámbitos del Proyecto y del Producto en Scrum

Hola a todos

Siguiendo con la serie (http://www.lecciones-aprendidas.info/2016/05/ambitos-del-producto-y-del-proyecto.html ), les comparto dónde está ubicado el Equipo Scrum (el cual esta compuesto por Product Owner, Scrum Master y Team Members) dentro del ámbito del Producto y del Proyecto

Saludos Ágiles

Jorge Abad

Ámbitos del Producto y del Proyecto

Hola a todos

Les comparto esta imagen que puede ayudar a identificar qué ámbito corresponde al producto y qué ámbito al proyecto, ayudando a aclarar algunas dudas al respecto.

Saludos Ágiles
Jorge Abad