Las Claves Del Product Management: Métodos y Estrategias para Lograr El Éxito de Tus Productos Digitales

LAS CLAVES
DEL PRODUCT
MANAGEMENT
Métodos y estrategias Chloé Dumolard
para lograr el éxito de Floriane Sirven
tus productos digitales
LAS CLAVES
DEL PRODUCT
MANAGEMENT
MÉTODOS Y ESTRATEGIAS
PARA EL ÉXITO DE TUS
PRODUCTOS DIGITALES
1
Presentación de las autoras
Chloé Dumolard
Chloé Dumolard es Lead Product Manager y formadora

apasionada en Thiga. Su carrera le ha llevado a ocupar puestos
clave en grandes empresas como Decathlon, SNCF Voyageurs o la
Fábrica Digital del Grupo Seb, donde ha dirigido todas las etapas
de la creación de un producto, desde la prueba de concepto hasta la
búsqueda del Product Market Fit. En las startups Evaneos, Leetchi
y Alma, ha tenido un impacto decisivo en la visión de Producto y
la estructuración de los equipos. Definición de OKRs, investigación
de usuario, priorización del roadmap… ésta apasionada de la
danza conoce a la perfección las acrobacias del Producto.
Floriane Sirven
Consultora en Thiga desde hace cinco años, Floriane Sirven

fue Head of Product en Chanel, donde jugó un papel determinante
en la implementación de la gobernanza de Producto y lideró la
definición del roadmap con un gran desafío de gestión del cambio.
Anteriormente, trabajó para SNCF y Se Loger, donde gestionó todo
el ciclo de vida del producto, desde la visión hasta el delivery en
un contexto ágil con iteraciones continuas. Comprometida con
transmitir sus experiencias prácticas, Floriane es actualmente
formadora senior en Thiga Academy y desarrolla los programas de formación de Producto en
L’Oréal.
2
ACERCA de y
Fundada en 2014 en París, Thiga es una consultora internacional única que busca cerrar
la brecha entre la aspiración y la ejecución. Permite a las empresas convertirse en líderes
tecnológicos a través del Pensamiento de Producto y el desarrollo completo de productos
digitales de principio a fin.
En 2011, Marc Andreessen acuñó la frase «El software se está comiendo el mundo». Más de
una década después, más empresas que nunca, independientemente de su sector de actividad
tradicional, se consideran empresas de software o de datos.
Sin embargo, convertirse en una verdadera empresa tecnológica líder es un desafío. Requiere
una cultura, organización y un conjunto de habilidades específicas. El éxito como empresa
digital implica a menudo un ADN común que va más allá de los equipos de desarrolladores e
involucra a todos, desde la dirección hasta el marketing, las ventas y el servicio al cliente. Esto
es el Product Management.
Durante la última década, Thiga se ha convertido en un líder en Product Management y

Product Design. Contamos con un equipo de 250 consultores y formadores en Francia y España.
Con Thiga Academy, formamos a más de 2000 personas al año.
Thiga nació en el ecosistema tecnológico, ayudando a las startups a desarrollar sus

productos. Somos doers y hoy en día, acompañamos a las empresas que quieren transformar su
organización para adoptar la cultura de Producto.
Como pioneros en este mercado, hemos jugado un papel importante en el corazón de la

comunidad de Producto. Organizamos una conferencia anual llamada “La Product Conf ”, que
reúne a 1500 participantes. Tenemos nuestro propio media y hemos publicado 6 libros. Este es
nuestro recién nacido y estamos muy felices porque apenas lo has abierto.
Si necesitas acompañamiento por nuestra consultoría, encuéntranos en thiga.co/es
Si necesitas formar a tus equipos, acompañamos sus carreras en Product Management y

Product Design hasta los puestos de Product Leader. Mira en academy.thiga.co
3
PREFACIO
4
Prefacio de Christopher Parola,
Chief Product Officer de Yousign
Al escribir el prefacio de este libro, pienso en los numerosos encuentros y experiencias
que han nutrido mi visión del Product Management durante los últimos quince años. Cuando
comencé, eran pocas las personas que conocían el término Product Management; la moda
todavía estaba en los Product Owners y en la ola de la agilidad.
Tener un libro como este entre manos me habría facilitado las cosas. Este trabajo es una
destilación de la esencia misma del Product Management, impregnado de realidades, métodos
y rituales que he practicado diariamente, compartido con mis equipos y que he podido abordar
en mis artículos y conferencias.
El marco necesario para la autonomía
Chloé y Floriane han logrado describir en este libro numerosos conceptos y prácticas que
permiten crear el marco propicio para la autonomía.
Encontrarás en estas páginas no una fórmula mágica o un framework adicional, sino más
bien una mezcla de observaciones y consejos concretos sobre cómo construir y mantener un
producto digital sólido. Descubrirás la importancia del alineamiento de equipos y la claridad
de la visión, que han sido fundamentales para mí en Meilleurs Agents, dentro del grupo Aviv y
ahora en Yousign.
Como Chief Product Officer, estoy convencido de que mi rol es proporcionar a mis equipos
el marco en el que puedan ser autónomos. Visión de producto, principios de equipo, prácticas
de discovery y delivery, todo está explicado, argumentado y acompañado de ejemplos.
Esta autonomía es la clave de tu éxito. Libera la innovación y permite la construcción de

productos con el mayor impacto.
«¿Cuál es tu visión de producto?»
Al igual que Chloé y Floriane, quienes dedican toda la primera parte del libro a la visión
de producto, he escuchado constantemente esta pregunta. No hay conferencia, meetup o
encuentro entre profesionales del producto donde no se aborde.
Cuando hablo de visión de producto, me refiero a una visión a nivel empresarial, que se
integra en la misión y en la estrategia. A veces se llama “visión empresarial”, pero entonces a
menudo se confunde demasiado con conceptos de transformación del mundo por la empresa.
5
Pero no es eso. Para mí, la visión de producto es lo que nuestro producto debe convertirse para
entregar su valor y tener su impacto.
El tema de la visión de producto te concierne, ya seas Product Manager, Product Designer,

Product Marketing Manager o miembro del comité ejecutivo. La visión de producto te será útil,
ya sea definida a nivel empresarial o para uno de tus numerosos productos. Y este libro ofrece
un camino para construirla.
He tenido que definir la visión de producto en dos posiciones: como contribuidor indivi-
dual la primera vez y como CPO la segunda. Sorprendentemente, los pasos son bastante simi-
lares, y te ayudarán ya seas líder o gerente. ¡No descuides esta fundación esencial!
Rituales y lenguaje común
Numerosos rituales se presentan a lo largo del libro, particularmente basados en el ejemplo

ficticio de Thiga Eats.
Este hilo conductor permite visualizar de manera muy concreta las diferentes etapas y es
una gran cualidad de este libro.
Los rituales presentados son el cemento de los equipos de Product Managers. Estructuran
la vida cotidiana y crean coherencia. Son indispensables para alinear la visión y clarificar la
comunicación. En pocas palabras, anclan al equipo. Adaptan las estrategias y anticipan los
problemas. Son la clave de nuestra resiliencia y nuestro éxito en el mundo del producto. Son
nuestra constante, nuestro pulso en un universo en constante evolución.
Para aquellos que no sois fanáticos de los rituales, sabed que es necesario entenderlos para
trascenderlos. No tienes que aplicarlos como un manual escolar, pero conocerlos en detalle, con
ilustraciones y casos concretos, te permitirá sacar lo mejor de ellos en tu contexto y dejar de
lado lo que no pueda funcionar. No veas en este libro una forma de dogmatismo sino una caja
de herramientas de la cual será fácil extraer.
El impacto como brújula
Todos los métodos y prácticas descritos en el libro te permiten alcanzar el único objetivo
fundamental para cualquier equipo de producto: tener impacto.
6
En Meilleurs Agents, teorizamos e implementamos el concepto de Impact Teams con mi
cómplice de siempre, Nicolas Baron, ahora Chief Technology Officer en Yousign.
Estábamos en hipercrecimiento y nuestro objetivo era aumentar la implicación de los equi-

pos, alinearlos en torno a objetivos comunes y responsabilizarlos para alcanzar metas. Cuanto
más los involucrábamos en la toma de decisiones, más comprometidos estaban.
Partíamos de excelentes bases. Meilleurs Agents ya tenía una cultura ágil establecida, con
rituales y mejora continua. La empresa había invertido en pruebas automatizadas para asegurar
la calidad del código. Teníamos la capacidad de desplegar frecuentemente, lo cual es esencial
para acelerar el aprendizaje. Finalmente, los equipos estaban localizados, lo que facilitaba la
comunicación y colaboración. Eso fue antes de la epidemia de Covid 19... Esta organización
resistió perfectamente el impacto del teletrabajo.
Establecimos los Impact Teams, equipos multidisciplinares responsables de objetivos cuan-

tificados. Cada equipo era autónomo para determinar cómo alcanzar sus objetivos. Se orga-
nizaron reuniones de intercambio de experiencias entre Product Managers para fomentar la
difusión del conocimiento.
Este nuevo paradigma afectó al comité ejecutivo, que pasó de un rol de decisores a estrate-
gas al establecer los objetivos correctos. Se animaba a los equipos a proponer ideas, seguido
de un largo proceso de evaluación basado en el potencial de alcance, el impacto esperado y la
confianza en el proyecto para decidir cuáles se adoptaban.
Estos Impact Teams no son un fin en sí mismo, y en Yousign, nuestra organización es

híbrida. De nuevo, un excelente ejemplo de herramienta a conocer y adaptar a tu contexto.
Terminaré diciéndote que el viaje del Product Manager es un viaje de evolución personal y
profesional, y este libro es una etapa clave en este emocionante camino. Puede ser un descubri-
miento o un redescubrimiento para los más experimentados entre vosotros.
Os deseo una lectura ilustrativa e impactante,
Christopher Parola
7
ÍNDICE
8
Introducción................................................................................................. 10
Módulo nº1: Establecer el rumbo............................................................... 18

Capítulo 1 : Entender el contexto del producto...........................................20
Capítulo 2 : Definir una misión y objetivos para el equipo........................28
Capítulo 3 : Identificar oportunidades de Producto..................................36
Capítulo 4: Crear el roadmap..........................................................................44
Módulo nº2: Entender el problema y elegir la solución........................... 54

Capítulo 5: Comprender el discovery............................................................56
Capítulo 6 : Profundizar en los problemas de los usuarios.....................64
Capítulo 7 : Imaginar, diseñar y elegir soluciones......................................74
Capítulo 8 : Probar posibles soluciones........................................................84
Capítulo 9 : Centrarse en las prioridades....................................................92
Módulo nº3: Construir el producto........................................................... 102

Capítulo 10 : Preparar los desarrollos..........................................................104
Capítulo 11 : Gestionar el delivery con agile................................................116
Capítulo 12 : Planificar y proporcionar visibilidad.....................................126
Capítulo 13 : Seguir el progreso y gestionar los imprevistos.................139
Capítulo 14 : Entregar las funcionalidades..................................................145
Capítulo 15 : Gestionar el lanzamiento de las funcionalidades...............153
Módulo nº4: Mejora continua...................................................................... 160

Capítulo 16 : Definir las medidas del éxito....................................................162
Capítulo 17 : Recolección y seguimiento de datos......................................170
Capítulo 18 : Desarrollar el producto............................................................176
Capítulo 19 : Gestionar los bugs y la deuda técnica...................................184
Capítulo 20 : Trabajar en equipo y colaborar con los stakeholders.....190
Conclusión.................................................................................................... 200
Agradecimientos......................................................................................... 202
Glosario..................................................................................................................204
9
INTRODUCCIÓN
INTRODUCCIÓN
10
INTRODUCCIÓN
Nuestras intenciones
El Product Management ocupa un lugar esencial en las organizaciones que sitúan los pro-
ductos y servicios digitales en el corazón de su estrategia. Esta disciplina permite lanzar pro-
ductos que realmente se ajustan a las expectativas de los usuarios y mejorar los productos
existentes para mantenerse competitivos. El Product Management es estratégico, ¡ya que no es
fácil crear productos exitosos!
Históricamente, la gestión de productos surgió en el sector de bienes de consumo en los

departamentos de marketing. Pero la naturaleza misma de los productos tecnológicos hace que
esta gestión sea particular: las evoluciones pueden ser muy rápidas, realizadas de manera incre-
mental, y es fácil medir su uso en tiempo real. Por lo tanto, no es pertinente separar el diseño de
nuevos productos de su desarrollo. Los desarrolladores y los Product Managers deben trabajar
juntos. El Product Management se ha convertido en una disciplina principal de las empresas
tecnológicas, diferenciada de la función de marketing. Y los equipos de Product Management
son liderados por un/a Chief Product Officer, integrado/a en el comité de dirección.
A través de nuestras misiones con clientes, hemos probado metodologías de producto y

diferentes enfoques según los contextos, y aprendido de los equipos y nuestros pares. Por eso,
decidimos reunir los fundamentos en un libro concreto y práctico, para daros las claves del
Product Management.
No partimos de una página en blanco, ya que este libro es la versión completamente revi-
sada del primer libro sobre Product Management escrito en francés. Desde la primera edición
de 2015, ¡el mundo del Producto ha cambiado mucho! El Product Management ya no está reser-
vado solo para startups. Por un lado, las empresas en expansión enfrentan desafíos de rentabi-
lidad y consolidación. Por otro lado, las grandes empresas han comenzado su transición hacia
lo digital para organizarse y gestionar productos a gran escala.
En este contexto efervescente, hemos consolidado nuestro conocimiento en Thiga. Así

nació el proyecto de reedición del pequeño libro verde que seguramente te guió en tus primeros
pasos como Product Manager.
La ambición de este libro es ofrecer una guía de referencia del Product Management.
Descubrirás las mejores prácticas para dominar el enfoque del Producto, consejos valiosos
basados en nuestras experiencias y ejemplos concretos para ilustrar conceptos clave. También
encontrarás todos los recursos necesarios para poner rápidamente en práctica los métodos.
Finalmente, referencias esenciales del mundo del Producto te animarán a profundizar en cier-
tos temas.
11
INTRODUCCIÓN
Un libro para todos

los Product Managers
Estamos convencidos de que no existe una única manera de hacer productos, y que es
importante saber adaptar nuestras prácticas. Por eso, queríamos escribir una guía utilizable,
independientemente de tu contexto. Hemos hecho todo lo posible para no ser demasiado
dogmáticos, compartiendo lo que consideramos buenas prácticas realistas y adaptables a
diferentes realidades.
Este libro está dirigido tanto a Product Managers que trabajan en productos destinados a
usuarios profesionales (B2B), particulares (B2C) o empleados (B2E), a PMs responsables de un
producto de pago o gratuito, de un producto en SaaS (Software as a Service), de un sitio web o
de una aplicación móvil, ya sea que estés a cargo de la totalidad de un producto o bien de una
parte del recorrido del usuario o de un componente.
Tanto si acabas de llegar al puesto como si eres un Product Manager experimentado,

encontrarás en este libro elementos prácticos para guiarte en tu día a día. Al igual que el
deportista que hace su entrenamiento o el músico que practica sus escalas, hay fundamentos
del producto a los que los Product Managers vuelven constantemente, independientemente de
su nivel de experiencia. La estructura del libro explicada a continuación permite abrir cualquier
página, recordar las buenas prácticas y cerrarla.
Como líder de Producto, este trabajo es una herramienta de compartir y transmitir, un

resumen de buenas prácticas que puedas transmitir fácilmente a tus equipos.
Lo que aprenderás
Este libro te ofrece una visión general del ciclo de vida de un producto digital, desde la
definición de la estrategia hasta la mejora continua. No solo te damos conocimientos teóricos,
sino también las claves para comprender los entresijos del Product Management. Equipado
con una visión completa de la disciplina y herramientas efectivas, ¡estarás listo para crear
productos exitosos!
Aprenderás cómo:
◉ Comprender la visión y la estrategia de tu empresa y de tu producto.
◉ Definir objetivos ambiciosos para tu equipo.
◉ Construir un roadmap orientado a objetivos.

12
INTRODUCCIÓN
◉ Priorizar las iniciativas correctas.
◉ Llevar a cabo un discovery eficaz.
◉ Construir y mantener tu backlog.
◉ Gestionar el delivery con Agile.
◉ Definir los indicadores de éxito adecuados.
◉ Mejorar tu producto de manera continua después de la producción.
◉ Adoptar la postura correcta para colaborar con los stakeholders y trabajar en equipo.
Una estructura adaptada a

diferentes lecturas
Este libro está dividido en cuatro módulos, abordando cada uno una etapa clave del proceso
del Producto. Cada módulo se divide en capítulos, cada uno centrado en un concepto específico.
Puedes elegir leer nuestro libro:
◉ De principio a fin, para tener una visión general del enfoque del Producto.
◉ Por módulo, para profundizar en una etapa específica del proceso.
◉ Por capítulo, para enfocarte en un tema específico.
13
INTRODUCCIÓN
Los conceptos se ilustran a través del ejemplo de una empresa ficticia llamada “Thiga Eats”.
Este caso práctico de hilo conductor está representado por recuadros verdes.
Thiga Eats
Thiga Eats es un servicio de entrega de platos cocinados y de productos

de alimentación lanzado por Thiga en 2020 y con sede en París. Los
pedidos se realizan en la aplicación móvil de Thiga Eats con restaurantes/
tiendas de comestibles asociados cercanos y son entregados por
repartidores independientes (bicicleta, moto, etc.). Imagina que te unes
a Thiga Eats como Product Manager del equipo de Activación, cuyo
ámbito abarca desde la búsqueda de platos hasta el pago en línea.
Ofrecemos plantillas para ayudarte a utilizar determinadas herramientas.
Estas plantillas son descargables gratuitamente gracias a

un código QR.
En algunos capítulos, ciertos conceptos se destacan a través de recuadros grises.
Para profundizar...
Estos conceptos te permitirán ampliar tus conocimientos, obtener una

perspectiva más amplia o descubrir prácticas innovadoras que aún no
conoces.
14
INTRODUCCIÓN
Al final de cada capítulo, encontrarás nuestros consejos para convertirte en un Product
Manager experimentado y al final de cada módulo, un resumen de los elementos clave a recordar.
Finalmente, si algunos términos o conceptos no son claros, puedes consultar el glosario al

final del libro. Allí encontrarás una corta definición del término en cuestión y, si es necesario,
una referencia al capítulo en el que se describe el concepto con más detalle.
Aclaraciones para la lectura

El Producto
En Thiga, consideramos como Producto cualquier bien o servicio destinado a satisfacer

una necesidad del usuario. Si este producto es una herramienta inmaterial, distribuida a través
de medios digitales, entonces es un producto digital.
En este libro, utilizaremos el término “producto” para referirnos, según el contexto, a la

totalidad de un producto digital, o solo a una subparte correspondiente al ámbito de un equipo.
No agregamos el término “digital” cada vez por motivos de fluidez en la lectura. Es implícito. Los
productos físicos no son el tema de este trabajo.
Los oficios del Producto
En el libro, mencionaremos los diferentes oficios que intervienen en las actividades del
Producto. Aunque los títulos utilizados varían de una empresa a otra, usaremos los términos
Product Manager, Product Designer y Product Marketing Manager, que nos permitirán referir-
nos a las diferentes competencias.
El/la Product Manager (PM) es el director de orquesta del producto. Es responsable de

tomar decisiones estratégicas para el producto para que este tenga un impacto positivo tanto
para el usuario como para la empresa. En la intersección de problemas de usuario, negocios y
técnicos, los Product Managers dan la dirección estratégica y priorizan los temas del equipo,
participan en el descubrimiento de necesidades del usuario y en el diseño de soluciones, ges-
tionan el delivery y se aseguran de seguir el éxito del producto. Cabe señalar que el/la Product
Manager asume un rol de Product Owner (PO) en un equipo que funciona en Scrum. Este rol
se menciona exclusivamente en este marco de trabajo Agile. Aunque existen contextos donde
encuentras PMs y POs, en Thiga consideramos que el término Product Manager hace referencia
al oficio, mientras que el término Product Owner se refiere al rol asumido durante la gestión de
desarrollos en Scrum.
15
INTRODUCCIÓN
El/la Product Designer (PrD) es un/a UX/UI Designer con una fuerte cultura de Producto.
Los Product Designers aplican todas las metodologías y técnicas de la Experiencia de Usuario
(UX) al servicio de la estrategia, el diseño de recorridos, la creación de interfaces y el ren-
dimiento de un producto. Los Product Designers tienen un papel clave, especialmente en las
actividades de investigación de usuario, diseño de funcionalidades y creación de interfaces.
El/la Product Marketing Manager (PMM) juega un papel fundamental en la estrategia,

aportando un profundo conocimiento del mercado y del cliente (el que compra). Es respon-
sable del posicionamiento del producto, es decir, de la adecuación entre la propuesta de valor
y la demanda del mercado. Esta función también es clave en la colaboración del equipo de
Producto con los equipos de marketing, ventas y servicio al cliente en el acompañamiento de
lanzamientos.
Cultura de Producto y cultura de Proyecto
Se distingue entre cultura de Producto y cultura de Proyecto, ya que existen diferencias

fundamentales en los enfoques. Un proyecto tiene un inicio y un final, así como un presupuesto
que se consume durante su vida útil. Por el contrario, un producto tiene un inicio, pero no
necesariamente un final. A lo largo de su ciclo de vida, el producto evoluciona. El enfoque de
Proyecto se basa en la planificación, las acciones se realizan de manera secuencial, formando
una serie de resultados predecibles. Por el contrario, un enfoque de Producto se asemeja a un
bucle (el bucle de aprendizaje) de actividades que se repiten infinitamente.
Cuando se adopta un enfoque de Producto, generalmente se integra el enfoque Agile para

entregar las funcionalidades lo más rápido posible. Recomendamos adoptar ambos enfoques
que comparten ciertos principios, incluyendo la orientación al usuario, la optimización, la
autonomía de los equipos y la mejora continua.
16
INTRODUCCIÓN
17
MÓDULO №1
1—
Establecer
el rumbo
«Los roadmaps deben

proporcionar claridad y
enfoque, ayudando al equipo
a comprender el porqué de
su trabajo y cómo contribuye
de manera más amplia a
Establecer el rumbo
la visión del Producto.»

— Bruce McCarthy
18
MÓDULO №1
El Product Management consiste en navegar en la incertidumbre,
encontrar el equilibrio entre formular una visión y permanecer flexible para
alcanzarla, y en crear productos que aporten valor tanto a los usuarios como
a la empresa. Para ello, es necesario comenzar definiendo la estrategia del
Producto, ¡es decir, establecer el rumbo!
El roadmap es la herramienta central de un equipo de Producto, ya que

permite explicar el camino a seguir para materializar la estrategia y destaca
las iniciativas en las que el equipo se concentrará en los próximos meses.
Mucho más que una lista de funcionalidades a desarrollar, el roadmap es
una herramienta poderosa de alineamiento y comunicación que te ayuda a
compartir con el resto de la organización las elecciones del equipo de Producto.
Establecer el rumbo
Para construir el roadmap, primero debes dominar el contexto en el que

se enmarca tu producto, sumergiéndote en la visión y estrategia de empresa, y
luego desglosar esa estrategia en objetivos para tu equipo, responsabilizándote
de la misión de tu equipo. Recuerda estar constantemente atento a tus usuarios
y a tus partes interesadas para detectar nuevas oportunidades que abordar.
19
MÓDULO №1
CAPÍTULO 1
Entender el contexto
del producto
Una de tus misiones como Product Manager es dominar la visión y la estrategia de tu
producto. Es importante comprender y, en ocasiones, cuestionar estos elementos que te
permiten establecer el rumbo y solidificar tus futuras decisiones de Producto.
Apropiarse de la visión y estrategia

La visión y estrategia del Producto son el resultado de una estrategia empresarial más
amplia. Estas informaciones son compartidas a los equipos de Producto más a menudo por el
Chief Product Officer, el Head of Product o por los fundadores, quienes a menudo desempeñan
este papel en startups.
La visión, motor de la motivación
La visión es el mundo ideal que se desea crear para los usuarios a mediano plazo (2 a
5 años). Centrada en los usuarios, orientada hacia el futuro e inspiradora, permite crear un
alineamiento de alto nivel entre todas las partes interesadas alrededor de la razón de ser del
producto y la definición de su éxito para los usuarios y su entorno. Con la finalidad de motivar a
los equipos, la visión cambia poco frecuentemente. Se encuentra la visión en forma de una frase
corta, simple e inspiradora que puede tomar diferentes formas, por ejemplo:
◉ Una «declaración en la que creemos », una declaración que resume las

convicciones y aspiraciones de la empresa.
Establecer el rumbo
20
MÓDULO №1
Declaración en la que creemos de Thiga Eats
« Estamos convencidos de que cada persona debe poder disfrutar de una

cocina sana y equilibrada fácilmente desde su hogar.»
◉ Una «declaración de diferenciación», una declaración que destaca las

características, ventajas o cualidades distintivas de una empresa, producto o servicio
en relación con sus competidores.
Declaración de diferenciación de Thiga Eats
Para los habitantes de grandes ciudades que no tienen ni el tiempo ni la

energía para cocinar, pero sí una conciencia de consumo responsable,
Thiga Eats es un servicio que permite recibir platos de calidad de
restaurantes y tiendas de alimentación de su barrio. A diferencia de Uber
Eats o Deliveroo, Thiga Eats ofrece una selección de calidad y garantía de
ecorresponsabilidad.
La estrategia, un marco para la ambición
La estrategia establece el marco a medio plazo (1 a 2 años) sobre cómo alcanzar la visión.
En otras palabras, la estrategia describe cómo acercarse a la visión, cómo reducir la brecha
entre la situación actual del Producto y el estado que se desea alcanzar. Richard P. Rumelt,
uno de los pensadores más influyentes en materia de estrategia y gestión, revela en su libro
Good Strategy, Bad Strategy: «El núcleo de una buena estrategia contiene tres elementos prin-
cipales: el diagnóstico de un problema, una dirección apropiada, y un conjunto de acciones
coherentes».
◉ El diagnóstico explica el “por qué”: permite una comprensión común y clara de la

Establecer el rumbo
situación actual del producto en el mercado, identificar tendencias fundamentales

y proyectar escenarios y anticipar movimientos de la competencia. El principal
problema que se desea resolver próximamente se resume en forma de desafío.
21
MÓDULO №1
◉ La dirección responde al “qué”: es el enfoque a adoptar para responder al desafío

que se plantea y describe en pocas frases cómo se vería el éxito (y el fracaso), por qué
el desafío es deseable, accesible para la empresa, pero también a qué se debe renun-
ciar para alcanzarlo.
◉ Las acciones detallan el “cómo”: forman un conjunto coherente que permite

alinear las actividades de la empresa.
La estrategia puede cambiar para tener en cuenta nuevos desafíos u oportunidades (lle-
gada de nuevos actores a tu mercado, introducción de normativas, levantamiento de rondas de
financiación, nueva iniciativa de alto valor...).
Una buena estrategia permite autonomía a los equipos, brindándoles contexto y estable-
ciendo un marco que permite que las iniciativas surjan y sean seleccionadas orgánicamente. Da
una dirección a seguir, pero también deja un margen de maniobra a los equipos.
Establecer el rumbo
22
MÓDULO №1 Establecer el rumbo
23
Estrategia Thiga Eats
MÓDULO №1
Contribuir al diagnóstico estratégico
El diagnóstico se compone de información sobre el mercado, la organización y el producto.

Como Product Manager, contribuyes de cerca o de lejos (según tu empresa, perfil, seniority,
etc.) a establecer elementos del diagnóstico con respecto al mercado y al Producto. El análisis
de la organización, que corresponde a las competencias del Head of Product, generalmente es
completado por este último.
Elementos del diagnóstico
Información sobre el mercado

El diagnóstico del Producto debe ser alimentado con información sobre el mercado,
incluyendo el análisis de tus competidores, lo que te permitirá comprender el posicionamiento
de tu producto.
Para realizar este análisis, puedes:

Establecer el rumbo
◉ Realizar un seguimiento de los productos de tus competidores

directos e indirectos. Interésate en el posicionamiento que tienen, las funcio-
nalidades que proponen y las novedades previstas, probando su producto o revisando
su roadmap si esta es pública.
24
MÓDULO №1
◉ Analizar los recursos proporcionados por los equipos de Product
Marketing (estudios de mercado, benchmark de competidores, etc.).
◉ Construir tu análisis sobre la base de los elementos recopilados.
La formalización de este diagnóstico del mercado depende a menudo del tipo de análisis
que se realice. Un formato que funciona bien es un conjunto de diapositivas que resuma las
observaciones y aprendizajes.
Información sobre el producto
También debes interesarte de cerca en tu producto. Al tomar perspectiva sobre la situación,

la historia de éxitos y fracasos, puedes proyectarte en nuevos objetivos y desafíos.
Para ello, utilice datos cuantitativos y cualitativos. Aquí tienes algunos ejemplos de activi-
dades que puedes llevar a cabo para apoyar esta evaluación:
◉ Estudiar las principales métricas de tu producto (capítulo 16).
◉ Identificar los puntos de fricción en el recorrido del usuario (tasa de abandono en

cada etapa del recorrido).
◉ Auditar tus funcionalidades (nivel de adopción, frecuencia de uso).
◉ Estudiar los comentarios de tus usuarios y extraer temas recurrentes.
◉ Analizar la satisfacción de tu producto a través de encuestas de satisfacción o comen-

tarios públicos.
Establecer el rumbo
25
MÓDULO №1
Sintetizar los elementos de

diagnóstico con DAFO
El DAFO (Debilidades, Amenazas, Fortalezas, Oportunidades) es un

framework que puede utilizarse para sintetizar estos elementos de
diagnóstico internos y externos.
El DAFO te permite enumerar las Fortalezas y Oportunidades que tienes, y

las Debilidades y Amenazas a las que te enfrentas. Te ayuda a definir una
estrategia que se base en tus ventajas competitivas y anticipa los riesgos a
los que estarás expuesto/a.
DAFO de Thiga Eats

Establecer el rumbo
26
MÓDULO №1
Nuestros consejos
◉ La visión no siempre se formaliza en forma de una frase; a veces
tendrás acceso a varios documentos que te permitirán comprender
la orientación a seguir.
◉ Si no tienes acceso a información precisa sobre la visión y la estrate-

gia, no dudes en formalizarla tú mismo. Haz preguntas a tu Product
Leader para entender mejor la dirección estratégica que debes seguir
y comparte la información con tu equipo.
◉ Tu mercado y tu Producto están en constante evolución; renueva tu

