Una alternativa complementaria al modelo operativo de producto
Sin duda las propuestas de Marti Cagan clarifica las ideas centrales en las que se tiene que basar un organización que quiera trabajar con un enfoque orientado a producto.
Sin embargo, todavía se pueden generar confusiones en los equipos que se quieren mover hacia un modelo de este tipo ya que no se da claridad de los roles responsables de liderar cada una de las partes del proceso de conceptualización y desarrollo de producto, lo que puede llevar a fricciones dentro de los equipos y entre los distintos departamentos que puedan llegar a impedir el desarrollo de una estrategia orientada en la creación de productos para aportar valor al negocio.
De cara a lidiar con esta problemática podemos adaptar los diferentes riesgos asociados al desarrollo de producto a tres momentos fundamentales:
La identificación del problema de negocio
La identificación del problema de producto
La solución al problema de producto
La definición e identificación del problema de negocio es el momento en el que debemos tener en cuenta aspectos como el tamaño del mercado objetivo, la competencia, las características del mercado objetivo, el timing o el producto market fit. El problema de negocio debe responder a dos preguntas muy claras:
¿Hay una oportunidad de mercado que nos permita ganar dinero?
¿Cuanto está dispuesto a pagar un usuario por la resolución de su necesidad?.
El riesgo que se debe aclarar en esta fase es la viabilidad del problema de negocio, es decir ¿es viable para la compañía a nivel operativo, legal y de negocio ofrecer un producto que ataque ese espacio de mercado o esa problemática específica?
Los roles responsables que deben liderar en este momento son aquellos con más conocimiento del mercado, del negocio o, si ya hablamos de dominios más particulares como por ejemplo la logística o las finanzas, aquellas personas con un conocimiento más profundo del dominio sobre el que se está desarrollando el producto. No olvidemos que un Product Manager tiene que saber como hacer producto, y no ser un experto en el dominio sobre el que se desarrolla el producto, ya que este conocimiento del dominio, que en muchas ocasiones requiere de muchos años de experiencia, puede ser aportado por especialistas que traigan este conocimiento al equipo de producto.
La definición del problema de producto es el momento en el que transformamos el problema de negocio en un problema de producto, es decir colocamos al usuario en el centro y profundizamos en sus necesidades para identificar con claridad qué problema del usuario estamos resolviendo y si esta resolución aporta o no suficiente valor al usuario como para que esté dispuesto a pagar dinero por ese producto. La pregunta que se debe responder aquí con la máxima claridad es:
¿Qué problema, necesidad o deseo del usuario estamos resolviendo?.
El riesgo asociado a este momento es el Valor ya que debemos entender el valor que le aportamos al usuario al resolver su problema mediante un producto y entender si este valor nos permitirá aportar un beneficio al negocio.
En este momento es donde la figura del Product Manager es más importante y debe liderar de manera que la transformación del problema de negocio en un problema de producto se haga de forma correcta.
La solución al problema de producto es el momento donde trabajamos en la definición de la solución, entendemos qué funcionalidades son necesarias para ayudar a resolver el problema, las implementamos, las probamos, las iteramos y vuelta a empezar. La pregunta constante que necesitamos hacernos en este punto para evitar caer en convertirnos en una feature factory o fábrica de funcionalidades es:
¿Esta funcionalidad resuelve el problema de producto que queremos resolver?.
Esta pregunta no solo hay que hacérsela durante la definición de la funcionalidad sino sobre todo una vez la funcionalidad está en producción ya que al igual que no hay un plan que resiste el contacto con el enemigo, Napoleón dixit, no hay funcionalidad que resista el contacto con el usuario, por lo menos en las primeras iteraciones. Los riesgos identificados por Cagan para esta fase son la usabilidad y la factibilidad, es decir si el producto se puede usar y se puede implementar, muy en la línea de la propuesta de Tim Brown en su libro Change by Design.
El liderazgo en este momento pasará a los equipos de diseño y desarrollo, ya que son ellos los que conocen las implicaciones a bajo nivel de las decisiones que se toman para resolver el problema asignado.
En los tres momentos hemos hablado de liderazgo, pero este liderazgo no debe en ningún caso derivar en un enfoque secuencial en cascada que limita la capacidad de los miembros del equipo de adquirir el contexto suficiente para hacer bien su trabajo. La filosofía que debe imperar aquí es la de “Que no te lo cuenten” de manera que en cada una de las fases están involucrados los roles de negocio, producto, diseño e ingeniería, materializado este último en la figura del Tech Lead o responsable técnico, aunque en cada momento el liderazgo y por derivación el miembro del equipo con capacidad de decisión sea cada uno de los roles mencionados anteriormente.