Product Owner's Views - Explicación

Hola a todos

Generalmente vemos al Dueño de Producto (Product Owner - PO ) trabajando en dos frentes, en el frente de la definición del producto y en el frente de la construcción del mismo, por medio de este artículo quiero compartir que la visual del PO debe considerar tres frentes(1)(2) para realizar una correcta construcción del producto.

• Vista 1 - Descubrimiento (Discovery):
• En este frente el PO trabaja con el Equipo del Producto (Product Team), que puede estar compuesto por:
• expertos del negocio
• arquitectos de software y arquitectos empresariales
• Expertos en UX / UI
• clientes
• posibles suarios
• expertos en Seguridad y Riesgos
• expertos en Procesos
• gerentes de Producto (Product Managers) 
• otros PO e interesados claves
• Para definir:
• el producto,
• la visión del producto
• la lista ordenada del producto (Product Backlog)
• el producto minimo viable (Minimum Viable Product - MVP) 
• las versiones, 
• los prototípos,
• los indicadores,
• los esquemas de ROI
• las hipótesis, etc.
• Para esto se vale de:
• visitas a clientes y usuarios
• conocer donde va a ser usado el producto (gemba walks)
• investigaciones de mercado
• análisis de la compentencia (benchmarks)
• estrategias de construcción del producto
• dependencia de otros productos o soluciones, etc.
• Vista 2 - Desarrollo (Development): 
• En esta vista el PO proporciona y explica del Product Backlog priorizado y refinado al Equipo de Desarrollo (Development Team) para que el producto sea creado según su conocimiento y capacidades, y basado en los lineamientos del Equipo del Producto.
• Vista 3 - Producción (Production): 
• En esta vista el PO observa si el producto esta siendo usado según las expectativas para las que fue creado y valida la generación de valor del mismo.

De cada uno de estos frentes el Product Owner obtiene valiosa retroalimentación sobre el Producto que debe considerar y balancear de acuerdo a los tiempos y propósitos que tenga identificados con las versiones a liberar; estas retroalimentaciones le sirven para generar una próxima mejor versión y por ende un mejor producto, estas son:

• Retroalimentación 1 (Feedback 1) del ambiente producción y los usuarios, al Equipo de Desarrollo:
• Uso del producto
• funcionalidades más usadas
• funcionalidades menos usadas
• estadisticas basadas en uso
• hipótesis que funcionaron y las que no
• Funcionamiento del producto
• incidentes y bugs a ser priorizados
• problemas de rendimiento y funcionamiento
• estadisticas de desempeño
• problemas de seguridad
• deuda técnica identificada y que debe ser priorizada
• Retroalimentación 2 (Feedback 2) del Equipo de Desarrollo al Equipo del Producto. 
• El equipo de desarrollo comienza a conocer tanto el producto, que se convierte en otro interesado clave (key stakeholder), proporcionando información para la construcción del mismo. Dentro de la retroalimentación brindada pueden estar las siguientes:
• funcionalidades innecesarias
• funcionalidades a adicionar
• estrategias de implementación
• deuda técnica identificada a ser priorizada
• incidentes y bugs a ser priorizados
• retos técnicos
• estimaciones
• nuevas dependencias técnicas
• nuevas dependencias funcionales con otros productos o equipos de trabajo
• Retroalimentación 3 (Feedback 3) del ambiente de producción y los usuarios al Equipo del Producto:
• Uso del producto
• funcionalidades más usadas
• funcionalidades menos usadas
• estadisticas basadas en uso
• hipótesis que funcionaron y las que no
• valor o ROI generado vs. el esperado
• datos que se obtienen de la validación de hipótesis
• Funcionamiento del producto
• incidentes y bugs a ser priorizados
• estadisticas de desempeño
• problemas de seguridad identificados
• problemas de experiencia de usuario identificados
• deuda técnica identificada y que debe ser priorizada
• estadísticas basadas en experiencia de usuario

Bienvenidos sus comentarios

Saludos ágiles

Jorge Abad

Notas, Referencias, Aclaraciones, Comentarios y Observaciones

1. El análisis acá presentado esta pensado está formulado para productos basados en software, para otro tipo de productos se sugiere realizar análisis similar y reemplazar roles, actividades y fuentes según sea la industria de solución.
2. Este diagrama fue resultado del análisis del dual-track, algunas interesantes referencias a continuación:
• Dual Track Development is not Duel Track - clic aquí
• Dual-Track Agile: Why Messy Leads to Innovation - clic aquí
• Dual-Track Agile - clic aquí
• How to set up Dual-Track Scrum in Jira - clic aquí
3. Gracias a mis amigos Jaime Icaza y Daniel Ramirez por sus valiosos comentarios para mejorar este artículo.