diagnóstico una o dos veces al año.
Establecer el rumbo
27
MÓDULO №1
CAPÍTULO 2
Definir una misión

y objetivos para
el equipo
Como destaca Marty Cagan, autor de Inspired: «Los buenos equipos obtienen su inspiración
de sus objetivos, de la observación de las dificultades de los clientes, del análisis de los datos que
estos clientes generan al usar su producto, y de su búsqueda constante para resolver problemas
reales mediante la tecnología». Los objetivos claros hacen a un equipo de Producto autónomo,
ayudándolo a plantearse las preguntas correctas y a tomar las decisiones adecuadas.
Misión y métricas del equipo

La misión de un equipo es su razón de ser. Estable a lo largo del tiempo, resume en unas
pocas palabras simples y comprensibles el medio por el cual el equipo contribuirá a alcanzar
la visión del Producto.
Misión de un equipo en Thiga Eats
El equipo de Activación tiene como misión llevar a nuestros nuevos usuarios

a realizar su primer pedido.
Establecer el rumbo
28
MÓDULO №1
No es necesariamente tu responsabilidad determinar la misión de tu equipo de Producto.
Estas decisiones están estrechamente vinculadas a la estructura de la organización y a menudo
son determinadas directamente por los Product Leaders. Además, si te integras a un equipo
ya establecido, este, por supuesto, ya habrá definido su ámbito de actuación. Como Product
Manager, debes encarnar esta misión en todas las decisiones que tomes e infundirla en tu
equipo. Asimismo, cuando la misión de tu equipo te sea comunicada, no dudes en cuestionarla
y hacer propuestas si algún elemento te parece poco claro.
Para evaluar en qué medida tu equipo cumple con su misión, las principales métricas
establecidas son muy útiles. En forma de una o varias métricas clave, tienes la posibilidad de
seguir el éxito a largo plazo de tu equipo. De la misma manera que la misión, estas pueden ser
comunicadas por tus Product Leaders o también puedes hacer propuestas.
Métrica clave del equipo de Activación
La métrica clave es el porcentaje de usuarios que han realizado un primer

pedido en la aplicación
Los objetivos para dirigir el impacto

del equipo
¿De dónde vienen los objetivos?
Los objetivos de un equipo deben surgir de la estrategia. Pueden ser establecidos de manera top-
down por los Product Leaders, o bien definidos de manera bottom-up por el equipo.
Sea cual sea tu contexto y punto de partida, debes centrarte en los objetivos de tu equipo para
vincularlos con tu roadmap (capítulo 4).
Establecer el rumbo
29
MÓDULO №1
Los objetivos se derivan de la estrategia
El papel de los objetivos de equipo
Los objetivos crean una dinámica colectiva y ambiciosa dentro de tu equipo. Como punto de
partida de toda iniciativa, los objetivos tienen el beneficio de:
◉ Establecer la ambición para un periodo determinado.
◉ Favorecer la alineación de las partes interesadas.
◉ Permitir la autonomía del equipo para crear el roadmap.
◉ Garantizar el enfoque de los esfuerzos del equipo en torno a las iniciativas clave.
Para establecer tus objetivos, asegúrate de tener objetivos SMART :
Specific (Específico) : procura que cada objetivo sea representativo de una aspiración
Establecer el rumbo
◉
única, clara y precisa.
◉ Measurable (Medible) : para evaluar el logro de cada objetivo a través de las iniciati-
vas que liderarás, debes asociarles medios para medirlos.
◉ Achievable (Alcanzable) : tus objetivos deben ser ambiciosos, pero realistas.

30
MÓDULO №1
◉ Relevant (Relevante) : deben estar en concordancia con el ámbito de tu equipo y la
estrategia.
◉ Time-bound (Limitado en el Tiempo) : debes establecer un límite temporal para

alcanzar tus objetivos.
Objetivo del equipo de Activación
Un objetivo SMART para el equipo de Activación podría ser, por ejemplo:

“Mejorar la precisión de las sugerencias ofrecidas a un nuevo usuario”. Se
puede medir a través de la tasa de conversión desde la lista de propuestas
de restaurantes a partir de ahora hasta septiembre.
El framework OKR
OKR, por sus siglas en inglés de Objectives and Key Results, es un método
cada vez más extendido para modelar la estrategia (de una empresa, un
producto o un equipo). Desarrollado en Intel y adoptado por Google en 1999,
se basa en dos pilares:
1. Objetivos ambiciosos e inspiradores.
2. Key Results o indicadores clave de medida del éxito, cuantificables y

limitados en el tiempo.
En una organización que utiliza el enfoque OKR en todos los niveles, los
objetivos de cada equipo son una derivación de los OKR estratégicos de la
empresa. Esto asegura que todos los equipos avancen en la misma dirección
y contribuyan en el logro de los objetivos estratégicos.
Establecer el rumbo
31
MÓDULO №1
Los OKR en diferentes niveles
Establecer y gestionar los objetivos

de tu equipo
Definir bien los objetivos
Como Product Manager, vas a definir los objetivos colaborando con tu equipo y tus líderes
de roducto. Debes centrarte en aquellos que aporten valor a los usuarios y la empresa. Una
vez identificados, tendrás que elegir para conservar solo unos pocos. Un conjunto de tres o
cuatro objetivos es adecuado para dejar un campo de acción suficientemente amplio y tener un
impacto, manteniendo el enfoque del equipo. Para ayudarte, descarta los objetivos que no estén
alineados con la visión de Producto y aquellos que no estén relacionados con la misión de tu
equipo. Asegúrate de validar estas elecciones con tus líderes de producto, quienes se encargarán
de que esto no perjudique la colaboración entre equipos o cree nuevos silos.
Establecer el rumbo
32
MÓDULO №1
Objetivo excluido por el equipo de Activación
Para nuestro equipo de Activación, descartaremos el objetivo de “permitir

a los restauradores autogestionar su incorporación de manera 100%
autónoma”, ya que no es responsabilidad del equipo, sino que será
gestionado por el equipo B2B.
Una vez fijados los objetivos, también debes definir los indicadores clave de rendimiento
(KPI) que permitan medir el valor aportado. Puedes valorar:
◉ Un impacto en la evolución de una métrica clave (impacto);
◉ El lanzamiento de una funcionalidad clave que permitirá impactar tus métricas

(lanzamiento);
◉ La adquisición de nuevos conocimientos que te ayudarán a tomar decisiones futuras

(aprendizaje).
Es importante elegir un objetivo a alcanzar para cada métrica. Así, una vez transcurrido
el tiempo asignado, bastará con evaluar si se ha alcanzado el objetivo.
KPIs del equipo de Activación
Para el objetivo de “mejorar la precisión de las sugerencias propuestas a un

nuevo usuario”, podemos fijar hasta septiembre:
◉ +25 % de conversión desde la lista de propuestas de restaurantes

(Impacto);
◉ Lanzar el módulo «sugerencia de la semana» (Lanzamiento);
◉ Evaluar el potencial de una recomendación de restaurante según el

perfil del consumidor (Aprendizaje).
Establecer el rumbo
33
MÓDULO №1
Añadir un objetivo de responsabilidad
No olvides considerar la responsabilidad de tu producto. Si piensas que

es necesario acelerar en este aspecto, añade un objetivo dedicado (por
ejemplo, “hacer el producto más accesible” o “prevenir comportamientos
negativos”).
Como menciona Fabrice Des Mazery en el libro Responsables: «Como

diseñadores de productos, somos responsables de cómo damos vida a los
productos y de sus efectos en el mundo. No podemos permitirnos ignorar el
papel que jugamos hoy en día, especialmente porque los usuarios son cada
vez más conscientes de cómo funcionan los productos que consumen».
Tus objetivos responsables también pueden enfocarse en los límites que

deseas respetar, las métricas serán entonces más bien “anti-KR” que
buscarás reducir (por ejemplo, “tiempo máximo por sesión de usuario” o
“número máximo de interrupciones de servicio por semana”...).
Cuándo definir los objetivos y reevaluarlos
Generalmente, los objetivos de la empresa se definen anualmente, y los objetivos de los

equipos se definen trimestralmente. Sin embargo, en el caso de startups que necesitan reaccio-
nar y alinear su estrategia regularmente con las evoluciones del mercado, los objetivos estraté-
gicos pueden ser revisados con más frecuencia.
Te aconsejamos revisar tus objetivos de forma trimestral para evaluar si has alcanzado tu
meta. Te encontrarás queriendo continuar trabajando en un objetivo que sigue siendo relevante
adaptando las métricas o el objetivo.
Establecer el rumbo
34
MÓDULO №1
Nuestros consejos
◉ Comparte claramente y regularmente la misión de tu equipo con todas
tus partes interesadas para reunir a tus colaboradores y avanzar jun-
tos en la dirección correcta.
◉ Para fijar una ambición de impacto, estudia la evolución de tu métrica

y propón una proyección por encima de los números que observas. Si
optas por una nueva métrica, comienza por fijar un objetivo que justi-
fique el esfuerzo que quieres dedicarle.
◉ Asegúrate de seguir los objetivos del equipo presentando los resul-

tados en rituales de equipo regulares.
Establecer el rumbo
35
MÓDULO №1
CAPÍTULO 3
Identificar
oportunidades de
Producto
Las solicitudes, las ideas, los comentarios de los usuarios, los datos... todos estos elementos
constituyen el sustrato de tu Producto. Procedentes de múltiples fuentes y llegando en distintas
formas, procesarás estas entradas para detectar nuevas oportunidades.
Identificar insights
¿Qué es un insight?
Para entender mejor cómo identificar estas oportunidades a partir de fuentes variadas,
tomémonos un momento para definir qué es un insight. Un insight ofrece una explicación
contextualizada de hechos observados, ya sean problemas o hallazgos positivos. Como destaca
Daniel Pidcock, Product Designer y teórico del Atomic Research, «es el análisis de los hechos
lo que conduce a una interpretación. Uno o varios hechos pueden conectarse para crear un
insight.»
Identificar los insights te permite tomar mejores decisiones respecto a los próximos pasos
para tu producto.
Establecer el rumbo
36
MÓDULO №1
El modelo de Atomic Research
La investigación exploratoria
Existen diferentes enfoques de investigación y recomendamos combinarlos. De hecho,
es importante considerar dos ejes de análisis. El primer eje distingue lo que la gente dice
(su actitud ante el producto) de lo que la gente hace (su comportamiento). El segundo
eje diferencia los enfoques cuantitativos (el qué) de los enfoques cualitativos (el porqué).
Las aproximaciones de investigación Establecer el rumbo
37
MÓDULO №1
Para identificar nuevos insights, puedes comenzar identificando los síntomas o los
problemas a través de la investigación cuantitativa. Esta te permite identificar tendencias. Los
datos recopilados sobre el uso de tu producto, a través del etiquetado (capítulo 17), te permiten
comprender en detalle cómo interactúan tus usuarios con tu producto. Gracias a estos datos,
puedes detectar las funcionalidades más utilizadas y aquellas que no lo son o para las cuales tus
usuarios no logran completar el recorrido esperado.
Una vez identificados los problemas, puedes buscar entender las razones mediante la
investigación cualitativa exploratoria. La investigación exploratoria implica observación
directa, encuesta profunda y análisis minucioso para desarrollar una comprensión completa de
los usuarios: quiénes son, qué les interesa, qué motiva su comportamiento y sus decisiones, etc.
Las peticiones de las partes interesadas
El departamento de Marketing, el servicio al cliente y el servicio de ventas también

pueden ser fuentes indispensables de insights, especialmente en el caso de productos B2B.
Por su proximidad con los usuarios y clientes o gracias a su experiencia en un área particular,
identifican temas y asuntos a abordar. Es imperativo que te reúnas periódicamente con todas
tus partes interesadas para tener visibilidad sobre estas cuestiones.
Además de formular prioridades estratégicas, es posible que la alta dirección presente

peticiones. Puede tratarse de un nuevo proyecto estratégico a integrar, una solución a
profundizar o una oportunidad a estudiar.
Los cambios en la legislación y las restricciones legales también generan peticiones. Estas
generalmente conducen a cambios no negociables que deben realizarse en el producto. El
departamento legal también puede hacer sugerencias para ayudarte a mejorar tus prácticas,
especialmente en términos de RGPD y cuando existe una zona gris en la legislación. No dudes
en acercarte a ellos.
Establecer el rumbo
38
MÓDULO №1
Lista de entradas del equipo de Activación
Aquí está la lista de entradas derivadas de la investigación de usuarios, los

datos del Producto y las peticiones de las partes interesadas:
Detectar oportunidades de Producto a

abordar
Categorizar entradas
Ahora que has recopilado las entradas, el desafío es distinguir los verdaderos problemas
—para los cuales puedes ofrecer una solución— de los problemas para los cuales tus usuarios
no buscan activamente una solución (o ya están cubiertos por una alternativa, y que no son
verdaderos problemas). Para ello, comienza por detectar tendencias identificando los temas que
se superponen. Las múltiples solicitudes que has recibido, así como los insights de los usuarios,
a veces pueden emanar del mismo problema de usuario, por eso es importante categorizarlos.
Establecer el rumbo
Esto también te permite diferenciar entre los comentarios aislados y los problemas más críticos.
39
MÓDULO №1
Identificar oportunidades
Gracias a la categorización de tus entradas, haces emerger una multitud de oportunidades

para tus usuarios, tus potenciales clientes y tu negocio. Aunque pueda ser tentador querer resol-
verlas todas, deberás abordar antes que nada las oportunidades que tendrán el mayor impacto
en tus objetivos, priorizándolas en el roadmap (capítulo 4).
Para identificar bien tus oportunidades, puedes utilizar un Opportunity Solution Tree
(OST), un árbol en el que las oportunidades secundarias están vinculadas a oportunidades prin-
cipales más grandes. Recomendado por la famosa conferenciante y coach Teresa Torres en su
libro Continuous Discovery Habits, la creación de este árbol permite:
◉ Comprender bien la complejidad de ciertas oportunidades y destacar las conexiones

entre ellas (algunas se parecen, son subconjuntos de una oportunidad más grande);
◉ Dividir problemas mayores, que pueden parecer insuperables, en subproblemas más

pequeños y a los cuales es más fácil responder;
◉ Entregar valor de forma iterativa, permitiéndote resolver los problemas más pequeños
que, uno por uno, te acercan a una resolución del problema matriz más amplio.
Tu árbol de oportunidades puede ser enriquecido a lo largo del tiempo, añadiendo

oportunidades mayores o suboportunidades a medida que recolectas nuevos insights.
Establecer el rumbo
40
MÓDULO №1
Opportunity Solution Tree del equipo de Activación
A partir de las entradas recopiladas, podemos construir el siguiente

Opportunity Solution Tree:
Establecer el rumbo
41
MÓDULO №1
Nuestros consejos
◉ Reúne entradas e información procedente de tu investigación en un
documento común para facilitar el análisis y el intercambio de conoci-
mientos entre los miembros del equipo.
◉ Cuando recolectes feedback, ¡no hagas una selección previa! Incluso si

los elementos recolectados no son relevantes en el momento, podrán
alimentar la detección de futuros insights.
◉ Para animar a tus partes interesadas a presentar solicitudes de forma

regular, asegúrate de darles visibilidad sobre el seguimiento de sus
temas.
Establecer el rumbo
42
MÓDULO №1 Establecer el rumbo
43
MÓDULO №1
CAPÍTULO 4
Crear
el roadmap
El roadmap, documento estrella de los equipos de producto, es a menudo el centro de sus
preocupaciones. Literalmente “hoja de ruta”, sirve para organizar los pasos que hay que dar a
lo largo del tiempo para convertir la estrategia en realidad. Como explica Bruce Mccarthy en
su libro Product Roadmap Relaunched, «una hoja de ruta no es una lista de características
que se quieren implementar, sino una herramienta de comunicación estratégica que crea una
comprensión compartida del impacto que se quiere tener».
El roadmap, una herramienta estratégica

Un roadmap permite ilustrar el camino que tomarás para alcanzar tus objetivos (capítulo
2). Todo roadmap se compone de tres elementos indispensables: una escala de tiempo, objetivos
y, finalmente, iniciativas vinculadas a estos objetivos y priorizadas en la escala de tiempo.
La escala de tiempo
Es importante que el roadmap se mantenga a un nivel alto, ya que no es un calendario de

fechas precisas detallando las funcionalidades que van a ser desarrolladas. Sin embargo, si ya
conoces la fecha de un hito comercial importante (lanzamiento de una campaña de marketing,
apertura de las ventas para Navidad o entrada en vigor de una nueva regulación, por ejemplo),
puedes hacerla aparecer en una anotación para tenerla presente. Así, el roadmap se representa
generalmente bajo el formato Ahora, Siguiente, Después:
Ahora representa el horizonte más cercano. Puede tratarse, según tu organización,

Establecer el rumbo
◉
de un trimestre, un ciclo de X días, semanas o meses. Aquí agrupas las iniciativas más
prioritarias.
◉ Siguiente representa el próximo ciclo. Generalmente de una duración idéntica

a Ahora, agrupa las iniciativas ya priorizadas, aunque menos prioritarias que las
44
MÓDULO №1
anteriores. El nivel de prioridad de estos elementos puede cambiar de aquí al final
del ciclo en curso.
◉ Después agrupa el conjunto de iniciativas interesantes, pero que no son prioritarias

por el momento. No se trata de añadir todas las iniciativas mencionadas a lo largo del
tiempo, sino de hacer una selección para conservar sólo aquellas que detectes con un
potencial interesante. Aquí también, el nivel de prioridad será revisado regularmente.
Los objetivos
El roadmap está orientado a un Outcome (impacto) y no a Output (producción).

Las iniciativas de Ahora deben necesariamente estar vinculadas a tus objetivos (capítulo 2)
asegurándote de que esto sea claramente visible en el roadmap (por ejemplo, mediante la
elección de un código de colores visual). Puede ser que las iniciativas de Después aún no estén
vinculadas a objetivos, por eso no son prioritarias.
Diferentes formatos de roadmap
Objetivos en línea
Establecer el rumbo
45
MÓDULO №1
Objetivos en columnas
Objetivos por colores

Establecer el rumbo
46
MÓDULO №1
Las iniciativas
Las iniciativas representan los temas del equipo y pueden presentarse en forma de:
◉ Oportunidades, para las cuales será necesario primero pasar por una fase de
descubrimiento (Módulo 2);
◉ Funcionalidades, que ya han pasado por la fase de descubrimiento y pueden avan-

zar a delivery (Módulo 3).
Un soporte visual y accesible
Para facilitar los intercambios, el formato del roadmap es importante para que esta sea accesible,
legible y fácilmente comprensible. Se pueden considerar varios soportes, pero recomendamos
priorizar una representación gráfica simplificada.
Hoy en día existen numerosas herramientas que permiten modelar un roadmap: un tablero
en Notion, Miro, diapositivas o incluso utilizando herramientas como Productboard. A
continuación, hemos presentado algunos ejemplos de cómo formatear un roadmap:
Establecer el rumbo
47
MÓDULO №1
Roadmap del equipo de Activación realizado en Notion

Establecer el rumbo
48
MÓDULO №1
Plan de trabajo del equipo de Activación realizado en Miro
Establecer el rumbo
49
MÓDULO №1
Crear y compartir tu roadmap

Para cumplir con su función, el roadmap debe ser cocreada, compartida y comunicada
regularmente.
Elaborar el roadmap con las partes interesadas
Un roadmap es, ante todo, un objeto de conversación que permite alinear a todos los
interlocutores en torno a prioridades comunes. Para que sea aceptada, debe ser el resultado de
discusiones e investigaciones conjuntas con tus partes interesadas.
Para crear tu roadmap, previamente has recopilado toda la información necesaria, como
tus objetivos (capítulo 2), las oportunidades (capítulo 3), las funcionalidades importantes y
cualquier otra información relacionada con hitos importantes, restricciones, dependencias,
etc. Con todo este material, podrás organizar tu roadmap identificando las iniciativas más
prioritarias (capítulo 9).
Puedes realizar un primer borrador de tu roadmap y presentarlo a tus partes interesadas

para asegurarte de que todos estén alineados con las prioridades del próximo ciclo, o bien
organizar un taller de roadmapping para priorizar tu roadmap en sesión.
Una vez fijadas tus elecciones, es importante presentar tu roadmap a los tomadores de
decisiones (tus Líderes de Producto, posiblemente los responsables de departamentos en tu
organización) para que estos puedan asegurarse de que los roadmaps de los diferentes equipos
estén bien alineadas y en acuerdo con la estrategia.
Hablar regularmente de tu roadmap
El roadmap a veces se publica de manera confidencial o puntual. Esto es un error, ya que

debe ser una herramienta constante de alineación para los colaboradores. Desde su construc-
ción con las partes interesadas, durante su publicación y hasta que se publique una nueva
edición, es conveniente evangelizar sobre su evolución. Esto implica, en particular, comunicar
regularmente sobre los impactos alcanzados, los cambios de prioridades, las novedades, etc.
Establecer el rumbo
50
MÓDULO №1
Como Product Manager, tu rol es educar a las partes interesadas, recordándoles que el
roadmap representa lo que es prioritario en un momento dado y en función de la información
disponible. Si un elemento no figura en el roadmap o se identifica como no prioritario, esto no
significa que la iniciativa nunca se considerará. Simplemente, explica que el enfoque del período
actual se centra en otros temas. Para gestionar mejor las expectativas, sé firme y transparente
sobre las prioridades actuales, pero invita a las partes interesadas a replantear la pregunta en los
próximos talleres de priorización. Para facilitar esta comunicación, aprovecha los momentos
de intercambio entre el equipo o con tus partes interesadas para hacer recordatorios. No dudes
en presentar cifras clave sobre el progreso y la consecución de objetivos, por ejemplo, durante
tus revisiones (capítulo 11).
Posicionarte como responsable del roadmap
A lo largo de tu carrera, probablemente te enfrentarás varias veces a roadmaps que estás

a cargo de ejecutar, pero en las que no has contribuido a definir. Este es el caso si te unes a
una organización en la que el roadmap se definió antes de tu llegada o si evolucionas en una
organización en la que el roadmap es definida por los líderes de Producto.
Independientemente de la situación en la que te encuentres, nunca olvides que eres el

responsable del roadmap de tu equipo. Debes ser capaz de presentarlo y conocer su contenido a
la perfección. Sea cual sea el caso, debes hacerlo tuyo y, en la medida de lo posible, cuestionarlo.
Si hay algo que no entiendes o si tienes dudas sobre la priorización de ciertos elementos en
comparación con otros (cuando te familiarizas con un nuevo contexto, por ejemplo), no dudes
en consultar a tus líderes de Producto o a tus partes interesadas. También debes colaborar con
tu equipo para determinar qué puedes entregar y qué desafíos debes posponer. Recuerda que un
roadmap debe ser cocreado, así que quienes te rodean están en la mejor posición para ayudarte
a cuestionar la priorización preestablecida.
Establecer el rumbo
51
MÓDULO №1
Nuestros consejos
◉ Si surge una oportunidad no priorizada en tu roadmap durante el
período, haz las preguntas correctas antes de integrarla en tu roadmap.
¿Contribuye la oportunidad al logro de los objetivos establecidos? ¿Qué
oportunidad debes despriorizar en su lugar?
◉ Cambiar con demasiada frecuencia de prioridades puede tener rápi-

damente consecuencias significativas en tu capacidad para entregar
valor, pero también en la motivación del equipo. Recuerda estos riesgos
a tus partes interesadas si son la iniciativa de numerosas solicitudes.
◉ Si deseas confrontar tu roadmap con tus usuarios, puedes hacerla

pública, en su formato original o en una versión simplificada. Así
podrás recoger comentarios y obtener información útil para nutrir
tus próximos ciclos.
Establecer el rumbo
52
MÓDULO №1
Lo esencial
de este módulo
1. La visión y la estrategia son los fundamentos de sus futuras decisiones sobre

productos.
2. Como Product Manager, puedes contribuir a la estrategia ayudando a diagnosticar el

mercado, los competidores y el propio producto.
3. Para comprender plenamente el contexto y los problemas que rodean a tu producto,

debes consultar a los líderes de tu organización.
4. Define la contribución de tu equipo a los objetivos generales de la empresa, definiendo

su misión y sus objetivos.
5. Tus objetivos deben ser limitados en el tiempo, medibles y acompañados de una meta
clara.
6. Recoge regularmente nuevas peticiones de tus interlocutores, identifica nuevos

puntos de vista para detectar oportunidades para tu producto.
7. Las oportunidades, tu misión y tus objetivos son los cimientos de tu roadmap.
8. El roadmap es una intención de alcanzar tus objetivos, una representación gráfica de

tu estrategia y, sobre todo, un soporte para la alineación.
9. El roadmap se construye conjuntamente con las partes interesadas y se comparte

periódicamente para reorientar el rumbo.
Establecer el rumbo
53
2—
Entender el
problema
y elegir la
solución
««El descubrimiento (discovery

en inglés) es una disciplina
clave para reducir los riesgos
y maximizar las posibilidades
de éxito de un producto.»
— Teresa Torres
54
MÓDULO №2
Una de las áreas clave del Product Management consiste en entender
las necesidades de los usuarios y tomar decisiones informadas para crear los
mejores productos, eso es lo que llamamos discovery. En otras palabras, el
discovery es un proceso de reducción de riesgos que, a través de un contacto
Entender el problema y elegir la solución
regular con los usuarios, talleres y herramientas adecuadas, permite definir la

mejor solución para satisfacer la necesidad de los usuarios.
En este módulo, repasaremos los principios fundamentales del discovery,

antes de profundizar en cómo entender el problema, diseñar la solución y
probarla con los usuarios. También veremos cómo tomar decisiones a lo largo
del proceso mediante métodos de priorización adecuados.
55
MÓDULO №2
CAPÍTULO 5
Comprender el
discovery
El discovery comprende una serie de actividades que nos permiten entender el
comportamiento de los usuarios, identificar sus problemas y necesidades, diseñar las soluciones
más adecuadas y eficaces y ponerlas a prueba. El discovery es esencial porque contribuye
a limitar el riesgo de fracaso, ayudando a los equipos a decidir cuál debe ser el producto a
construir.
¿Por qué realizar el discovery?

El discovery consiste en entender el problema que hay que resolver (descubrimiento del
problema) y diseñar la solución para resolverlo (descubrimiento de la solución). Teresa Torres,
autora del libro Continuous Discovery Habits, describe el discovery como «un proceso de toma
de decisiones que tiene en cuenta al usuario en todo momento». El objetivo es descubrir los
problemas antes de tomar la decisión de empezar a desarrollar.
Es importante asegurarse de poder responder algunas preguntas fundamentales:
◉ ¿Por qué es importante este problema?

◉ ¿A quién afecta?
◉ ¿Cómo puedes convencer al público objetivo?
◉ ¿Cuándo debe realizarse?
◉ ¿En qué consiste la solución?
No esperes a tener tiempo suficiente o las herramientas perfectas para ponerte manos a
la obra. ¡Más vale poco que nada! Formularte estas pocas preguntas ya te proporcionará infor-
mación valiosa.
56
MÓDULO №2
Gestión del proceso de discovery
El Lean Canvas para plantear hipótesis
El Lean Canvas, desarrollado por Ash Maurya, es una plantilla interesante para plantear
las hipótesis que se verificarán durante el discovery. El Lean Canvas aborda temas orientados
al producto o al mercado:
◉ Segmentos de usuarios: ¿Cuál es el público objetivo de tu producto? ¿Quiénes

son tus posibles primeros usuarios?
◉ El problema y las alternativas : ¿Cuáles son los 3 principales problemas que

intentas resolver para tus potenciales primeros usuarios? ¿Y cuáles son las soluciones
existentes (alternativas) que ofrecen hoy una respuesta completa o parcial a esos
problemas?
◉ La propuesta de valor única:la propuesta de valor es la razón por la que

tus clientes potenciales deberían convertirse en usuarios. ¿Cómo resuelves sus
problemas?
◉ Soluciones : ¿cuáles son las tres características principales que resolverán los pro-
blemas de tus early adopters?
◉ Canales : ¿cuáles son los canales que puedes utilizar para llegar a tus futuros
usuarios?
◉ Métricas : ¿qué métricas medirás para validar o invalidar tus hipótesis?
◉ Costes : ¿cuáles son los costes fijos y variables?

◉ Ingresos : ¿cuál es el modelo de negocio? ¿Cómo vas a ganar dinero?
◉ Ventajas competitivas : qué te hace más eficaz que los demás para resolver los
problemas que has identificado (conocimientos técnicos, red de contactos, marca,
etc.).
Descarga la plantilla Lean Canvas
57
MÓDULO №2
El doble diamante para pensar el problema y la solución
Design Thinking es un enfoque iterativo y empático para generar nuevas ideas y resolver
problemas. A menudo representado en forma de doble diamante, el enfoque tiene una parte para
el problema y otra para la solución. Cada diamante se divide en dos fases: una de divergencia y
otra de convergencia.
El doble diamante
El primer diamante, o diamante del problema, reúne todas las actividades implicadas en la
exploración y definición del problema del usuario que intentamos resolver. Comienza con una
fase de divergencia, que consiste en recopilar toda la información posible mediante entrevistas,
observaciones e inmersiones (capítulo 6). Le sigue una fase de convergencia, en la que se reduce
el campo de posibilidades al problema que el producto tendrá que resolver. No podrás resolver
todos los problemas planteados, por lo que tendrás que hacer elecciones y tomar decisiones en
esta fase antes de poder pasar al segundo diamante.
El segundo diamante, o diamante de la solución, reúne todas las actividades de ideación

y diseño (capítulo 7) que te permiten identificar la solución al problema elegido. Una vez más,
tendrás que trabajar en una fase de divergencia para explorar todas las posibles soluciones al
problema, antes de converger en la solución que luego podrás probar con sus usuarios. Y una
vez más, tendrás que tomar decisiones.
¿Y si no funciona? Tendrás que empezar de nuevo.
58
MÓDULO №2
Discovery Discipline para la claridad y la alineación
Además del conocido enfoque del doble diamante, existen otros métodos como el pro-
puesto por Tristan Charvillat y Rémi Guyot en su libro Discovery Discipline. Partiendo de la
constatación de que el doble diamante era un buen punto de partida -pero no suficientemente
preciso- y de que “tomar decisiones sigue siendo la actividad más importante y más compli-
cada, porque siempre es más cómodo divergir que converger”, Tristan y Rémi crearon una meto-
dología basada en siete pasos: F.O.C.U.S.E.D.:
◉ (Frame) Enmarcar para definir la ambición del proyecto de discovery;
◉ (Observe) Observar para identificar el caso de uso principal que hay que estudiar;
◉ (Claim) Reclamar para imaginar rápidamente un posicionamiento de la funcionalidad;
◉ (Unfold) Desplegar para seleccionar los momentos clave de la experiencia que hay
que abordar;
◉ (Steal) Robar para reutilizar las soluciones existentes que funcionan;
◉ (Execute) Ejecutar para ensamblar y construir una solución funcional pertinente;
◉ (Decide) Decidir, para evaluar la calidad de la solución y decidir si desarrollarla o no.
El marco de trabajo F.O.C.U.S.E.D
Frame Observe Claim Unfold Steal Execute Decide

