Realice las siguientes actividades después de la lectura:

1. Genere 5 preguntas de selección múltiple con 4 alternativas donde 1

(una) opción sea la respuesta correcta, referente a las lecturas.
2. Niveles de planificación de producto

     Describa los elementos de La “Cebolla de planificación” aplicado a la 

     agilidad.
Una gestión ágil de producto no debe significar que no tengamos un plan. Debemos aplicar un plan
que sea flexible para acomodar cambios en las asunciones subyacentes y mantenga un equilibrio
entre el largo y el corto plazo. Eso se consigue con el enfoque conocido como Cebolla de la
Planificación.
La planificación multicapa o “Cebolla de la Planificación” ayuda a los equipos de producto a elegir
el nivel adecuado de detalle dependiendo del alcance temporal en el que están planificando. Estos
niveles son:
 Visión
 Roadmap
 Release
 Iteración
 Diario

Visión
En lo más alto del modelo tenemos el nivel de la Visión. Como sabemos, la visión define el futuro
del producto a largo plazo (que según el producto de que se trate puede ser un período típicamente
de entre uno y varios años): qué problemas va a resolver y para quién los va a resolver. La visión
debe expresar y ayudarnos a entender el valor que nuestro producto aporta a los clientes y cómo
podría diferenciarse de otras soluciones que intentan resolver los mismos problemas.
Una forma de conseguirlo es elaborar de forma colaborativa con los implicados en la organización
un lienzo de visión de producto o un artefacto similar que podamos contrastar con el mercado.
Aunque la visión debe tener una vocación de estabilidad y de referencia a largo plazo esto no quiere
decir que no tenga que revisarse periódicamente (sobre todo en mercados muy dinámicos) digamos
en plazos de 6 meses a un año, para adaptarla a las nuevas condiciones de clientes, competidores,
tecnologías, entorno, etc.
Roadmap
El roadmap es uno de los artefactos principales de la estrategia de producto y define cómo se van a
alcanzar los objetivos plasmados en la visión a lo largo del tiempo (próximos meses-años). El
roadmap despliega y expande la visión en una sucesión de versiones de producto (o, como veremos a
continuación, de backlogs de release).
Especialmente el roadmap interno (dirigido a departamentos y stakeholders de nuestra empresa)
suele ser muy detallado -incluyendo calendarios, proyectos, tecnologías- y constituye una potente
herramienta de planificación y desarrollo. El roadmap no habla (sólo) de features, sino
principalmente de mercados, aplicaciones, personas, problemas, escenarios, valor, capacidades y
diferenciadores clave y objetivos de negocio.
Por el contrario, el roadmap externo va dirigido al mercado, es menos detallado y constituye
esencialmente una herramienta de comunicación y marketing. En cualquier caso, tanto los roadmaps
internos como los externos transmiten una información de prioridades y de disponibilidad.
El roadmap debe centrarse en temas
Desde el punto de vista de planificación de producto, es útil que cada release gire alrededor de
un tema que define un objetivo de negocio, una persona o un problema de cliente.
¿Y por qué es importante? Porque sólo enfocándonos en un tema vamos a poder resolverlo al 100%.
De lo contrario nuestro producto siempre va a quedarse resolviendo el 40% del problema de mucha
gente pero no va a ser excelente para nadie. Y, como sabemos, la gente no tiene “medios
problemas”, sino problemas enteros…
Las técnicas de integración y despliegue continuos típicas de los productos digitales nos permiten ir
liberando un flujo continuo de funciones y características. Pero que algo se “pueda hacer” no quiere
decir que sea lo mejor que “debamos hacer”. Enfocar una release en todas las funciones y
características que satisfacen un objetivo de negocio, una persona o un problema de cliente tienen
ventajas no sólo a la hora de implementar una solución más integrada y consistente, sino a la hora
de comunicarla y venderla. Empaquetando nuestras entregas alrededor de temas estamos
insuflando a nuestro producto una vocación de propósito y foco muy valiosa.
El roadmap no debe ser muy detallado en la descripción de cada release (especialmente las más
alejadas en el tiempo del momento actual) y específicamente en cuanto a la UX, funciones y
características que cada una debe poseer. Todo eso se irá concretando -incluyendo las necesarias
actividades de descubrimiento y validación de producto– cuando se vaya acercando el momento de
entregar cada una de ellas. Lo que sí es importante es que explicite cualquier precedencia y
dependencia entre funciones y características del producto en sus diferentes releases.

