Comparativa con otras responsabilidades

Clase 5 de 12 • Curso de Fundamentos de Product Owner

Clase anteriorSiguiente clase

Christian Manuel Campos Navarro

student•

Se nota el conocimiento y dominio del tema de la profesora.

Es muy esclarecedora su forma de explicar los temas del curso.

Gracias.

Yangetze González

company_admin•

De verdad que sí.

Iván Felipe Bohórquez Ramírez

student•

Es una profesional en la materia

Luciano Vicidomini

student•

DIFERENCIAS CON LOS SIGUIENTES ROLES: • PRODUCT MANAGER: crean estrategias globales del producto. Además de lo que hace un PO ve estrategias de marketing y toda la logística que esta atrás de un equipo. Dentro de un equipo también tiene roles como los del Po. Puede ser que un Product manager se encargue del proyecto global y tenga a varios PO haciendo partes de ese proyecto. Ellos crean estrategias para construir productos: planificación, ejecución y lanzamiento. • BUSINESS ANALYST: Ayuda a identificar y definir las soluciones que maximizarán el valor entregado por una organización a sus partes interesadas. Muchas veces se confunde este rol con el del PO. Un PO puede tener un analista que lo apoye en sus actividades, un PO puede también ser un business analyst y tener las responsabilidades propias del PO. Los Business analyst no priorizamos, simplemente se facilita la información para que otros tomen decisiones.

María Jimena Rodríguez Contreras

student•

gracias

Marylin Giugni Ortega

student•

De acuerdo con el caso de estudio y la explicación, considero que Product Manager es Susana, Product Owner es Sergio y Business Analyst es Alejandro

Mario Andrés Castro Martínez

student•

Nunca pensé encontrarla por acá profe, un verdadero gusto. 😊

Jesús Jurado de la Rosa

student•

Me gusto la acotación de que el Business Analyst generaliza la información, mas no la prioriza. Super importante!

Mauricio Ricardo Suárez Calderón

student•

¿Qué opinan de estas definiciones? Quiero saber si estoy en lo correcto o estoy equivocado en alguna de ellas.

Vanessa Amaya

teacher•

Hola Mauricio! aquí te dejo mis observaciones y comentarios sobre lo redactaste.

Durante el curso no hablo de OKRs, así que si vas a citar a Platzi y a este curso como fuente, podría dar un mensaje equivocado sobre el contenido del curso.

Ahora bien, de manera general, tanto el Product Owner como el Product Manager pueden llevar a cabo el seguimiento a través de los OKRs, incluso el Business Analyst.

El Product Manager se encarga de definir la estrategia de producto y supervisa su proceso creativo y lanzamiento. Como parte de la estrategia puede poner restricciones de tiempo para el time to market pero es el equipo quien hace la planeación para cumplir con esas restricciones.

Para el Product Owner, el Product Manager es uno de los involucrados relevantes, siempre y cuando no sea la misma persona quien ejecute ambas responsabilidades, ya que en muchas empresas el Product Manager ejecuta las responsabilidades del Producto Owner en equipos Scrum.

El Product Manager es un rol y el Product Owner es una responsabilidad para quienes tienen equipos Scrum. Antes se hacía referencia al PO como un rol también pero a partir de la más reciente guía oficial, ya se maneja como responsabilidad.

El Product Owner más que ser un interlocutor entre el cliente y el equipo Scrum, representa la voz del cliente ante el equipo Scrum, esa voz se alimenta de otras voces y mucha información, digamos que es el filtro de entendimiento y prioridades para el equipo.

Scrum no se escribe en mayúsculas porque no es un acrónimo :)

Agregaría la responsabilidad al PO de Priorizar el trabajo para el equipo orientado al valor de negocio y valor al consumidor / usuario final. También le agregaría la responsabilidad de dar el contexto y claridad suficiente al equipo para que entiendan los requisitos.

De manera general el Business Analyst si pude tomar decisiones, pero sobre todo influir en ellas, solo que en un equipo Scrum, el BA como rol es de apoyo al PO y no toma decisiones de priorización porque estas le corresponden al Product Owner.

El Business Analyst se ve desde dos maneras: Como rol: Alguien que realiza las responsabilidades de un BA dentro de un equipo. Como disciplina: Un PO debe de saber prácticas de Business Analyst para ejecutar efectivamente sus funciones.