El método, que se ha probado en PayPal y se ha adoptado en BlaBlaCar, pretende ofrecer un

marco claro para la toma de decisiones. Puede aplicarse a distintas organizaciones, distintos
equipos y todo tipo de iniciativas. La fuerza de este marco sistemático y sintetizado nos permite
lograr un impacto cada vez mayor.
59
MÓDULO №2
Iniciarse en el discovery
Define tus necesidades de discovery
Antes de lanzarse al discovery, decide el nivel de inversión que debes asignar en función
de la madurez del tema, el nivel de ambición, el riesgo que estás dispuesto a asumir y el tiempo
de que dispones. ¿Dispones de conocimientos que te ayuden? ¿Buscas duplicar el uso de una
funcionalidad o simplemente mejorar la tasa de retención en un pequeño porcentaje? ¿Hasta
dónde estás dispuesto a degradar la experiencia del usuario para lanzar un nuevo tema?
¿Cuánto tiempo tienes para dedicarle?
Una vez hecho esto, identifica las actividades que hay que poner en marcha utilizando una
matriz de madurez:
◉ El problema está claro y el riesgo es bajo: puedes desarrollar la solución

directamente y medir el impacto en producción;
◉ El problema está claro, pero el riesgo es alto: hay que centrarse en el

descubrimiento de la solución (capítulo 7);
◉ El problema no está claramente identificado y el riesgo es bajo: lleva

a cabo una breve fase de descubrimiento del Problema que te ayude a clarificarlo y a
empezar a pensar rápidamente en la solución (capítulo 6);
◉ El problema no está claramente identificado y el riesgo es alto: lleva a

cabo una fase de discovery avanzada.
60
MÓDULO №2
Matriz de madurez para los
miembros del equipo de activación
Realizar el discovery en equipo

El discovery es esencial para identificar el problema y las soluciones adecuadas. Puede
parecer una tarea desalentadora, pero puedes estar seguro de que en muchos casos no tendrás
que hacerlo solo. Llevarás a cabo las numerosas actividades de discovery con el apoyo de los
diseñadores de productos y/o investigadores de UX (de tu equipo o de la organización). Puedes

dividir las actividades en función de tus habilidades y aptitudes. No importa cuál de los Product
Managers o Product Designers esté más implicado, lo más importante es que las actividades se
lleven a cabo correctamente y que los resultados se compartan con el resto del equipo.
Además de los Product Designers, otros perfiles también pueden ayudarte a tomar las
decisiones necesarias a lo largo del proceso de discovery. No dudes en recurrir a tu Responsable
Técnico y a tu Responsable de Marketing de Producto para que te ayuden a tomar decisiones.
Sus conocimientos te permitirán ampliar tu visión y asegurar que tienes debidamente en
cuenta las cuestiones empresariales, las necesidades de los usuarios y las limitaciones técnicas.
61
MÓDULO №2
Nuestro consejo
◉ Si tienes poco tiempo, pregúntate qué tipo de discovery podrías hacer
con el tiempo que dispones.
◉ Acuérdate de documentar tus descubrimientos a medida que avanzas,

utilizando documentos de síntesis.
◉ El discovery no es una validación científica. Aunque hayas reducido la

incertidumbre, debes confiar en tus convicciones y probar funcionali-
dades con los usuarios para medir su impacto.
◉ Si las partes interesadas se muestran reacias a perder tiempo en el dis-

covery, recuérdales que resulta muy costoso desarrollar una solución
que no satisfaga las necesidades de los usuarios. Invertir en discovery
reduce este riesgo.
62
MÓDULO №2 Entender el problema y elegir la solución
63
MÓDULO №2
CAPÍTULO 6
Profundizar en los
problemas de los
usuarios
Descubrir oportunidades requiere que comprendas, profundices y definas los problemas de
los usuarios. Con un enfoque centrado en el usuario, se trata de procesar la información para
comprender su vida cotidiana, su contexto y averiguar qué necesitan antes de crear soluciones.
Comprender los problemas
Entrevistas con los usuarios
Las entrevistas son una buena forma de recopilar información cualitativa que te permitirá
conocer mejor los problemas de los usuarios. Antes de llevar a cabo estas entrevistas, hay que
crear un panel basado en criterios de elegibilidad o exclusión. Hay varias formas de formar este
panel:
◉ Pregunta a personas de tu entorno, amigos y colegas. La prueba de

amigos y familiares es una forma sencilla de ahorrar tiempo. Sin embargo, es arries-
gada porque tiene muchos sesgos. Tu círculo cercano no es necesariamente represen-
tativo de tus usuarios objetivo.
◉ Busque usuarios potenciales allí donde estén: redes sociales, sitios web
especializados, ferias o incluso en una estación de tren o una cafetería...
◉ Recurre a empresas especializadas en la captación de perfiles.Estas

soluciones son extremadamente eficaces y, aunque cuestan dinero, te permiten reunir
un conjunto que corresponde a un objetivo preciso.
64
MÓDULO №2
Una vez que hayas reclutado a tu panel, prepara tu guía de entrevista y organiza las
entrevistas individuales. Si eres nuevo en esto, puedes construir y seguir un guión de entrevista
como el que sugiere el speaker internacional Ash Maurya en Running Lean. El guión te permitirá
comparar tu visión de los problemas con el de los entrevistados e identificar las soluciones
existentes que puedan estar utilizando.
Durante una entrevista, no intentes vender tu producto, ¡estás allí para aprender! Repasa
cada problema e intenta evaluar su importancia para el posible cliente, prestando atención a
los siguientes inconvenientes:
◉ Si un entrevistado te dice que se encuentra regularmente con un problema

grave, pero no busca activamente una solución, quizá esté exagerando la magnitud
del problema, inconscientemente o no, para complacerte.
◉ No generalices demasiado rápido: las entrevistas con los usuarios te dan

señales, pero solo los datos cuantitativos pueden evaluar el comportamiento de todos
tus usuarios.
Complementar con observación, inmersión e investigación

cuantitativa
Las entrevistas con usuarios ayudan a recopilar información valiosa, pero es importante
tener en cuenta que lo que dicen los usuarios en las entrevistas no siempre se corresponde
exactamente con lo que hacen en la realidad.
Por eso es buena idea complementar las entrevistas con la observación para analizar el
comportamiento y el contexto del público objetivo. Por ejemplo, te recomendamos que pases
un día con el equipo de atención al cliente o sobre el terreno con los usuarios. Es una forma
sencilla de recabar opiniones.
La inmersión también es una buena forma de sumergirse en la experiencia de tus usuarios.

Prueba tú mismo el producto en una situación real, lo que te facilitará la detección de proble-
mas relacionados con el contexto en el que se utiliza.
Por último, puedes respaldar tus hipótesis con datos cuantitativos. Analizando tu producto,
puedes completar tu comprensión de los problemas con datos de uso. También puedes pedir
a los usuarios que den su opinión sobre los problemas que has detectado en las entrevistas
enviando un cuestionario a un grupo objetivo más amplio. Las estadísticas cuantitativas son
una buena forma de complementar tu aprendizaje.
65
MÓDULO №2
Formalizar los aprendizajes

Una vez identificada toda la información, puedes extraer y formalizar las lecciones
aprendidas para resumir los puntos esenciales. Para ello existen varias herramientas.
User Persona
Un User Persona es un usuario ficticio típico, basado en datos de usuarios, cuyos objetivos
y motivaciones se pretende representar y resumir. Para crear un User Persona se utilizan los
datos representativos de los usuarios, recogidos mediante entrevistas y observaciones. Se
pueden formalizar distintos tipos de User Persona:
◉ User Persona principal : la persona para la que se diseña el producto y cuyas

necesidades y objetivos se deben satisfacer.
◉ User Persona secundario : la persona que comparte las mismas necesidades

y objetivos que la persona principal, pero que, sin embargo, tiene características
propias que no son prioritarias.
◉ User Persona negativo (o antipersona): la que representa a un no usuario, que no

es nuestro objetivo y al que el producto decepcionará.
Los User Persona permiten comprender mejor al público objetivo y los problemas a los
que se enfrentan. Facilitan el acceso a la información sobre los usuarios y ayudan a tomar las
decisiones correctas durante los talleres de diseño.
66
MÓDULO №2
El User Persona simplificado
(plantilla para descargar p.73)
Pero cuidado, los User Persona tienen el inconveniente de ser un poco estáticas y a veces
incluso caricaturescos. Como señala Fabrice Des Mazery en su libro Responsables, las personas
pueden convertirse rápidamente en estereotipos determinados por prejuicios y cargados de

detalles inútiles para la toma de decisiones. Para evitar este uso nocivo, hay que recordar que los
usuarios tienen experiencias dinámicas y motivaciones que son contextuales, es decir, pueden
querer algo en un contexto y estar completamente en contra en otro. Por eso, la persona debe
combinarse con otras representaciones, como los user journeys o los mapas de experiencias,
para ilustrar sus diferentes motivaciones, emociones y actitudes en distintos momentos de su
vida.
67
MÓDULO №2
El mapa de empatía
El mapa de empatía es una herramienta de colaboración para visualizar lo que sabes sobre
una categoría de usuarios de tu producto. El objetivo es compartir una visión común de las
necesidades de los usuarios.
Puedes utilizarlo durante tus sesiones de observación o en un taller para resumir los
resultados de la investigación de usuarios. Se compone de cuatro cuadrantes:
◉ Lo que dice el usuario: aquí se enumeran sus expresiones, es decir, lo que el

usuario dice en voz alta;
◉ Lo que el usuario piensa: aquí prestas especial atención a lo que el usuario no

expresa directamente (por timidez o educación, por ejemplo);
◉ Lo que hace el usuario: este cuadrante representa sus acciones;
◉ Lo que siente el usuario: aquí detallas su estado emocional utilizando adjetivos

o frases cortas (¿qué le preocupa?, ¿le sorprende?, ¿le emociona?).
68
MÓDULO №2
El mapa de empatía
(descargar plantilla p.73)
El mapa de empatía puede utilizarse como apoyo a la investigación de usuarios, en

particular para tomar notas durante tus sesiones de observación sobre el terreno, o en talleres
internos con tus interlocutores para compartir la comprensión del objetivo. En este caso, el
mapa de empatía servirá de base para crear las personas.
El mapa de experiencias
El mapa de experiencia visualiza la experiencia global de un usuario que quiere alcanzar un

objetivo. No se limita al uso de su producto en particular, sino que describe en orden cronológico
todas las etapas y comportamientos del usuario a lo largo de su recorrido.
69
Experiencia de usuario de Thiga Eats
70
MÓDULO №2
Una vez identificadas las distintas etapas, el mapa de experiencia puede utilizarse para
poner de relieve el comportamiento del usuario en cada una de ellas, así como los puntos
débiles y las oportunidades de mejora de la experiencia.
Descarga la plantilla de persona, mapa de empatía y mapa

de experiencia.
Aclarar el problema
¿Has explorado los problemas y formalizado los aprendizajes? El siguiente paso es describir
estos problemas de forma sencilla para poder enmarcar la búsqueda de una solución. Para ello,
te sugerimos que utilices la frase “¿Cómo podríamos…?” Esta formulación es lo suficientemente
amplia como para no influir en la elección de la solución y centrarse en el resultado esperado
por el usuario. Ante todo, la especificación del problema debe:
◉ No presuponer una solución.
◉ Hacer hincapié en el problema que se pretende resolver.
◉ Especificar el usuario objetivo.
Un problema identificado por el equipo de Activación

El problema puede formularse así: «¿Cómo podríamos reducir los residuos

generados por un pedido?»
71
MÓDULO №2
Nuestro consejo
◉ Antes de embarcarte en actividades de discovery para explorar un
problema, comprueba que el tema no haya sido estudiado ya por otro
equipo y revisa los conocimientos disponibles en relación con el tema.
◉ En las entrevistas con los usuarios, es preferible plantear preguntas

abiertas que empiecen por «qué», «quién», «cuándo», «para qué» o
«cómo», para no influir en las respuestas.
◉ Para que no te olvides de tus personas una vez creadas, utilízalos en

cada taller y sesión de feedback para introducir los temas.
72
73
MÓDULO №2
CAPÍTULO 7
Imaginar, diseñar y
elegir soluciones
En Design Thinking, la generación de un gran número de soluciones innovadoras a un
problema dado se facilita mediante el uso de talleres. Se basan en la convicción de que la
inteligencia colectiva, frente al diseño aislado, es la mejor manera de hacer surgir soluciones
relevantes e innovadoras. Sobre estas bases se pretende sacar a la luz soluciones a tus problemas
específicos.
Talleres de ideación y codiseño
Talleres de ideación
Un taller de ideación es una actividad dedicada a generar nuevas ideas en respuesta a

un problema planteado en un contexto específico. El objetivo es generar el mayor número
posible de ideas para solucionar el problema planteado. Para ello, hay que partir del problema,
formulado como un «¿cómo podríamos...?» (capítulo 6) y utilizar distintos métodos y técnicas
para generar ideas.
74
MÓDULO №2
Tema de un taller de ideación del equipo de Activación
« ¿Cómo podríamos reducir los residuos generados por un pedido? »
He aquí algunos ejemplos de talleres de ideación:
Lluvia de ideas
La lluvia de ideas (brainstorming en inglés) es un taller de grupo utilizado para generar el

mayor número posible de ideas en torno a un tema en un tiempo limitado. Implica un proceso de
reflexión libre y espontáneo en el que se anima a todos los miembros del grupo a proponer ideas, en
un entorno colaborativo y abierto.
Este taller es fácil de organizar y suele ser un buen punto de partida para la ideación. Pero hay
que tener en cuenta algunas reglas clave que tranquilizarán a los participantes y garantizarán el éxito
del taller. Antes de empezar, conviene recordar los siguientes puntos:
◉ Abstente de juzgar: deja que todos se expresen sin juzgar las ideas que surjan, para
no restringir lo que la gente puede decir.
◉ Fomenta las ideas excéntricas: no pongas límites a la creatividad, haga caso

omiso de las limitaciones técnicas o del posible coste de las soluciones propuestas.
◉ Céntrate en el tema: procura que el taller no se desvíe en todas direcciones, mante-

niendo el foco en el tema principal.
◉ Aprovecha las ideas de los demás: ten en cuenta las ideas de los demás e
incorpóralas a tu propio pensamiento. Esto refuerza la colaboración y la creatividad.
◉ Distribuye la palabra: una conversación cada vez, anima a los participantes a

dejar hablar y a escucharse.
◉ Busca la cantidad: el objetivo es que surja el mayor número posible de ideas. La

fase de convergencia permitirá después elegir entre esas ideas.
◉ Sé visual: si trabajas cara a cara, utiliza post-it y una pizarra. Si trabajas a distancia,
asegúrate de utilizar una herramienta de colaboración para registrar las distintas
ideas.
75
MÓDULO №2
Mapa de impacto
Los mapas de impacto son un formato fácil de conciliar con un enfoque orientado a
objetivos. Inventado por Gojko Adzic, el mapa de impacto anima a los participantes a
centrarse en identificar características que ayuden a alcanzar un objetivo bien definido.
Para ello, tendrás que decidir antes del taller en qué objetivo quieres centrarte. Durante
el taller:
1. Junto con los participantes, rellena los impactos, es decir, los

comportamientos esperados de las distintas partes interesadas y las conductas que
deseas generar.
2. Completa las iniciativas que deben ponerse en marcha para

generar estos comportamientos. Esto te permitirá identificar claramente
sus funcionalidades.
3. Al final del taller, prioriza las iniciativas y funcionalidades con tus parti-
cipantes asignándoles un indicador de impacto (alto, medio, bajo).
76
77
Impact Mapping del Equipo de Activación
MÓDULO №2
Talleres de codiseño
Estos talleres permiten concretar más una idea, en forma de recorridos, pantallas, soportes,
etc. Pueden consistir en analizar la necesidad y, por tanto, definir funcionalidades, o en crear
maquetas.
Tema de un taller de codiseño

del equipo de Activación
“¿Cómo podríamos destacar las ofertas ecorresponsables en la lista de

resultados?”
He aquí algunos talleres de codiseño:
User Story Mapping
Este formato de taller es muy adecuado para la creación de un nuevo producto y también
puede utilizarse para diseñar una nueva funcionalidad bastante compleja. El user story
mapping ayuda a contextualizar las funcionalidades en relación con el recorrido del usuario y a
priorizar las ideas. Al final de este taller, será capaz de dibujar una primera versión realista de
su producto o funcionalidad. En una o varias sesiones:
1. Sitúa todas las etapas del recorrido del usuario en el eje horizontal. Si tienes varias
personas, crea un user story map por persona para reflejar los diferentes recorridos
2. Los participantes imaginan y discuten las funcionalidades para cada etapa, ignorando
cualquier restricción.
3. A continuación, ordenan las distintas funcionalidades en función de su prioridad,

hasta converger en una versión que incluya únicamente las funcionalidades
necesarias para responder a su problema.
Descarga tu plantilla de user story map.
78
MÓDULO №2
Story map «Proponer resultados en función de dónde
me encuentre»
79
MÓDULO №2
Card sorting
El card sorting es un método para construir la arquitectura de la información de un sitio o

aplicación, con la participación de sus usuarios. Su objetivo es clasificar el contenido de un pro-
ducto según una estructura coherente y rápidamente comprensible para los usuarios.
El método de card sorting consta de tres etapas:
1. Inventario de todas las características y contenidos del producto: cada

una de estas características se traza en una tarjeta. Las tarjetas pueden presentarse en
papel o introducirse en una herramienta en línea.
2. Presentación de las tarjetas a los usuarios :se les pide que agrupen las distin-
tas tarjetas en grupos coherentes según tu punto de vista.
3. Análisis de los resultados: al final del taller, los resultados se analizan manual-
mente o en línea con la herramienta utilizada.
Hay que señalar, no obstante, que el card sorting no define una arquitectura de la información
definitiva. Proporciona una base que debe completarse en función de la estrategia del producto,
las limitaciones técnicas y los requisitos de usabilidad.
80
MÓDULO №2
Organización de los talleres
Para preparar y llevar a cabo estos talleres, trabajarás codo con codo con Product
Designers. Juntos debéis definir las funciones y responsabilidades de cada uno para una organi-
zación óptima: ¿Quién prepara el taller? ¿Quién lo dirige? ¿Quién facilita los debates?
Elegir a los participantes
Para preparar bien un taller, primero hay que elegir bien a los participantes. Un grupo
multidisciplinar te aportará un abanico más rico de ideas. En función del tema, puedes implicar
a representantes de la voz del usuario (customer success, servicio de atención al cliente, etc.),
representantes del cliente (equipo de ventas, marketing), expertos en el tema en cuestión (legal,
datos, etc.) o incluso perfiles técnicos (desarrolladores).
En la medida de lo posible, recomendamos no involucrar a los líderes, ya que su presencia

puede influir en los participantes (autocensura, por ejemplo). Si los altos directivos desean
realmente contribuir a los talleres, pídeles que participen en la sesión introductoria para
explicar lo que está en juego. También puedes pedirles que lean los resultados al final del taller.
Preparar y dirigir el taller
Antes del taller, comunica el objetivo y el orden del día. Esto permitirá a los participantes
planificar y preparar los elementos con antelación. Si participan personas que no están familia-
rizadas con las prácticas de producto, dedica tiempo a explicar los principios fundamentales del
discovery. También es una buena forma de demostrar el valor del taller en cuestión para garanti-
zar su participación constructiva.
Durante el taller, recuerda:

1. Empezar presentando el contexto y el problema que hay que resolver;
2. Cronometrar las diferentes secuencias y mantener el ritmo para que el taller termine
con un resultado concreto;
3. Dar las gracias a los participantes al final del taller por su tiempo y energía. Comunicar
el acta y los próximos pasos.
81
MÓDULO №2
¿Taller presencial o a distancia?
Los talleres cara a cara facilitan el intercambio de puntos de vista y el

desarrollo de nuevas ideas (durante el taller y en los descansos). Por otro
lado, se pierde tiempo después del taller en transcribir los resultados.
Con la formación a distancia, los introvertidos pueden sentirse más a

gusto y los extrovertidos pueden ser más inclusivos. Pero también genera
fricciones por problemas de conexión o de acceso a las herramientas.
En todos los casos, se recomienda evitar los formatos mixtos en los que una
parte de los participantes es presencial y la otra a distancia, para garantizar
el buen desarrollo del taller.
Seleccionar las soluciones que se van a probar
Los talleres permiten identificar varias soluciones posibles y empezar a priorizar-

las con los participantes. Sin embargo, estas soluciones deben repercutir en los obje-
tivos que se quieren alcanzar (viables), ser técnicamente factibles (viable técnica-
mente), aportar valor al usuario (usables) y no introducir un uso negativo (responsables).
Elegir la solución
No olvides tener en cuenta las limitaciones, ya sean de RGPD, éticas, tecnológicas, jurídi-
cas o financieras. A continuación, hay que poner a prueba las soluciones elegidas. (Capítulo 8).
82
MÓDULO №2
Nuestros consejos
◉ Facilita los talleres con herramientas visuales. Ya sea cara a cara o a
distancia, las pizarras blancas, los post-it y los lienzos pueden ayudar
a organizar los debates, priorizar las ideas y fomentar la colaboración.
◉ Limita el número de participantes para generar suficientes ideas y dar

a todos la oportunidad de expresarse.
◉ Asegúrate de que los participantes más introvertidos compartan sus

ideas y que los más extrovertidos no acaparen demasiado espacio.
83
MÓDULO №2
CAPÍTULO 8
Probar posibles
soluciones
El principal objetivo del discovery es reducir el riesgo de desarrollar una solución que
no cumpla las expectativas de los usuarios o los objetivos de la empresa. Probar las posibles
soluciones, comparándolas con las reacciones de tus usuarios y la realidad sobre el terreno, te
permite reducir aún más el riesgo de fracaso antes de lanzarte al desarrollo.
Las diferentes pruebas
Comprobar la propuesta de valor
Cuando empiezas a tener ideas para soluciones, e incluso antes de diseñar un prototipo,
puedes comprobar que se entiende bien la propuesta de valor de una funcionalidad. Una prueba
de propuesta de valor te permite validar el atractivo de una funcionalidad utilizando medios
poco costosos, como la prueba de humo.
La prueba de humo consiste en simular que la funcionalidad ya existe y evaluar las

reacciones de los usuarios. Puedes adoptar la forma de un botón falso, un anuncio que resuma
la propuesta de valor o una página de aterrizaje falsa. También se conoce como prueba de la
puerta falsa, porque la funcionalidad no existe realmente y no es posible utilizarla una vez
atravesada la puerta de prueba. Evaluando el porcentaje de usuarios que hacen clic en el
botón, visitan la página de destino o dejan comentarios, puedes estimar el éxito futuro de esta
funcionalidad.
84
MÓDULO №2
Prueba de humo del equipo de activación
Para comprobar el interés de los usuarios, el equipo añadió a los criterios

de búsqueda una falsa opción de recomendación de restaurantes basada
en su perfil y midió la tasa de búsqueda utilizando esta opción.
9:41 9:41
Sin embargo, ten cuidado, porque las pruebas de propuesta de valor, como las pruebas de
humo, pueden llevar a la decepción de los usuarios cuando se den cuenta de que la solución pro-
puesta no está disponible. Ten cuidado de no quebrantar la confianza de los usuarios ni dañar la
imagen del producto. Presta especial atención al mensaje que transmites en la interfaz de esta
prueba. En lugar de fingir que ha ocurrido un error técnico, es mejor ser claro con el usuario,
explicándole que la función está prevista para un futuro próximo e invitándole a dar su opinión.
85
MÓDULO №2
Probar la facilidad de uso de la solución
Las pruebas de prototipos permiten comprobar si la solución es fácil de usar y entender. Por
tanto, es muy útil para averiguar cómo mejorar la experiencia de usuario de una funcionalidad.
Para llevar a cabo este tipo de prueba, es recomendable trabajar con Product Designers
para diseñar un prototipo basado en maquetas interactivas. El prototipo puede ser más o menos
detallado y fiel a la realidad de la funcionalidad prevista. La prueba se lleva a cabo durante
una serie de entrevistas con los usuarios, durante las cuales se observa su comportamiento, se
recogen sus impresiones y acciones y, por último, se registran sus impresiones.
Al final de una prueba de prototipo, se obtienen las señales adecuadas para poder decir si
se ha logrado el ajuste Problema/Solución, es decir, si la solución parece responder al problema.
Ten cuidado, estas señales verifican que la solución es buena sobre el papel, pero no garantizan
que la aplicación vaya a satisfacer a los usuarios en una situación real. Por eso es importante no
sacar generalizaciones precipitadas de los resultados obtenidos, y completarlos estableciendo
el valor y midiendo el comportamiento real.
Probar aportando valor
El MVP
El objetivo del MVP (Producto Mínimo Viable) es aprender probando el valor en lugar de
entregar un producto o una funcionalidad. El enfoque MVP se utiliza para detectar el ajuste
producto/mercado, es decir, si el producto o la funcionalidad satisfacen las expectativas del
mercado.
El MVP se basa en el bucle Construir-Medir-Aprender de la metodología Lean Startup. Este

proceso iterativo se utiliza para probar la necesidad y el compromiso de un público reducido,
los usuarios tempranos (early adopters), proporcionando el valor mínimo. No se dirige

inmediatamente al público más amplio, conocido como la mayoría temprana (early majority).
86
MÓDULO №2
Los diferentes objetivos de los usuarios
(Diagrama de Geoffrey A. Moore)
¡Pensar en un MVP significa pensar en grande, empezar en pequeño! Frente a la filosofía

Get Big Fast, que consiste en lanzar rápidamente un producto industrializado sin validar
antes su atractivo para los usuarios. Incluso Facebook, que ahora se dirige al gran público,
empezó dirigiéndose a los estudiantes de Harvard antes de expandirse a otras universidades
estadounidenses, luego a institutos, etc., adaptando su producto a cada ocasión.
Para llevar a cabo su prueba del MVP, puedes llegar a ofrecer una versión muy manual de
sus funciones. Conocidas como Mechanical Turk, Wizard of Oz o Concierge Test, estas pruebas
pretenden simular manualmente la experiencia final, dando al mismo tiempo la impresión de
una forma de automatización. De este modo, el valor lo aporta un ser humano en lugar del
código. Por ejemplo, Airbnb probó un sitio web en el que los fundadores ofrecían su propio piso
en alquiler. Otro ejemplo sería un chatbot, manejado en realidad por un humano con escenarios
de respuesta predefinidos.
El test beta
Más adecuado para un producto o una funcionalidad principal, el test beta consiste en lan-
zar un alcance mínimo con posibles inestabilidades o un alcance incompleto para poder reco-
pilar feedback y mejorar en función de estos comentarios. La versión beta puede estar abierta
a inscripción o no, dirigida a usuarios externos, o realizada internamente con una población de
usuarios más familiarizados (colaboradores, comunidad de usuarios embajadores, etc.).
87
MÓDULO №2
No-Code
El No-code explotó en 2020 y se refiere a un conjunto de herramientas, o incluso una

tendencia, que tiene como objetivo crear un producto digital sin ningún conocimiento de
lenguajes de programación. Todas las herramientas No-code tienen el mismo enfoque: abstraer
la complejidad del desarrollo (programación, alojamiento, seguridad, etc.). De este modo, es
posible tener un producto totalmente funcional en pocos días sin ningún tipo de desarrollo,
lo que le permite probar y aprender de sus usuarios sin comprometerse demasiado con el
desarrollo. Comet, Prello, Qonto y Payfit son solo algunos ejemplos de productos que utilizan
este enfoque No-Code.
¿Cómo se realizan las pruebas?
Probar o no probar
Probar soluciones puede ser costoso y llevar mucho tiempo, sobre todo, cuando se tiene
en mente probarlo todo. Para limitar el tiempo y los costes, hay que identificar los elementos
que deben probarse con los usuarios y los que pueden desarrollarse directamente. Puede que
algunos temas no requieran pruebas. Es el caso, por ejemplo, de los desarrollos obligatorios
ligados a limitaciones técnicas o cuando la solución ya está claramente identificada, es barata
de desarrollar y presenta poco riesgo. En cambio, cuanto más complejas, innovadoras o
diferentes sean las soluciones habituales, más pruebas serán necesarias. Depende de ti evaluar
hasta qué punto es necesario probar una solución antes de desarrollarla (en función de lo difícil
que sea volver atrás y de los posibles efectos secundarios).
Definir la hipótesis y los criterios de éxito

Hay que empezar por definir las hipótesis que se pretenden validar o refutar, basándose
en las posibles soluciones identificadas como resultado del descubrimiento. A continuación,
para validar o rechazar estas hipótesis, hay que definir uno o varios criterios de éxito, incluido
un umbral de rendimiento a partir del cual las hipótesis puedan considerarse validadas. Para
ayudarte a definir este umbral, utiliza los datos de que dispongas o elige un valor por debajo del
cual no desees invertir en desarrollo.
Si las hipótesis están mal definidas o son demasiado generales, los criterios de éxito son
poco o nada relevantes y los umbrales de rendimiento se eligen sobre la marcha, el análisis del
88
MÓDULO №2
rendimiento de la solución será defectuoso. Al final, todo el proceso puede hacer perder más
tiempo del que ahorra. Para ayudarte a definir correctamente estos elementos, piensa en tus
objetivos (capítulo 2).
Marco de prueba del equipo de activación
89
MÓDULO №2
Realización de las pruebas
En función de tu hipótesis, puedes elegir la prueba más adecuada y generar datos

