¿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. 

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 en el futuro cercano. 

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. 

¿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.
  • 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 los Equipos de Producto acerca del futuro del producto porque hay visibilidad de las oportunidades.
  • Se facilita la priorización.
  • Los Equipos de Producto tienen una guía que los habilita a tomar decisiones tácticas efectivas.

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)
  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).

Taller de Product Strategy y Materiales relacionados

Para seguir contagiando nuestra pasión, en Kleer diseñamos un Taller de Product Strategy. Si te interesa y quieres participar, regístrate en este formulario –vamos a hacer una sesión de práctica con  grupo reducido de participantes y nos interesa tu feedback y participación.

También incluimos debajo una lista con materiales de referencia para que puedas investigar y aprender más sobre Estrategias 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.

Publicado también en el blog de Kleer.

7 + 1 tips para el Liderazgo Ágil Transformacional

El Póster “Liderazgo Ágil Transformacional en pocas palabras” de Mia Kolmodin y Björn Sandberg me pareció muy interesante así trabajé con ellos y con Elysabeth Guevara para hacer la traducción al español (ya antes hicimos la traducción del Póster Agile Product Ownership).

Captura parcial del Póster
Captura parcial del Póster Liderazgo Ágil Transformacional

Algunos de los temas tratados en el póster son: el cambio de liderazgo y de la gerencia para apalancar las transformaciones ágiles, el mindset ágil y contexto organizacional que incluye el Marco Cynefin, el estilo de liderazgo ágil y organizaciones que aprenden en contextos VUCA. 

Los 7 tips a intentar en este camino de transformación son:

  1. Optimizar la eficiencia de flujo en lugar de la eficiencia de recursos
  2. Crear redes para fomentar el crecimiento de las personas
  3. Habilitar el desempeño mediante la autonomía y la responsabilidad en lugar de gestionar el desempeño
  4. Potenciar a las personas en lugar de considerarlos recursos
  5. Definir los complejos desafíos y valorizar la experimentación y el aprendizaje
  6. Habilitar los sistemas de gestión de trabajo tipo “pull” en lugar de “push” 
  7. Encontrar juntos los procesos mínimos viables

En Kleer te acompañamos en tu camino hacia la agilidad organizacional y consideramos que el cambio de estilo de liderazgo es muy importante para su éxito. Especialmente nos referimos a un desarrollo específico para incrementar el nivel de conciencia de los líderes tanto individual como grupalmente. Nuestro programa de liderazgo ágil comienza con un assessment 360 e incluye formación y práctica de varios de los temas tratados en el Póster y algunos otros. Asimismo el proceso incluye sesiones de Agile Coaching individual.

¿Y cuál es el octavo tip para el Liderazgo Ágil Transformacional? Impulsar la mentalidad o el pensamiento de Producto a toda la organización con el objetivo de ser más efectivos en sus resultados comerciales, alinear su estrategia de productos con estos objetivos, y priorizar a las iniciativas más eficaces que ayudarán a convertir esos productos en generadores sostenibles de crecimiento. Si quieres saber más de estos programas de liderazgo ágil contáctanos

Aquí les dejo el post original de Mia Kolmodin en el blog de Dandy People donde también pueden descargarlo libremente. Por otro lado en el blog de Kleer encontrarán posts de transformaciones ágiles y temas afines.

Descarga el Poster en español aquí

Pablo Lischinsky

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

Un Checklist latino para Product Owners

¿Qué tiene que saber, ser y tener un Product Owner para ser “ideal”?

 

User Story Mapping
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 oportunosTommy 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_xa8xZYg3FTGH7ONhMYFIJLu3PDg6ncc9D3XYSIXBCQ/edit#heading=h.1rh3pipkg4by

Advanced Product Owners

apow-prisma

A medida que los Equipos Scrum van creciendo en experiencia y ganando madurez, sus Product Owners (POs) disponen de nuevas oportunidades y enfrentan diversos desafíos. Algunos autores se refieren a que debemos pasar de “entregar el producto” (product delivery) a “descubrir el producto” (product discovery) con foco en innovación y la experimentación para maximizar la Productividad, Calidad y Satisfacción del Equipo y de la Comunidad del Proyecto completa.

Desde el punto de vista del rol de Product Owner se requiere entonces avanzar a un nivel mayor de conciencia y entendimiento de las necesidades del negocio a través de los Stakeholders, de las capacidades de los Equipos y el conocimiento del ecosistema completo en el que nos encontramos y al que queremos impactar positivamente a través del Producto que se está co-creando.

Vemos entonces que el rol de PO tal como se pensó originalmente está limitado en sus capacidades, competencias y responsabilidades y no está del todo adaptado a cómo concebimos la agilidad y el desarrollo de productos hoy en día. Siguiendo el espíritu de la mejora continua debemos evolucionar el rol de PO.

Algunos de los ejes de transición de los Product Owners son:

PO Nivel Básico

PO Nivel Avanzado

Conocer y representar los intereses de todos los Stakeholders del proyecto. Acercar el equipo al negocio para facilitar una conversación más directa entre todo el equipo Scrum y los Stakeholders.
Expresar claramente los ítems del Product Backlog y priorizarlos para alcanzar los objetivos del producto de la mejor forma posible, buscando optimizar el valor del trabajo del Equipo de Desarrollo. Impulsar la co-creación de funcionalidad nueva o mejorada utilizando innovación incremental, usando conceptos de Lean Development, Hypothesis-Driven Innovation y herramientas de Design Thinking.
Hacer visible al Product Backlog y lograr que sus ítems sean entendidos al nivel necesario por el Equipo Scrum y los Stakeholders. Utilizar planes de release, mapas de impacto, mapas de historias de usuario y customer journeys como herramientas estratégicas para la toma de decisiones del negocio y el equipo de desarrollo trabajando juntos.
Responsable del Retorno de la Inversión (ROI) del proyecto. Fomentar que la responsabilidad del equipo y toda la comunidad del proyecto esté firmemente vinculada a los resultados del negocio.

Para colaborar en el desarrollo de las habilidades avanzadas del rol de Product Owner, Kleer ofrece el entrenamiento Advanced Product Owners Workshop (APOW), ver temario y más información aquí.

Este artículo fue escrito en equipo por Ricardo ColussoPablo Lischinsky, ¡en la foto de abajo en plena acción de APOW!

rickypabloapow