Vision de Producto: para qué sirve y cómo se construye
En gestión de productos hablamos con frecuencia de la “visión” como algo que debe enmarcar nuestro roadmap y guiar el desarrollo de producto a largo plazo, y con frecuencia achacamos el fracaso de una marca al hecho de que “carece de una visión clara”. Pero ¿para qué sirve y cómo se construye una visión de producto?
Intuitivamente todos tenemos una idea de la visión como algo que describe las soluciones (productos y servicios) que vamos a proporcionar y los tipos de clientes a los que vamos a servir en un futuro más o menos cercano. Dependiendo de la industria, la visión puede cubrir típicamente entre 2 y 5 años aunque en algunos sectores (pensemos en farmacia) la visión puede abarcar plazos mucho más largos.
Ciertamente, la visión no busca describir los productos que estamos vendiendo hoy, aunque es a través de una sucesión de productos y versiones “actuales” como aspiramos a alcanzar esa visión. Y siempre deberíamos tener una visión hacia el futuro: si nos acomodamos en nuestros productos y mercados presentes podemos ser presa fácil de rivales más innovadores. Así pues, la visión debe actualizarse periódicamente. 
La Visión debe validarse y ser estable, pero tiene que poder evolucionar
Asumiendo que estamos utilizando un proceso de desarrollo de nuevos productos más o menos flexible y centrado en el mercado, una expresión estable de la visión sólo puede ser el resultado de las actividades de descubrimiento y validación del producto. Previamente, durante las actividades de búsqueda y evaluación preliminar de la oportunidad de mercado, es útil manejar borradores provisionales de la visión de producto (con su expresión de clientes, problemas, soluciones, etc.) pero que no constituyen visiones validadas.
Con posterioridad, si la evaluación de la oportunidad culmina en un “Go!” y acometemos el proceso propiamente dicho de desarrollo del producto, sin duda que las asunciones recogidas en la visión se convertirán en las primeras hipótesis a comprobar.
Mediante un proceso iterativo de análisis y experimentación en el mercado (aplicando entrevistas, observaciones, contraste de mockups…) podemos ir eliminando incertidumbres y refinando los componentes de nuestro modelo de negocio y nuestra visión. El objetivo de esta actividad, que consiste en descubrir un producto que valga la pena construir y comprobar el Encaje Problema/Solución, equivale a alcanzar una visión de producto validada.
Posteriormente, cuando la visión se despliega en un roadmap que explica cómo vamos a alcanzarla a través de sucesivas versiones y empezamos con la implementación de éstas, entramos en una fase de validación del producto y de comprobación del Encaje Producto/Mercado durante la cual la visión debe gozar de una cierta estabilidad y vocación de permanencia (o al menos, toda la que nos permiten estos enfoques en lo que cualquier asunción está sujeta a refutación).
Aunque en esta etapa el protagonismo lo tienen otros artefactos (requisitos, prototipos, backlogs… e incluso un “Lienzo de Producto”) más enfocados en el avance del desarrollo, la visión siempre está presente como guía y referencia para el proceso. Además de la misión obvia de indicarnos hacia dónde tenemos que ir y qué tenemos que desarrollar, en estos tiempos “ágiles” la visión cumple dos objetivos muy importantes:
- Transmite un sentido de propósito y de intención que debe inmunizarnos ligeramente contra las veleidades de “pivotar” a la mínima dificultad. Hemos visto muchas empresas que aplican de una manera tan extrema los principios lean que a fuerza de pivotar acaban pareciendo pollos sin cabeza. La visión nos insufla un sesgo hacia la perseverancia que puede ser muy útil.
- Además de indicarnos lo que deberíamos desarrollar la visión nos marca lo que NO debemos desarrollar: en principio, toda funcionalidad, característica, atributo… que nos aleje del camino para alcanzar dicha visión. Estos nos protege de solicitudes oportunistas de muchos stakeholders (inversores, directivos, vendedores…) que en el mejor de los casos tienen sólo una panorámica parcial del mercado.
Finalmente, a un nivel más estratégico, una visión validada sirve de base para definir una estrategia de producto (que dibuja el camino para alcanzar dicha visión) y un roadmap interno en la que se definen las sucesivas versiones del producto para ir acercándonos a ella.
La Visión debe enfocarse en el Valor para el Cliente
Se pueden aplicar muchos enfoques para definir la visión, pero si asumimos que el objetivo de todo producto es resolver un problema de mercado, yo optaría por un enfoque basado en el valor para el cliente. En otras ocasiones hemos definido este valor como “la utilidad percibida del conjunto de beneficios que recibe un cliente a cambio del coste total de una oferta, teniendo en consideración otras ofertas y precios competitivos”.
Por lo tanto la visión debería tener en cuenta específicamente aspectos como los beneficios y costes de toda índole (funcionales/ emocionales/ económicos y explícitos/ ocultos) de nuestra oferta y los diferenciadores frente a las principales alternativas que ofrece el mercado. Sin embargo, como veremos, la mayoría de artefactos existentes para expresar la visión no van más allá del plano de la experiencia de usuario y las features&functions del producto.
¿Qué forma debería tener esta visión basada en el valor? En un próximo post haremos una propuesta de plantilla de Visión de Producto que intente recoger estas ideas.
Y si quieres saber dónde encaja la visión en una planificación ágil de producto, lee este post.
El post “Vision de Producto: para qué sirve y cómo se construye” se publicó primero en “Marketing & Innovación”.
[Una buena función de «product management» es imprescindible para gestionar cada producto como un negocio. Descubra en este taller práctico cómo implementar una gestión de productos realmente enfocada en el mercado.]
Llevamos algunos años anunciando la muerte del Product Management… por lo menos tal y como se concebía hasta ahora. Pero algunos de los consultores y autores que venden estas ideas esencialmente gestionan negocios cuyo éxito se basa en gran medida en que estas predicciones lleguen a hacerse realidad. Es importante tener en cuenta posibles conflictos de interés a la hora de valorar ciertas opiniones.![El rol de Product Owner no es suficiente en empresas que comercializan productos para un mercado. Para que un Product Owner pueda colaborar eficazmente con su Product Manager (o asumir alguna de sus funciones) es imprescindible un mayor conocimiento y experiencia en aspectos de negocio. Las empresas de producto que desean tener éxito en el mercado necesitan Product Managers experimentados… y los contratan. No hay más hay que ver las ofertas de empleo que se publican en los sitios web de las propias compañías (incluso de las más punteras) o en LinkedIn. Sin embargo, en los últimos años la tendencia a la “agilización” ha llevado a algunos evangelistas de Agile a promover la sustitución del “anticuado puesto de Product Manager” por el más moderno de Product Owner. En realidad, lo que estos apóstoles promueven es extender las atribuciones del rol de Product Owner original de Scrum, elevándolo a la altura de una especie de “Súper Product Owner”, que aborde cada vez más áreas de la gestión de producto. En definitiva, lo que postulan es sustituir el rol de Product Manager por el de un Product Owner cuyas funciones cada vez se parece más a las de aquél. En este blog hemos hablado ya de las relaciones entre Product Manager y Product Owner y de por qué prescindir de uno u otro puesto es una mala idea. Y personalmente soy un firme partidario de aplicar lo que de bueno tienen los enfoques Agile/Lean/Design Thinking al Product Management… y a todas las áreas de la empresa. Creo que las empresas de producto -especialmente en mercados tecnológicos, rápidos e innovadores- se beneficiarían de una Gestión de Producto más Agile/Lean (no quiero entrar en guerras de religión con el nombre). Pero es ilusorio pensar que por ampliar el alcance del rol de Product Owner y prescindir del de Product Manager vamos a gestionar mejor nuestros productos. Y lo creo por varios motivos: • Las actividades de un Product Owner (incluso en sus versiones más avanzadas) son una parte de las necesarias para garantizar el éxito de un producto en el mercado, y que definen la responsabilidad del Product Manager. El desarrollo de nuevos productos no lo es todo: antes hay que descubrir y analizar la oportunidad de mercado y después hay que comercializar, explotar, mantener y evolucionar el producto. Contrariamente a lo que muchos ingenieros podrían pensar, el lanzamiento no es el principio del fin de un producto: es el fin del principio. Un rol que en sus versiones más básicas únicamente existe durante el proyecto de construcción del producto no puede aspirar a garantizar el éxito de éste en el mercado. • La realidad es que lo que con mayor frecuencia se encuentra en las empresas es un “Mini Product Owner”, no sólo en actividades, sino en habilidades. Aparte de que el alcance de los roles de Product Manager y Product Owner son diferentes (el Jefe de Producto es mucho más estratégico y enfocado al exterior), el tipo de profesional que desempeña este último tampoco ayuda. En la mayoría de las empresas se trata de alguien con bagaje puramente técnico y con escasa experiencia y aptitud para entender realmente un mercado, descubrir las necesidades esenciales de los clientes y colaborar con los otros departamentos de la empresa y gestionar el producto como un negocio a lo largo de todo su ciclo de vida. (Nota al margen: la formación sobre Product Owner/”Agile Product Manager” disponible en España deja bastante que desear, limitándose en muchos casos a cubrir una Gestión Ágil de PROYECTOS, en el mejor de los casos complementada con pinceladas de Lean Startup y otros enfoques de moda, pero no necesariamente con gestión de PRODUCTO). El Product Owner típico necesita más conocimientos y habilidades de negocio No podemos dar la “propiedad” de los aspectos estratégicos de un producto a alguien que carece de los conocimientos y la experiencia necesarios. Estos son algunos de ejes de gestión de producto que deberían mejorar muchos Product Owners: • Mejorar su perspectiva sobre la estrategia de producto global y las sinergias de la cartera de productos. El Product Owner típico tiende a optimizar la release, sin tener en cuenta las oportunidades de bundling y cross-selling con otros productos, y a veces pierde de vista el roadmap. • Aprender a diferenciar entre unos pocos clientes y el mercado en su conjunto. El Product Owner medio tiende a dar credibilidad y a generalizar el input de los clientes más cercanos o comunicativos y de aquellos que se avienen a probar el producto durante el desarrollo. Además, es habitual que el mercado se componga en realidad de diferentes grupos de clientes, cada uno caracterizado por unas necesidades similares - pero diferentes de un grupo a otro. Pero las técnicas de segmentación y targeting no suelen estar entre los conocimientos del Product Owner. • Entender los drivers que crean valor para el cliente para convertirlos en productos más comprables y aprender a elaborar posicionamientos, comparativas respecto a la competencia y mensajes significativos para el mercado. Las propuestas de valor que elabora el Product Owner típico en realidad consisten en enumeraciones de atributos y funcionalidades. • Entender el modelo de negocio que sustenta el producto y las herramientas para capturar el máximo valor para la empresa: packaging, pricing. El Product Owner medio tiene tendencia a añadir funcionalidades sin pensar en cómo rentabilizarlas. • Aprender a priorizar aspectos estratégicos del producto (tales como la experiencia de usuario, los drivers de compra o una arquitectura que permita evolucionarlo fácilmente y crear productos derivados) frente a funcionalidades de usuario visibles individuales. • Mejorar sus habilidades para comunicar eficazmente y aumentar su credibilidad ante los departamentos de Marketing, Ventas, Soporte, la Dirección de la empresa y, en general, todos los que tienen que contribuir a que el producto sea un éxito en el mercado. Un Product Owner que mejorara sus capacidades de gestión de producto no sólo podría colaborar más eficazmente con su Product Manager, sino que podría abrir una vía de desarrollo y evolución profesional hacia ese rol. En resumen, necesitamos una gestión de productos mucho más Agile/Lean, pero suprimir la figura del Product Manager y sustituirla por la de un (Súper) Product Owner no es la manera de conseguirlo. El post “Si quieres ser un Product Owner excelente aprende Product Management” se publicó primero en “Marketing & Innovación”. [Desarrollar nuevas ofertas y modelos de negocio en mercados tecnológicos plantea retos muy particulares. Descubre en este documento cómo desarrollar productos que los clientes necesitan.]](https://conversisconsulting.com/wp-content/uploads/2013/11/product-owner-needs-product-management.jpg?w=300&h=240)
Conversis - Crecimiento de productos tecnológicos 