cuantitativos. Sin embargo, nada te impide realizar después entrevistas con los usuarios para
entender por qué has obtenido tal o cual resultado. La combinación de datos cuantitativos y
cualitativos te permitirá comprender mejor dónde reside el valor para sus usuarios y te dará
pistas sobre cómo iterar posteriormente.
Análisis de los resultados
Una vez recopilados los datos de la prueba, pregúntate si se han alcanzado los umbrales
de éxito definidos. Si no es así, considera que la prueba ha refutado las hipótesis y que debes
buscar otras soluciones posibles. Pero que no cunda el pánico. Ten en cuenta que el objetivo es
aprender.
En caso de fracaso total, no habrás perdido el tiempo ni el presupuesto: comprender que

vas por mal camino desde el principio minimiza las pérdidas. Por último, también es posible
que valides la solución, pero también que se te ocurran nuevas hipótesis que poner a prueba.
En este caso, puede que te resulte necesario iniciar una nueva prueba.
90
MÓDULO №2
Nuestros consejos
◉ No te apegues personalmente a las soluciones que pruebes. Aunque
pueda parecer desalentador rechazar una solución en la que llevas
trabajando varios días, o incluso varias semanas, ¡sigue siendo obje-
tivo! Evalúa los resultados de la prueba en función de sus criterios de
éxito preestablecidos para decidir si implantas o no la solución.
◉ Si decides no probar la solución, puedes utilizar otras herramientas

para limitar los riesgos y avanzar aprendiendo e iterando. Por ejem-
plo, puedes adoptar una estrategia de despliegue gradual abriendo
una funcionalidad a un pequeño número de usuarios a modo de vista
previa, antes de probar gradualmente su escalabilidad.
◉ En determinados contextos, las cuestiones de imagen de marca o las

limitaciones de seguridad pueden dificultar la realización de pruebas
de humo o de MVP que ofrezcan funcionalidades parciales. En este
caso, debes optar por las pruebas de prototipos para reducir los ries-
gos de tus ideas de solución.
91
MÓDULO №2
CAPÍTULO 9
Centrarse en las
prioridades
Priorizar significa elegir el foco en el que el equipo concentrará sus esfuerzos. Es importante
no priorizar únicamente en función de las propias intuiciones o las de los líderes, sino hacerlo
metódicamente.
Priorizar las oportunidades

Cuando elabores tu roadmap (capítulo 4), tendrás que priorizar las oportunidades que
identifiques para centrar tu esfuerzo de discovery. He aquí algunos métodos que te ayudarán a
elegir con conocimiento de causa, plantearte las preguntas adecuadas y tomar las decisiones
correctas.
El cuadro de mando de impacto
Hay que priorizar las oportunidades que tendrán mayor impacto en los objetivos (capítulo
2). Para cada oportunidad, evalúa cómo puede ayudarte a acercarte a tu objetivo. Además
del impacto en tu objetivo, puedes elegir varios criterios de evaluación. El cuadro de mando
integral de impacto te permite medir el impacto en función de varios criterios ponderados.
Como primer paso, identifica los criterios y ponderaciones con tus partes interesadas. El
impacto puede ser en la empresa o en el usuario. He aquí algunos ejemplos no exhaustivos:
◉ Ventas o cuota de mercado.
◉ Imagen de marca.
◉ Reducción de costes.
◉ Limitación del riesgo tecnológico.
92
MÓDULO №2
◉ Adquisición de nuevos usuarios;
◉ Activar y retener a estos nuevos usuarios;
◉ etc.
A continuación, valora tus oportunidades en función de los criterios de evaluación

asignándoles una puntuación, por ejemplo, de 1 a 100. La puntuación obtenida te ayuda a
priorizar las oportunidades con mayor puntuación.
Cuadro de mando de impacto para el equipo de

Activación
Criterio* 1. 2. 3. 4. Puntuación
Ponderación 30% 20% 20% 30% 100%
Proponer
resultados
en función 80 70 50 70 270
de dónde me
encuentre
Optimizar el
proceso de
50 50 40 15 155
recomenda-
ción
Mejorar la
relevancia de
60 30 10 30 130
la geolocaliza-
ción
Proponer
resultados
30 40 20 10 100
en función de
quién soy
1. Volumen de usuarios
2. Conversión
3. Facturación
4. Impacto medioambiental
93
MÓDULO №2
El mapa de oportunidades
El marco ideado por Anthony Ulwick se basa en el principio de que la gente compra productos
para obtener un resultado esperado. Basándose en el modelo JTBD (jobs-to-be-done) de Clayton
Christensen, puedes definir una lista de resultados esperados y pedir a los usuarios que los valo-
ren en una escala del 1 al 10 en función de dos criterios:
◉ Su importancia.
◉ Su grado de satisfacción.
A partir de estos elementos, Ulwick sugiere calcular una puntuación de oportunidad para cada
resultado esperado, desglosada del siguiente modo Puntuación de oportunidad = Importancia
+ (Importancia * Satisfacción)
A continuación, puedes clasificar las oportunidades en cuatro categorías:
◉ Puntuación de la oportunidad > 15 = excelente.
◉ > 12 = muy buena.
◉ > 10 = buena.
◉ < 10 = adecuada o supera las expectativas.
Las oportunidades con las puntuaciones más altas son a la vez las más importantes y las menos
satisfechas, por lo que deben explorarse en primer lugar.
94
MÓDULO №2
Puntuación de oportunidades del equipo de activación
Oportunidad Importancia Satisfacción Puntuación
Proponer resultados
en función de dónde 10 6 14
estoy
Proponer resultados
en función de quién 7 3 11
soy
Mejorar la relevancia
9 8 10
de la geolocalización
Optimizar el proceso
6 9 3
de recomendación
Priorizar las funcionalidades

Una vez identificadas las posibles soluciones (capítulo 7), puedes evaluar el esfuerzo
necesario para aplicarlas y priorizar las que aporten más valor con menos esfuerzo. También
en este caso, los marcos no deben considerarse puntuaciones absolutas de priorización; la
decisión depende del nivel de confianza en la priorización, el nivel de riesgo que estés dispuesto
a asumir o cualquier restricción adicional.
La matriz Esfuerzo/Impacto
Como te habrás dado cuenta, la matriz Esfuerzo/Impacto permite clasificar las

funcionalidades en dos ejes: impacto, por un lado, y esfuerzo, por otro. Como hemos visto
anteriormente, el impacto puede evaluarse de diferentes maneras: reducción del dolor del
usuario, impacto en el negocio, etc. El esfuerzo también puede tener en cuenta diferentes
criterios: tiempo de desarrollo, competencias actuales del equipo, esfuerzo de sincronización
del proyecto, esfuerzo de creación de contenidos, etc. Céntrate en las funcionalidades que
tengan el mayor impacto y requieran el menor esfuerzo.
95
MÓDULO №2
La matriz Esfuerzo/Impacto
MoSCoW
El método MoSCoW te permite priorizar tus funcionalidad es según los siguientes criterios:
Mo — Must have : debe llevarse a cabo.
S — Should have : debería hacerse si es posible. Estas funcionalidades son importantes
pero no cruciales.
Co — Could have : podría realizarse si no repercute en las demás funcionalidades
en curso.
W — Won’t have : no se llevará a cabo.
La priorización mediante la técnica MoSCoW puede ser un buen punto de partida, ya que
es fácil de establecer y colaborativa. Puedes utilizarla en un taller con las partes interesadas
para implicarles en la priorización y llegar a un consenso.
96
MÓDULO №2
El marco RICE
El marco RICE es un método elaborado por Intercom y basado en cuatro criterios:
◉ R (Reach) de Alcance: ¿a cuántas personas puede llegar/afecta el problema?
◉ I (Impact) de Impacto: ¿qué impacto tendrá la resolución del problema?
◉ C (Confiance) de Confianza: ¿hasta qué punto son seguras tus estimaciones de

Alcance e Impacto? ¿Dispones de datos cuantitativos y cualitativos que respalden los
indicadores anteriores?
◉ E (Effort) de Esfuerzo: ¿cuál es la inversión, el tiempo de trabajo estimado para todo

el equipo, la energía necesaria para implantar la funcionalidad? ¿Existen elementos
(dependencias, tecnologías desconocidas, muchas pantallas, etc.) que aumenten la
complejidad de la implantación de la solución?
La puntuación RICE se calcula del siguiente modo: (Alcance x Impacto x Confianza)/

Esfuerzo
Esta relación entre el valor del problema y el esfuerzo necesario para desarrollar la solu-
ción se utiliza para priorizar las soluciones con el mejor retorno de la inversión, es decir, la
puntuación RICE más alta.
97
MÓDULO №2
RICE del equipo de activación
Problema Solución R I C E Puntuación
Guardar direcciones
Proponer 2 3 3 1 18
favoritas
resultados
en función
de dónde me
encuentre Geolocalización 4 4 4 5 12,8
Banner de patrocinio 3 3 4 1 36
Optimizar el
proceso de
patrocinio
Patrocinio en el
2 2 4 2 8
proceso de pedido
Descarga las plantillas de matriz esfuerzo-impacto,

RICE y MoSCoW
98
MÓDULO №2
Nuestros consejos
◉ La lista de marcos aquí presentada no es exhaustiva. Existen más
de veinte técnicas de priorización conocidas. Como siempre, debes
probar y adaptar los métodos a tu contexto.
◉ Una buena colaboración y comunicación con las partes interesadas

durante el proceso de priorización te ayudará a fomentar la aceptación.
◉ Ten cuidado de no caer en la trampa de “todo es importante”. Sea cual

sea el método que utilices, priorizar implica necesariamente tomar
decisiones.
99
Lo esencial
de este módulo
1. El descubrimiento abarca una serie de actividades, incluidas las que implican a los
usuarios, destinadas a obtener ideas explorando problemas e imaginando y probando
soluciones.
2. Utiliza marcos metodológicos para estructurar el discovery: Design Thinking y su

doble diamante, Lean Startup y su Lean Canvas, Discovery Discipline y el método
F.O.C.U.S.E.D.
3. Profundiza en los problemas de los usuarios mediante entrevistas, observación,

inmersión, etc.
4. Utiliza la inteligencia colectiva para imaginar funcionalidades durante los talleres de

lluvia de ideas, Story Mapping, Impact Mapping, etc.
5. Identifica las soluciones más complejas mediante pruebas para hacer frente a la
realidad sobre el terreno.
6. Estructura tus pruebas definiendo hipótesis, eligiendo la prueba adecuada,

recopilando datos y comentarios y analizando los resultados.
7. La priorización te permite mantener la atención en cada fase del proceso del

producto y para cualquier tipo de elemento: una gran oportunidad que explorar o
una funcionalidad que probar.
101
3—
Construir el
producto
«El valor reside en la

ejecución, no solo en la
idea. Es esencial construir
rápidamente, aprender y
adaptarse en función de los
feedbacks de los clientes.»
— Ash Maurya
MÓDULO №3
El enfoque de Producto se caracteriza por la obsesión por el usuario y
el cuidado constante de entregar soluciones que satisfagan su necesidad, al
mismo tiempo que se alinean con los objetivos comerciales de la empresa. Si
el Product Discovery permite limitar los riesgos de lanzar una funcionalidad
inadecuada, el Delivery permite entregar el valor de sus funcionalidades de
manera continua y en los mejores plazos, con el objetivo de obtener feedback
regular de los usuarios y así iterar rápidamente.
En este módulo, veremos cómo enfrentar este desafío en equipo,

preparando los desarrollos de manera eficaz y gestionando el Delivery
Construir el producto
con Agile. También aprenderás cómo planificar y seguir el progreso de los

desarrollos y cómo testear y lanzar tus funcionalidades.
103
MÓDULO №3
CAPÍTULO 10
Preparar los
desarrollos
Herramienta central del delivery, el backlog de Producto es clave para preparar el desarrollo
de las nuevas funcionalidades. Permite tener una visión global sobre lo que constituirá el
producto y organizar el delivery de manera incremental. Se requiere un trabajo en equipo
para alimentarlo, redactar las Historias de Usuario y asegurarse de que todo esté listo antes de
desarrollar.
El backlog de Producto
Los elementos del backlog
Un backlog es un conjunto ordenado de elementos a realizar para entregar el producto, es

todo el trabajo que el equipo va a tener que realizar. A menudo presentado en forma de lista, el
backlog se compone de diferentes elementos:
◉ La Épica, unidad funcional de valor : una Épica describe una parte de

la solución a desarrollar para responder al problema identificado. Contiene las
informaciones macroscópicas de contexto, de valor esperado y de criterio de éxito.
La Épica es un contenedor de varias Historias de Usuario que, cuando se desarrollan,
contribuyen a entregar el valor objetivo.
◉ La Historia de Usuario, descripción funcional detallada : una Historia

de Usuario describe una necesidad del usuario y especifica cómo evolucionar el

producto para responder a ella. El objetivo es especificar el desarrollo de una parte
de una funcionalidad.
◉ La Historia Técnica, tema técnico : los requisitos técnicos para el desarrollo

de las Historias de Usuario (actualización de versión de un componente técnico,
refactorización de un elemento técnico) se formalizan como Technical Stories. Estos
104
MÓDULO №3
elementos contienen la descripción de las tareas técnicas a realizar así como el obje-
tivo buscado. Generalmente son redactados directamente por el equipo de desarrollo.
◉ El ticket de bug, solicitud de corrección de una anomalía : las ano-

malías, comportamientos no deseados de tu producto, deben aparecer en el backlog
para que su resolución sea priorizada frente a las nuevas funcionalidades.
◉ La Spike, tema de estudio :cuando una solicitud no es estimable porque hay

demasiadas incógnitas, o bien cuando se necesita una fase de investigación antes de
decidir sobre la solución a implementar para una funcionalidad dada, es posible crear
una Spike. Estos estudios suelen tener un límite de tiempo. Esto permite reservar
una parte de la capacidad del equipo para la realización del estudio, controlando el
impacto en el resto de los desarrollos. Para maximizar el éxito de la fase de estudio,
recomendamos definir de antemano los entregables esperados. Si el objetivo no se
ha alcanzado cuando el tiempo asignado ha terminado, puedes decidir prolongar la
duración del estudio o posponerlo.
¿Y la feature?
En algunas organizaciones existe un nivel de granularidad adicional entre

la Épica y la Historia de Usuario, llamado feature. Añadir este nivel de
desglose adicional permite agrupar tus Historias de Usuario en conjuntos
funcionales coherentes intermedios, especialmente relevantes si tu
producto es complejo o de tamaño considerable. En este caso, tus Épicas
se dividen en features que a su vez se dividen en Historias de Usuario. Por
ejemplo, se puede tener una Épica «Gestión de la cuenta», dividido en varias
features como la «Creación de la cuenta», la «Supresión de la cuenta» y
la «Reiniciación de la contraseña», que a su vez se dividen en Historias de
Usuario más pequeñas. Lo importante es ante todo definir un marco de
referencia que sea claro para tu equipo.
105
MÓDULO №3
El mantenimiento del backlog
El backlog es central para el equipo, que lo consulta para conocer las soluciones a desarrol-
lar. Las partes interesadas también pueden consultarlo para tener visibilidad sobre los temas
en curso y futuros.
Tu rol es dar vida a tu backlog añadiendo, retirando o reorganizando sus elementos regular-
mente. Asegúrate de siempre mantener en la parte superior las Historias de Usuario de mayor
valor. Al principio del backlog, las Historias de Usuario priorizadas estarán detalladas, mientras
que bajando en la lista, la prioridad será menor y los elementos más grandes, menos detallados.
No dediques demasiado tiempo en añadir y precisar los elementos en la parte baja del
backlog. ¿Por qué escribir, discutir, estimar, en resumen, tomar tiempo del equipo si no tiene la
capacidad de absorber la carga de desarrollo? Haz que tu backlog sea siempre pequeño y legible,
concentrándote en la entrega de funcionalidades de alto valor añadido.
¿Backlog o no backlog?
Un backlog no es un recordatorio, con el riesgo de convertirse en un cajón

de sastre ilegible en el que se anotan todas las nuevas ideas.
La metodología Shape Up, desarrollada en Basecamp y explicada en el

libro del mismo nombre escrito por Ryan Singer, incluso recomienda no
complicarse con un backlog y concentrarse en las soluciones a construir
en el próximo ciclo de seis semanas. Las ideas que no fueron seleccionadas
se descartan. Considera que si siguen siendo relevantes seis semanas
después, surgirán naturalmente. Destaca especialmente la carga mental
que representa un backlog demasiado grande, así como el tiempo
consumido en el refinamiento del backlog: «Los backlogs son una carga que
no necesitamos llevar. Docenas, luego cientos de tareas se acumulan, de las
cuales todos sabemos que nunca tendremos tiempo para ocuparnos. Este
montón creciente nos da la impresión de estar siempre atrasados, incluso
si no es el caso. No es porque alguien pensó que una idea era importante
hace un trimestre que debemos seguir trabajando en ella una y otra vez.
Los backlogs también son una gran fuente de pérdida de tiempo. El tiempo
pasado revisando, cuidando y organizando viejas ideas impide que todos

avancen en los proyectos que realmente importan.»
106
MÓDULO №3
Crear tu backlog
Desglosar las Épicas en Historias de Usuario
La creación del backlog a nivel Épica comienza en realidad en la fase de Product Discovery,
cuando específicas la solución. En esta etapa, el Épica no está lo suficientemente detallado para
comenzar los desarrollos, por lo que debes desglosar tu Épica en Historias de Usuario a través
de las actividades del refinamiento del backlog.
Épica e Historias de Usuario del equipo de Activación
La Épica «Identificar los restaurantes cercanos a casa» puede

descomponerse en varias Historias de Usuario:
◉ Filtrar la lista de restaurantes en relación a mi dirección.
◉ Visualizar los restaurantes en un mapa.
◉ Ajustar el radio de búsqueda «cercano».
◉ Previsualizar el detalle del menú del restaurante desde el mapa.
Llevar a cabo un refinamiento
El refinamiento del backlog es un ritual colaborativo que reúne en la mesa a todos los
participantes en el delivery. Al final de los refinamientos del backlog, debes haber resuelto todas
las incertidumbres y poder lanzarte a los desarrollos con tranquilidad.
Por lo tanto, es importante que los temas tratados durante los refinamientos sean
compartidos y comprendidos por todo el equipo. Algunos equipos prefieren ritualizar
los refinamientos definiendo horarios semanales, otros solicitan intercambios según las
necesidades y la disponibilidad del equipo.
107
MÓDULO №3
◉ Durante las sesiones de refinamiento, debes realizar las siguientes actividades:
◉ Ponerte de acuerdo con el equipo sobre el buen desglose de las Épicas en Historias
de Usuario.
◉ Identificar las reglas de negocio y los criterios de aceptación.
◉ Detectar los elementos a clarificar.
◉ Evaluar la complejidad.
Para enmarcar las sesiones de refinamiento, puedes apoyarte en talleres participativos

como el Example Mapping o el Tres Amigos.
El Example Mapping te permite abordar durante un tiempo limitado (25-30 min) el alcance
de una Historia de Usuario e identificar las reglas de negocio y criterios de aceptación asociados
y las preguntas restantes a precisar. Al final del taller, los participantes votan si se sienten
cómodos para comenzar el desarrollo o si es necesario continuar precisando los elementos.
108
MÓDULO №3
Ejemplo de mapeo del equipo de activación
109
MÓDULO №3
El taller Tres Amigos, que reúne en la mesa al Product Manager, desarrollador y tester, ayuda
en la escritura de las Historias de Usuario y, en particular, de los criterios de aceptación. Antes
del taller, escribes las reglas de negocio de la Historia de Usuario. Estas pueden ser compartidas
con antelación para que el equipo prepare las preguntas. Durante el taller, se revisan las reglas
y los participantes redactan conjuntamente los criterios de aceptación. El taller generalmente
permite aclarar ciertas áreas grises y precisar, si es necesario, las reglas a implementar.
Redactar una Historia de Usuario
Más allá de su estructura y contenido, las Historias de Usuario son ante todo un medio de
discusión entre tú y los miembros del equipo, permitiendo intercambiar perspectivas sobre la
necesidad y ponerse de acuerdo sobre las soluciones a desarrollar. Ron Jeffries, informático
estadounidense de renombre, señala que las buenas Historias de Usuario integran tres aspectos:
◉ Carta (Card): información sintética y fácil de entender (que puede caber en una
tarjeta).
◉ Conversación (Conversation): discusiones e intercambios que dan lugar a reglas

de negocio, no dictadas por los Product Managers.
◉ Confirmación (Confirmation): una comprensión compartida de las expectativas a

través de los criterios de aceptación.
Así, el buen formato de una Historia de Usuario es aquel que funciona para ti y está ideada
en función de los temas. En algunos equipos, suficientemente maduros, y para ciertos temas
pequeños, de bajo riesgo o técnicos, la Historia de Usuario reducida a una descripción funcional
puede ser suficiente. ¡No olvides que un equipo alineado y que comparte el conocimiento del
producto no necesariamente necesita Historias de Usuario detalladas!
110
MÓDULO №3
Enfoque en el framework INVEST
El framework INVEST te proporciona una guía para redactar el contenido

de tus Historias de Usuario. Sus seis criterios te permitirán cuestionarte
para redactar buenas Historias de Usuario:
◉ Independiente : tus Historias de Usuario deben, en la medida de lo

posible, ser independientes unas de otras para poder ser desarrol-
ladas y entregadas individualmente.
◉ Negociable : deben fomentar la discusión y pueden ser modificadas

hasta que entran en desarrollo.
◉ Valor : deben aportar valor. Dado que la noción de valor siempre

es difícil de evaluar, las Historias de Usuario deben ser expresadas
con una visión del objetivo buscado para el usuario y la empresa.
◉ Estimable : deben ser lo suficientemente claras para que el equipo

pueda evaluar su complejidad.
◉ Pequeña (Small) : deben ser de tamaño suficientemente pequeño

para evitar los efectos túnel. Intenta, por tanto, desglosar finamente
tus Historias de Usuario.
◉ Testable : las Historias de Usuario deben contar una historia, de la

cual los tests se derivan de manera evidente.
Por ejemplo, puedes redactar tus Historias de Usuario de la siguiente manera:
◉ Un título, expresando el propósito de la Historia de Usuario.
◉ Una frase narrativa orientada al usuario describiendo el beneficio deseado, a

menudo estructurada en la forma «como un/a...», «quiero...», «para poder...».
◉ Un conjunto de reglas de negocio, detallando el comportamiento esperado para

satisfacer la necesidad, así como los criterios de aceptación y condiciones necesarias
para la validación de la funcionalidad (capítulo 14).
111
MÓDULO №3
Una Historia de Usuario del equipo de Activación
A partir del taller de example mapping, el/la Product Manager del equipo de
Activación pudo redactar la siguiente Historia de Usuario:
Aplicar un descuento en el primer pedido
Como nuevo usuario, quiero utilizar mi código de descuento del 10% en mi

primer pedido, para aprovechar mi oferta de bienvenida.
Reglas de negocio:
◉ El descuento se aplica solo si el usuario introduce un código válido
(WELCOME en mayúsculas o minúsculas).
◉ El descuento se aplica solo en cestas de 25 € o más.
◉ El código es utilizable solo una vez y en el primer pedido.
Las reglas se precisaron gracias a las preguntas planteadas durante el

taller.
Esta estructura genérica te servirá de base para la redacción de tus Historias de Usuario.
Luego puedes completarlas agregando los elementos relevantes para la comprensión de la
necesidad y de la solución: maquetas, esquema de arquitectura, plan de etiquetado (capítulo
17)…
Antes de ir a desarrollo
Organízate con el Kanban Ready
Para organizar las etapas de refinamiento de las soluciones, puedes visualizar las etapas en
un tablero Kanban. La visualización te permitirá organizarte con tu equipo y comunicar con
transparencia sobre los temas próximos a desarrollarse.
112
MÓDULO №3
El Kanban Ready es un buen medio para ajustar el ritmo de preparación de las Historias
de Usuario, en función de la capacidad del equipo de desarrollo. Puedes aspirar a adoptar
un enfoque de corto plazo para el desarrollo de las Historias de Usuario. Se evitará
llenar un backlog con elementos que caerán en el olvido unas semanas más tarde.
Construir el Definition of Ready
Una vez realizado el refinamiento, ¿se preguntan cuándo una Historia de Usuario puede ser
desarrollada? Normalmente, es el equipo quien podrá responder a esta pregunta, pero un
Definition of Ready (DoR) les ayuda a identificar más fácilmente este estado.
La DoR es la lista de elementos requeridos que una Historia de Usuario debe cumplir para
pasar al desarrollo. Se trata de un contrato establecido con el equipo, que permite explicitar lo
esperado de una Historia de Usuario y tener una garantía de calidad antes de los desarrollos.
Definition of Ready del equipo de Activación

113
MÓDULO №3
La DoR puede evolucionar con el tiempo y difiere de un equipo a otro, e incluso de un

producto a otro. Para definirla, organiza un taller con todo el equipo.
No temáis al síndrome del backlog vacío. Seleccionar únicamente las Historias de Usuario
listas para pasar al desarrollo asegura la entrega y la calidad de sus desarrollos. Y si les falta
elementos funcionales, recordad que también existen las Technical Stories, Spikes y tickets de
bug.
Nuestros consejos
◉ Cuando tomes posesión de un backlog existente, tómate el tiempo para
hacer limpieza y eliminar los elementos demasiado antiguos, esto per-
mite apropiarse del entorno y validar el valor de cada solución.
◉ Cuando desgloses tus Épicas en Historias de Usuario, ten en mente

que no necesitas implementar la totalidad de la Épica para entregarla a
los usuarios. Prioriza las Historias de Usuario que permitan entregar
el valor mínimo de cada Épica. Las otras Historias de Usuario identifi-
cadas podrán ser priorizadas más tarde, en función de los feedbacks
de los usuarios.
◉ No esperes a un refinamiento para comenzar a recoger opiniones

sobre la factibilidad técnica, UX, etc., de una Historia de Usuario.
Pueden comenzar a hablar de una Historia de Usuario con su equipo
cuando tengan un poco de tiempo antes o después de su reunión dia-
ria, por ejemplo.
114
115
MÓDULO №3 Construir el producto
MÓDULO №3
CAPÍTULO 11
Gestionar el delivery
con agile
Para el Delivery, los equipos de Producto se apoyan en el enfoque ágil. Agile permite una
mejor capacidad de respuesta a los cambios, las exigencias y las necesidades de los usuarios
gracias al desarrollo iterativo y continuo. Apoyándose en los principios y valores de Agile, el
equipo se esfuerza por establecer un funcionamiento colaborativo y humano, propicio para la
iteración y la mejora continua.
Los fundamentos de Agile
Los valores y principios
Agile se compone de 4 valores y 12 principios descritos en un manifiesto, que permite

desarrollar productos digitales de calidad mediante la entrega de pequeños incrementos.
Los valores fundamentales de Agile indican que:
◉ Las personas y las interacciones son más importantes que los procesos y
herramientas. La comunicación y la colaboración entre los miembros del equipo son
esenciales para el éxito de un producto.
◉ Un producto operativo es más importante que una documentación exhaustiva.

Aunque la documentación es necesaria, la prioridad debe darse a la creación del
producto.
◉ La colaboración con el cliente es más importante que la negociación contractual.

Se enfatiza en el contacto del equipo con el cliente para responder adecuadamente a sus
necesidades que evolucionan con el tiempo.
◉ La adaptación al cambio es más importante que seguir el plan. En lugar de

aferrarse a un plan inicial fijo, el equipo está abierto a los cambios y puede responder
de manera flexible.
116
MÓDULO №3
Los 12 principios de Agile
Los frameworks Agile son marcos de trabajo definidos de acuerdo con estos principios y
valores. Existen varios, como Scrum, Kanban, Extreme Programming... Aunque las prácticas
Agile pueden evolucionar, la rigurosidad con la que debes aportar valor de manera rápida y
regular a tus usuarios (principio fundacional del Manifiesto Agile) permanece intacta.
117
MÓDULO №3
Adoptar un marco de trabajo ágil al pie de la letra, sin tomar distancia para comprender
y aplicar los principios y valores, no convierte al equipo en ágil. Por el contrario, encarnar
los valores sin beneficiarse de las herramientas que ofrecen los marcos Agile será difícilmente
sostenible a largo plazo, especialmente en el caso de productos maduros, cada vez más
complejos, con cada vez más usuarios.
Los prerrequisitos
Como prerrequisito para la correcta aplicación de Agile, es necesario establecer un entorno

propicio para la autonomía y la colaboración del equipo. De hecho, el éxito de un equipo ágil
reside en su capacidad para ser empoderado, con un alto grado de alineación y autonomía. Por
eso, un equipo de Producto Agile es:
◉ Multidisciplinar y autoorganizado : incluye a todas las personas (a tiempo

completo o parcial) necesarias para el delivery, ya sea en diseño, desarrollo y prueba.
◉ Autorizado para tomar decisiones : puede tomar decisiones y poner en pro-

ducción de manera regular y autónoma.
Inspirarse en los diferentes marcos Agile
Scrum, un marco estructurado
Scrum se basa en la implementación de ciclos de desarrollo cortos e iterativos llamados

sprints, durante los cuales el equipo se enfoca en la entrega de un alcance específico y
establecido. Basado en tres pilares fundamentales —la transparencia, la inspección o la
capacidad de cuestionarse a sí mismo, y la adaptación al cambio—, el marco detalla 3 roles, 3
artefactos y 4 eventos.
118
MÓDULO №3
Los 3 roles de Scrum
◉ El Product Owner tiene el rol de maximizar el valor del producto realizado por el
equipo. Es responsable de la gestión del backlog, asegura representar las necesidades
de las distintas partes interesadas en los ítems del backlog y comunica objetivos de
Producto claros. El rol de Product Owner es específico del marco Scrum. En princi-
pio, estas responsabilidades recaen en los Product Managers.
◉ El Scrum Master tiene el rol de acompañar al equipo en la aplicación de Scrum.

También facilita la comunicación entre los distintos actores y elimina los obstáculos
que encuentra el equipo. Dependiendo de las organizaciones y los niveles de madurez
de un equipo, el rol de Scrum Master puede ser desempeñado por una persona
compartida entre varios equipos o por un desarrollador dentro del equipo.
◉ El equipo de desarrollo realiza el trabajo necesario para la creación del producto

y la entrega de un incremento terminado.
Los 3 artefactos de Scrum
Scrum menciona tres artefactos principales que permiten difundir la información con
transparencia:
◉ El Product Backlog es la lista de ítems necesarios para construir o mejorar el