El roadmap debe revisarse y actualizarse con mayor frecuencia que la misión (y obviamente,
siempre cuando ésta ha sido modificada). Períodos entre dos y seis meses (incluso menores) son
habituales.

3. Concepto de Producto Mínimo Viable / Minimum Viable Product

(MVP).
 Resuma: Definición, Medir y aprender, lea desde página 323 del libro texto
básico del curso: metodos-agiles-scrum-kanban-leanpd.pdf.

redacte 5 Errores más comunes en la definición del producto mínimo viable

Un producto viable mínimo tiene solamente aquellas funcionalidades que permiten que
el producto sea lanzado. Típicamente se lanza sólo a un segmento de todos los posibles
clientes, tales como los early adopters.
¿Cuáles son los errores más comunes en la definición del MVP?
1- SOBREDIMENSIONAR EL MVP
Uno de los errores más comunes en el proceso de definición del MVP es que termine
con un nuevo producto sobredimensionado. Esto suele ocurrir si la persona que define el
MVP es la misma que ha ideado el nuevo producto. En este caso es aconsejable
que alguien ajeno al proceso creativo tome el papel de comprador (o usuario) para aislar
las funcionalidades necesarias del MVP. Normalmente es muy complicado que la
persona que ha ideado el nuevo producto pueda renunciar a una funcionalidad para crear
una primera versión reducida del mismo.
2- NO TENER PRESENTE LAS CAPACIDADES DEL EQUIPO
En la definición del producto viable mínimo deberemos tener presente las capacidades
del equipo del que disponemos. Para crear un nuevo producto, muchas veces innovador,
es necesario usar determinadas tecnologías y habrá que hacer desarrollos a medida. El
éxito o fracaso en la creación del MVP irá ligado a tener los conocimientos y
capacidades para poder realizarlo. En un startup es bueno que en la definición del
MVP participe todo el equipo, o una representación de los distintos perfiles de los que
se dispone. De un trabajo colectivo es más fácil que aparezca un MVP realista a las
capacidades del equipo. De no ser así es fácil caer en errores que pondrán en juego el
éxito del proyecto.
3- PENSAR QUE EL MVP ES LA VERSIÓN BARATA DEL PRODUCTO
Otro error muy común es pensar que el MVP es solo la versión barata o lite del
producto. El MVP no hace referencia a las versiones o modalidades de pago del
producto. Se trata de la definición de funcionalidades mínimas para que el producto
pueda ser utilizado para sus potenciales clientes. Si centramos el MVP con la versión
lite estaremos cometiendo el error de no probar las funcionalidades avanzadas con
nuestros usuarios o clientes y seguramente no estaremos hablando de una versión
mínima.
4- RELACIONAR LA PALABRA VIABLE CON LA RENTABILIDAD
La palabra viable no hace referencia a la viabilidad económica del proyecto ni a su
rentabilidad. Hace referencia a las funcionalidades. El MVP no es el producto con el
que empezaremos a ganar dinero, sino que nos permitirá medir si nuestra idea es viable
o no. En definitiva, el MVP nos sirve para evaluar si hay gente dispuesta a usar nuestra
aplicación o a pagar por el uso de nuestra plataforma. Unir la rentabilidad a la creación
del MVP es muy arriesgado, no nos permitirá iterar a partir del feedback recibido de los
usuarios o clientes y imprimirá mucha presión al equipo.
5- NO INCLUIR EL TIEMPO EN EL PLANTEAMIENTO
Para un startup, en la creación de un nuevo producto, el tiempo es una variable muy
importante. Una mala gestión del tiempo puede hacer fracasar un producto o incluso
hacer quebrar un startup. El tiempo, aunque sea infinito de forma global, es limitado
para un startup. Es limitado por la financiación de la que se dispone y en muchos casos
requiere que su producto funcione y sea rentable antes de que se termine el dinero. Para
ello es muy importante para la salud del startup no unir la creación del MVP a
la rentabilidad de la misma.