Product Owner - Blog de Pablo Lischinsky

21/6/22, 08:53 Product Owner – Blog de Pablo Lischinsky
Blog de Pablo Lischinsky

Agile & Product Consulting, Coaching, Training, Mentoring
Etiqueta: Product Owner
¿Por qué crear una Estrategia

de Producto?
(qué evitar y qué es lo importante)
Por Pablo Lischinsky y Ricardo Colusso
Cuando hablamos de una Estrategia de Producto nos referimos a un plan de alto nivel
que describe:
lo que una organización quiere lograr con su producto, y

cómo planea hacerlo
para impulsar la estrategia de la empresa.
https://pablolischinsky.wordpress.com/tag/product-owner/ 1/20
Ilustración de Ingrith Rojas
La Estrategia de Producto también incluye un diagnóstico de la situación actual,

junto con la selección de problemas relevantes y oportunidades sobre las que
pondremos foco.
Construimos productos para entregar valor a los clientes y para que impulsen y
hagan sostenible a la Empresa. La Estrategia de Producto es entonces una
conexión entre la visión del Producto y los resultados buscados, tanto de los clientes
como de la Empresa.
¿Por qué es difícil crear y mantener la Estrategia de

Producto?
Como dice Marty Cagan en su libro Empowered, definir una Estrategia de Producto
requiere cuatro cosas que son difíciles en la mayoría de las empresas:
Estar dispuesto a tomar decisiones difíciles sobre lo que es realmente

importante.
Identificar y aprovechar los hallazgos (insights).

Convertir los hallazgos en acciones innovadoras.
Hacer gestión activa sin recurrir al micromanagement.
Elegir significa tener foco. Decidir qué pocas cosas hay que hacer realmente y, por lo
tanto, todas las que no se van a hacer.
¿Por qué dedicarle energía y tiempo a la Estrategia de

Producto?
Cuando hay una Estrategia de Productos bien definida y comunicada:
Product Management provee claridad a stakeholders y a los equipos acerca del

futuro del producto porque hay visibilidad de las oportunidades a explorar.
Se facilita la priorización ya que se ordenan los problemas y oportunidades más
que las funcionalidades o entregables (outcomes over outputs).
Los equipos de Producto tienen una guía que los habilita a tomar decisiones
tácticas efectivas a su alcance.
Algunos tips sobre qué evitar y qué es lo más

importante en una Estrategia de Producto
Abordar una Estrategia de Producto es complejo y requiere esfuerzo.
Qué evitar
1. Creer que la Estrategia de la Empresa = Estrategia de Producto

2. A partir de la Estrategia de la Empresa crear un Portafolio de Proyectos extensa y
asignársele a los equipos para que los “construyan” (no caer en la trampa de
construir, ver libro de Melissa Perri)
3. Creer que hacer OKRs es tener una estrategia de Producto
Lo más importante y lo que debes impulsar
1. Dedicar esfuerzo a desarrollar – y revisar periódicamente – la Estrategia de

Producto que indica una dirección clara y comunicada.
2. Definir un proceso básico de desarrollo de esta estrategia que incluya una
investigación cualitativa y cuantitativa, priorización de los hallazgos,
formulación de hipótesis, ejecución de experimentos de validación, y creación
de Roadmaps orientados a resultados.
3. Apoyarse en técnicas como OKRs para Equipos de Producto con la idea de medir
el avance del equipo. Ajustar la Estrategia de esos logros y aprendizajes.
4. Desarrollar Equipos de Producto empoderados para llevar adelante desafíos de
Productos de punta-a-punta (y ya no desarrolladores de funcionalidades).
Evolucionar los equipos para hacer Dual Track continuo, es decir, hacer Product
Discovery y Product Delivery continuo y en paralelo.
Definir y desarrollar “Opportunity Solution Trees” como base táctica para la
experimentación y el desarrollo de aprendizaje validado.
Taller de Product Strategy y Materiales relacionados

Para seguir contagiando nuestra pasión, en Kleer diseñamos un Taller de Product
Strategy y acompañamiento tanto a equipos de producto como a la Gerencia de
Producto. Contáctanos si te interesa.
Materiales de referencia para que puedas investigar más sobre Estrategia de