producto, priorizados por el Product Owner según su valor.
◉ El Sprint Backlog contiene los elementos más prioritarios del Product Backlog
que el equipo de desarrollo se compromete a entregar durante el sprint en curso.
◉ El incremento es la suma de desarrollos que respetan la Definition of Done (capítulo

14) y pueden ser puestos en producción.
El sprint
En el corazón del marco Scrum, el sprint tiene una duración máxima de cuatro semanas.
Esta duración es generalmente fijada por los líderes de Producto y no por los Product Managers,
para asegurar coherencia entre equipos. Sin embargo, el objetivo para Scrum es tener iteraciones
lo más cortas posibles para entregar los incrementos de Producto, obtener feedback y ajustar el
alcance lo más pronto posible.
El sprint comienza con la planificación del sprint, donde el equipo se compromete con un
objetivo a alcanzar: el objetivo del sprint o sprint goal. Marcado por los daily, termina con la
revisión y la retrospectiva.
119
MÓDULO №3
Los 4 eventos de Scrum
◉ La Sprint Planning establece el marco del sprint. Durante esta ceremonia, el

equipo discute las Historias de Usuario más prioritarias y determina lo que puede ser
incluido en el sprint definiendo el objetivo del sprint.
◉ La Daily se organiza todos los días a la misma hora, permitiendo al equipo compar-
tir el progreso del sprint respecto al objetivo del sprint. El objetivo de la Daily no es
reportar el trabajo realizado, sino identificar los posibles puntos de bloqueo lo más
rápidamente posible y ajustar la priorización y el backlog del sprint si es necesario,
para garantizar el logro del objetivo.
◉ La Sprint Review permite al equipo presentar a las partes interesadas el resultado

del sprint. El equipo hace una demostración de los incrementos realizados y puede
recoger el feedback de las partes interesadas. Una buena práctica es que la demos-
tración la realicen los desarrolladores que contribuyeron al desarrollo de las funcio-
nalidades presentadas. Además de la demo, la Review es también la oportunidad de
compartir elementos clave como el seguimiento del rendimiento, un balance sobre el
avance del roadmap o la consecución de objetivos.
◉ La Sprint Retrospective (Retro) permite hacer un balance del sprint para

identificar los éxitos y fracasos, así como las áreas de mejora. También permite imple-
mentar acciones de mejora continua. Existen múltiples formatos de retrospectiva, lo
que permite renovarse y hacer el ejercicio más dinámico (capítulo 20).
120
MÓDULO №3
El marco de trabajo Scrum
Kanban, un flujo continuo

Kanban se basa en el principio de flujo continuo. Los elementos listos y prioritarios del
backlog son «arrastrados» en el tablero Kanban. Antes de comenzar un nuevo tema, el equipo
revisa si puede avanzar o terminar alguno de los temas actuales. El enfoque Kanban se centra
en la visualización del trabajo en curso, la limitación de este trabajo, la optimización del flujo
y la mejora continua.
La visualización del trabajo en curso
El tablero Kanban es una herramienta que permite visualizar el flujo de trabajo en forma
de etapas, cada etapa representada por una columna. El flujo representa de manera exhaustiva
el conjunto de actividades necesarias para entregar una funcionalidad. Según tus necesidades,
el tablero puede ser tan simple como «por hacer», «en curso» y «hecho», o bien más detallado,
con columnas como «por analizar», «listo», «en desarrollo», «en revisión», «en prueba»,
«terminado», «desplegado», «cerrado».
La tarjeta Kanban es un elemento del backlog (capítulo 10). Colocadas en el tablero por orden
de prioridad, las tarjetas, que son todas de tamaño equivalente, van a moverse por las columnas
de izquierda a derecha. Es posible que una tarjeta salte algunas columnas, pero en principio no
pueden regresar atrás. Los criterios de ese movimiento deben ser explícitos y compartidos.
121
MÓDULO №3
Esta representación visual es esencial, ya que permite dar una mejor visibilidad sobre el
trabajo en curso y facilita la identificación de puntos de bloqueo que podrían impedir el avance
de los temas.
La limitación del trabajo en curso
«Deja de empezar, empieza a terminar» es un lema que refleja bien el enfoque Kanban.
El objetivo es hacer que el máximo número de elementos pase lo más rápido posible de una
columna a la otra. En lugar de trabajar en un gran número de tareas en paralelo, se impone para
cada columna del tablero un límite en el número de elementos que pueden figurar al mismo
tiempo en la columna. Esto es lo que se llama el WIP Limit (Work in Progress Limit). Una vez
alcanzado el límite, el equipo se concentra en los elementos presentes en la columna y se ayuda
mutuamente para hacerlos avanzar a la siguiente etapa.
El marco de trabajo Kanban
Optimización del flujo
En Kanban, para optimizar el flujo de trabajo, es importante analizar los procesos de pro-
ducción e identificar las etapas que más tiempo consumen. El tiempo de ciclo (cycle time), un
indicador que mide el tiempo para pasar de una etapa a otra, permite detectar los cuellos de
botella. El tablero también ayudará a identificar las etapas en las que las tareas se acumulan.
Al identificar las etapas problemáticas, es posible mejorarlas y optimizar el proceso de entrega
de funcionalidades.
122
MÓDULO №3
Mejora continua
El enfoque Kanban fomenta la mejora continua evaluando regularmente el proceso e

identificando oportunidades de mejora. El equipo discute los éxitos y fracasos con el objetivo
de identificar formas de mejorar el rendimiento en el futuro. Aunque no hay un ritual específico
documentado en el marco de Kanban, la retrospectiva es un buen medio para enmarcar esta
reunión regular.
Adaptar los marcos Agile para su equipo

Scrum y Kanban son dos marcos de trabajo que implementan los principios y valores
Agile con el objetivo de mejorar la colaboración, transparencia y productividad. Aunque ambas
aproximaciones tienen similitudes, cada una tiene sus especificidades y limitaciones.
Scrum, que ofrece más procesos y reglas, así como un ritmo iterativo fijo con los sprints,
es adecuado para contextos que requieren una planificación rigurosa, como cuando se
necesita un fuerte alineamiento entre diferentes equipos que trabajan en el mismo ámbito.
Sin embargo, Scrum puede volverse restrictivo, obligando a los Product Owners a proveer un
número significativo de Historias de Usuario listas para ser incluidas en un sprint en una fecha
específica, o limitando la capacidad de adaptarse durante un sprint.
Kanban, más flexible, permite ajustar más rápidamente los cambios de prioridades y es
más adecuado en contextos que requieren una capacidad de adaptación rápida. Por otro lado,
Kanban puede carecer de estructura y planificación a largo plazo.
Algunos equipos optan por un modelo híbrido, a menudo llamado Scrumban, para adaptar
el marco a sus necesidades operativas. Pueden comenzar con el enfoque de flujo de Kanban
mientras agregan elementos de Scrum, como el daily, la review y la retrospectiva. También
pueden elegir mantener el ritmo de los sprints y permitir que el equipo tome directamente del
backlog las Historias de Usuario prioritarias a medida que se completan otros tickets.
123
MÓDULO №3
Nuestros consejos
◉ Prueba diferentes marcos Agile: al igual que con un producto, no
dudes en iterar para encontrar la mejor manera de trabajar en equipo
(la que se adapte a todos).
◉ Para el día de la review, puedes preparar un soporte de presentación y

videos de demostración de las funcionalidades para evitar imprevistos
en vivo, el famoso «efecto demo».
◉ No descuides la retrospectiva: tanto en Scrum como en Kanban, la

mejora continua es esencial, y este evento permite al equipo unirse en
torno a acciones comunes a implementar.
124
125
MÓDULO №3
CAPÍTULO 12
Planificar y
proporcionar visibilidad
Debido a que se encuentra en el corazón del delivery, su equipo de Producto genera
expectativas entre todas los stakeholder. Debe responder regularmente a las preguntas a
menudo temidas: ¿cuándo se entregará el producto? ¿Cuánto cuesta el desarrollo de la feature?
Aunque es difícil, e incluso riesgoso, predecir la fecha de entrega de una feature, es esencial poder
proporcionar visibilidad a sus stakeholder.En este capítulo, veremos cuáles son las herramientas
para proporcionar esta visibilidad y organizarse eficazmente sin invertir demasiado tiempo.
Prever el aterrizaje de las feature
¿Por qué es difícil predecir?
Cuando se crea un producto digital, el desarrollo de cada nueva feature es único y requiere
una implementación específica. Aquí no se trata de desarrollar una pieza de un producto físico
producido a gran escala, donde sería posible conocer de antemano los detalles de la producción:
materiales necesarios, tiempo para producir, proceso de producción. Para cada nueva feature,
el tiempo necesario para su realización solo se conocerá una vez que esta esté terminada.
La incertidumbre es un componente del desarrollo y del Product Management. Cuando

preparas el backlog (capítulo 10), manejas elementos más o menos ciertos y de diferentes
tamaños. Ten en cuenta que cuanto más pequeñas sean tus Historias de Usuario, más fiables
serán las predicciones. Tomemos el ejemplo de un trayecto entre tu casa y tu lugar de trabajo.
Si trabajas a cinco minutos a pie de tu casa, puedes predecir fácilmente el tiempo necesario
para llegar a la oficina. Por otro lado, si vives a tres paradas de metro de tu oficina, el tiempo de
viaje es un poco más incierto... Finalmente, si para llegar a tu trabajo necesitas tomar dos líneas
diferentes en varias paradas cada una, se vuelve casi imposible predecir con certeza el tiempo
de viaje necesario. Puedes formular una hipótesis, pero los posibles contratiempos (retraso,
incidente, gran afluencia) podrían retrasarlo.
126
MÓDULO №3
Fecha conocida o hipótesis de entrega
Como habrás entendido, es imposible evaluar con certeza la complejidad de implementación

de una feature, y por lo tanto, la fecha en la que podrá ser entregada. La fecha de entrega es, por
lo tanto, una hipótesis que debe ajustarse a medida que avanza el desarrollo.
Es posible que a veces tengas que enfrentarse a restricciones fuertes (evento anual, rediseño
mediático de la marca, contrato ineludible), para los cuales se te pedirá que te comprometas
con una fecha. Si surgen contratiempos que ponen en peligro esta fecha impuesta, puedes jugar
con tres variables de ajuste:
◉ Retrasar el lanzamiento.
◉ Reducir el alcance entregando menos funcionalidades de lo previsto.
◉ Aumentar los costos reforzando los equipos.
Como Product Manager, debes explicar estos elementos a tus stakeholder y acordar juntos
el camino a seguir.
127
MÓDULO №3
¿Más desarrolladores para ir más rápido?
La creencia de que cuanto más grande es un equipo de desarrollo, más rápido

puede producir, generalmente es errónea. ¡Y no importa el framework con
el que trabajes! En realidad, cuanto más grande es el equipo (a partir de 8
personas), más dificultades puede tener para organizarse, comunicarse
y distribuir el trabajo de manera que todos puedan trabajar en paralelo,
perjudicando así la productividad. Además, debes dedicar más tiempo a
preparar el delivery, en detrimento de tus otras actividades como Product
Manager. Un equipo más pequeño (5 o 6 personas) te permite dedicar más
tiempo al discovery, el análisis de feedbacks, la medición del impacto... Sin
embargo, un refuerzo puntual puede ser efectivo si los desarrolladores que
vienen a ayudar pueden trabajar rápidamente y de manera autónoma en
tu ámbito. Si se necesita un largo período de capacitación, aquí también, es
probable que pierdas más tiempo del que ganas.
Ratio de desarrolladores por PO según el estudio LPC 2022

128
MÓDULO №3
Herramientas para ayudar en la
previsión y planificación
Las estimaciones y la velocidad en Scrum
Las estimaciones
El trabajo de previsión y planificación comienza durante la presentación del backlog a los

desarrolladores. La estimación de las Historias de Usuario por el equipo es el primer elemento
para refinar su comprensión de la complejidad.
La estimación expresa la complejidad para realizar la Historia de Usuario y puede ser anun-
ciada en diferentes formatos con el objetivo de constituir un referente de comparación de un
elemento a otro. Generalmente se elige un tamaño en talla de camiseta (XL, L, M, S) para las
Épicas o un punto de complejidad para las Historias de Usuario (siguiendo la secuencia de
Fibonacci: 1, 2, 3, 5, 8, 13).
Las Historias de Usuario deben ser estimadas por el equipo de desarrollo, idealmente en
grupo. Así es como se desarrolla una sesión de estimación:
1. Describes el resultado funcional esperado de cada Historia de Usuario.
2. Cada desarrollador evalúa simultáneamente la complejidad de la Historia de Usuario

utilizando el referente del equipo. Si las valoraciones dadas son diferentes, se invita
a los desarrolladores a dialogar y llegar a un acuerdo sobre una estimación rápida-
mente (limitando el tiempo de intercambio a unos minutos).
3. ¿Y si no hay consenso? ¡Se toma la estimación más alta!
Gracias a cada estimación, dispones de información adicional que enriquece tu referente,

permitiéndote comparar la complejidad de los diferentes elementos del backlog.
129
MÓDULO №3
La cotización extrema para estimar

hasta 100 Historias de Usuario en 1 hora
La cotización extrema es una técnica de estimación que permite evaluar en

un tiempo reducido el máximo número de Historias de Usuario. El taller se
organiza contigo y todo o parte del equipo de desarrollo. Se desarrolla de la
siguiente manera:
◉ Antes del taller, todas las Historias de Usuario o Épicas a estimar

se escriben en post-its. El facilitador también prepara un tablero
cuyas columnas representan un valor de complejidad (ya sea 1, 2,
3, 5, 8... según Fibonacci o XS, S, M...).
◉ Presentas rápidamente los temas a estimar al equipo de desarrollo

de manera que entiendan lo esperado, pero sin entrar en los
detalles de la solución técnica.
◉ El equipo identifica la Historia de Usuario menos compleja y la

más compleja para colocarlas en los extremos del tablero. Estas
servirán de referencia para comparar la complejidad del resto de
las Historias de Usuario.
◉ En una primera ronda de estimación silenciosa, cada desarrollador

toma un post-it y lo coloca en la columna correspondiente a la
complejidad estimada.
◉ Una vez estén todos los post-its colocados, el equipo se concede un

tiempo de reflexión silenciosa para tomar nota de las estimaciones
antes de proceder a una segunda ronda de estimación. Durante
esta segunda ronda, los desarrolladores mueven libremente y sin
consultar los post-its a otras columnas, resaltándolos si no están
de acuerdo con la estimación inicial.
◉ Una vez finalizada la segunda ronda, se considera que todos los

post-its que no se han movido están correctamente estimados. El
equipo puede entonces discutir y llegar a un acuerdo sobre las
estimaciones de los otros post-its, limitando así las discusiones a

solo aquellos temas que son objeto de debate.
130
MÓDULO №3
Ten en cuenta que el tiempo dedicado a estimar no necesariamente mejora la precisión
de la previsión. Como dice John Cutler, experto en Producto y coach de renombre, «En lugar
de enfocarse en “mejores” estimaciones (...) concéntrese en: trabajar en partes más pequeñas,
entregar frecuentemente, exponer el trabajo a usuarios/clientes más rápidamente, probar
hipótesis antes, limitar dependencias, tener un código menos frágil, limitar las transferencias.
Sus estimaciones mejorarán.»
El movimiento no estimate
Si bien las estimaciones son una herramienta para el equipo Scrum, no son
una obligación para el buen funcionamiento del delivery. Es más, la Guía
Scrum no las menciona. Para el movimiento no estimate (sin estimaciones)
liderado por Vasco Duarte, uno de los líderes de la comunidad Agile:
◉ Estimar toma demasiado tiempo.
◉ Las estimaciones no son fiables.
◉ Las estimaciones no son los únicos indicadores para prever.
Si piensas que el ritual de estimación te hace perder eficacia, prueba este

enfoque siguiendo algunas buenas prácticas:
◉ Implementa alternativas como más comunicación con los stakeholder,
iteraciones más cortas, un desglose funcional más detallado....
◉ Confía en la experiencia del equipo para confirmar que el contenido de

tu sprint es realizable (definir un índice de confianza).
◉ Prueba el funcionamiento con el equipo y ajusta durante las

iteraciones.
131
MÓDULO №3
La velocidad del equipo
La velocidad representa la capacidad de tu equipo para producir, es decir, la cantidad de

puntos que un equipo completo puede realizar en un sprint. Se calcula a partir de los desarrollos
realizados en los ciclos anteriores.
La velocidad de un equipo evoluciona con el tiempo. Si es incierta cuando un equipo se

forma recientemente, aumenta y se vuelve muy fiable a medida que el equipo gana competencia
y optimiza su funcionamiento. Sin embargo, puede disminuir si un desarrollador está ausente,
si la motivación o el ánimo del equipo disminuye o si problemas técnicos ralentizan los
desarrollos (un código que se vuelve difícil de mantener, un proceso largo de testing...).
La velocidad es una herramienta de predicción que permite dar visibilidad al equipo y a los
stakeholders. No es una herramienta de control y, al igual que con las estimaciones, siempre hay
un margen de error e imprevisibilidad. Aquí hay algunas reglas a tener en cuenta para usarla
adecuadamente:
◉ Las estimaciones no son compromisos, sino apreciaciones que permiten

organizar el desarrollo.
◉ Cuanto más maduro y regular es un equipo, más se afinan y refuerzan

estas apreciaciones como un indicador de previsibilidad.
◉ Comparando la estimación y la realización, se adaptan de manera

empírica las previsiones futuras y se puede afinar la visibilidad.
◉ La velocidad no es comparable entre equipos, cada uno tiene su propio

referencial de estimación.
◉ La velocidad no es una medida del trabajo individual, ya que la entrega

de una feature puede ser asegurada por varias personas del equipo.
El lead time y el flujo en Kanban

El lead time
El lead time mide en días el tiempo total necesario para realizar un elemento del backlog,
desde su creación hasta la entrega. Esto incluye el tiempo de desarrollo, pero también el tiempo
de refinamiento, los tiempos de espera...
132
MÓDULO №3
Cálculo del Lead Time
Por lo tanto, el lead time ofrece una indicación sobre el tiempo necesario para entregar una
feature. Partiendo del principio de que la feature contiene 4 Historias de Usuario de tamaño equiva-
lente y que se necesitan 3 días para validar una Historia de Usuario, se plantea la hipótesis de que son
necesarios 12 días para entregar la feature.
El flujo
El flujo representa el número de elementos completados al final del proceso. Tomando los
elementos del backlog, el flujo sería el número de elementos entregados en un período dado
(por ejemplo, una semana). Haciendo el ratio del número de elementos con respecto al flujo,
se obtiene una estimación del tiempo necesario para entregar una feature a sus usuarios. En
nuestro ejemplo de feature que contiene 4 Historias de Usuario, y considerando un flujo de 2
Historias de Usuario terminadas por semana, se cuentan dos semanas para entregar la feature.
Planificar los desarrollos
Anticipar las dependencias con otros equipos
Gestionar las dependencias es parte del día a día de los Product Managers, especialmente
en organizaciones donde varios equipos deben colaborar. Las dependencias surgen cuando un
equipo no puede alcanzar su objetivo de manera autónoma y necesita el desarrollo de una
feature, un trabajo técnico o la resolución de un bug por parte de otro equipo. Para planificar
los desarrollos de la forma más eficaz posible, es importante detectar las dependencias lo más
temprano posible, especialmente a través de las discusiones durante los refinamientos. Una
vez identificadas las dependencias, debe coordinarse con los Product Managers de los equipos
afectados para acordar las prioridades y ajustar sus desarrollos. Si es necesario, sus líderes de
Producto también pueden ayudarte a alinear las diferentes prioridades.
133
MÓDULO №3
¿Qué es la planificación PI?
La planificación PI (Product Increment Planning) es una ceremonia de

planificación a gran escala. Con una duración de uno a dos días, reúne en
el mismo espacio a los diferentes equipos involucrados en el desarrollo de
un producto. Durante esta ceremonia, los equipos planifican los desarrollos
de las próximas 8 a 12 semanas, identificando y tomando en cuenta las
dependencias entre todos.
134
MÓDULO №3
Realizar un plan de lanzamiento
El plan de lanzamiento se utiliza para planificar el desarrollo de las funcionalidades a corto

plazo, en contraste con el roadmap, que establece el ritmo de la estrategia a medio/largo plazo.
Complementario al roadmap, el plan de lanzamiento debe contener:
◉ El nombre del lanzamiento y la fecha. Puedes indicar una fecha precisa si es

fija o un horizonte de tiempo (mes, semana, etc.).
◉ Las funcionalidades principales incluidas en el lanzamiento.
Plan de lanzamiento del equipo de Activación
Puedes construir tu plan de lanzamiento utilizando, por ejemplo, la plantilla Go product

roadmap de Roman Pichler, autor y formador reconocido. A pesar de su nombre, que puede
llevar a confusión, esta tiene la ventaja de presentar la temporalidad, el objetivo, las funciona-
lidades y, posiblemente, las métricas a seguir después de la puesta en producción para medir el
logro del objetivo establecido.
135
MÓDULO №3
La Go Product Roadmap (plantilla)
El plan de lanzamiento sirve, ante todo, para dirigir y sincronizar al equipo alrededor
del objetivo común. Al igual que las otras herramientas del equipo de Producto, se actualiza a
medida que avanza el desarrollo (después de cada final de sprint o puesta en producción) para
reflejar de la mejor manera la situación actual.
136
MÓDULO №3
Nuestros consejos
◉ Para facilitar las estimaciones, compara dos elementos del backlog
entre ellos para identificar el más complejo. Con el tiempo, puedes
determinar qué elemento es de tamaño M en comparación con un L,
por ejemplo, y así establecer un referencial.
◉ A veces te encontrarás dividido entre tus stakeholders que exigen

una fecha de entrega precisa, y tu equipo que teme que una fecha
sea percibida como un compromiso firme. Sé pedagógico, recuerda
que es importante dar visibilidad para permitir que otros equipos se
organicen, pero también que las previsiones pueden cambiar.
◉ Cuando hagas tu plan de lanzamiento, piensa en reservar ancho

de banda para los temas menores que no hayas planificado, como
la corrección de anomalías o pequeñas mejoras. Para ello, evita
sobrecargar los lanzamientos e indica que un porcentaje de la
capacidad del equipo estará dedicado a estos temas.
137
MÓDULO №3
CAPÍTULO 13
Seguir el progreso
y gestionar los
imprevistos
A medida que avanza el desarrollo, las estimaciones relacionadas con la fecha de entrega
de una funcionalidad se hacen más precisas. Así, puedes ofrecer mayor visibilidad a tus
stakeholders. Buena noticia, existen herramientas para ayudarte a seguir el progreso del equipo
de Producto y ajustar tus estimaciones con total transparencia.
Seguir el avance de los desarrollos
La importancia de la gestión visual
Particularmente apreciada en Kanban, la gestión visual es una herramienta poderosa para

seguir los desarrollos y resaltar los posibles bloqueos. A partir de los indicadores de cycle time
(capítulo 11) o durante sus intercambios regulares con el equipo, pueden identificar cuando
un elemento del backlog pasa más tiempo del previsto en una etapa y, por lo tanto, se retrasa.
Les aconsejamos entonces usar un código visual propio de su equipo para resaltar este bloqueo
(una bandera en Jira, un punto adhesivo en un post-it, etc.). En los días siguientes, pueden así
monitorear el avance del tema más atentamente y tomar acciones concretas para desbloquear
la situación si es necesario.
138
MÓDULO №3
Ejemplo de gestión visual
El burn-down
El burn-down permite seguir el avance de los desarrollos en un sprint, varios sprints o

varias semanas. El burn-down es una representación gráfica del alcance restante por hacer, es
decir, el conjunto de Historias de Usuario que aún no cumplen con los criterios de su Definition
of Done (capítulo 14). El eje de las abscisas del gráfico muestra el tiempo (sprint, día o semana),
mientras que el eje de las ordenadas indica el número de puntos de complejidad o de Historias
de Usuario del alcance. Utilizando los indicadores de velocidad o de flujo (capítulo 12), pueden
trazar la trayectoria ideal a seguir. Al actualizar regularmente el burn-down de acuerdo con el
ritmo real de desarrollo, es más fácil comparar el avance de los desarrollos con sus previsiones.
Burn-down de un sprint Burn-down de un proyecto

139
MÓDULO №3
El burn-up
Similar al burn-down, el burn-up también se construye sobre la base del número de puntos
de complejidad o de Historias de Usuario. Esta vez, el gráfico representa el alcance realizado y
es especialmente útil para hacer seguimiento a lo largo de varios sprints o semanas. Midiendo la
velocidad o el flujo de manera regular, sus hipótesis se vuelven más precisas sobre:
◉ La fecha de finalización del alcance elegido (MVP, primera versión...).
◉ El alcance que serán capaces de entregar en una fecha determinada.
Ejemplo de uso de un burn-up

140
MÓDULO №3
En caso de imprevistos, ajustar e
informar
Tratar un bloqueo en un tema en desarrollo
A pesar de todos sus esfuerzos de estimación y previsibilidad, a veces ocurre un imprevisto

que bloquea el avance de los desarrollos:
◉ La solución técnica prevista no es viable.
◉ Un problema de deuda técnica les impide avanzar como se había planificado.
◉ Una dependencia no había sido detectada previamente.
◉ Una ausencia imprevista en el equipo.
Si esto sucede, acérquense rápidamente a las personas adecuadas para identificar y resol-
ver el problema. No duden en liberar tiempo al equipo para llevar a cabo una investigación más
profunda, redefinir la Historia de Usuario para entregar solo una parte del alcance o bien revisar
la priorización para resolver el problema antes de pasar a otro tema.
Ajustar los tiempos y dar un índice de confianza
Las herramientas que les hemos presentado anteriormente os ayudan a detectar posibles
retrasos en los desarrollos. Debéis utilizar estos elementos para ajustar vuestras hipótesis de
entrega y vuestro plan de lanzamiento (capítulo 12). Esto es aún más cierto si otros equipos se
ven impactados por la entrega de una funcionalidad. Puede tratarse de otro equipo que depende
de este desarrollo para avanzar o de otro departamento (como marketing o servicio al cliente)
que espera la entrega de la funcionalidad para lanzar una campaña o responder a clientes.
Además de estos reajustes temporales, podéis utilizar un índice de confianza sobre la fecha
de entrega para comunicar también a vuestros stakeholders. Vuestro índice de confianza está
influenciado por diferentes elementos como el nivel de dependencia respecto a otro equipo,
el nivel de incertidumbre sobre la solución técnica prevista, o el número de stakeholders que
deben intervenir en la validación de los desarrollos. Por supuesto, cuanto más se acerquen al
final de los desarrollos, menos incertidumbre sobre la fecha de finalización habrá y mayor será
vuestro índice de confianza.
141
MÓDULO №3
Nuestros consejos
◉ Comunica regularmente y haz accesible la información sobre el
avance de los desarrollos. Esto puede evitarte tener que responder
individualmente a las preguntas de los stakeholders.
◉ Se transparente sobre los posibles bloqueos explicando las razones de

los retrasos y las medidas implementadas para remediarlos.
◉ Sé cuidadoso cuando utilices los burn-up y burn-down para comunicar.

Por sí solos, estos instrumentos pueden ser utilizados de manera
inadecuada, para evaluar el rendimiento de los equipos o la capacidad
de producción. Se centran en el resultado sin destacar las causas de
los posibles retrasos o bloqueos.
142
143
MÓDULO №3
CAPÍTULO 14
Entregar las
funcionalidades
Cuando los desarrollos están a punto de finalizar y las funcionalidades están casi listas
para ser entregadas, deben asegurarse de que estas cumplan con los criterios de aceptación
de las Historias de Usuario y se ajusten a la Definition of Done, sin comprometer la calidad del
producto existente.
Probar las funcionalidades

En el equipo, cada uno tiene un papel que desempeñar para cubrir las pruebas técnicas y
funcionales de cada funcionalidad y permitir ofrecer a los usuarios funcionalidades de calidad:
◉ Los desarrolladores prueban sus desarrollos integrando pruebas técnicas.
◉ Los Product Designers y Product Managers realizan pruebas fun-

cionales que buscan validar la conformidad de los desarrollos con lo esperado, des-
crito en las Historias de Usuario y los prototipos.
◉ Los Testers redactan, ejecutan y mantienen campañas de pruebas

funcionales avanzadas, automatizadas o no.
144
MÓDULO №3
Enfoque en las pruebas técnicas
◉ Las pruebas unitarias verifican si el producto funciona correc-

tamente a nivel de la implementación del código. Son una pro-
tección contra las regresiones.
◉ Las pruebas de integración verifican si la aplicación se comu-

nica correctamente con las otras partes de la aplicación.
◉ Las pruebas de rendimiento, carga o resiliencia verifican si la

aplicación es robusta y resiste al intenso uso
Realizar las pruebas de aceptación
Las pruebas de aceptación verifican que las funcionalidades desarrolladas cumplan con los
criterios de aceptación de las Historias de Usuario (capítulo 10). Podéis redactar las pruebas de
aceptación utilizando el BDD (Behaviour-Driven Development). Inventado por Dan North, el
BDD consiste en redactar pruebas que describen el comportamiento esperado de la funcionali-
dad en un lenguaje comprensible para todos y con ejemplos concretos. El objetivo es facilitar la
comprensión del resultado funcional esperado entre vosotros, los desarrolladores, los testers y
también de probar fácilmente las Historias de Usuario. Al validar una Historia de Usuario, pue-
den referirse a la lista de criterios de aceptación, desplegar todos los escenarios de prueba y así
verificar que cada criterio se cumpla correctamente.
Podéis uniformar la sintaxis de las pruebas de aceptación utilizando el lenguaje Gherkin.

Este lenguaje se basa en una sintaxis estandarizada, que se presenta de la siguiente manera:
GIVEN (dado que): los prerrequisitos para la correcta ejecución de la prueba.
WHEN (cuando): acción a realizar.

THEN (entonces): resultado esperado.
La estructura Gherkin no solo facilita la lectura, sino que también permite ser reutilizada
para alimentar la automatización de pruebas.
Para cada Historia de Usuario, y especialmente para cada criterio de aceptación de su

Historia de Usuario, pueden redactar uno o varios tests en Gherkin. El objetivo no es parafra-
145
MÓDULO №3
sear las reglas de negocio, sino proporcionar ejemplos precisos, especialmente para casos de
errores o casos marginales.
Tests de aceptación de una Historia de Usuario del

equipo de Activación
146
MÓDULO №3
Realizar pruebas de no regresión
Antes de desplegar una nueva funcionalidad, es importante asegurarse de que esta no