Te felicito por este esfuerzo de simplificar las diferencias en estas responsabilidades.

Si te surgen más dudas a partir de lo que te expliqué, avísame por favor.

Feliz año nuevo!

Sandra Sierra

student•

Excelente aporte de @mauriciosuarezplatzi y excelente respuesta de @Vanessa_amaya. Actualmente estamos definiendo roles y responsabilidades y llegamos a esta misma discusión si el PO lo era o no. Ya me queda claro que es una responsabilidad y que en algún momento tanto el PM como el BA (empoderado para priorizar) podrían tenerla.

David De la Cruz

student•

Mis comentario sobre el caso de estudio. PM: Susana PO: Sergio BA: Alejandro Es más, como viene la lectura me atrevería a decir SM: Sandra

Arles A. Pinzon Molina

student•

👏 Me encanta como Vanessa está Clarita con lo que pasa debajo del iceberg en las organizaciones. La línea entre el analista de negocio y el product manager se hizo borrosa con la pandemia, la agilidad y las metodologías ágiles. Es una tremenda perspectiva la que nos comparten en esta clase. ¡Gracias!

Vanessa Amaya

teacher•

Gracias a ti!!!!

Y si, tienes razón, luego las líneas entre los roles se hacen difusas y que sean difusas no es el problema sino la confusión que esto puede provocar y las acciones que pueden estar dejándose de hacer.

Joan S.TrianaV

student•

COMPARATIVA CON OTRAS RESPONSABILIDADES Comparativa entre Product Manager y Business Analyst. -Product Manager: crear estrategias para construir productos (van desde la planificación, ejecución y lanzamiento), todo lo necesario para logística del lanzamiento de un producto y más actividades que van más allá de las responsabilidades de un Product Owner de software. Dentro un equipo tiene responsabilidades como de un Product Owner, también puede ser que un Product Manager se encargue del proyecto a un nivel global y tenga uno o varios Product Owners y haciendo partes de ese proyecto. -Business Analyst: ayudar a identificar y definir soluciones que maximicen el valor entregado por una organización a sus partes interesadas. Algunas veces se confunde con el rol de Product Owner, la principal distinción es que un Product Owner puede ser un Business Analyst y trabajar con todas las disciplinas y conocimientos que trae el análisis de negocio, pero ejecutar las responsabilidades de Product Owner en un equipo, también un Product Owner puede trabajar con un analista que lo apoye en sus actividades. Una diferencia entre los Business Analyst y los Product Owner, es que los Business Analyst no priorizan, sencillamente facilitan información para la toma de decisiones.

Jonathan Quiros Barquero

student•

1) Problemática del caso

El caso presenta varios retos típicos en la adopción de Scrum, que son los siguientes:

Desalineación de expectativas de negocio
- Marketing (Susana) piensa en el consumidor final.
- Ventas (Sergio) está enfocado en los ejecutivos que usan la app. → Esto genera confusión en la priorización del backlog.
Backlog poco refinado y no orientado a valor
- Hay muchas ideas técnicas y de diseño (OCR, integraciones, performance, UX), pero falta ordenarlas en función del impacto real al negocio y al usuario.
Problemas de colaboración y roles difusos
- Sandra actúa como líder técnica, pero también cubre tareas del Scrum Master.
- Alejandro apoya, pero no tiene clara su interacción con Sergio.
- Faltan mecanismos para que todos participen en las ceremonias (ejemplo: algunos no se sienten cómodos en las retrospectivas).
Falta de cocreación UX – desarrollo
- Santiago (UX) y los front-end (Luz, Gustavo) no logran integrarse a tiempo, generando retrabaljo.
Limitación de presupuesto y presión por resultados
- Se debe decidir en el último Sprint qué funcionalidades maximizan valor con recursos limitados.

2) Conocimientos y herramientas ágiles necesarias

Para atacar estas problemáticas, el equipo debería fortalecer lo siguiente:

a) Gestión del Product Backlog

User Stories bien definidas (formato: Como [rol] quiero [funcionalidad] para [beneficio]).
Acceptance Criteria / Definition of Done claros.
Técnicas de priorización ágil: MoSCoW, WSJF (Weighted Shortest Job First), Kano, o simplemente valor de negocio vs esfuerzo.

Herramienta útil: User Story Mapping para visualizar el flujo del usuario (ejecutivo de ventas) y ordenar backlog.