Producto:
Inspired: How to Create Tech Products Customers Love, 2nd Edition, Marty Cagan,
2017.
Empowered: Ordinary people, extraordinary results, Marty Cagan y Chris Jones,
2020.
Escaping the Build Trap: How Effective Product Management Creates Real Value,
Melissa Perri, 2018.
Product Direction, How to build successful products at Scale, with Strategy,
Roadmaps and OKRs, Nacho Bassino, 2021.
Outcomes over Outputs, Why customer behavior is the key metric for business
success, Joshua Seiden, 2019.
Pablo Lischinsky / 6 mayo, 2021 / Agilidad / product discovery, Product Management, Product
Owner / Deja un comentario
Slicing: 18 maneras de mejorar tus

Historias de Usuario
Post creado junto a Ricardo Colusso
Co-creando Historias de Usuario más pequeñas y simples
Junto a Ricardo Colusso y Elysabeth Guevara estuvimos trabajando en una nueva

versión de las Cartas de Slicing. De estas cartas han evolucionado varias versiones en
Kleer, también estuvieron involucrados Damián Buonamico y Martín Salías. El actual
formato está inspirado en las cartas de DoD y DoR de Thomas Wallet.
Ágiles 2016, Quito, Facilitación por Cris Rúa

Ágiles 2016, Quito. @AgilEsCrisRua
Las Cartas de Slicing te ayudarán a encontrar nuevos criterios para subdividir las
Historias de Usuario grandes (épicas) y complejas en otras más pequeñas y simples.
El alcance del juego es dividir historias de usuario o épicas en historias más pequeñas
en el contexto del desarrollo de software, aplicado a los Ítems de un Backlog de
Producto (PBI), aunque se puede extrapolar a otros contextos.
Puedes utilizarlas en sesiones de Refinamiento y Planning para trabajar de manera

colaborativa con el equipo de desarrollo y el Product Owner.
¿Qué es Slicing?
Al hacer desarrollo ágil de software, nuestra prioridad número uno es

satisfacer al cliente con la entrega temprana y continua de software de
valor, y la pregunta que debemos hacernos constantemente es: ¿cuál es la
forma más simple y rápida de entregar algo de valor al cliente? Para
responder esa pregunta, podemos reformularla como: ¿cuáles son
algunas opciones para entregar valor a un cliente lo antes posible? Esta
es la esencia de hacer slicing o cortes de historias: el por qué detrás de
esto.
La pregunta no es: ¿cuál es la forma más sencilla y rápida de desarrollar
esta historia?
— Effective story slicing por Neil Killick
Slicing o splitting (dividir, rebanar en cortes) es una práctica que permite reducir la
complejidad y esfuerzo requerido de las Historias de Usuario, y que se aplica a todos
los ítems sobre los cuales trabaja el equipo. Cuánto más pequeñas sean las Historias
de Usuario resultantes, mayor será además la posibilidad de completarlas dentro de
un Sprint. Eso mitiga el riesgo de que las Historias de Usuario y habilita obtener
feedback frecuente y temprano los cual es muy importante en contextos complejos.
Si su «corte» (división) da como resultado múltiples historias más

pequeñas, cada una de las cuales se deben entregar para completar la
más grande, en realidad no está «cortando» (dividiendo), se está
descomponiendo. La división (incluso la división funcional y técnica) da
como resultado opciones independientes, no tareas que obligatoriamente
debe hacer.
— Neil Killick @neil_killick

https://twitter.com/neil_killick/status/1021558297755697154?s=20
Este juego de cartas te ayudará a tener un Product Backlog más refinado y manejable
para entregar valor de manera iterativa e incremental.
Un proceso iterativo e incremental es aquel que progresa a través del refinamiento