impacte negativamente en el funcionamiento global del producto. Para ello, lleva a cabo prue-
bas denominadas de no regresión. Sin embargo, estas pruebas pueden rápidamente convertirse
en consumidoras de tiempo. Por lo tanto, debes priorizar los casos a probar (los recorridos con
más tráfico, los casos de uso más críticos...).
La automatización de los tests también es una estrategia interesante para facilitar las cam-
pañas de tests de no regresión. Dependiendo de las organizaciones, las pruebas automatizadas
pueden ser implementadas directamente por los desarrolladores durante la implementación de
una Historia de Usuario o por un tester automatizador.
Adaptar sus esfuerzos de prueba
Dependiendo de la madurez de tu producto, del tipo de funcionalidad, del contexto com-

petitivo o legal, tu estrategia de prueba para las nuevas funcionalidades no será equivalente. En
equipo, debéis definir la profundidad de las pruebas que deseáis llevar a cabo. Esta se reflejará a
través del número de pruebas de aceptación a realizar y en la inversión en Quality Assurance (QA
147
MÓDULO №3
por sus siglas en inglés). Sin embargo, hay que tener en mente que probablemente no se puedan
cubrir todos los casos marginales. Hay que aceptar que para algunos usuarios minoritarios, el
funcionamiento no será totalmente optimizado.
En un equipo que requiere un ejercicio de QA minucioso, el refuerzo de testers dedicados al

equipo es una ventaja considerable. No obstante, si no cuentan con testers, aseguraos de colaborar
bien con el equipo de desarrollo y liberar tiempo para probar de manera adecuada. Cuando esta
situación se vuelve demasiado exigente e influye en la calidad del discovery (porque tienen poco
tiempo para dedicarle) o la velocidad del equipo (porque los desarrolladores pasan demasiado
tiempo en las pruebas), es recomendable sugerir al líder de Producto establecer un verdadero
equipo de QA que pueda ayudarles en la optimización y automatización de las pruebas.
Desplegar funcionalidades
Verificar la Definition of Done
Al igual que la Definition of Ready (capítulo 11), la Definition of Done (DoD) es un contrato
establecido con el equipo de desarrollo, y reúne en forma de lista el conjunto de criterios que
debe respetar una Historia de Usuario para ser considerada como terminada. Su rol es, espe-
cialmente, verificar que se haya realizado una revisión de código, que las pruebas de acep-
tación estén validadas, que la documentación esté actualizada y que el etiquetado esté bien
implementado.
Definición de “Done” del equipo de Activación

148
MÓDULO №3
La DoD debe permanecer en los hechos, ser realista y ser exhaustiva. No obstante, puede
evolucionar para reajustar el nivel de calidad cuando sea necesario. Una vez que sus Historias
de Usuario validan la DoD, pueden desplegar las funcionalidades en producción.
¿Cuándo organizar una reunión de Go/No Go para

el despliegue?
Cuando trabajes en un tema arriesgado que requiere una validación por

parte de un equipo específico, o cuando lancéis una nueva funcionalidad
que impacta a varios equipos y que requiere una coordinación de las
actividades de lanzamiento (varias puestas en producción sucesivas en
el caso de una asociación, formación de equipos en el terreno...), debéis
prestar especial atención a la decisión de ponerlo en producción. En este
caso, organiza una reunión donde las partes interesadas puedan decidir
desplegar o no, y sobre todo, validar las etapas de lanzamiento.
Entregar de forma contínua o en release
Cuando el equipo considera que la funcionalidad puede ir a producción, tienen la opción

de entregar la funcionalidad inmediatamente a los usuarios o esperar para ofrecer un conjunto
de funcionalidades coherentes. Aquí las diferentes aproximaciones:
◉ La entrega continua: las funcionalidades se ponen en producción en cuanto las

Historias de Usuario cumplen con los criterios de la Definition of Done. La ventaja
de esta aproximación es que permite entregar las funcionalidades lo más rápido
posible para recoger feedback. No obstante, esta aproximación implica un desglose
en Historias de Usuario independientes que aportan valor por sí mismas para ser
entregadas directamente a los usuarios.
◉ La creación de release: varias funcionalidades se agrupan para formar un

incremento en el Producto coherente para entregar. La release permite entregar un
bloque funcional más completo a los usuarios. Esta aproximación se debe favorecer
cuando los equipos tienen fuertes dependencias o cuando trabajan en un producto

para el cual el nivel de exigencia es alto. Por ejemplo, para una API bancaria, el riesgo
de entregar a los usuarios un modo degradado de una funcionalidad sobre la cual se
iterará más tarde es demasiado importante. Se preferirá entregar una release más
completa que asegure el nivel de calidad y seguridad esperado por los usuarios.
149
MÓDULO №3
Actividades después del despliegue
Verificar la producción
Una vez realizada la entrega y si el producto lo permite, no dudes en hacer una verificación
rápida en producción. Si detectáis un problema o una anomalía, se puede:
◉ Realizar un rollback volviendo a la versión anterior de la aplicación para

restaurar instantáneamente el correcto funcionamiento de su producto, y luego
investigar el problema con calma.
◉ Realizar un hotfix entregando rápidamente una corrección.
Activar las funcionalidades con un feature flag
Un feature flag o feature toggle es una técnica que permite activar o desactivar fácilmente
una funcionalidad en producción, sin necesidad de un despliegue específico. Gracias al feature
flag, pueden entregar sus funcionalidades en producción y activarlas más tarde o solo para un
público objetivo. Esta técnica ofrece numerosas ventajas:
◉ Ofrecer más flexibilidad al equipo al disociar el despliegue, por un lado, de la

disponibilidad de la funcionalidad para los usuarios, por otro.
◉ Facilitar el rollback en caso de problema, desactivando la funcionalidad

mientras se realizan los correctivos necesarios.
◉ Hacer disponible gradualmente una funcionalidad, activándola para un

público limitado antes de hacerla accesible para todos los usuarios.
◉ Facilitar la gestión de las pruebas de propuestas de valor (capítulo 8) o expe-

rimentaciones (capítulo 18), activándolas para objetivos específicos en un tiempo
limitado.
150
MÓDULO №3
Nuestros consejos
◉ No esperar a que las Historias de Usuario estén terminadas para
probar. Probar localmente con los desarrolladores puede ayudar a
detectar algunos ajustes muy rápidamente.
◉ Las pruebas funcionales no son únicamente responsabilidad de los

Product Managers, especialmente si no tenéis testers en el equipo.
Los desarrolladores pueden realizar pruebas cruzadas durante la
revisión del código para verificar la funcionalidad desarrollada por un
compañero.
◉ Asegurar un alto nivel de calidad del producto es un proceso que

va más allá de los tests. Cuanto más colaboréis desde el principio
de los desarrollos en el refinamiento y la redacción de los criterios
de aceptación en el equipo, así como en el respeto de la DoR, más
fácilmente validaréis la etapa de tests.
151
MÓDULO №3
CAPITULO 15
Gestionar el
lanzamiento de las
funcionalidades
¡Tu nueva funcionalidad está disponible y quieres darla a conocer! Para hacerlo, necesitas
comunicarte tanto interna como externamente para facilitar su adopción y asegurarte de
recopilar rápidamente feedback. Los Product Marketing Managers serán tus mayores aliados
para construir una estrategia de Go-To-Market efectiva y coherente.
Las actividades del Product Marketing

Manager
Comunicar sobre las novedades puede requerir un esfuerzo más intenso con una verdadera
estrategia de posicionamiento y de Go-To-Market. Siendo el eslabón real entre la parte comercial
y la parte de Producto, el Product Marketing Manager (PMM) va a ayudaros especialmente a:
◉ Estudiar el mercado para conocer el entorno competitivo, comprender quién es el

comprador y contribuir a la estrategia de Producto (capítulo 1).
◉ Encontrar el mensaje impactante que destaque las características y los beneficios de

las funcionalidades.
◉ Ayudar a vender bien el producto, coordinar la comunicación y asegurar un lanza-

miento al mercado sin dificultades.
◉ Coordinar los lanzamientos de varias funcionalidades o productos.
152
MÓDULO №3
El Marketing de Producto, enlace entre la parte comercial y
el Product Management
Sales Product Product Tech

& business marketing management
Informar a los equipos internamente
Comunicar y recopilar feedback
La comunicación con las partes interesadas es una actividad central para los Product
Managers. Un momento crucial al que deben prestar especial atención es el lanzamiento de
nuevas funcionalidades para comunicar sobre los cambios, el impacto esperado, el alcance... Para
ello, dispones de varios mecanismos que te permiten asegurar que las partes interesadas estén
informadas sobre las nuevas funcionalidades:
◉ La release note (interna): es un mensaje conciso para comunicar rápidamente

sobre las novedades. En tu nota de lanzamiento interna, describe brevemente
la funcionalidad, recuerda el impacto esperado, proporciona el enlace a la
documentación para encontrar información más detallada y agradece a todas las
personas que han contribuido al lanzamiento de esta nueva funcionalida
153
MÓDULO №3
Una nota de lanzamiento interna del equipo de Activación
◉ La review : es una reunión para hacer la demostración de la funcionalidad y recibir

feedback de manera instantánea. La review te permite intercambiar más a fondo
sobre las especificidades y el funcionamiento de la funcionalidad, responder a las
preguntas de tus stakeholders y recoger feedback en directo.
Documentar eficazmente
La comunicación de tus nuevas funcionalidades también pasa por la documentación.

Documentar te permite afinar las sutilezas del producto y te ahorra tiempo cuando necesites
explicar con más detalle su funcionamiento. Consolidar el conocimiento del Producto en el mismo
lugar permite crear una única fuente de la verdad. Así puedes incentivar a los equipos a referirse a
la documentación cuando sea necesario.
Para que sea comprendida por todos, es importante que la documentación sea clara, concisa
y sin jerga técnica. Para lograrlo, redacta la documentación desde un punto de vista del usuario,
explica por qué decidiste implementar la funcionalidad y en qué consiste antes de detallar su
funcionamiento paso a paso. También puedes mantener un glosario para los términos específicos
del sector y añadir capturas de pantalla para facilitar la comprensión. Piensa igualmente en los
soportes anexos tales como las FAQ y los How-to para formar a los equipos de servicio al cliente
que deberán responder a las preguntas de los usuarios.
Piensa en la documentación como un producto, es el reflejo de tu propio producto y debe

evolucionar con él. Distribuir el esfuerzo de documentación en el tiempo hace la tarea menos tediosa,
evitando así la pérdida de información. Para asegurarte de actualizarla en cada iteración, puedes
integrar en la Definition of Done el hecho de haber redactado la documentación de la funcionalidad.
154
MÓDULO №3
Gestionar el lanzamiento de sus nuevas
funcionalidades
Comunicar sobre las novedades
Ahora que los equipos internos están alineados, es momento de pensar en informar a
los clientes (los que compran) y los usuarios (los que usan) sobre las mejoras. Esta actividad
podría ser realizada por tu Product Marketing Manager. En ausencia de un PMM, debéis
asumir una parte de la responsabilidad y compartirla con el equipo de marketing y/o el equipo
comercial. Intenta identificar las necesidades clave de los equipos para que puedan tomar el
relevo: considera una sesión informativa para explicar por qué desarrollaste este producto
o funcionalidad, hacedles una demostración… Identificad los canales de comunicación más
apropiados para su lanzamiento. Para ayudarles, aquí tienen algunas ideas:
◉ La release note (externa): mostrada directamente en el producto, la newsletter

o en la tienda para una aplicación móvil, es un buen medio para atraer la atención del
usuario o los clientes sobre nuevas funcionalidades, al mismo tiempo que refuerza el
vínculo que mantienen con la marca.
155
MÓDULO №3
Una nota de lanzamiento externa del equipo de Activación
◉ Las campañas de adquisición y de concienciación: si acabáis de lanzar

una funcionalidad importante o una nueva oferta que requiere una comunicación
especial, considerad organizar campañas de adquisición o de concienciación a través
de campañas publicitarias, newsletters o un email bien dirigido.
156
MÓDULO №3
Acompañar a los usuarios
Antes de un lanzamiento, evalúa la necesidad de prever un onboarding para acompañar a los

usuarios y piensa en cómo van a apropiarse del producto o de la funcionalidad. ¿Es fácilmente
visible durante el recorrido o requiere un acompañamiento específico? Si es así, probablemente
sea necesario establecer un proceso de onboarding. Este consiste en presentar la funcionalidad
dentro de su aplicación. De manera secuencial, hay que mostrar al usuario el beneficio y luego
el recorrido que se ha diseñado para él o ella. Intenta activar el onboarding en un momento
pertinente y preséntalo una sola vez, permitiendo al usuario omitirlo si así lo desea.
Nuestros consejos
◉ Se transparente y adapta el lenguaje a los diferentes interlocutores.
Cuanto más os esforcéis por clarificar y simplificar sin utilizar
jerga, mejores serán los feedbacks que podréis recibir sobre las
funcionalidades.
◉ El objetivo de la comunicación interna y de la documentación es informar

y compartir el conocimiento. Apuesta por formatos impactantes:
mensaje en Slack, cuestionarios, vídeos, reuniones mensuales…
◉ ¡Bloquea tiempo para documentar! El viernes, por ejemplo, cuando las

urgencias de la semana han pasado, es un momento ideal...
157
MÓDULO №3
Lo esencial de este
módulo
1. El backlog es una herramienta que agrupa los elementos que constituyen el producto.
Evoluciona y se precisa a lo largo de las actividades de refinamiento.
2. El backlog refinement es un conjunto de actividades que conducen a discusiones en

equipo con el objetivo de acordar una visión común de las funcionalidades a entregar
y especificarlas.
3. Agile es el cuadro de trabajo que os permite entregar las funcionalidades del Producto
lo más rápidamente posible mediante pequeños incrementos en cadena.
4. No podéis predecir una fecha exacta de lanzamiento para las funcionalidades, pero
hay herramientas que pueden ayudaros a emitir una hipótesis, aunque sea necesario
ajustarla durante el desarrollo para dar visibilidad a los stakeholders.
5. El plan de lanzamiento es complementario al roadmap y permite planificar el

desarrollo de las funcionalidades a corto plazo.
6. La calidad es asunto de todo el equipo. Diferentes tipos de pruebas funcionales y

técnicas os permiten validar los desarrollos.
7. Además de las pruebas, otros medios aseguran que entreguéis funcionalidades de

calidad y en buenas condiciones: los criterios de aceptación, la Definition of Done, la
entrega continua, la feature flag...
8. Durante los lanzamientos, pensad en comunicar de manera proactiva internamente a

los stakeholders y externamente a los usuarios.
9. Los Product Marketing Managers son una ayuda valiosa para asegurar un lanzamiento
eficaz de nuevas funcionalidades.
158
159
4—
Mejora
continua
«Los equipos de Producto

deben adoptar una cultura de
experimentación, aprendizaje y
mejora continua. Se trata de ser
adaptable y de utilizar los datos
y la retroalimentación para
guiar la toma de decisiones.»
— Melissa Perri
MÓDULO №4
El ciclo de vida de un producto no se detiene cuando se lanza a producción.
La mejora continua de un producto es esencial para garantizar su éxito a largo
plazo. El mundo evoluciona constantemente y las tendencias del mercado y
las expectativas de los usuarios cambian con rapidez. Es tu responsabilidad
garantizar que tu producto siga siendo competitivo y relevante, midiendo
el impacto en los usuarios y en la empresa. Tus prácticas como equipo y el
trabajo en colaboración con las partes interesadas también son clave para el
éxito del producto. En este módulo, te ayudaremos a definir medidas de éxito,
recopilar y analizar datos para tomar decisiones para el producto. Veremos
cómo combinar el discovery y la entrega continua para hacer evolucionar el
producto, ya sea mejorando, optimizando o eliminando funciones. Veremos
cómo garantizar la calidad del producto a largo plazo. Por último, estudiaremos
el enfoque y la postura que debes adoptar para trabajar con tu equipo y las
partes interesadas para dar vida a tu producto y maximizar su impacto.
Mejora continua
161
MÓDULO №4
CAPÍTULO 16
Definir las medidas del

éxito
Una de tus principales responsabilidades es asegurarte de que el producto del que eres
responsable aporte valor, tanto a los usuarios como a la empresa. Por lo tanto, para medir el éxito
de un producto, debes tener en cuenta numerosos factores, como la satisfacción del cliente, la
frecuencia de uso, el crecimiento de los ingresos, la cuota de mercado, etc. En este capítulo, veremos
cómo medir el éxito de las funcionalidades del producto y las medidas más relevantes a poner en
marcha.
Cómo medir el éxito
Ser informado por datos
En cada etapa del proceso de Producto, los datos te ayudan a tomar las decisiones correctas a
través de señales que debes interpretar. Aunque no se trata de dejar que los números determinen
tus elecciones, se espera que seas informado por datos, es decir, que enriquezcas tus intuiciones y
observaciones para respaldar tus decisiones. «Sin datos, solo eres otra persona con una opinión.
Sin opinión, solo eres otra persona con datos», como bien dijo el estadístico estadounidense W.
Edwards Deming.
Ser informado por datos significa recopilar datos para generar insights. Te corresponde
compartir e intercambiar información con las partes interesadas, confrontar los análisis para
obtener aprendizajes y tomar decisiones.
Mejora continua
162
MÓDULO №4
Datos, KPI, Métrica: ¿cuál es la diferencia?
◉ Los datos son información en bruto. Se recopilan, almacenan y

procesan para ser utilizados en el seguimiento de métricas o KPI,
como el número de usuarios activos, por ejemplo.
◉ Una métrica es una medida obtenida a partir de datos brutos.

Transforma estos datos en una medida significativa que permite
evaluar el rendimiento de un producto, como el número de usuarios
activos mensuales, por ejemplo.
◉ Un KPI es un indicador clave de rendimiento que mide los elementos

más importantes de tu producto y el logro de tus objetivos a largo
plazo. Evalúa el estado de salud de tu producto, como el 75% de
usuarios activos mensuales durante el trimestre, por ejemplo.
Medir el éxito en diferentes niveles
El éxito de tu producto puede medirse en diferentes niveles. Puedes hacer un seguimiento

de KPI relacionados con el logro de tus objetivos, el impacto de tus funcionalidades, pero
también con el rendimiento general del producto.
Medir el logro de tus objetivos
Cuando defines objetivos para tu equipo, también debes definir KPI asociados que permi-
tan medir el logro de estos objetivos. Estos son los principales indicadores clave de rendimiento
(KPI) que hay que controlar para evaluar si se están alcanzando las ambiciones que te has
fijado.
Medir el impacto de tus funcionalidades
Cuando lanzas nuevas funcionalidades, es probable que no satisfagan perfectamente las

necesidades de tus usuarios, incluso si has tomado la precaución de probar cuidadosamente tus
Mejora continua
soluciones de antemano. Probablemente, necesitarás realizar ajustes e iterar según los comen-
tarios de los clientes. Para ayudarte a medir este impacto, te aconsejamos seguir métricas rela-
cionadas con tus funcionalidades. Por ejemplo:
163
MÓDULO №4
◉ El uso y la participación de los usuarios (tasa de uso, número de usos por

usuario).
◉ La conversión y la tasa de rebote.
◉ El rendimiento técnico (tiempo de carga, tasa de fallos).
Medir el rendimiento del producto
Tu producto, o el ámbito en el que interviene tu equipo, por su contribución al rendimiento

general de la empresa, tiene un impacto global que puedes seguir mediante métricas de
impacto, tales como:
◉ El uso del producto (compromiso, adopción, retención).
◉ El negocio aportado por el producto (conversión, ingresos).
◉ La satisfacción de tus usuarios (NPS, CSAT) ;
◉ La estabilidad y el rendimiento técnico global de tu producto.
Es posible que ya estés siguiendo parcialmente estas métricas si están directamente rela-
cionadas con tus objetivos. Sin embargo, tus objetivos trimestrales pueden llevarte a concen-
trarte solo en una parte de todo tu ámbito. Esto no te impide vigilar las métricas globales para
asegurarte de que el rendimiento se mantiene.
Medir, sí, pero ¿qué?
Medir el outcome
En general, las medidas de output (producción), como la velocidad (número de puntos de

complejidad, líneas de código, bugs...), el desarrollo de funcionalidades (número de Historias
de Usuario, número de lanzamientos...), el cumplimiento de los plazos (time-to-market), no
son buenos indicadores de éxito. Aunque pueden ser relevantes para planificar los desarrollos
Mejora continua
y proporcionar visibilidad, no miden la creación de valor. Centrarse en estas medidas puede

llevar a un equipo a caer en la trampa de construir funcionalidades sin preocuparse por el
impacto. Al describir este peligro, la coach y autora estadounidense Melissa Perri destaca la
importancia de que un equipo de Producto se centre en el valor para los usuarios y la empresa.
Por lo tanto, te aconsejamos que prefieras seguir medidas de outcome (impacto).
164
MÓDULO №4
Evitar las métricas de vanidad
Las métricas de vanidad son aquellas que dan la impresión de que el producto funciona
bien, pero que no reflejan el impacto real de una acción o decisión. A menudo es difícil inter-
pretarlas correctamente.
Una buena métrica debe ayudar a la toma de decisiones. Para ser accionable, debe ser:
◉ Fácil de medir y comprender.
◉ Medir una evolución en lugar de un número absoluto.
Métricas del equipo de Activación
Para el equipo, cuya misión es maximizar el número de usuarios que realizan

un primer pedido, se consideran métricas de vanidad:
◉ El número de nuevos usuarios: aunque un número elevado pueda

parecer impresionante, no necesariamente refleja la calidad de
estos nuevos usuarios y su predisposición a realizar un pedido.
Podrías estar tentado de inflar el número de nuevos usuarios
mediante técnicas agresivas de adquisición, pero esto no te ayu-
dará a cumplir tu misión.
◉ El número de búsquedas de restaurantes: un gran número de

búsquedas puede parecer positivo, ya que podría significar un gran
interés de los usuarios en realizar pedidos. Sin embargo, también
podría indicar una gran dificultad para los usuarios para encon-
trar lo que buscan. La métrica es difícil de interpretar y accionar.
Mejora continua
165
MÓDULO №4
En su lugar, el equipo utilizará las siguientes métricas:
◉ Porcentaje de crecimiento del número de usuarios que realizan un

primer pedido: aquí nos interesamos únicamente en los usuarios
verdaderamente interesados en el servicio, mientras medimos el
progreso a lo largo del tiempo.
◉ Porcentaje de nuevos usuarios que realizan un primer pedido: esto

permite evaluar la calidad de los esfuerzos de adquisición.
El uso simultáneo de estos dos indicadores asegura que atraigas más y

más nuevos usuarios a lo largo del tiempo y que estos usuarios estén bien
orientados e interesados en tu producto.
Métricas adelantadas y rezagadas
Para obtener una visión completa del rendimiento de tu producto, es importante medir
tanto las métricas adelantadas como las rezagadas. Las métricas adelantadas ayudan a tomar
decisiones informadas, mientras que las métricas rezagadas permiten medir el impacto a largo
plazo y las áreas que requieren mejoras.
Las métricas rezagadas son medidas de resultados pasados. Se les llama rezagadas
porque el impacto en estas métricas llega demasiado tarde para ser accionable. Es el reflejo
de decisiones o acciones pasadas. Esto es especialmente cierto en el caso de las ventas, que
representan el resultado anual, pero se miden al final del ciclo, cuando es demasiado tarde para
influir en ellas. Aunque estas medidas son esenciales, son difíciles de impactar directamente
con las funcionalidades lanzadas.
Por otro lado, las métricas adelantadas miden el cambio inmediato. Pueden ser seguidos en
tiempo real y son más fáciles de influir mediante nuevas funcionalidades.
Para influir en tus métricas rezagadas, descomponlas en varias métricas adelantadas que
puedas impactar más fácilmente. Aumentando el número de usuarios o de nuevos clientes,
puedes predecir un aumento de las ventas.
Mejora continua
166
MÓDULO №4
Métricas adelantadas y rezagadas del equipo de Activación
El equipo quiere aumentar las ventas generadas por los primeros pedidos.
Se trata de una métrica rezagada, difícil de impactar directamente. Por ello,
ha identificado varias métricas adelantadas: ventas de primeros pedidos =
número de nuevos usuarios * tasa de conversión * cesta media.
Así, para aumentar las ventas, el equipo puede:
◉ Aumentar el número de nuevos usuarios.
◉ Aumentar la tasa de conversión.
◉ Aumentar la cesta promedio.
Métricas piratas
Si no sabes por dónde empezar, las métricas piratas, también conocidas como el marco
AARRR, ofrecen un buen punto de partida para enmarcar tus KPI. Creadas por el empresario e
inversor Dave McClure, estas métricas se basan en cinco desafíos que reflejan las etapas de la
vida de un usuario:
◉ Adquisición : mide el rendimiento de los canales a través de los cuales tus usua-
rios acceden a tu producto (número de visitas por mes, tasa de conversión, coste de
adquisición...).
◉ Activación : mide la capacidad de activar a tus usuarios, es decir, incitarlos a usar tu

producto de manera significativa (porcentaje de usuarios que realizan una acción clave
por primera vez).
◉ Retención : mide la capacidad de retener a tus usuarios activados a lo largo del

tiempo (tasa de retención).
◉ Recomendación : mide la tendencia de tus usuarios a captar nuevos usuarios

Mejora continua
por recomendación (porcentaje de usuarios que hacen recomendaciones, tasa de

conversión de usuarios referidos...).
◉ Ingresos : mide la monetización de tu producto (conversión de usuarios gratuitos a

usuarios premium de pago, el valor de vida del cliente...).
167
MÓDULO №4
Métricas Piratas del equipo de Activación

Mejora continua
168
MÓDULO №4
Nuestros consejos
◉ Considera anotar el KPI de tu funcionalidad en tu descripción de la
Épica para enmarcar la ambición desde el inicio y medir su impacto una
vez entregada.
◉ Si has definido tus objetivos en formato OKR, puedes identificar un

resultado clave (KR) que sea una métrica adelantada para medir el
impacto directo de tus acciones y un KR que sea una métrica rezagada
para medir el impacto a largo plazo en el producto.
◉ Para seguir regularmente el éxito, revisa tus indicadores clave de

rendimiento (KPI) cada semana o cada mes. Presta especial atención
al seguimiento durante las entregas de funcionalidades importantes.
Mejora continua
169
MÓDULO №4
CAPÍTULO 17
Recolección y
seguimiento de datos
La recolección y el seguimiento de datos cuantitativos y cualitativos son esenciales para
evaluar el éxito de un producto. Estos datos te permiten entender las necesidades y expectativas
de los usuarios, identificar las fortalezas y debilidades de un producto, y tomar decisiones
estratégicas informadas. En este capítulo, exploramos los métodos y herramientas para
recolectar y visualizar datos.
Recolectar Datos Cuantitativos
¿Qué es un Plan de Etiquetado?
Un plan de etiquetado, también llamado plan de marcado o plan de seguimiento, es un

documento que describe cómo se utilizan las etiquetas para recolectar datos sobre una web o
una aplicación móvil. Las etiquetas son elementos de código que permiten recopilar datos sobre
el comportamiento de los usuarios, tales como las páginas visitadas, las acciones realizadas, la
duración de la visita, etc.
El plan de etiquetado determina los eventos que deben rastrearse (generalmente las
acciones del usuario), las variables a recolectar y las reglas de activación de las etiquetas.
Generalmente, se elabora en colaboración con un Analista de Producto y los desarrol-

ladores. El plan de etiquetado asegura una recolección de datos precisa y fiable, y debe evolu-
cionar a medida que lo hace el producto.
Mejora continua
170
MÓDULO №4
Ejemplo de Plan de Etiquetado
Dependiendo de las organizaciones, varios perfiles pueden ser responsables. Aquí están los
diferentes casos:
◉ Cada equipo se encarga de su plan de etiquetado. En este caso, es común

que no haya o haya pocos estándares comunes y disparidades entre los equipos.
◉ Un responsable de analítica se encarga de centralizar y redactar

las especificaciones: acompaña al equipo en la implementación (pero es
el equipo quien implementa), valida que funcione correctamente y mantiene un
estándar común.
◉ Un equipo dedicado se encarga de mantener el plan de etiquetado.

En el caso de sistemas complejos, o de amplios portafolios de productos o marcas,
es posible que un equipo dedicado sea responsable de crear y mantener el plan de
etiquetado.
Crear el Plan de Etiquetado

Mejora continua
El plan de etiquetado debe definirse antes del desarrollo, cuando decides qué medidas te
permitirán evaluar el impacto de una funcionalidad. Al elaborar el plan, prevé un etiquetado
lo suficientemente detallado para permitir un análisis del comportamiento de tus usuarios.
Al evaluar la tasa de abandono de un recorrido de usuario, considera hacerlo para cada etapa
171
MÓDULO №4
individual en lugar de para el recorrido completo. De lo contrario, podrías encontrar que el

rendimiento de tu funcionalidad es insuficiente, sin saber qué hacer para mejorar la situación.
También es esencial prever el etiquetado necesario para el seguimiento de tus objetivos de

Producto. Sin esto, no puedes saber cómo las entregas afectan a tus objetivos.
Ya sea para el etiquetado de las funcionalidades o del producto en general, aquí hay algunas
buenas prácticas:
◉ Escribe en inglés.
◉ Utiliza palabras raíz precisas y comprensibles para todos.
◉ Usa solo verbos de acción en cantidad limitada.
◉ Haz combinaciones entre palabra raíz y verbo de acción.
◉ Produce una pestaña por página o funcionalidad.
◉ Añade un estado de avance.
◉ Realiza QA para verificar que los datos se recopilan correctamente.
Una vez realizado el plan, la implementación de las etiquetas puede hacerse a través de her-
ramientas de gestión de etiquetas o directamente en el código por los desarrolladores.
Recolectar Datos Cualitativos
Explicar los Datos Cuantitativos a través del Cualitativo
Al lanzar nuevas funcionalidades, recolectar y analizar datos cuantitativos no es suficiente.