b) Roles y eventos Scrum

Claridad de roles: Sergio (PO), Sandra (SM), equipo dev autoorganizado.
Scrum Master debe fomentar seguridad psicológica en retrospectivas y reuniones (por ejemplo, dot voting o retros con notas anónimas).
Daily Scrums enfocados en inspección y adaptación, no en reportes.

Herramienta útil: Retrospective formats (Mad/Sad/Glad, 4L’s, Starfish).

c) Colaboración UX y Dev

Involucrar a UX desde la planificación y refinamiento, no al final.
Usar prototipos en Figma/InVision antes de pasar a desarrollo → validación rápida con usuarios.

Herramienta útil: Design Sprint o UX Storyboards.

d) Enfoque en valor y métricas ágiles

Definir Objetivos del Sprint (Sprint Goals) ligados a resultados de negocio.
Usar métricas ágiles como Velocity, Burndown Chart, Lead Time, y métricas de producto (adopción por ejecutivos, reducción de tiempo de captura, menos rechazos de documentos).
Preparar Release Planning con entregas incrementales.

Herramienta útil: OKRs alineados con el backlog.

e) Priorización en entornos de restricción

Con poco presupuesto → se necesita foco en MVP (Producto Mínimo Viable).
Ejemplo: dejar performance avanzado o “nice to have” para después, y enfocarse en la captura y validación básica de documentos.

Herramienta útil: Impact Mapping o Value vs Effort Matrix.

Marco Nava

company_admin•

Comunidad, pregunta, si tengo varios PO, ¿que figura se encarga de darles orden, el Product Manager?

Jorge Marroquin

student•

El Chief Product Owner coordina las prioridades entre los Product Owners que trabajan con cada uno de los equipos. Los CPO alinean las prioridades del Backlog con los stakeholders y las necesidades de los clientes. Esta info complementaria te ayudará.

Hugo Díaz

student•

Caso de estudio:

Susana, Product Manager.
Sergio, Producto Owner.
Alejandro, Business Analyst.
Sandra, Scrum Master.
Developers, Carlos, Luz, Daniel, Gustavo, María José & Santiago.

Eleonora Peña Rodriguez

student•

Un analista de negocio y un Product Owner (PO) tienen roles distintos, aunque pueden compartir algunas responsabilidades. Un analista de negocio se centra en identificar necesidades y requisitos del negocio, mientras que el PO actúa como el enlace entre el equipo de desarrollo y los stakeholders, priorizando el backlog del producto. Ambos son cruciales en la gestión de proyectos, pero sus enfoques son diferentes. En un entorno Scrum, el PO tiene mayor empoderamiento en la toma de decisiones sobre el producto.

Yobana Sandoval Parra

student•

Sergio = Product Owner (gestión táctica del backlog, priorización, conexión diaria con el equipo).
Susana = Product Manager (visión estratégica y objetivos de producto).
Alejandro = Business Analyst (detalle de requisitos y apoyo en refinamiento).

Yobana Sandoval Parra

student•

Problemáticas culturales que se evidencian

Comunicación desigual en el equipo: en planeación y retrospectivas hablan Sergio y Alejandro, mientras otros miembros casi no participan .
Poca confianza para expresar problemas: se sabe que hay conflictos, pero no se manifiestan; se esconden tensiones en lugar de gestionarlas .
Trabajo remoto con cámaras apagadas: genera malos entendidos, falta de compromiso y desconexión del equipo .
Dependencia excesiva del PO: Sergio centraliza priorización, refinamiento y comunicación con stakeholders, lo que limita autonomía del equipo .
Orientación a “entregar features” más que a “entregar valor”: riesgo de perder de vista la experiencia del usuario final y el impacto de negocio.

Edwar Y. Castillo B.

student•

Carlos Andrés Jimenez Castañeda

student•

Porque en algunas comunidades o celulas esta la figura de BPO y de DPO?

Vanessa Amaya

teacher•

Hola Carlos! en mi opinión esto que mencionas es una manifiestación de la importancia que les dan las empresas a las Jerarquías...

Sandra Sierra

student•

Vanessa, me gustaría conocer desde tu experiencia o quizás me puedas dar alguna referencia que consultar, acerca de los roles de PM y BA, como se van especializando o desarrollando a nivel empresarial.

