El pasado mes de febrero, tuve ocasión de asistir a un curso de Product Owning impartido por los chicos de Makoto Squad (Xavi Gost principalmente) en las instalaciones de Playtomic en Madrid (cito a Playtomic porque es una startup interesante, que lo está haciendo muy bien y ha crecido una pasada en su año y pico de vida). Lo primero que me llamó la atención es que estamos acostumbrados a leer «Product Owner», por lo que leer «Product Owning» ya me picó la curiosidad.

Lo primero, decir que me gustó la variedad de personas/empresas que asistieron, había gente de varias startups y varias empresas grandes, de empresas consultoras y de producto propio, lo que enriquece mucho las casuí­sticas que se pueden plantear durante las sesiones.

Ahora sí­, ya arrancamos con lo que fué el curso, el planteamiento es muy interesante, ir más allá del puro rol del Product Owner, trabajar la fase de descubrimiento de producto y añadir nuevos puntos de vista a la creación de nuestro backlog y a la forma en la que escribimos historias de usuario.

Abrimos el tema de la Fase de Descubrimiento en los proyectos con una reflexión muy interesante, «Seremos felices si conseguimos ser coherentes con lo que pensamos, lo que decimos y lo que hacemos«.

No voy a reventar el ejemplo de Xavi, pero me quedo con la frase, porque aplica a cantidad de cosas en nuestro día a dí­a, y en especial cuando trabajamos en un producto.

Muchas veces no está alineado el objetivo del producto, con las características que queremos darle y con la estrategia de marketing o comercial que se aplica, o simplemente con lo que cada uno tenemos en nuestra cabeza (pero no hemos compartido antes de empezar). Que el Product Owner vele por ello me parece una idea estupenda, al fin y al cabo, es el nexo del producto que balancea entre todos los interesados y los equipos que lo construyen. Pero debe fomentarse el diálogo como vía fundamental para conseguir estar alineados y tener el mismo producto/servicio en la cabeza.

El mensaje más importante es que por que una técnica haya funcionado en otro entorno no tiene porque funcionar en el tuyo, para eso es necesario valorar cuál es el objetivo de la misma y si tiene sentido aplicarla en tu entorno. No recuerdo cuantas veces pude oír ‘Te crees que eres Google, no sois Google señores.’  🙂

El ejemplo claro, su Design Sprint, que es un proceso de cinco días desarrollado por Google Ventures para buscar responder las preguntas críticas sobre el desarrollo de producto a través del diseño, creación de prototipos y pruebas con clientes.

Trabajando con equipos multidisciplinares integrados generalmente por el responsable del producto y sus colaboradores en la construcción, con el objetivo de no tener que esperar al final de un costoso ciclo de desarrollo para entender si solución es una buena idea o no. Es decir, pretende proporcionar una visión rápida del producto terminado teniendo en cuenta las necesidades de los clientes.

Si vamos un paso más allá en el descubrimiento del producto y contando con que aquellos que me leáis ya conocéis lo que es un User Journey, me pareció muy refrescante (por el modo) la dinámica de llevarla a grupos de estereotipos en lugar de arquetipos, eso permite llegar a situaciones extremas en las que salen usos muy interesantes de los productos/servicios.

En la parte de historias de usuario me pareció transgresor el mensaje, historias que nos son historias, estimaciones que no sirven para nada.

Y por último la “Fantasía de Control”, un concepto que nos sacude, por mucho que estimemos, que “planifiquemos”, que midamos velocidades y esfuerzos… ¿es real? Y lo subrayo, ¿real?.  Todos conocemos la respuesta, una persona del equipo se pone enferma una semana, otra tiene un hijo, otro cambia de trabajo…

¡Ojo! Con esto no digo que no sirvan para nada, pero que tenemos que tratarlas como lo que son y ser siempre muy conscientes de la cantidad de factores que nos pueden afectar, la mejor garantía es nuestro compromiso como profesionales, de que siempre daremos lo mejor para intentar aportar el máximo valor posible lo antes posible.

Voy a ir cerrando. Si hay algo que me ha gustado especialmente, es la cantidad de referencias o conceptos sobre los que investigar y leer que se han facilitado, y aquí es donde creo que aplica la cita ‘Si crees que sabes mucho, es que no conoces a suficiente gente.’ o cualquiera de sus variantes, ‘… no has leído lo suficiente’, ‘… no has trabajado con equipos suficientemente grandes (o pequeños)’, etc.

A continuación os dejo la lista de referencias que me han parecido interesantes, evidentemente algunas ya las conoceréis pero siempre aparecen algunas nuevas que enriquecen nuestras habilidades:

Libros:

• The Lean Startup: How Constant Innovation Creates Radically Successful Businesses
• User Story Mapping: Discover the Whole Story, Build the Right Product – Jeff Patton
• Agile Inception Deck
• Lean inception
• La naturaleza del desarrollo de Software
• Extreme Programming Installed – Ron Jeffries

Lecturas:

• Ley de Conway
• La navaja de Ockham
• Design Sprint Google
• Pomodoro

Conceptos:

• El espíritu crítico
• La fantasía de control
• Serendipia
• La falacia de evidencia incompleta (cherry picking)
• Minimum Marketable Feature (MMF)

Herramientas

• Test Complete (como herramienta de pruebas UI)
• Trello (como conductor de una presentación)
• Stories On Board

Como nota final, decir que la cantidad de aproximaciones, referencias y giros que aporta el curso me ha parecido fantástica, ¿qué pega le puedo poner?, pues que personas que no estén pensando en escenarios volátiles o cambiantes, y tengan en sus cabezas “su problema” pueden verlo como poco preciso o concreto. Si lo valoras como recopilar herramientas para considerar su uso en la realidad de cada uno, muy bueno.

Me gustaría entrar en más detalles, pero como eso sería destripar el curso, mejor lo dejo aquí. 😉