Los datos cuantitativos te proporcionan información sobre el “qué”, pero sin explicarte el
“por qué”. Por ejemplo, es posible que una nueva funcionalidad no tenga el éxito esperado,
sin entender las causas de este escaso entusiasmo. Para comprender el porqué, acércate a tus
Mejora continua
usuarios para explicar los análisis cuantitativos a través de retroalimentación cualitativa.
172
MÓDULO №4
El análisis conjunto de datos cuantitativos y cualitativos es importante para entender
bien los problemas de los usuarios. Sin embargo, no se trata de preguntarles cómo mejorar
tu producto o cómo evolucionar una funcionalidad. Aunque tu producto debe diseñarse y
construirse con el objetivo de responder a un problema del usuario, estar centrado en el usuario
no significa responder a todos sus deseos. Intentar comprender sus necesidades sigue siendo
tu principal objetivo. Si acuden a ti con soluciones, céntrate en los problemas subyacentes que
les llevan a pedir una solución concreta. Estos pueden servir de base a hipótesis para reanudar
el discovery.
Organizar la Recolección Cualitativa
Para recolectar retroalimentación sobre las funcionalidades que acabas de lanzar, puedes
proceder de manera activa yendo al encuentro de los usuarios, o de manera pasiva dejando que
los usuarios te proporcionen información. Para ello, hay varias formas de hacerlo:
◉ Enviar un cuestionario o una encuesta por correo electrónico a los usuarios

que han utilizado la funcionalidad.
◉ Añadir un módulo de comentarios en una etapa clave del recorrido para

incentivar al usuario a dejar una calificación o un comentario.
◉ Realizar entrevistas a usuarios después de una evolución del producto (capítulo 6).
◉ Analizar los recorridos para identificar fricciones mediante herramientas de

grabación de sesiones o mapas de calor.
◉ Tomar nota de los comentarios en las tiendas de aplicaciones o en Google.
◉ Incitar a los equipos de servicio al cliente, ventas y de customer success

a proporcionar feedback. Puedes implementar soportes estandarizados
para facilitar los intercambios (canal de comunicación preferente, reuniones de
intercambio, plantilla de retroalimentación para rellenar...).
Mejora continua
173
MÓDULO №4
Buenas Prácticas para Seguir Bien los

Datos
Menos es Más
Cuando se trata de datos cuantitativos como cualitativos, ¡menos es más! En resumen, solo
recolecta los datos que necesitas. Cuantos más datos tienes, menos enfoque tienes y menos
accionables son. Define tus criterios de éxito antes de pensar en qué dato recolectar (capítulo
15). Esto te ahorrará tiempo a la hora de poner en marcha tu plan de etiquetado, recopilar datos
y analizarlos. Considera también el aspecto ético (¡y regulado!) de la recolección de datos. No
olvides que tienes una responsabilidad para con tus usuarios: la de recolectar, transformar y
almacenar solo los datos que te permitan mejorar tu producto.
Sistematizar el Seguimiento
Es indispensable medir el impacto de las funcionalidades que entregas en producción.

Para no olvidarlo, puedes añadir una etapa a tu tablero Kanban. Una vez entregadas las
funcionalidades, colócalas en una columna “a supervisar”. El tiempo a partir del cual puedes ver
un impacto puede variar en función de tu sector de actividad, alcance y la propia funcionalidad.
El análisis de los datos te permite extraer aprendizajes, enriquecer y optimizar tu producto

(capítulo 18). Por lo tanto, las Historias de Usuario permanecerán en esta columna hasta que
decidas que se ha logrado el impacto deseado, o hasta que crees una nueva oportunidad o
Historias de Usuario evolutivas basadas en los datos analizados.
Añadir una Columna Dedicada al

Monitoreo al Tablero del Equipo
Mejora continua
174
MÓDULO №4
La Visualización de los Datos
Para visualizar y analizar los datos, dispones de varias herramientas. Elige aquellas que
ofrecen funcionalidades de procesamiento y formateo de datos. Te ahorrarán tiempo y te
ayudarán a extraer las informaciones esenciales. Para medir la audiencia y uso, herramientas
analíticas como Google Analytics o Amplitude son verdaderos aliados. Para realizar análisis de
recorridos, herramientas como Hotjar o Contentsquare son totalmente adecuadas.
La visualización de datos también puede ser utilizada con fines de comunicación interna.
Los líderes de una empresa no tienen ni el tiempo ni el deseo de desgranar un conjunto de datos.
Es tu responsabilidad hacer que los datos sean legibles de forma rápida, sencilla y eficaz en sus
informes o durante sus comités de dirección. Puedes usar un archivo Excel así como un soporte
más avanzado, con visualización de datos, a través de una herramienta como Looker Studio
(antes Google Data Studio) o Tableau. Para elegir los datos importantes que quieres compartir,
consulta tus objetivos y los indicadores clave de rendimiento que hayas definido (capítulo 15).
Nuestros Consejos
◉ Reserva regularmente tiempo en tu agenda para estructurar la recogida
de datos y llevar a cabo el análisis. El Discovery que irás haciendo poco a
poco te permitirán acelerar el conocimiento de tu producto y reforzar
tus convicciones.
◉ Cuando analices los datos recogidos, piensa en términos de recorrido del

usuario estudiando lo que ocurre antes y después. Los datos aislados de
su contexto rara vez son información fiable.
◉ Organiza sesiones para que tu equipo pueda ver las grabaciones

que registran el uso de tu producto, o navegar por los distintos
cuadros de mando. Invita también a las principales partes interesadas
para que participen y comparte con ellos estos conocimientos.
+
Mejora continua
175
MÓDULO №4
CAPÍTULO 18
Desarrollar el
producto
Al desarrollar un producto, es importante recordar que ofrecer nuevas funcionalidades
no es un fin en sí mismo. Debes desarrollar tu producto añadiendo nuevas funcionalidades,
pero siempre con el objetivo de satisfacer nuevas necesidades. Optimizar o eliminar las
funcionalidades existentes también son opciones sólidas. Para lograrlo, considera el Discovery y
el Delivery no como una sucesión de etapas lineales, sino como un proceso cíclico donde ambas
fases se llevan a cabo de manera paralela y continua.
Enriquecer, optimizar, eliminar
Crecer de manera responsable
Tu producto se enriquece con nuevas funcionalidades a medida que abordas nuevas

iniciativas del roadmap. Cada nueva iniciativa es una oportunidad para reflexionar sobre
la responsabilidad de tu producto. Independientemente de la misión de tu empresa, puedes
integrar gradualmente cambios que hagan tu producto más responsable. Esta responsabilidad
puede abordarse desde diferentes ángulos:
◉ Usuario : ¿son claros y transparentes los mensajes mostrados en tu producto?

¿Tratas los datos del usuario de manera responsable y asegurándote de tener su
consentimiento? ¿Es tu producto accesible para todas las personas? ¿Es fiable?
¿Reduce la frustración en caso de errores o fallos?
Mejora continua
176
MÓDULO №4
◉ Medio ambiente : ¿cómo puedes reducir el consumo energético de tu producto?
¿Reduces el tamaño de las páginas, el envío de emails innecesarios o los tiempos de
carga?
◉ Económico : ¿tu producto genera desequilibrios económicos en detrimento de tus

usuarios? ¿Son honestas tus opciones de pago o crean una dependencia injustificada
que impide al usuario cancelar su suscripción, por ejemplo?
Los 8 rasgos de responsabilidad de un producto por

Fabrice Des Mazery, autor de Responsables:
◉ Honesto : no miente, no embellece la realidad, no oculta nada, no

hace promesas que no puede cumplir al 100%.
◉ Meritorio : merece el tiempo, la atención y las emociones que solicita

de sus usuarios. El retorno sobre el compromiso del usuario debe
ser positivo.
◉ Abierto : no excluye a nadie que pueda beneficiarse legítimamente

de sus servicios.
◉ Cuidadoso : presta atención a su usuario y lo protege de conse-

cuencias nocivas, a él y a quienes lo rodean.
◉ Fiable en cuanto a datos : no espía, no sustrae información, no usa

ni comparte datos sin consentimiento y protege el acceso a estos
datos.
◉ Predecible : sus reacciones son comprensibles, sus decisiones cla-

ras y sus recursos accesibles.
◉ Optimizado : limita su consumo en servidores, en redes y en el ter-

minal del usuario.
◉ Equilibrado : o crea desequilibrios de poder económico directos,

Mejora continua
en beneficio de sus usuarios y en detrimento de otros actores

económicos.
177
MÓDULO №4
Al hacerte estas preguntas, contribuyes a prevenir los efectos nocivos de tu producto y lo

haces más responsable.
Optimizar mediante la experimentación
Cuando analizas el éxito de las funcionalidades, puedes observar que algunas no están a la
altura o podrían mejorarse. Para lograrlo, puedes implementar un enfoque de experimentación.
Define primero un objetivo claro a alcanzar, por ejemplo, mejorar la tasa de uso de una
nueva funcionalidad o la tasa de conversión de una landing page. Para obtener resultados que
puedas interpretar, asegúrate de que cada experimentación consta de los siguientes elementos:
◉ La suposición.
◉ La hipótesis.
Experimentación del equipo de Activación
La suposición:suponemos que la razón por la que tantos usuarios no

aprovechan su código de referencia es que el campo no es lo suficientemente
visible.
La hipótesis: si colocamos el campo encima del botón de validación, debería

mejorar la tasa de uso del código de recomendación.
La prueba: si colocamos el botón encima, la tasa de utilización del código

aumentará un 50%.
Aprendizaje: si validamos la prueba, desplegaremos el nuevo diseño.

Mejora continua
178
MÓDULO №4
◉ La prueba.
◉ El aprendizaje.
A veces tus experimentos tendrán como objetivo comparar el rendimiento de dos o

más versiones de una página o funcionalidad. Estos experimentos se realizan sometiendo
aleatoriamente a algunos usuarios a cada una de las versiones y comparando el rendimiento de
cada una. Los tipos de prueba preferidos son:
◉ Los tests A/B ue consisten en ajustar un único elemento de una página o

funcionalidad, como el color o el texto de un botón, por ejemplo, y comparar el
rendimiento de las versiones A y B para identificar cuál convierte mejor.
◉ Los tests multivariables que consisten en comparar el rendimiento de dos o

más versiones ajustando varias variables, como dos landing pages diferentes.
Test A/B y test multivariante
Mejora continua
179
MÓDULO №4
Eliminar funcionalidades
A lo largo del ciclo de vida de un producto, la relevancia, el impacto y el uso de las

funcionalidades varían. Cuando trabajas de manera continua, debes asegurarte de que tu
producto no se convierta en un montón de novedades y que estas sigan contribuyendo a
entregar valor. A veces, añadir o reelaborar funcionalidades puede canibalizar comportamientos
antiguos o hacer que partes de tu producto queden obsoletas. Analizando los datos y utilizando
auditorías puntuales, deberías detectar las funcionalidades que no se utilizan o han dejado de
utilizarse y eliminarlas. Eliminar funcionalidades innecesarias permite mantener el foco en las
funcionalidades esenciales, simplificar la navegación y la comprensión del producto para tus
usuarios y mejorar la mantenibilidad.
Matar tu producto
Si dudas entre mantener o matar tu producto, hazte las siguientes

preguntas:
◉ ¿Ya no es viable financieramente (y esto ha sido así por un tiempo)?

¿Todavía genera suficientes ingresos, o el margen es casi por
completo consumido por los costes de mantenimiento, que se han
vuelto demasiado altos debido a una deuda técnica significativa?
◉ ¿Tienes suficientes recursos para gestionarlo adecuadamente en

términos de equipo de desarrollo, calidad y soporte al cliente? ¿No
sería el trabajo de estos equipos más provechoso si estuvieran en
otro producto?
◉ ¿Compite con varios productos o funcionalidades de la misma

empresa, ya sea en términos de mercado o de equipos?
Mejora continua
180
MÓDULO №4
Discovery y delivery en paralelo
y de manera continua
El Dual Track
Para avanzar de forma eficaz en tu roadmap, asegúrate de que las actividades de delivery y
discovery se lleven a cabo en paralelo. Mientras el delivery de algunas funcionalidades está en
curso, también debes anticipar los futuros desarrollos realizando discovery sobre las próximas
oportunidades prioritarias. Esta aproximación se conoce comúnmente como el dual track: los
ciclos de discovery y delivery coexisten y se alimentan mutuamente. Así, los ciclos de discovery
tienen como principal objetivo conocer y priorizar los problemas y oportunidades a resolver.
Los ciclos de delivery siguen su ritmo de desarrollo con el objetivo de entregar progresivamente
incrementos de Producto que aporten valor. Finalmente, el feedback y los datos posteriores a
las entregas alimentan nuevamente el discovery. ¡El ciclo se cierra!
El Dual Track
Oportunidad Funcionalidad
Medir y
aprender
Mejora continua
181
MÓDULO №4
La trampa a evitar es dejarse atrapar por el delivery y las urgencias del día a día. Piensa en
reservar tiempo para las actividades de discovery. Para que esta paralelización pueda imple-
mentarse, debes:
◉ Tener un delivery eficaz que os permita liberar tiempo para actividades de

discovery.
◉ Fomentar la autonomía de tu equipo. Apóyate en su líder técnico para no

estar constantemente solicitado durante el delivery.
◉ Organizar el discovery de manera que recolecten datos de forma continua.
Realizar discovery de manera continua
Algunos equipos piensan a veces, erróneamente, que el discovery toma tiempo y que es
difícil de implementar. Por lo tanto, se limitan a unos pocos grandes proyectos de investigación
de usuarios al año. Asegúrense de no caer en esta trampa: cuanto más espacien los puntos de
contacto con tus usuarios, mayor será el esfuerzo necesario para comprender sus necesidades.
Teresa Torres, autora de Continuous Discovery Habits, hace una clara distinción entre el
discovery en modo proyecto, donde se necesitan varias semanas para reclutar usuarios,
organizar y realizar entrevistas, analizar los resultados y preparar una presentación, y el
discovery continuo que consiste en asegurarse de estar en contacto cada semana con sus
usuarios de una forma u otra. El discovery continuo facilita el trabajo en dual track. Para
lograrlo, puedes, por ejemplo, realizar las siguientes actividades:
◉ Recolectar feedback de manera pasiva a través de un formulario en el sitio

web, por ejemplo, y analizar el feedback cada semana.
◉ Realizar escuchas conjuntas con el servicio de atención al cliente o analizar la

opinión de los usuarios a través del formulario de contacto, las reseñas de las tiendas o
cualquier otro medio.
◉ Implementar test A/B utilizando herramientas adecuadas.
◉ Probar tu solución con miembros de tu entorno. Aunque no se trate

necesariamente de usuarios que correspondan exactamente a tu público objetivo,
Mejora continua
podrás recoger información interesante e identificar elementos recurrentes.
182
MÓDULO №4
◉ Realizar una entrevista exploratoria semanal con un usuario que
corresponda a tu público objetivo. Aunque la creación de un grupo de usuarios
disponibles para una entrevista requiere un poco de organización previa, una vez que
hayas creado comunidad, podrás realizar entrevistas regulares fácilmente.
◉ Seguir regularmente los datos cuantitativos, incorporando, por ejemplo,

un momento de compartir las cifras clave durante la revisión o eventos recurrentes.
Nuestros consejos
◉ Antes de embarcarte en la experimentación, asegúrate de poder reco-
pilar resultados rápidamente (objetivos claros, tráfico suficientemente
importante para obtener resultados significativos). Si este no es el caso,
lanza la funcionalidad, monitorízala de cerca y desactívala en caso de pro-
blemas (gracias al feature flag).
◉ Si decides eliminar una funcionalidad o un producto, ten en cuenta que,

aunque sean pocos, algunos usuarios pueden depender de ti. Informales
con antelación, sé transparente sobre lo que motiva tu decisión y ofrece
alternativas cuando sea posible.
◉ Llevar a cabo Delivery y Discovery cada semana requiere un poco de

organización. Para ello, considera bloquear espacios dedicados en tu
agenda para atender las solicitudes de los desarrolladores, preparar los
próximos desarrollos, realizar actividades de Discovery y hacer el análi-
sis de rendimiento.
Mejora continua
183
MÓDULO №4
CAPÍTULO 19
Gestionar los bugs y la

deuda técnica
Mejorar tu producto también implica la gestión de bugs y la deuda técnica. Como Product
Manager, debes asegurarte de que los bugs se traten de manera eficaz. También tendrás que
priorizar los trabajos técnicos, teniendo en cuenta las necesidades de los usuarios y los objetivos
de la empresa, para garantizar la calidad del producto y su éxito a largo plazo.
Gestionar los bugs
¡Lo construyes, lo mantienes!
Una vez que las funcionalidades están en producción, es posible que te reporten fallos
(bugs). A diferencia de los métodos de desarrollo en cascada, donde el producto se transfiere del
equipo de build (que desarrolla la solución) al equipo de run (que se encarga del mantenimiento
y soporte), hoy en día se recomienda un enfoque donde los desarrolladores que diseñaron la
solución también son responsables de ella. «You build it, you run it» (tú lo construyes, tú eres
responsable). ¡Las ventajas son múltiples!
◉ Los desarrolladores que diseñaron la solución son también quienes mejor la conocen.
Por lo tanto, son inmediatamente operativos y no dependen de una transferencia de
conocimientos.
◉ Esto permite ser más reactivo frente a un incidente, minimizando el tiempo necesa-
rio para intervenir. En las organizaciones que han mantenido un equipo de build y
uno de run, se observa que este último está rápidamente limitado en su capacidad de
Mejora continua
intervención, ya que raramente puede identificar y aplicar una corrección de forma

autónoma.
184
MÓDULO №4
◉ Esto permite a los desarrolladores estar más cerca de los usuarios y recoger sus
comentarios directamente, lo que a menudo les motiva a diseñar una solución más
robusta para minimizar la necesidad de intervención.
Detectar y priorizar bugs
Una gestión eficaz de los bugs en producción se organiza alrededor de cuatro etapas.
1. Detección : Los bugs son creados por la persona que los detecta. Puedes ser tú, como
Product Manager, especialmente si un usuario te informa directamente de un error.
También pueden ser creados por un miembro del equipo, del servicio de atención al
cliente o cualquier otra persona que interactúe con el producto. Los bugs contienen la
descripción de los pasos para reproducir el problema, el resultado observado y el resultado
esperado. Cuando se detecta un bug en producción, debe tratarse inmediatamente. Esto no
significa que deba corregir el bug inmediatamente, pero sí que debe tomar conocimiento
de él lo más rápidamente posible, intentar reproducirlo y, si es el caso, documentar los
elementos relevantes para la reproducción del bug. Finalmente, debe comunicarse con los
stakeholders involucrados.
2. Priorización : no todos los bugs son igual de importantes o urgentes. Por tanto, hay
que aceptar que no se podrán corregir todos. Un bug que se produce en producción debe
tratarse más rápidamente que un bug que se produce en una versión en desarrollo o en
pruebas. Del mismo modo, un bug detectado en el camino crítico de tus usuarios, y que
impide el buen funcionamiento de las principales acciones, no tiene la misma criticidad
que un bug que se produce en una funcionalidad poco utilizada o que representa un
problema menor.
3. Corrección : los bugs más prioritarios se corrigen inmediatamente. En función de la

importancia del bug, no dudes en añadir escenarios de prueba adicionales para evitar que
se repita en futuras versiones. Los errores menos críticos pueden priorizarse con otras
Historias de Usuario al planificar futuras versiones.
4. Validación : una vez corregido el bug, hay que probarlo como una Historia de Usuario
clásica y enviarlo a producción. Si el bug es muy crítico, podemos lanzar lo que llamamos
un hotfix, es decir, una versión dedicada exclusivamente a la corrección. Si la criticidad es
más moderada, el parche puede integrarse en la versión actual. Una vez que el parche esté
Mejora continua
en producción, hay que informar a las personas afectadas.
185
MÓDULO №4
Preocuparse por la deuda técnica
¿Qué es la deuda técnica?
La deuda técnica es una metáfora del desarrollo de software inventada por el informático
Ward Cunningham. Se basó en el concepto existente de deuda financiera y lo aplicó al campo
del desarrollo de software. En el desarrollo, el código endeudado de tu producto es el capital
y los bugs son los intereses. En cuanto añades nuevas funcionalidades, el capital aumenta y
genera más bugs y mantenimiento. Si los reembolsos de capital no son regulares, los intereses
seguirán siendo elevados. La deuda técnica representa, por tanto, partes del código que no se
utilizan, o en las que es difícil realizar cambios y, por tanto, actualizaciones. Para asegurarte de
que tu producto evoluciona con el tiempo y no se ve bloqueado por un mantenimiento excesivo,
debes mantener su deuda técnica bajo control. El mejor defensor de esta filosofía ante las partes
interesadas eres tú.
La deuda técnica concierne tanto al mantenimiento como a la fiabilidad y escalabilidad de

tu producto.
◉ Mantenimiento: ya sea correctivo (corregir defectos y errores de una aplicación)

o adaptativo (adaptar una aplicación para que siga funcionando con versiones más
recientes de los componentes técnicos en los que se basa), el mantenimiento de
aplicaciones o software está en el centro de tu trabajo y afecta directamente a los
equipos de desarrollo. Cuanto más implique este mantenimiento, más tiempo pasará
tu equipo de desarrollo corrigiendo bugs y menos funcionalidad ofrecerá.
◉ La escalabilidad de un producto: la esencia misma de la gestión de productos

es ofrecer las funcionalidades que mejor se adapten a las necesidades reales de los
usuarios. Si el producto deja de evolucionar funcionalmente, acabará yendo cuesta
abajo. Además, la falta de escalabilidad requerirá intervenciones más largas y difíciles
en el código para desarrollar nuevas funcionalidades.
◉ Fiabilidad: un usuario que se enfrenta a un software inestable o a una aplicación

cuyo comportamiento es aleatorio puede volver una segunda vez, pero nunca una
tercera.
Mejora continua
186
MÓDULO №4
Dominar el nivel de deuda técnica
Hacer un producto que no requiera mantenimiento, cuyas evoluciones sean fáciles y

rápidas de implementar y que sea muy fiable, es muy utópico. La deuda técnica es inevitable
y a veces deliberada. En algunos casos, el equipo puede tomar la decisión consciente de crear
deuda técnica para entregar una funcionalidad dentro de los plazos exigidos.
Cuando se identifica un elemento de deuda técnica (voluntario o no), a menudo gracias a

su equipo de desarrollo, debe identificar la táctica para absorberla. Tu trabajo como Product
Manager consiste en encontrar el compromiso adecuado para maximizar la escalabilidad y la
fiabilidad de tu producto, mientras minimizas el tiempo dedicado al mantenimiento.
Mejora continua
187
MÓDULO №4
El cuadrante de la deuda técnica
Este marco de Martin Fowler de ThoughtWorks categoriza la deuda técnica

en cuatro tipos:
Excesiva e imprudente Moderada y prudente
Deuda producida por equipos que deciden Una deuda completamente deliberada
deliberadamente hacer algo "rápido y para entregar a tiempo una versión del
sucio" porque no pueden tomarse el producto puede que no valga la pena ser
VOLUNTARIA
tiempo necesario para diseñar su código pagada si los intereses son

de manera limpia. suficientemente pequeños.
Ejemplo: sitio de e-commerce que realiza Ejemplo: una parte del código raramente
una gran parte de su facturación durante modificada.
la temporada de Navidad. Las
funcionalidades deben lanzarse antes de
este período.
Deuda a menudo debida a equipos que Deuda técnica existente en los equipos,
ignoran las prácticas más básicas de incluso los más experimentados, porque es
INVOLUNTARIA
diseño y arquitectura. inevitable.
Ejemplo: startups para las cuales es más A menudo, solo al final de un proyecto te
importante validar una idea o ser el das cuenta realmente de lo que el diseño
primero en lanzarse al mercado que debería haber sido, incluso si el código y la
escribir código de calidad. arquitectura implementados son muy
buenos y están bien pensados.
Minimizar la deuda técnica
Ahora seguramente te preguntes cómo producir la menor cantidad de deuda técnica

posible mientras sigues entregando funcionalidades a tiempo y cómo convivir con una deuda
técnica existente intentando, aun así, minimizarla.
En primer lugar, la deuda técnica está vinculada de forma más general a la calidad. Cuando
existe una cultura de la calidad en el seno del equipo y con las partes interesadas, cuando se
Mejora continua
realizan esfuerzos previos mediante la elaboración de Historias de Usuario, test, programa-

ción entre pares, DoD, entrega regular de código, etc., parte del problema vinculado a la deuda
técnica ya se ha resuelto.
188
MÓDULO №4
En ciertos casos, se debe prestar especial atención a la deuda técnica para absorberla. Para
abordarla, asigna una parte de la capacidad del equipo a la gestión de la deuda para mejorar el
rendimiento poco a poco. Así, los desarrolladores podrán implementar:
◉ La regla del Boy Scout. Deja siempre el código en el que estás trabajando un
poco mejor de lo que lo encontraste. Esto permite a tu equipo abordar la deuda
técnica de forma casi gratuita. El principio es simple: cada vez que alguien toca un
trozo de código, tiene que hacerlo mejor que el estado en el que lo encontró. ¡Se trata
de la mejora continua!
◉ Tareas de refactorización.La refactorización, o reelaboración del código,

consiste en reelaborar el código fuente de una pieza de software sin añadir funciona-
lidad ni corregir errores, pero mejorando su legibilidad para simplificar el manteni-
miento o hacerlo más genérico.
◉ Una lista de deudas pendientes. El backlog de deuda enumera la deuda detec-

tada y las acciones voluntarias de deuda tomadas por el equipo. Cuando tomes una
decisión de este tipo, no olvides rellenar los elementos que motivaron tu elección, las
tareas para corregir la deuda tomada, el tiempo estimado que llevaría la corrección,
así como la fecha prevista para saldar esta deuda. El backlog te ofrece una visión clara
de la deuda por saldar, para que puedas priorizarla en función de tus necesidades y de
las previsiones de tu roadmaps.
Nuestros consejos
◉ La descripción del bug y los cambios necesarios para resolverlo son
esenciales para priorizar y corregir el problema correctamente.
Piensa en proponer una plantilla con campos obligatorios a rellenar
para los interesados que los notifiquen.
◉ Para corregir pequeñas anomalías a las que no se suele dar priori-

dad (errores de visualización, correcciones de redacción, etc.), orga-
niza de vez en cuando sesiones de corrección de bugs, reuniendo a
diseñadores de producto y desarrolladores. ¡La ventaja es que puedes
arreglar tantos bugs como sea posible mientras estableces un límite
Mejora continua
de tiempo dedicado!
◉ ¡No planifiques un sprint entero dedicado a la refactorización! Envía un

mensaje equivocado. En una situación de crisis, es admitir que has per-
dido el control de tu producto.
189
MÓDULO №4
CAPÍTULO 20
Trabajar en equipo
y colaborar con los
stakeholders
Como director de orquesta de tu producto, estás en el corazón de las interacciones con
tu equipo y los stakeholders. Debes asegurar una buena colaboración y de un funcionamiento
eficaz y agradable del equipo. Muchas de tus actividades te exigirán dominar habilidades como la
escucha, el liderazgo y la comunicación.
Colaborar con tus stakeholders
Identificar los stakeholders clave
Las partes interesadas (stakeholders) son todas las personas impactadas por tu producto
y que pueden influir, de una manera u otra, en tus decisiones. Puede identificar:
◉ Los stakeholders externos : usuarios del producto.
◉ Los stakeholders internos : Líderes de Producto, marketing, equipo comercial,

soporte, finanzas, legal u otros equipos de Producto.
Las interacciones con los stakeholders se producen en momentos puntuales, durante las
entrevistas con los usuarios y las actividades de discovery. En cuanto a los stakeholders, las
interacciones pueden ser un poco más complejas. Hay que establecer una relación de confianza
y colaboración eficaz con varias personas con intereses diferentes. Además, cuanto mayor sea
Mejora continua
el alcance, más stakeholders habrá que gestionar.
Para organizarte, el primer paso es identificar quiénes son tus grupos de interés y qué
importancia tienen para el diseño de tu producto. Para ello, puedes utilizar la matriz poder-in-
terés diseñada por Ackermann y Eden, expertos en estrategia, profesores y autores del libro
190
MÓDULO №4
Making Strategy: The Journey of Strategic Management, que te permite identificar cuatro gru-
pos de stakeholders:
◉ Los jugadores son las principales stakeholders con las que trabajas estrecha-
mente, porque tienen un gran interés en lo que tú y tu equipo hacéis. También tienen
una gran capacidad para influir en tus decisiones. Participan en las actividades de
discovery (módulo 2) y te transmiten directamente sus peticiones (capítulo 3).
◉ Los creadores de contexto tienen un gran poder, pero un interés directo limi-
tado en tu producto. No participan en el día a día, pero debes asegurarte de que están
satisfechos y consultarles sobre las decisiones importantes.
◉ Los sujetos muestran un gran interés por tu producto, aunque tengan poca influen-
cia. Son tus embajadores. Al involucrarlos en tu proceso, pueden convertirse potencial-
mente en actores. Si los dejas fuera, los convertirás en multitud.
◉ La multitud tiene poca influencia y poco interés en tu producto. Puedes limitarte

a informarles.
En resumen, el mapeo te permite dirigir el nivel de implicación de tus stakeholders para

comprometerlos en los temas correctos, en el momento adecuado, y obtener el apoyo de las
personas adecuadas en las decisiones correctas.
Mejora continua
191
MÓDULO №4
La Matriz Poder - Interés
Elegir y saber decir no

Tus stakeholders, y especialmente los players, regularmente presentan nuevas solicitudes.
Éstas se transmiten a menudo con urgencia, en función de las noticias de la empresa, la
actividad del negocio o los cambios regulatorios. Por ejemplo, el equipo de ventas puede pedirte
que realices una evolución del Producto para firmar rápidamente un contrato con un cliente
importante, sin olvidar al departamento legal que puede solicitarte una evolución del RGPD que
debes tratar con urgencia... Dado que la capacidad de producción del equipo no es extensible,
debes asegurarte de:
◉ Entender bien los desafíos de las solicitudes, especificándolas e

identificando su criticidad. Pregunta: “¿Para quién? ¿Por qué? ¿Por qué ahora?
¿Qué pasa si no hacemos nada?”.
◉ Tomar las decisiones correctas e informar de ellas a los stakeholders.

A menudo tendrás que rechazar ciertas peticiones, aunque provengan de la dirección.
Saber decir no es una habilidad esencial que debes dominar. “No, no todo es para ahora”;
Mejora continua
“No, esa funcionalidad no necesariamente tiene su lugar en esta versión, o incluso en el pro-
ducto”, “No, no habrá milagros y la fecha de entrega no se adelantará por arte de magia”: estos
son algunos mensajes que debes comunicar con diplomacia. Nunca olvides que tú eres el guar-
dián del valor del producto. Tu rol es asegurarte de la coherencia de las evoluciones con los
objetivos del producto. Aquí hay algunos consejos para decir no con diplomacia:
192
MÓDULO №4
◉ No digas que no demasiado rápido.
◉ Pregunta por qué (no pases al siguiente paso si no sabes el porqué).
◉ Reformula la petición.
◉ Comparte nuevamente los objetivos del Producto.
◉ Apóyate en tu priorización.
◉ Fomenta la colaboración.
◉ Ofrece perspectivas.
Comunicar y divulgar
La comunicación es una parte esencial de la gestión de los stakeholders y a ti te corres-