Muchas gracias.

Francisco Ponce

student•

No soy la profesora, pero puedo aportar un granito a tu duda. Los roles de Project Manager (PM) y Business Analyst (BA) son importantes en cualquier empresa u organización que desarrolle proyectos. Ambos roles tienen responsabilidades y habilidades diferentes, pero trabajan juntos para asegurarse de que los proyectos se completen de manera eficiente y efectiva.

Una PM es responsable de la gestión general del proyecto, lo que incluye establecer metas, asignar tareas, gestionar el presupuesto y asegurarse de que el proyecto se complete a tiempo y dentro del presupuesto. Una BA, por otro lado, se enfoca en analizar el negocio y sus requisitos, y luego traducir esos requisitos en un plan de proyecto que la PM pueda seguir.

Ambos roles pueden desarrollarse y especializarse a nivel empresarial de diferentes maneras. Por ejemplo, una PM puede desarrollar habilidades en gestión de riesgos o en el manejo de equipos de alto rendimiento. Una BA puede especializarse en un área específica del negocio, como finanzas o tecnología, o puede desarrollar habilidades en técnicas de análisis de datos para ayudar a tomar decisiones informadas.

Sandra Sierra

student•

Totalmente de acuerdo @FranciscoEP, muchas gracias por tu comentario. Esa sinergia que hay entre dos roles llevan a proyectos más exitosos.

De todas maneras, aprovecho y amplio un poco la inquietud en otro contexto: un ingeniero de datos, puede ganar experiencia, habilidades técnicas y humanas y puede evolucionar a un científico de datos, por ejemplo. En el caso del PM y BA, ¿qué podria ser?

Ronald Barzola

student•

Y el rol del Data Traslator? Últimante he escuchado que también une el equipo de business y de tecnología. ¿Podría ser el PO también o tendría que estar dentro del equipo de desarrollo?

Vanessa Amaya

teacher•

Hola!!! El Product Owner no es un rol sino una responsabilidad para equipos que usan el marco Scrum. Si bien, en las primeras guías de Scrum venía como rol, en la más reciente versión de la guía se especifica ya como una responsabilidad ya que los roles paralelos fueron una confusión. De este en particular que mencionas del Data Traslator, es un rol que está naciendo dentro de proyectos que manejan altos volúmenes de datos. Yo considero que un Data Traslator es una especialización que podría quedarse corta para un PO. Sobre si este rol tendría que estar dentro del equipo de desarrollo, Scrum no distingue roles dentro del desarrollo para ayudar a romper el trabajo en silos, entonces, los desarrolladores para Scrum, no solo son los desarrolladores sino todos los hacedores de realidad, todos los ejecutores.

Espero que mi respuesta te sirva

Ricardo Carrasco Islas

student•

En cuanto al PO vs otros roles o áreas como puede ser el área de negocio, ¿en dónde caen las siguientes responsabilidades?:

Generar el Roadmap end to end
Determinar Épicas y Features
Identificar dependencias con 3ros
Dar seguimiento a contratos y/o requerimientos con 3ros
Dar seguimiento a los estatus del área de tecnología
Coordinar reuniones y determinar fechas con las distintas áreas y 3ros

Tengo mucha confusión si estas tareas son responsabilidad de un PO o de otras áreas o roles.

Vanessa Amaya

teacher•

Hola Ricardo!

El Product Ownership tiene que ver mucho con provocar el análisis colaborativo dado que un PO carece de todos los conocimientos necesarios para llevar de punta a punta ciertos análisis, a continuación aclaro responsabilidades de los puntos que mencionaste:

PO puede realizar las actividades end to end de:

Dar seguimiento a contratos y/o requerimientos con 3ros
Coordinar reuniones y determinar fechas con las distintas áreas y 3ros (si las reuniones tienen que ver con Negocio y cliente final)

PO dispara el análisis y el equipo que se encargará de hacerlo realidad lo complementa:

Generar el Roadmap end to end
Determinar Épicas y Features
Identificar dependencias con 3ros

Se encarga el Scrum Master:

Dar seguimiento a los estatus del área de tecnología
Coordinar reuniones y determinar fechas con las distintas áreas y 3ros (si las reuniones tienen que ver con la ejecución del proyecto)

Mariana Di Salvatore

student•

PM Susana

PO Sergio

BA Alejandro