sucesivo. Iteramos para encontrar o mejorar el valor entregado. Lo hacemos de
forma incremental para construir gradualmente y así obtener el valor de negocio
buscado.
Es un compromiso de todo el equipo que se puede mejorar con el tiempo.
Las cartas
El juego consta de cartas de criterios que podrían utilizarse para dividir una Historia de
Usuario compleja. Por ejemplo:
También cuenta con cartas vacías para agregar nuevos criterios no contemplados en
el juego.
Recomendaciones de Impresión
Se recomienda imprimir las cartas a color, en tamaño A6 (105 x 148 mm) o similar,
sobre un papel estucado/cuché/recubierto de 300 gramos. Otra opción es usar un
papel de menor calidad y plastificar las cartas o usarlas en sobres de plástico
transparente, lo cual permite hacer anotaciones en el sobre con marcador de pizarra.
La última carta es el dorso de las otras cartas.
¿Cómo jugar?
Descarga las Cartas de Slicing
Dada una historia de usuario aparentemente muy grande o compleja:
1. Repartimos todas las cartas entre los participantes de la reunión de refinamiento.
2. Cada participante elige entre sus cartas la que considera que contiene la mejor
estrategia de slicing posible y la pone sobre la mesa.
3. Por consenso se decide cuál de todas las estrategias sobre la mesa será la más
conveniente y se aplica para crear las nuevas historias derivadas de la historia
original.
¡A jugar colaborativamente con todo el equipo!
Ejemplo de una épica y las historias de usuario resultantes
Conoce más de las Cartas de Slicing escaneando este QR o entrando a kl.la/slicing-

kards y cuéntanos cómo las usaste con #SlicingKards en las redes sociales.
Conoce más de nuestros entrenamientos relacionados: Advanced Product Owners y
Product Discovery. En Kleer ayudamos en en el camino de la Agilidad Organizacional.
Por otro lado en el blog de Kleer encontrarán posts de transformaciones ágiles y
temas afines.
Enlace a Cartas de Slicing en kleer.la
Para saber más:
1. How to Split a User Story, R. Lawrence.

2. Why Most People Split Workflows Wrong, R. Lawrence.
3. Fifty Quick Ideas to Improve your User Stories, G. Adzic y D. Evans.
4. The essence of story slicing in agile development, N. Killick.
5. Effective story slicing , N. Killick.
6. Slicing heuristics, N. Killick.
7. Elephant Carpaccio exercise Facilitation guide, Henrik Kniberg & Alistair Cockburn.
8. Kate Oneal: Meeting with Susan, Ron Jeffries.
Pablo Lischinsky / 1 abril, 2020 / Product Management / Product Owner, refinement, Scrum,
Slicing, user stories / 1 comentario
Póster «Agile Product Ownership»
Hace pocos días encontré el Póster «Agile Product Ownership» de Mia Kolmodin y me
pareció muy bueno y digno de compartir, así que decidí escribirle para ofrecerle hacer
la traducción al español.
No pretende ser una traducción ortodoxa sino más bien útil y enmarcada dentro del
contexto de la comunidad ágil de Latinoamérica, en la que me muevo desde hace
algún tiempo. Así que me tomé ciertas libertades al dejar en inglés algunas frases o
palabras como el título.
Aquí les dejo el enlace al post de Mia en el blog de Dandy People donde pueden
descargarlo libremente: https://dandypeople.com/blog/translated-to-spanish-agile-
product-ownership-in-a-nutshell-poster/
Hay mucha información en el poster, no solo para los Product Owners y/o Product
Managers sino para todo el equipo de desarrollo de productos.
¡Espero que les sea de utilidad y que lo difundan!
Descarga el Poster en español aquí.
Pablo Lischinsky
@pablolis
Pablo Lischinsky / 5 junio, 2017 / Agile, Business agility, Scrum / design, experiments, innovation,
product development, product discovery, Product Management, Product Owner, value / 2 comentarios
Product Owners que potencian las

Transformaciones Digitales
Por Pablo Lischinsky @pablolis y Ricardo Colusso @rcolusso
El Framework Scrum promueve el rol de “Product Owner” (PO) y si bien su concepción y

descripción original no ha evolucionado mucho, el contexto actual de las empresas y
de las transformaciones digitales sí ha cambiado las exigencias sobre este importante
rol. En este trabajo cuestionamos el rol del PO y proponemos algunas opciones para
potenciar sus destrezas. Gestionar el product backlog ya no es suficiente para
maximizar el ROI.
Transformarse o quedar atrás
Las grandes empresas que tienen en su núcleo de negocio servicios digitales se

enfrentan a nuevas startups con propuestas disruptivas que amenazan sus modelos
de negocio. Además, los consumidores tienen nuevas demandas y es un desafío
adaptarse y mantenerse vigente, con el riesgo de quedarse atrás de la competencia y
perder clientes.
Tradicionalmente el Product Owner (PO) dentro de un equipo Scrum se ocupa de la gestión

del backlog de cara a los stakeholders y el equipo de desarrollo, buscando siempre
maximizar el retorno de inversión (ROI).
El trabajo del PO “tradicional” se centra entonces en hacer bien el producto relevado

o demandado ayudando al equipo a entregar el mayor valor posible en cada
iteración. Sin embargo, por diversas razones las transformaciones digitales presentan
desafíos que no pueden superarse trabajando de esa manera, entre ellas:
1. Los productos a desarrollar tienen un alto contenido de discovery: pretenden dar

respuesta a problemas inéditos para los cuales no hay soluciones efectivas
conocidas.
2. Requieren descubrir y diseñar en forma colaborativa, emergente, iterativa e
incremental un producto que sea de valor para el negocio, de alta usabilidad (UX)
y técnicamente factible.
3. Existen dependencias entre diferentes áreas de la organización que se convierten
en impedimentos duros o provocan retrasos.
4. Los stakeholders impactados por el producto suelen tener amplios desacuerdos
en sus intereses y presentar contradicciones al momento de plantear sus
necesidades.
5. Existen otros roles dentro de las empresas que se solapan con el rol de PO:
Product Manager, CEO, Director, Marketing y Ventas, con visiones del negocio no
siempre holísticas o sistémicas.
6. En los niveles directivos se presentan sesgos cognitivos sobre la dirección del
producto a desarrollar, con imposición de visiones no validadas y micro-
management.
7. El contexto organizacional puede dificultar la colaboración y la co-creación
entre stakeholders claves y el equipo de desarrollo.
Es por esto que las Transformaciones Digitales requieren que los POs adquieran
nuevas habilidades para que desde su rol colaboren en el logro de los objetivos de
negocio esperados.
No se trata ya de crear un producto correctamente sino también de hacer el

producto correcto. Construir eficientemente el producto equivocado es un enorme
desperdicio.
Habilidades de los Product Owners para las Transformaciones

Digitales
Buscamos que los Product Owners que trabajan en el contexto de Transformaciones

Digitales adquieran nuevas habilidades estratégicas, de facilitación y trabajo en equipo
y nuevas técnicas y herramientas.
HABILIDADES ESTRATÉGICAS
Un PO con un enfoque más centrado en la estrategia de negocio/producto y el

valor entregado a los stakeholders que en la táctica de desarrollo del mismo.
Un PO más consciente de que puede estar enfrentándose a contextos complejos
o de problemas desconocidos y soluciones desconocidas, para los cuales lo más
sensato es trabajar en ciclos de aprendizaje y validación de hipótesis haciendo
experimentos basados en prototipos.
Conocimiento del ciclo de vida de productos, tipos de modelos de negocio, sus
riesgos y su impacto en desarrollo de productos.
No sólo usar métricas de proceso sino además métricas cuantitativas y
cualitativas de negocio para medir el impacto real y poder validar la estrategia
usada.
HABILIDADES PARA LA FACILITACIÓN Y TRABAJO EN EQUIPO
Los productos que son el resultado de la co-creación entre personas técnicas y del
negocio, en ambientes facilitados por Product Owners que estimulan el
entendimiento sistémico de la empresa, la negociación, la innovación, la
experimentación y el aprendizaje (Discovery).
Facilitar conversaciones y talleres efectivos para lograr una visión y estrategia

compartida de producto con los stakeholders clave y el equipo de desarrollo.
Un PO con un enfoque más cercano a un líder al servicio de la comunidad del
producto que de un “dueño” de la verdad.
Confianza en el equipo de desarrollo al apoyar sus iniciativas técnicas de
refactoring, automatización de pruebas, spikes, pair programming y todo lo que
decidan para mantener gestionada la deuda técnica del producto y ayudarlo a
hacer visible a la gerencia/directorio sobre estas prácticas y su necesidad para
mantener el código de alta calidad y adaptable.
Ayudar activamente a construir un excelente ambiente de trabajo donde el
equipo pueda crecer en todos los aspectos.
CONOCIMIENTO Y USO DE NUEVAS TÉCNICAS Y HERRAMIENTAS
Nuevos enfoques para apoyar y lograr mecanismos de desarrollo evolutivo e

incremental incluyendo los procesos de discovery y desarrollo experimental (Design
Thinking, Prototyping, Lean Startup, Lean UX, Analytics y desarrollo ágil de
software).
Herramientas de priorización del backlog utilizando conceptos de valor de negocio,
costos de oportunidad y otros.
Conclusión
En el complejo y cambiante contexto global empresarial de hoy los Product Owners no

pueden limitarse a gestionar el backlog, deben desarrollar habilidades estratégicas,
habilidades de facilitación y conocimiento en nuevas técnicas para maximizar el ROI
de sus productos. Los POs avanzados que cuenten con esas habilidades tendrán un
rol muy importante en el liderazgo y desarrollo de productos digitales de valor.
Pablo Lischinsky / 2 marzo, 2017 / Agile, Empredimiento, Lean, Lean Startup, Scrum / Business
model, Business strategy, business value, customer development, design, development team, diseño,
experiments, innovación, innovation, Lean, Lean Enterprise, Lean Startup, prioritizing, product backlog,
product development, product discovery, Product Manager, Product Owner, prototyping, Scrum, Scrum
Master, Scrum team, software development, sprint, stackeholders, teamwork, user stories, UX, valor,
value, value stream / 1 comentario
Un Checklist latino para Product Owners
¿Qué tiene que saber, ser y tener un Product Owner para ser «ideal»?
User Story Mapping
Introducción
Existen varias interpretaciones para el rol «Product Owner» de Scrum, definido de
forma oficial en la Guía de Scrum.
Este «Checklist latino» pretende ser una herramienta útil para que tanto Product
Owner’s como Scrum Masters y personas del negocio puedan analizar en qué aspectos
están suficientemente bien y en qué aspectos podrían mejorar, de forma tal de ser
cada vez mejores en su oficio o rol. ¿Cuál es mi norte como Product Owner (PO)?
Existen variaciones del rol de PO en función de diversas circunstancias:
Madurez del equipo en cuanto a su recorrido en agilidad (ver Shu-Ha-Ri).

Tipo de producto (para clientes internos (IT), producto digital masivo (Ej. Trello))
Segmento vertical: games, banking, empresa centrada en producto(s).

Momento dentro del Ciclo de Vida del Producto (no es lo mismo antes de validar
Product/Market fit que durante crecimiento, madurez o declive).
La complejidad del producto (productos muy complejos pueden requerir de un
equipo que cumpla el rol de PO en lugar de una persona).
Responsabilidades
Comprensión: de la necesidad y el valor del negocio. Business skills.
Tener el norte claro: descubrir, clarificar y comunicar la Visión.
Construir, validar (con los interesados), comunicar y actualizar periódicamente el
Roadmap (hoja de ruta, plan de entregas).
Análisis de Información: saber identificar diferentes niveles o jerarquías de
información, categorizar, dividir (hacer slicing), reunir, generalizar, especializar.
Priorización – Decir que no.
Tener foco en el Retorno de Inversión centrado en los objetivos de negocio.
Dar ejemplos concretos que ilustren y permitan entender mejor.
Irradiar información: saber llevar de una manera asertiva la información del
negocio hacia el equipo. Todo el equipo debe tener claro el problema o visión del
producto.
Validación: es responsable de la validación del producto recibido.
Indagar, preguntar acertadamente (preguntas abiertas o cerradas según
corresponda en cada momento).
Organizar y facilitar las reuniones de Refinamiento del Product Backlog,
Planificación del Sprint y Revisión del Sprint.
Asistir a la Retrospectiva del Sprint. Dependiendo de la madurez del equipo de
desarrollo y del equipo de Scrum, a veces se recomienda realizar una Retrospectiva
interna para el Equipo de Desarrollo para tratar temas más técnicos y de gestión
propia del equipo y otra reunión de Retrospectiva en la cual participen todos:
Scrum Master, Equipo de Desarrollo y Product Owner.
Muy recomendado: Asistir a la Reunión Diaria.
Obtener feedback y dar visibilidad del impacto al cliente en cada iteración.
Mantener el Backlog actualizado (refinamiento adecuado, priorizado).
Fomentar la sinergia entre el Scrum Master y el Equipo de Desarrollo, en pro del
crecimiento en conjunto del Equipo de Scrum.
Si corresponde, coordinarse con los demás Product Owners de un producto o