ponde proporcionar el nivel adecuado de información, pero también gestionar la frecuencia
para optimizar tus actividades. Ritualiza los intercambios para garantizar un contacto regular,
en particular organizando:
◉ El kick-off. Ya sea al inicio de un trimestre, en el lanzamiento de un nuevo producto,

una funcionalidad o una asociación importante, te aconsejamos realizar un kick-
off para presentar los objetivos, el roadmap y las diferentes etapas a las personas
involucradas. Esta reunión es un punto de información que permite alinear a todos
los stakeholders.
◉ La review. Este ritual te permite comunicar sobre las nuevas funcionalidades,

informar sobre las próximas etapas y recoger feedback.
◉ Los puntos de sincronización.Una reunión regular que te permite tener un

intercambio privilegiado en un comité más pequeño con un servicio, un grupo de
stakeholders o una persona. Es la ocasión para tratar las nuevas solicitudes y respon-
der a las preguntas de manera más detallada.
Además de las reuniones y contactos, te aconsejamos facilitar el acceso a la informa-

Mejora continua
ción sobre tus actividades y decisiones. Así, tus stakeholders pueden referirse a ella cuando lo
deseen. Apóyate en la documentación que has establecido, en soportes que puedas actualizar
regularmente: tu roadmap, un informe de la revisión, un resumen de los avances del delivery,
193
MÓDULO №4
una actualización de las grandes fechas límite... Estos soportes deben ser autoexplicativos y
fáciles de entender para los stakeholders involucrados. Por lo tanto, se debe hacer un esfuerzo
de divulgación, simplificación y explicación para no entrar en detalles técnicos y adaptarse al
vocabulario utilizado por los negocios.
Finalmente, piensa en formatos más concisos, con una perspectiva más amplia para comu-
nicar más globalmente sobre el impacto de tu equipo y producto. Una newsletter y/o una pre-
sentación ad hoc te permiten resaltar el trabajo realizado por el equipo.
Trabajar bien con tu equipo
Demostrar liderazgo
En general, como Product Manager del equipo, adopta, al igual que los desarrolladores, los
valores de Agile, que incluyen la colaboración y la ayuda mutua. Como no tienes una relación
jerárquica con el equipo, debes adoptar una postura de coach en lugar de manager. Se trata
de motivar dando dirección, asegurándote de que los recursos se utilicen correctamente para
servir los objetivos y permitir que el equipo sea autónomo para tomar las mejores decisiones.
También, como señala Marty Cagan en su best-seller Empowered, tus batallas son asegurarte
de tener:
◉ Un buen alineamiento con el equipo.
◉ Un buen nivel de autonomía.
Este rol puede ser difícil de asimilar, por lo que te aconsejamos algunas acciones:
◉ Estar presente para el equipo.Has realizado un esfuerzo importante de

definición y preparación, pero recuerda que sin el equipo (Product Designers,
desarrolladores...) no lograrás cruzar la línea de meta. ¡La resolución de problemas
es un deporte colectivo! Por lo tanto, permanece disponible para ayudar a tu equipo
al máximo.
◉ Demostrar adaptabilidad según las circunstancias. El equipo te otor-

Mejora continua
gará su confianza más fácilmente si siente que puedes adaptarte rápidamente y que
eres capaz de proponer alternativas.
◉ Comunicar la información clave a tu equipo. Los desarrolladores no son

simplemente ejecutores. Cuanto más los involucres en problemas con elementos de
194
MÓDULO №4
contexto, más compartirán los objetivos a alcanzar y los progresos, y más se sentirán
parte integral del éxito del producto.
◉ Hacer brillar a tu equipo.Tendrás que ser más visible que el resto del equipo y
ante los stakeholders. Por lo tanto, es importante recordar que los éxitos del producto
son el resultado de un trabajo colectivo. Por ejemplo, no olvides mencionar a los
desarrolladores que han contribuido a los éxitos en tus comunicaciones y durante las
reviews.
¿Deben los Product Managers tener un buen nivel técnico?
Estas son preguntas que muchos Product Managers pueden hacerse: “¿debo dominar los
fundamentos del desarrollo? ¿Es importante poder manejar API? ¿Debo poder hacer consultas
SQL en la base de datos?” En resumen, ¿qué nivel técnico debo tener?
Tener afinidad por los temas técnicos es importante, pero no necesariamente debes
dominar esas habilidades. Tu día a día es colaborar con los desarrolladores en funcionalidades
de Producto, entender las restricciones técnicas y tomar decisiones. Presta atención a
las conversaciones técnicas para detectar señales débiles sobre el trabajo a realizar: una
funcionalidad requerirá un esfuerzo significativo de mantenimiento, una solución alternativa
podría reducir la complejidad técnica... Para ello, debes ante todo ser curioso, saber cómo está
construido tu producto y entender los conceptos técnicos principales (el front-end, el back-end,
las APIs).
También debes sentirte cómodo discutiendo soluciones técnicas con los desarrolladores,
alternando entre un vocabulario de negocio y un vocabulario técnico para asegurarte de la
correcta comprensión.
Finalmente, es importante entender las dificultades del desarrollo. Ten en cuenta el

problema del cambio de contexto. Adentrarse en un tema para comenzar a desarrollar lleva
tiempo y los cambios frecuentes de temas afectan la concentración y la eficacia. Ten en cuenta
que molestar a un desarrollador, incluso por 5 minutos, costará más que solo 5 minutos...
Además, la multitarea y la acumulación de temas son fuentes de ralentización en el desarrollo.
Por eso es importante centrarse en los temas y retrasar algo si es necesario.
Mejora continua
195
MÓDULO №4
Mejorar el funcionamiento del equipo

El equipo de Producto debe entregar valor lo más rápido posible. Por lo tanto, es el motor
del producto y su buen estado influye en su rendimiento. Sin esto, no se puede avanzar. Por ende,
hay que cuidarlo y hacer todo lo posible para evitar que los engranajes se atoren. Asegúrate de:
◉ Que cada persona se sienta escuchada.
◉ Entender que la mejora continua de la calidad o las interacciones entre las personas
son temas esenciales.
◉ Inculcar una dinámica colectiva.
◉ Reaccionar cuando el equipo encuentre dificultades.
La retrospectiva es una forma sencilla de trabajar en este tema. Durante la retro, el equipo
identifica los elementos del proceso de desarrollo que han funcionado bien y aquellos que
necesitan mejora. De esta manera, el equipo construye un plan de acción de mejora que se
compromete a implementar en el próximo ciclo. Para aprovechar plenamente los beneficios
de la retro, es necesario establecer un clima de confianza. Debes crear un ambiente donde
el equipo pueda intercambiar abiertamente. Para lograrlo, puedes utilizar distintos formatos.
Aquí hay algunos ejemplos:
◉ “Mad, Sad, Glad”.
◉ “Start, Stop, Continue”.
◉ “4 L: Liked, Learned, Lacked, Longed for”.
◉ El “Speed Boat”.
Mejora continua
196
MÓDULO №4
Material de retrospectiva del equipo de Activación
Ejemplo de retro 1 Ejemplo de retro 2 Ejemplo de retro 3
Lo que me ha gustado
Lo que he aprendido
Lo que me ha faltado
Lo que me hubiera gustado
ACCIONES ACCIONES ACCIONES
No dudes en designar una función rotatoria en el equipo para variar la responsabilidad de

la facilitación. Considera también la posibilidad de organizar una retrospectiva más amplia de
forma puntual (una vez al trimestre, tras el final de un proyecto importante, etc.), invitando
a tu equipo ampliado y a los stakeholders, por ejemplo. Esto permitirá al equipo mejorar su
colaboración con las principales stakeholders, y a la organización mejorar la gestión de los
proyectos estratégicos.
Mejora continua
197
MÓDULO №4
Nuestros consejos
◉ Cuando llegues a una nueva zona, tómate tu tiempo para conocer
individualmente a tus interlocutores y a los miembros de tu equipo. El
objetivo es conocerlos para poder trabajar bien juntos en el futuro.
◉ En un contexto en el que tengas muchos stakeholders, identifica

a las personas clave que serán tus contactos privilegiados para
coconstruir.
◉ Rompe los silos entre tu equipo y los stakeholders. Para ello, invita a
tus stakeholders a venir a hablar con el equipo e implica a tu equipo en
reuniones estratégicas de vez en cuando.
◉ Algunos equipos añaden las acciones priorizadas al final de la

retrospectiva a su backlog. Esto permite hacer visibles las acciones
que hay que llevar a cabo y asegurarse de que avanzan.
Mejora continua
198
Lo esencial
de este módulo
1. El éxito puede medirse a distintos niveles: el logro de objetivos, el impacto de una

funcionalidad, el rendimiento general de tu producto.
2. Una buena métrica mide el resultado (el impacto de una funcionalidad) y no la

puesta en producción (la entrega de la funcionalidad) y te permite tomar decisiones
informadas sobre el desarrollo de esta funcionalidad.
3. Hay que basarse en los datos, es decir, tomar decisiones utilizando tanto datos
cuantitativos (el qué) como información cualitativa (el porqué).
4. Para que tu producto evolucione, mejóralo con nuevas funcionalidades, optimiza las
existentes o elimina las obsoletas.
5. El discovery y el delivery deben llevarse a cabo en paralelo y de forma continua para

aplicar un enfoque eficaz del producto.
6. Los fallos (bugs) deben evaluarse y priorizarse en relación con los demás elementos
del backlog. Los fallos más críticos se corrigen inmediatamente.
7. La deuda técnica es inevitable cuando se desarrolla un producto, pero debe

controlarse y supervisarse para que pueda absorberse con el tiempo.
8. Tu capacidad de escucha activa, tu habilidad para explicar las cosas en términos

sencillos y tu capacidad para decir que no, son esenciales para construir una relación
de confianza con los stakeholders.
9. Tienes que mostrar liderazgo a tu equipo. Dar sentido, colaborar y comunicar debe
formar parte de tus actividades diarias.
CONCLUSIÓN
CONCLUSION
Tu viaje al corazón del proceso del producto llega a su fin, ¡y esto es sólo el principio! Para
cada una de las etapas de estrategia, discovery, delivery, y de mejora continua, ahora dispones
de los conocimientos y herramientas necesarias para poder aplicar en tu día a día.
Este libro ha sido diseñado para enriquecer tus conocimientos y ofrecerte nuevas
perspectivas para destacar en el rol de Product Manager. Esperamos que utilices esta
información para continuar mejorando tus prácticas de Producto y tener un impacto positivo
en usuarios, equipo y organización.
Como un producto, siempre es posible mejorar, aprender e innovar. Mantente curioso,

continúa formándote y no temas experimentar. ¡Buena suerte en tu carrera como Product
Manager!
Para profundizar más, aquí te ofrecemos algunos recursos que nos inspiraron para escribir
este libro y que tratan con más detalle algunos conceptos clave:
◉ El Media, Thiga.
◉ Discovery Discipline, Rémi Guyot y Tristan Charvillat.
◉ Responsables, Fabrice des Mazery.
◉ Le Ticket, Kevin Deniau y Tanguy Verluise.
◉ Good strategy, Bad strategy, Richard P. Rumelt.
◉ Continuous Discovery Habits, Teresa Torres.
◉ Escaping the build trap, Melissa Perri.
◉ Inspired, Marty Cagan.
◉ Empowered, Marty Cagan.
◉ Product Roadmap Relaunched, Bruce Mccarthy.
◉ Running Lean, Ash Maurya.
◉ The Lean Startup, Eric Ries.
201
AGRADECIMIENTOS
AGRADECIMIENTOS
Nos gustaría expresar un cálido agradecimiento a Emérence Curutchet, Virginie Coux y
Geoffrey Chovet por su valiosa contribución. Su experiencia ha contribuido enormemente al
desarrollo del contenido de este libro.
Un gran gracias a nuestros cuidadosos revisores, Benjamin Danel, Sebastian Nankervis,

Elias Ghali, Naban Tuo, Alexis Lamrani, Hortense Bouzoud, Mathias Frey, Rémi Favre, Romain
Monclus, Simon Joliveau, Antoine Lancesseur. Sus comentarios perspicaces han enriquecido el
contenido de este libro.
También expresamos nuestro reconocimiento a Rémi Guyot y Julien Négui, nuestros

expertos editores. Su rigor y aguda atención al detalle han mejorado la calidad y coherencia de
nuestro trabajo.
Extendemos nuestros agradecimientos a Céline Winant-Pateron y al equipo de marketing

que contribuyen a promover este libro con dinamismo y creatividad, y a Camille Pfaender, quien
nos ha acompañado en la recta final hacia la publicación.
Agradecemos sinceramente a Christopher Parola por su valioso apoyo. Su iluminadora

introducción ofrece una perspectiva única a este libro. Queremos expresar nuestra gratitud
a Christelle Perrin de Médianes, quien ha sido una valiosa compañera a lo largo de este viaje
editorial. Su sensibilidad artística y profesionalismo han sido indispensables para darle a este
libro su forma final. También gracias a Mélina Ferrante-Giovannoni por su aguda visión al final
de la redacción.
Por último, queremos expresar nuestra gratitud a todas las personas del Thicrew que han
contribuido a la realización de este libro con su revisión, apoyo o consejo. Especial mención a la
Thicrew que hizo posible la traducción al castellano: Jose Rodríguez Masa, Omar Ruiz, Lourdes
Fernández y Pilar Ortiz.
203
GLOSARIO
GLOSARIO
204
GLOSARIO
Agile
Es un enfoque de gestión y desarrollo basado en la colaboración y la adaptación al cambio.
Promueve entregas iterativas y continuas. El enfoque Ágil se describe en un manifiesto que
comprende 4 valores y 12 principios.
Ver capítulo 11
API (Application Programming Interface)

Permiten la comunicación entre frontend y backend mediante el intercambio de datos. También se
utilizan para comunicar backends de diferentes servicios. Una API es como un contrato entre dos
sistemas donde una solicitud con un dato de entrada permite obtener nuevos datos en respuesta.
Backend
Es la parte algorítmica, donde se encuentra la implementación de las diferentes reglas de
negocio y que permite el acceso a la base de datos.
Backlog
Es un conjunto ordenado de elementos a realizar para entregar el producto.
Ver capítulo 10
Criterios de Aceptación
Son las condiciones que debe cumplir una funcionalidad para satisfacer las nece-
sidades del usuario. Pueden ser validados a través de pruebas de aceptación.
Ver capítulos 10 y 14
205
GLOSARIO
CSAT (Customer Satisfaction Score)

Es una medida utilizada para evaluar la satisfacción de los usuarios respecto a una experiencia
específica. Generalmente, se obtiene formulando a los clientes una pregunta a la que pueden
responder utilizando una escala de valoración, por ejemplo de 1 a 5, para indicar su nivel de
satisfacción y definiendo el umbral a partir del cual se considera satisfecho a un usuario.
Customer Lifetime Value (CLV)

El valor del ciclo de vida del cliente, en español, es una medida que estima el valor finan-
ciero total que un cliente aporta a una empresa a lo largo de su relación con ella. Tiene
en cuenta los ingresos generados por el cliente, los gastos relacionados con la fideliza-
ción y adquisición del cliente, así como la duración prevista de la relación con el cliente.
Customer Success
Es una función enfocada en la satisfacción y el éxito de los clientes de una empresa. Su objetivo
es ayudar a los clientes a aprovechar al máximo los productos ofrecidos por la empresa y
obtener el máximo valor de su inversión. Los profesionales de customer success trabajan en
estrecha colaboración con los clientes, proporcionando apoyo, asesoramiento, formación y
recursos para garantizar su satisfacción a largo plazo.
Cycle time
En Kanban, el Cycle Time permite medir el tiempo para pasar de una etapa a otra, y ayuda a
detectar cuellos de botella
Ver capítulo 11
206
GLOSARIO
Definition of Done (DoD)
Es un contrato firmado con el equipo de desarrollo, y establece en forma de lista todos los
criterios que debe cumplir una Historia de Usuario para considerarse completa.
Ver capítulo 14
Definition of Ready (DoR)

Es un acuerdo con el equipo de desarrollo, y recopila en forma de lista los ele-
mentos necesarios para que una Historia de Usuario pase a desarrollo.
Ver capítulo 10
Delivery
Es el proceso de poner un producto o una función a disposición de los usuarios. Implica la planifi-
cación, coordinación y desarrollo necesarios para entregar el producto, garantizando su calidad.
Ver módulo 3
Design Thinking
Es un método de diseño iterativo centrado en el usuario. Permite que surjan nuevas ideas,
indagando primero en los problemas del usuario antes de diseñar y probar soluciones para
resolverlos.
Discovery
Es un proceso de reducción de riesgos que, a través de un contacto regular con los usuarios,
talleres y herramientas adecuadas, permite definir la mejor solución para responder a las
necesidades de tus usuarios.
Ver capítulo 5
207
GLOSARIO
Épica
Es una unidad funcional de valor y describe una parte de la solución a desarrollar para res-
ponder al problema identificado. Una épica es un contenedor de varias Historias de Usuario
que, cuando se desarrollan, contribuyen a entregar el valor objetivo.
Ver capítulo 10
Funcionalidad
Es un conjunto de soluciones que han sido desmitificadas en la fase de discovery .
Las funcionalidades pueden pasar a delivery para ser entregadas a los usuarios.
Ver capítulo 4
Frontend
Es la parte visible de una aplicación, las interfaces para los usuarios (también llamado IHM por
Interface Hombre-Máquina).
Go-To-Market
La estrategia Go-To-Market o lanzamiento de producto permite introducir un producto en el
mercado, desglosando cada etapa del lanzamiento y estructurando cada una de las acciones en la
fase previa al lanzamiento, durante el lanzamiento y post-lanzamiento.
Heatmap
Un heatmap es una representación visual que destaca las áreas de interés de una interfaz.
Muestra las zonas en las que los usuarios hacen clic, pasan más tiempo o interactúan con más
frecuencia.
208
GLOSARIO
Historia de Usuario (user story)
Es una descripción funcional detallada. Una Historia de Usuario describe una
necesidad del usuario y especifica cómo evolucionar el producto para responder a ella.
Ver capítulo 10
Hotfix
Un hotfix es una actualización de software aplicada rápidamente para corregir un problema
específico, generalmente para resolver errores críticos o fallos de seguridad. A diferencia de
una actualización planificada, un hotfix se despliega de manera urgente sin esperar a la próxima
versión.
Ver capítulo 19
Iniciativa
Las iniciativas representan los temas del equipo y pueden adoptar la forma de oportunidades,
que primero tendrán que pasar por una fase de discovery, o de funcionalidades, para después
pasar a delivery.
Ver capítulo 4
Insight
Un insight ofrece una explicación contextualizada de hechos observados, ya sean problemas o
hallazgos alentadores.
Ver capítulo 3
209
GLOSARIO
Kanban
Kanban es un marco de trabajo Agile que recomienda visualizar el trabajo del equipo en un
tablero para seguir y optimizar las diferentes tareas y funcionalidades. Este enfoque permite
mejorar la colaboración, limitar el trabajo en curso y optimizar el flujo de trabajo, favoreciendo
así una entrega más rápida y una mejor calidad de las funcionalidades desarrolladas.
Ver capítulo 11
KPI
Un KPI (Key Performance Indicator) es un indicador clave de rendimiento que mide los elemen-
tos más importantes de tu producto y la consecución de tus objetivos a largo plazo. Evalúa el
estado de salud de tu producto (por ejemplo: 75% de usuarios activos mensuales en el trimestre).
Ver capítulo 16
Lead time
En Kanban, el Lead Time mide en días el tiempo total necesario para realizar un elemento del
Backlog, desde su creación hasta la entrega.
Ver capítulo 12
Lean Startup
El enfoque Lean Startup ofrece una multitud de conceptos y herramientas (Lean Canvas, MVP,
ciclo de aprendizaje) que permiten reducir el “desperdicio” de tiempo y dinero que suele produ-
cirse durante la concepción de un producto.
210
GLOSARIO
MVP
MVP (Minimum Viable Product) significa “producto mínimo viable”, pero se asemeja más a un
proceso. El concepto se basa en el ciclo Build-Measure-Learn de la metodología Lean Startup y
permite probar un producto o una funcionalidad mínima con un público limitado para responder
a un problema específico. El objetivo del MVP es recopilar feedback de los usuarios y aprender
rápidamente para iterar y mejorar el producto posteriormente.
Ver capítulo 8
NPS
El NPS (Net Promoter Score) es una medida utilizada para evaluar la satisfacción y lealtad de
los usuarios. Se basa en una simple pregunta: “En una escala de 0 a 10, ¿cuánto recomendarías
nuestro producto/empresa/servicio a un amigo o colega?”. Las respuestas se clasifican en tres
categorías: promotores (que califican con 9 o 10), pasivos (que califican con 7 u 8) y detractores
(que califican de 0 a 6). El NPS representa la diferencia entre los promotores y los detractores.
OKR (Objectives and Key Results)

Es un método para definir y seguir los objetivos estratégicos de una empresa. Consiste en
establecer objetivos claros y medibles, y definir los resultados clave a alcanzar.
Ver capítulo 2
Onboarding
Es el proceso de familiarización y puesta en marcha cuando un usuario comienza a usar el pro-
ducto. Su objetivo es facilitar la adopción del producto y asegurar una experiencia de usuario
óptima desde el principio.
211
GLOSARIO
Oportunidad
Es un tema relativamente grande que debe abordarse, que puede dividirse en varias suboportu-
nidades cuyas soluciones aún no se conocen. La oportunidad debe pasar primero por una fase
de discovery para especificar el problema que hay que resolver y las soluciones para abordarlo.
Ver capítulo 3
User Persona
Un User Persona es un usuario ficticio típico, basado en datos de usuario, cuyos objetivos y
motivaciones se pretende representar y resumir.
Ver capítulo 6
Propuesta de valor única (Unique Value

Proposition)
Es la expresión única del valor de un producto, que lo distingue de la competencia y
atrae a los clientes. Es una declaración concisa que destaca los beneficios específicos
y las razones por las que los clientes deberían elegir un producto en lugar de otro.
Ver capítulo 5
Release
Es una versión específica de un software, una aplicación o un producto que está lista para
ponerse a disposición de los usuarios. Las funcionalidades y correcciones de bugs se agrupan y
entregan como un todo coherente, identificado por un número o nombre de release específico.
Ver capítulo 13
212
GLOSARIO
Release plan
Se utiliza para planificar el desarrollo de funcionalidades a corto plazo. Define el orden de las
diferentes releases, teniendo en cuenta las prioridades y restricciones.
Ver capítulo 12
Retrospectiva (Retro)
Es una reunión que permite hacer un balance de un período pasado (un Sprint , un trimestre,
un proyecto). El objetivo de la retrospectiva es que el equipo de Producto o el equipo
ampliado (con los stakeholders ) detecten acciones de mejora continua a implementar.
Ver capítulos 11 y 20
Roadmap (hoja de ruta)

Es una representación gráfica simplificada que permite comunicar y compar-
tir eficazmente una intención estratégica con el fin de movilizar, alinear y coor-
dinar los esfuerzos de los stakeholders para alcanzar uno o varios objetivos.
Ver capítulo 4
Scrum
Es un marco de trabajo Agile centrado en la colaboración, la iteración y la entrega
continua de funcionalidades. Se caracteriza por ciclos de desarrollo cortos llamados
“Sprints”, reuniones regulares de planificación y revisión, y un equipo autoorganizado.
Ver capítulo 11
213
GLOSARIO
SQL (Structured Query Language)

Es un lenguaje de programación utilizado para manipular bases de datos relacionales. Permite
realizar operaciones como la creación, modificación y eliminación de datos, así como la gestión
de las estructuras de la base de datos.
Tasa de Conversión
Es una métrica utilizada para medir el porcentaje de usuarios o visitantes que realizan una
acción deseada, como realizar una compra, inscribirse a una newsletter o completar un
formulario.
Tasa de Rebote
Es una métrica utilizada para medir el porcentaje de visitantes que abandonan un sitio después de
consultar solo una página, sin realizar ninguna otra acción.
UI (User Interface)
Interfaz de usuario en español, incluye todos los elementos gráficos visibles que permiten a
un usuario interactuar con el producto. Incluye elementos como menús, botones, iconos,
formularios y otros elementos gráficos que permiten a los usuarios navegar y realizar acciones.
UX (User eXperience)
Se enfoca en la experiencia global de un usuario, su percepción, comportamiento, cuando
interactúa con un producto. La UX abarca todos los aspectos de esta experiencia, incluyendo
la ergonomía y facilidad de uso. La UX pone énfasis en la investigación del usuario, el diseño
centrado en el usuario y las pruebas de usabilidad para optimizar la satisfacción y el compromiso
de los usuarios.
214
GLOSARIO
Velocidad
La velocidad, utilizada en Scrum, es una medida de la cantidad de trabajo que un equipo puede
realizar durante un Sprint. Sirve para estimar la capacidad del equipo y planificar los Sprints
futuros.
Ver capítulo 12
215
Notas
216
Notas
217
Notas
218
Notas
219
Notas
220
Notas
221
Notas
222
Notas
223
¿Quieres aprender más sobre
Producto digital?
Encuentra nuestros libros y recursos descargables en

thiga.co/es
224

Las Claves Del Product Management: Métodos y Estrategias para Lograr El Éxito de Tus Productos Digitales

Cargado por

Las Claves Del Product Management: Métodos y Estrategias para Lograr El Éxito de Tus Productos Digitales

Cargado por

LAS CLAVES

Chloé Dumolard es Lead Product Manager y formadora

Consultora en Thiga desde hace cinco años, Floriane Sirven

Durante la última década, Thiga se ha convertido en un líder en Product Management y

Thiga nació en el ecosistema tecnológico, ayudando a las startups a desarrollar sus

Como pioneros en este mercado, hemos jugado un papel importante en el corazón de la

Si necesitas acompañamiento por nuestra consultoría, encuéntranos en thiga.co/es

Si necesitas formar a tus equipos, acompañamos sus carreras en Product Management y

El marco necesario para la autonomía

Esta autonomía es la clave de tu éxito. Libera la innovación y permite la construcción de

«¿Cuál es tu visión de producto?»

El tema de la visión de producto te concierne, ya seas Product Manager, Product Designer,

Rituales y lenguaje común

Numerosos rituales se presentan a lo largo del libro, particularmente basados en el ejemplo

El impacto como brújula

Estábamos en hipercrecimiento y nuestro objetivo era aumentar la implicación de los equi-

Establecimos los Impact Teams, equipos multidisciplinares responsables de objetivos cuan-

Estos Impact Teams no son un fin en sí mismo, y en Yousign, nuestra organización es

Os deseo una lectura ilustrativa e impactante,

Módulo nº1: Establecer el rumbo............................................................... 18

Módulo nº2: Entender el problema y elegir la solución........................... 54

Módulo nº3: Construir el producto........................................................... 102

Módulo nº4: Mejora continua...................................................................... 160

Históricamente, la gestión de productos surgió en el sector de bienes de consumo en los

A través de nuestras misiones con clientes, hemos probado metodologías de producto y

En este contexto efervescente, hemos consolidado nuestro conocimiento en Thiga. Así

Un libro para todos

Tanto si acabas de llegar al puesto como si eres un Product Manager experimentado,

Como líder de Producto, este trabajo es una herramienta de compartir y transmitir, un

◉ Comprender la visión y la estrategia de tu empresa y de tu producto.

◉ Definir objetivos ambiciosos para tu equipo.

◉ Construir un roadmap orientado a objetivos.

◉ Llevar a cabo un discovery eficaz.

◉ Construir y mantener tu backlog.

◉ Gestionar el delivery con Agile.

◉ Definir los indicadores de éxito adecuados.

◉ Mejorar tu producto de manera continua después de la producción.

Una estructura adaptada a

◉ Por módulo, para profundizar en una etapa específica del proceso.

◉ Por capítulo, para enfocarte en un tema específico.

Thiga Eats es un servicio de entrega de platos cocinados y de productos

Ofrecemos plantillas para ayudarte a utilizar determinadas herramientas.

Estas plantillas son descargables gratuitamente gracias a

En algunos capítulos, ciertos conceptos se destacan a través de recuadros grises.

Estos conceptos te permitirán ampliar tus conocimientos, obtener una

Finalmente, si algunos términos o conceptos no son claros, puedes consultar el glosario al

Aclaraciones para la lectura

En Thiga, consideramos como Producto cualquier bien o servicio destinado a satisfacer

En este libro, utilizaremos el término “producto” para referirnos, según el contexto, a la

Los oficios del Producto

El/la Product Manager (PM) es el director de orquesta del producto. Es responsable de

El/la Product Marketing Manager (PMM) juega un papel fundamental en la estrategia,

Cultura de Producto y cultura de Proyecto

Se distingue entre cultura de Producto y cultura de Proyecto, ya que existen diferencias

Cuando se adopta un enfoque de Producto, generalmente se integra el enfoque Agile para

«Los roadmaps deben

la visión del Producto.»

El roadmap es la herramienta central de un equipo de Producto, ya que

Para construir el roadmap, primero debes dominar el contexto en el que

Apropiarse de la visión y estrategia

La visión, motor de la motivación

◉ Una «declaración en la que creemos », una declaración que resume las

« Estamos convencidos de que cada persona debe poder disfrutar de una

◉ Una «declaración de diferenciación», una declaración que destaca las

Declaración de diferenciación de Thiga Eats

Para los habitantes de grandes ciudades que no tienen ni el tiempo ni la

La estrategia, un marco para la ambición

◉ El diagnóstico explica el “por qué”: permite una comprensión común y clara de la

situación actual del producto en el mercado, identificar tendencias fundamentales

◉ La dirección responde al “qué”: es el enfoque a adoptar para responder al desafío

◉ Las acciones detallan el “cómo”: forman un conjunto coherente que permite

Contribuir al diagnóstico estratégico

El diagnóstico se compone de información sobre el mercado, la organización y el producto.

Elementos del diagnóstico

Información sobre el mercado

Para realizar este análisis, puedes: