El VDD (Value Driven-Development), es el xDD que más me mola. Por encima del BDD, TDD, el DDD y cualquier otro DD que pueda conocer. Eso si, es importante definir qué es el valor, cómo lo medimos y cómo consideramos que estamos aportando producto que merece la pena ser construido a la organización.
En mi época de emprendedor, se me insistió mucho con que toda empresa tiene palancas que se pueden mover para hacer que el negocio evolucione. Hablaba mucho aquella época con un mentor financiero con muchísima experiencia en empresa grande que me decía:
Darío, tienes que acabar llevando tu empresa desde la playa, con una Tablet.
Tiene todo el sentido del mundo. Su punto era el siguiente, construye un panel con lo que quieras saber y monitorízalo siempre. Ten las palancas a mano para saber cuáles te interesa hacer que se muevan en tu empresa en cada momento. No te infoxiques, recuerda que lo tienes que poder ver desde la playa, en tu tablet.
En la gestión de producto, es lo mismo. Muchas veces he leído que el Product Owner es el CEO del producto. Lo mismo no puedes irte a gestionarlo a la playa, pero deberías tenerlo todo preparado para poder hacerlo.
¿Qué es el valor y cómo debería aterrizarlo?
Manque pese, el valor dentro de una compañía es dinero. Y debiéramos saber cómo se estructura para hablar con propiedad. Básicamente, porque nuestros objetivos tengan sentido deben ser medibles. Y no sólo medibles, comparables con el resto de iniciativas que hay en una empresa.
¿Cómo podemos saber si un producto SW tiene o no sentido? ¿Cómo sabemos si tenemos que lanzar esa campaña de marketing que tanto mola, reducir los costes en el proceso de envíos, automatizar nuestra atención al cliente o mejorar la forma en la que compramos?
¿Cómo comparamos nuestras iniciativas con las del resto de la compañía?
Yo creo, la clave de todo está en el balance y la cuenta de resultados. Un buen gestor de producto, ya sea en la figura del Product Owner o en la de Product Manager debe tener las cuentas de la compañía accesibles. Y poder entenderlas como lo haría un directivo. Esto no significa ser un experto en finanzas, sólo implica que sabes comunicarte en ese lenguaje, igual que sabe comunicarse con el equipo de desarrollo.
Aquí, es donde entra un concepto que me gusta mucho, la contabilidad de costes o analítica. No es la que hay que entregar a entidades públicas. Es una mucho más resumida, con ciertos valores claves que indican cómo va el negocio y que nos puede decir cómo invertir mejor el dinero o recursos, esfuerzos, tiempo, para conseguir aumentar el valor de la compañía.
La cuenta de resultados nos dice cómo se está gestionando la empresa:
El balance hace lo propio con el dinero. Qué se está financiando y cómo:
El total de activo neto y financiación debe ser igual. Debe coincidir en qué nos hemos gastado el dinero (Activo Neto) con el dinero que nos hemos gastado (Total financiación).
Se pueden desglosar partes del balance y la cuenta de resultados que te interesen más en concreto. Por líneas de negocio o productos, por ejemplo, para poder ver la rentabilidad que sacas de cada uno y poder potenciar, reducir o discontinuar el que te interese. Además, puedes ver cómo es la distribución de costes en cada uno de ellos, tratarlos de manera independientes casi como si fueran varias empresas diferentes que comparten ciertas partidas (Normalmente, casi todo lo que está por debajo del EBITDA).
Un tema de responsabilidades
Es la directiva la que controla las cuentas, pero no olvidemos que es el Product Owner la única persona que tiene el “Accountability” de maximizar el ROI (Retorno de inversión) de su producto. Suya es la última palabra sobre el Product Backlog, su priorización y es quien rinde cuentas de ello si las cosas no van como debieran. ¿Cómo puede responder sobre algo sin poder encajarlo dentro de la estructura de costes de una compañía? Complicado…
Punto de comparación único
Ahora si podemos responder a la pregunta anterior. ¿Cómo comparar iniciativas?
Con el SW, se pueden solventar muchos problemas empresariales de una manera estupenda y este cada vez tiene más presencia en el mundo, pero antes de ponernos a desarrollar, es interesante compararlo con alternativas fuera del SW. ¿Por qué construir algo que podemos solucionar contratando a más gente? ¿Cuál de las dos soluciones es mejor?
Entiendo que lo normal es que el SW a medio/largo plazo suela tener más beneficios, hace más escalable a un negocio, se equivoca menos… pero siempre podremos ver el impacto sobre la cuenta de resultados y el balance de ambas alternativas. Así podremos decidir cuál es la mejor para el ahora mismo. Puede ser que de momento no podamos financiar ese desarrollo y que para el negocio sea más conveniente llevarlo con una gestión manual. Aquí, podríamos hablar con operaciones comparar los dos puntos de vista, ver cuál es viable y si se da el caso de que las dos opciones lo son, decidir cuál es más conveniente para el momento actual del negocio.
Como pregunta al aire, ¿Puede ser que a veces el mejor desarrollo sea el que no se hace?
Foco y Transparencia
El primero, es uno de los valores de Scrum y el segundo, uno de sus pilares. Y me gusta contarlos como los que más debe cuidar el Product Owner. Pero esta figura, también debe defender que se les proporcionen. Una directiva clara con sus POs, con objetivos concisos de hacia dónde quiere que vaya el negocio, les debería compartir esta información. Si no se les empodera con esta información, nunca tendrán el Onwership del producto, no conocerán las palancas que hay que mover y estas figuras estarán más cercanas a un proxy o Business Analyst que a un Product Owner.
¿En tu empresa se empodera al Product Owner? ¿Cómo medís el valor?