negocio.
Prestar atención y foco a que las decisiones de diseño (UX – user experience) se
hagan en acuerdo con diseño de la arquitectura.
Constante presencia y colaboración con el equipo de desarrollo. Si es posible, que
trabajen físicamente juntos.
Colaborar en la evolución de la madurez del equipo (ver Tuckman-Lencioni).
Habilidades
Pasión por el problema que estamos queriendo resolver y el descubrimiento del
producto ajustado para resolverlo.
Capacidad de escucha.
Negociación.
Ser un líder y referencia dentro de la organización sobre la visión y el rumbo del
producto.
Comunicación efectiva y eficiente.
Conocer el contexto de negocio (competencia, tendencias).
Empatía con los clientes, el equipo, el scrum master, los interesados, el negocio.
Motivar a que todos los involucrados estén emocionados por construir el producto.
Interactuar con toda la comunidad que debe estar presente a la hora de definir
detalles y cuestiones macro del producto en construcción. Ejemplos: Product
Management, Estrategia, Marketing/ventas.
Manejo excelente de su tiempo.
Facilitación. Para situaciones en las cuales se requiere que un grupo de personas
se pongan de acuerdo o lleguen a una definición de prioridades o un detalle de
características.
Buen relacionamiento. Mucho más importante que tener todas las respuestas, es
tener la habilidad de saber “dónde” encontrarlas.
Técnicas, prácticas, metodologías que debería conocer y

manejar
Agile Manifesto: Valores y Principios.
Scrum
Lean Startup.
Design Thinking.
Agile inception.
User Story Mapping.
Impact Mapping.
Facilitación de espacios participativos.
Definición y división de Historias de Usuario.
Diversas técnicas de Priorización.
Definición de MVP (Producto Mínimo Viable).
Conceptos de Desarrollo ágil, iterativo e incremental de software con el objetivo de
ir descubriendo el valor de negocio.
Elevator Pitch.
HDD (Hypothesis Driven Design / Development).
Realizar experimentos – Canvas de Experimentos.
Métricas/Analytics.
UX (experiencia de usuario).
Prototyping.
Time boxing – Pomodoro.
Artefactos / Herramientas
Story Map.
Product Backlog.
Product Vision Board.
Impact Map.
Kanban board.
Métricas y gráficas de rendimiento.
Acerca de este documento

Este documento fue ideado por integrantes de la Comunidad Latinoamericana de
Metodologías Ágiles.
Quienes participaron en la creación del mismo fueron:
Alejandro Posada (Colombia), Giovanny Cifuentes (Colombia), Guillermo Alvarado

(Colombia), Marcela Barrera, (Colombia), Pablo Tortorella (Argentina), Pablo Lischinsky
(Uruguay), Rox Muñoz (México).
Colaboradores que aportaron con su lectura y comentarios oportunos: Tommy

Christie (Argentina), Roberto Mejías (Chile).
¿Comentarios? Los invitamos a leerlo y agregar sus sugerencias en el documento

compartido:
https://docs.google.com/document/d/1_xa8xZYg3FTGH7ONhMYFIJLu3PDg6ncc9D3XYS
IXBCQ/edit#heading=h.1rh3pipkg4by
Pablo Lischinsky / 24 enero, 2017 / Agile, Scrum / Agile, Backlog, Business strategy, desarrollo de
software, experimentación, gestión de requisitos, Lean Enterprise, Lean Startup, product development,
product discovery, Product Management, Product Manager, Product Owner, Scrum, Scrum Master,
software development, stakeholders, user stories, UX, valor, value, XP / 1 comentario
ENTRADAS ANTERIORES
Blog de Pablo Lischinsky / Blog de WordPress.com.

Product Owner - Blog de Pablo Lischinsky

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Product Owner - Blog de Pablo Lischinsky

Cargado por

Copyright:

Formatos disponibles

21/6/22, 08:53 Product Owner – Blog de Pablo Lischinsky

Blog de Pablo Lischinsky

Etiqueta: Product Owner

¿Por qué crear una Estrategia

(qué evitar y qué es lo importante)

Por Pablo Lischinsky y Ricardo Colusso

lo que una organización quiere lograr con su producto, y

para impulsar la estrategia de la empresa.

Ilustración de Ingrith Rojas

La Estrategia de Producto también incluye un diagnóstico de la situación actual,

¿Por qué es difícil crear y mantener la Estrategia de

Estar dispuesto a tomar decisiones difíciles sobre lo que es realmente

Identificar y aprovechar los hallazgos (insights).

¿Por qué dedicarle energía y tiempo a la Estrategia de

Product Management provee claridad a stakeholders y a los equipos acerca del

Algunos tips sobre qué evitar y qué es lo más

1. Creer que la Estrategia de la Empresa = Estrategia de Producto

Lo más importante y lo que debes impulsar

1. Dedicar esfuerzo a desarrollar – y revisar periódicamente – la Estrategia de

Taller de Product Strategy y Materiales relacionados

Materiales de referencia para que puedas investigar más sobre Estrategia de

Slicing: 18 maneras de mejorar tus

Post creado junto a Ricardo Colusso

Co-creando Historias de Usuario más pequeñas y simples

Junto a Ricardo Colusso y Elysabeth Guevara estuvimos trabajando en una nueva

Ágiles 2016, Quito, Facilitación por Cris Rúa

Puedes utilizarlas en sesiones de Refinamiento y Planning para trabajar de manera

Al hacer desarrollo ágil de software, nuestra prioridad número uno es

— Effective story slicing por Neil Killick

Si su «corte» (división) da como resultado múltiples historias más

— Neil Killick @neil_killick

Un proceso iterativo e incremental es aquel que progresa a través del refinamiento

Es un compromiso de todo el equipo que se puede mejorar con el tiempo.

Descarga las Cartas de Slicing

Dada una historia de usuario aparentemente muy grande o compleja:

1. Repartimos todas las cartas entre los participantes de la reunión de refinamiento.

¡A jugar colaborativamente con todo el equipo!

Ejemplo de una épica y las historias de usuario resultantes

Conoce más de las Cartas de Slicing escaneando este QR o entrando a kl.la/slicing-

Enlace a Cartas de Slicing en kleer.la

Para saber más:

1. How to Split a User Story, R. Lawrence.

Póster «Agile Product Ownership»

¡Espero que les sea de utilidad y que lo difundan!

Descarga el Poster en español aquí.

Product Owners que potencian las

Por Pablo Lischinsky @pablolis y Ricardo Colusso @rcolusso

El Framework Scrum promueve el rol de “Product Owner” (PO) y si bien su concepción y

Transformarse o quedar atrás

Las grandes empresas que tienen en su núcleo de negocio servicios digitales se

Tradicionalmente el Product Owner (PO) dentro de un equipo Scrum se ocupa de la gestión

El trabajo del PO “tradicional” se centra entonces en hacer bien el producto relevado

1. Los productos a desarrollar tienen un alto contenido de discovery: pretenden dar

No se trata ya de crear un producto correctamente sino también de hacer el

Habilidades de los Product Owners para las Transformaciones

Buscamos que los Product Owners que trabajan en el contexto de Transformaciones

Un PO con un enfoque más centrado en la estrategia de negocio/producto y el

HABILIDADES PARA LA FACILITACIÓN Y TRABAJO EN EQUIPO

Facilitar conversaciones y talleres efectivos para lograr una visión y estrategia

CONOCIMIENTO Y USO DE NUEVAS TÉCNICAS Y HERRAMIENTAS

Nuevos enfoques para apoyar y lograr mecanismos de desarrollo evolutivo e

En el complejo y cambiante contexto global empresarial de hoy los Product Owners no

Un Checklist latino para Product Owners