Conversis Consulting – Marketing orientado a resultados para mercados tecnológicos

Posts from the ‘gestión de producto’ category

¿Cómo acotar el espacio del problema a la hora de definir un producto? Después de entender las necesidades de los clientes hay que expresarlas como un conjunto de requisitos priorizados.

En las anteriores entregas de este post hablamos de la importancia de acotar el espacio del problema para desarrollar un producto y de cómo entender las necesidades de los clientes. En esta entrada analizamos diversas formas de articular esas necesidades en forma de requisitos que sirvan de base al diseño y la implementación de la solución.

Requisitos: expresando problemas de mercado

RequisitosEn definitiva, la comprensión de los problemas de los clientes tiene por objetivo identificar un conjunto de necesidades de dichos clientes lo más completo posible, estructurado (en una jerarquía o similar) y priorizado. A esta colección de expresiones de problemas es lo que se conoce como requisitos (de mercado) y constituye el componente principal del Market Requirements Document (un artefacto tradicional usado en desarrollo de productos).

Los requisitos no son especificaciones

Es importante resaltar que los requisitos son expresiones de problemas, no de soluciones. Las referencias a posibles formas de resolver el problema corrompen los requisitos, que deben ser siempre agnósticos respecto a la implementación. Sólo cuando entramos en fase de Diseño generamos un concepto de solución, una experiencia de usuario deseada y una descripción funcional que reflejan la manera en que esa solución resuelve el problema. Esa descripción se traduce en especificaciones de producto. En definitiva un requisito expresa el PARA QUÉ, una especificación expresa el CÓMO.

Artefactos para expresar requisitos

Existen muchos enfoques para expresar requisitos, a continuación os resumo los que han ido apareciendo por este blog. Es importante tener en cuenta que para cada una de ellos existen métodos y procesos para destilar las necesidades y convertirlas en requisitos, que iremos describiendo en futuros posts.

  • Expresiones literales (verbatims) de los clientes. Ésta es la forma preferida por los enfoques tradicionales de análisis VoC (Voz del Cliente). Según ellos, las citas literales dan idea del mundo del cliente, de cómo él percibe y vive sus problemas. Por eso según estas técnicas no sólo hay que utilizar las expresiones de los clientes, sino que la estructuración y priorización de estas expresiones también deben realizarlas los propios clientes, para evitar que los proveedores contaminen el análisis con sus ideas y soluciones.
  • Trabajos y Job Stories. Provenientes de la filosofía Jobs-To-Be-Done, las job stories tienen la forma
    Cuando <SITUACIÓN> quiero <MOTIVACIÓN> de manera que <RESULTADO>
    (por ejemplo: “Cuando un nuevo cliente importante se registra quiero que se me notifique, de modo que pueda iniciar una conversación con él”) y tratan de explicitar el contexto y el problema específico que hay que resolver en esa situación.
  • Resultados deseados. También relacionados con la filosofía Jobs-To-Be-Done y en las antípodas de las expresiones literales de los clientes, Tony Ulwick de Strategyn propone unas expresiones de necesidad que él denomina resultados deseados que siguen una sintaxis precisa:
    <DIRECCIÓN DE LA MEJORA> <UNIDAD DE MEDIDA> <OBJETO DE CONTROL> <CONTEXTO>
    (por ejemplo, “Minimizar la probabilidad de hacer cambios inadvertidos en la configuración cuando manipulo el dispositivo”). Estos resultados deseados son métricas que el cliente usa para medir el éxito cuando está realizando un trabajo.
  • Mi formato favorito para expresión de requisitos está muy influido por las enseñanzas de Pragmatic Marketing y tiene la forma:
    <PERSONA> cuando <ESCENARIO> necesita resolver <PROBLEMA>
    (por ejemplo, “el Gerente de Ventas, cuando una vez a la semana lleva a cabo una revisión de su territorio con el Director Comercial, necesita conocer el estado de todas las cuentas de los miembros de su equipo”).
    Este formato tiene la ventaja de que, además de explicitar el contexto y el problema a resolver, identifica a la persona (arquetipo) que lo padece. Esto es útil en productos de compra compleja, con varios usuarios diferentes y con varios roles involucrados en la compra y uso del producto, cada uno con sus objetivos y necesidades.
  • NOTA: diferencias con las user stories. Las historias de usuario son un artefacto de las metodologías ágiles que se utilizan para la especificación funcional de un producto. Tienen la forma
    Como <PERSONA> quiero/necesito <HACER ALGO> para conseguir <BENEFICIO>
    y se utilizan en la fase de Implementación de producto, para definir las funcionalidades que se van a construir en un sprint. Por lo tanto las user stories tienen sentido cuando ya se ha diseñado (al menos parcialmente) el producto y no residen en el espacio del problema sino en el de la solución.

El marco importancia / satisfacción

El proceso de recogida de requisitos suele finalizar con una estructuración de dichos requisitos en una jerarquía de temas y con su valoración según dos ejes: la importancia que para los clientes tiene ese requisito y el grado de satisfacción de dicho requisito mediante las soluciones actuales. Tanto la estructuración de los requisitos como su valoración según esos dos criterios deben ser realizadas por los clientes, para definir el espacio de problema desde su punto de vista. Obviamente las mayores oportunidades para el desarrollo de nuevos productos radican en requisitos que son muy importantes para los clientes pero que no están adecuadamente satisfechos por las soluciones actuales.

En conclusión, los requisitos son “requisitos del mercado”, no (especificaciones) del producto. La principal responsabilidad del equipo de producto para con sus colegas de diseño y desarrollo es proporcionarles requisitos que expresen problemas de mercado que valga la pena resolver. Sólo eso facilita el desarrollo de productos que los clientes quieran comprar.

El post “Definiendo tu producto: explorando el espacio del problema (3)” se publicó primero en “Marketing & Innovación”.

[¿Quieres aprender a aplicar estas ideas en tu empresa? Nuestros talleres sobre Marketing estratégico para empresas tecnológicas y Product Management de productos tecnológicos te pueden ayudar.]

Anuncios
Deja un comentario

¿Cómo acotar el espacio del problema a la hora de definir un producto? Entender las necesidades de los clientes es la primera etapa, como paso previo a expresarlas como un conjunto de requisitos.

En la primera parte de este post hablamos de la importancia de acotar el espacio del problema a la hora de desarrollar un producto. Como veremos en las siguientes entregas, esto se consigue en primer lugar entendiendo las necesidades de los clientes, para poder articularlas luego en forma de requisitos agnósticos respecto a la solución.

Cómo entender el problema del cliente

LInvestigación Clientesa comprensión de las necesidades de los clientes es uno de los temas más habituales de este blog. A continuación presentamos una breve panorámica de algunas de las técnicas que se aplican, con enlaces a otras entradas para los que queráis profundizar en este asunto. En resumen las técnicas para descubrir y entender problemas de mercado se pueden clasificar en cinco categorías, basadas en los siguientes aspectos:

Lo que los clientes dicen

Aquí se recogen las técnicas más tradicionales de investigación de mercados, tanto cualitativas (exploratorias) como cuantitativas (estadísticamente representativas), por ejemplo, entrevistas en profundidad, focus groups o encuestas. El foco de estas técnicas en la expresión del pensamiento consciente, y su dificultad para recoger necesidades no articuladas, no reconocidas o inconscientes han hecho que frecuentemente se complementen con herramientas provenientes de la Psicología tales como las técnicas proyectivas o el laddering. Últimamente la “netnografía” -el análisis de las publicaciones y comportamientos online espontáneos de los usuarios- ha venido a ampliar el repertorio de técnicas de esta categoría, aunque algunos la consideran a caballo entre ésta y la siguiente.

Lo que los clientes hacen

Se trata de técnicas que provienen del mundo de la Antropología y el Diseño y que consisten en “empatizar” con el cliente, bien observando directamente sus contextos, actitudes y comportamientos -para descubrir problemas no expresados, comportamientos compensatorios y limitaciones de los productos actuales- bien sumergiéndonos profundamente en dichas situaciones, para “sentir su dolor” en primera persona. Las visitas a clientes, las consultas contextuales, la investigación de factores humanos o el mapeado de experiencias de usuario son ejemplos de estas técnicas, que también nos ayudan a descubrir necesidades no expresadas o inconscientes.

Lo que los clientes construyen

En ocasiones, los usuarios avanzados “fabrican” soluciones para sus problemas más acuciantes. La técnica de los lead users nos permite de una manera sistemática no sólo aprovechar esa identificación de necesidades, sino también la innovación generada por los propios clientes. Con un enfoque diferente, la técnica de elicitación de metáforas nos permite sortear las limitaciones de la expresión consciente, la lógica y la verbalización al invitar a los clientes a elaborar collages a partir de fotografías y recortes de revistas que involucren sus canales de pensamiento y expresión no verbales (especialmente, visuales) y nos proporcionen información profunda sobre cómo conceptualizan un problema o experimentan un producto.

La interpretación del mercado

En lugar de preguntar u observar a los propios clientes, a veces es útil recurrir a “intérpretes” (expertos provenientes de ámbitos diversos) que analicen con nuevos ojos la experiencia global de los usuarios y nos ayuden a imaginar experiencias nuevas y no solicitadas. Éste enfoque nos sirve para descubrir necesidades anticipadas o inciertas y es habitual en lo que se conoce como innovación de significado o “dirigida por el diseño”.

La experimentación y aprendizaje en el mercado

Este enfoque, puesto de moda a raíz de las filosofías de Customer Development y Lean Startup, pero que cuenta con predecesores en forma de Marketing Expedicionario o Probe&Learn, consiste en realizar incursiones en el mercado real con versiones preliminares de la oferta que nos permitan validar el encaje problema/solución y el encaje producto/mercado e ir refinando dicha oferta.

Algunas de las técnicas y metodologías anteriores (por ejemplo, lead users, Customer Development) no son solo herramientas de investigación sino también de innovación en el sentido de que cubren todo el ciclo completo que va desde el descubrimiento de necesidades hasta la construcción del producto o solución.

Al final el método de investigación más adecuado depende del tipo de insight que deseemos obtener y de factores como nuestro grado de familiaridad con los clientes y sus necesidades y el de innovación de las soluciones que podemos proponer. Pero el éxito de nuestras investigaciones siempre va a depender de un factor clave: nuestra capacidad para desproveernos de nuestros prejuicios y opiniones preconcebidas; porque como dice el proverbio la empatía no consiste únicamente en caminar con los zapatos de otro, antes tienes que quitarte tus propios zapatos.

En la tercera parte de este post hablaremos de cómo destilar estas necesidades en forma de requisitos.

El post “Definiendo tu producto: explorando el espacio del problema (2)” se publicó primero en “Marketing & Innovación”.

[¿Quieres aprender a aplicar estas ideas en tu empresa? Nuestros talleres sobre Marketing estratégico para empresas tecnológicas y Product Management de productos tecnológicos te pueden ayudar.]

Deja un comentario

La definición del problema que va a resolver nuestro producto es un aspecto al que no se le suele prestar la debida atención. Hacerlo así y saltar prematuramente al diseño y a la implementación del producto (solución) puede traer consecuencias fatales.

Como hemos dicho más de una vez por estas páginas, esencialmente un producto es una solución a un problema de mercado. Para que haya una oportunidad para un producto debe existir un problema de mercado que sea lo suficientemente importante, urgente y generalizado dentro de un conjunto de potenciales clientes.

Espacios de problema y solución

Por eso en estrategia de producto hablamos de espacios de problema y de solución:

  • El espacio del problema es donde residen las necesidades que queremos que cubra nuestro producto. Este espacio se expresa en forma de problemas, necesidades, trabajos y objetivos que encontramos en los clientes y, a un nivel más bajo, de resultados deseados, requisitos, etc.
  • El espacio de la solución es donde residen los productos que aportamos para resolver esos problemas. Este espacio se expresa en términos de productos y soluciones y, a un nivel más bajo, de funcionalidades, prestaciones, características, atributos, especificaciones, etc. de dichos productos.

Al final, un producto de éxito es el que con mayor fortuna logra una intersección o mapeado óptimo entre los espacios de problema y de solución.

Espacio problema vs espacio solucionUna vez evaluada una oportunidad de mercado la primera fase en el desarrollo de un nuevo producto consiste en lo que algunos denominan Definición de producto, que consiste en descubrir y cuantificar esos problemas de mercado, y articularlos en forma de requisitos. Esta definición es un componente esencial de la estrategia de producto y una de las responsabilidades más importantes del Product Manager. De forma más o menos solapada con la Definición de producto, las actividades de Diseño crean una conceptualización, una funcionalidad y una experiencia de usuario para la solución y las de Implementación construyen dicha solución.

La decisión sobre qué problema vamos a resolver y para quién (y, por extensión, de los problemas que NO vamos a resolver) es la primera encrucijada clave de un producto.

No saltes demasiado pronto al espacio de solución

Uno de los errores más frecuentes que socavan las actividades de desarrollo de nuevos productos es saltar apresuradamente a concebir la solución sin haber llegado a comprender adecuadamente el espacio del problema. Especialmente en el caso de las empresas que deben comercializar nuevas tecnologías, la urgencia por aplicar éstas en soluciones hace que todo lo veamos desde la óptica de estas tecnologías y no dediquemos suficiente esfuerzo a entender y cuantificar los problemas de los clientes (como se suele decir, “al que tiene un martillo todo le parecen clavos”). La consecuencia es una mala comprensión de la verdadera naturaleza, importancia, urgencia y extensión del problema y de la variedad de soluciones alternativas que los clientes pueden utilizar para resolverlo.

Uno de los ejemplos más citados en la literatura sobre Product Managemente en relación a este tema es el del famoso “bolígrafo espacial”. Parece ser que en los pasados años sesenta, en plena carrera espacial entre americanos y soviéticos, ambos rivales se encontraron con la necesidad de dotar a sus astronautas de dispositivos para escribir en las naves espaciales, donde la falta de gravedad impedía el funcionamiento de bolígrafos y plumas convencionales. Los americanos se enfrascaron en un millonario proyecto para el desarrollo de un bolígrafo con un cartucho de tinta presurizado, capaz de funcionar en ausencia de gravedad. Por el contrario los soviéticos, que formularon el problema como “dispositivo para escribir en ausencia de gravedad”, dotaron a sus astronautas de… lapiceros. En conclusión, una mala comprensión del problema nos puede llevar a la construcción de productos inadecuados para el mercado.

¿Quiere esto decir que no deberíamos empezar con las fases de diseño hasta que no hayamos identificado y analizado exhaustivamente el problema de los clientes? Pues lo cierto es que no. Como veremos a continuación la comprensión de los problemas de mercado es una labor extremadamente difícil y a veces la mejor manera de acabar de entender las necesidades de los clientes, incluyendo su importancia y el grado de satisfacción con otras soluciones, es exponer a esos clientes a versiones preliminares de nuestros productos. Y de hecho, los nuevos enfoques ágiles en desarrollo de productos nos llevan a solapar las actividades de definición, diseño e implementación. Pero lo que siempre debemos impedir es que una insuficiente comprensión de las necesidades de mercado nos lleve a soluciones “miopes”.

El problema define el mercado

Como hemos dicho varias veces por aquí, el problema es el que crea y mide el mercado. No es sólo, como decía Theodore Levitt, que “la gente no quiere un taladro de un cuarto de pulgada, sino agujeros de un cuarto de pulgada”, en realidad probablemente lo que la gente quiere es un “método para fijar un cuadro a la pared de la manera más sencilla y menos invasiva posible”, abriendo el camino a otras soluciones como por ejemplo las fijaciones adhesivas.

Sólo cuando miramos al mercado desde el prisma del problema a resolver entendemos su magnitud y contra qué otras soluciones competimos. Un mercado no está específicamente ligado a un tipo de solución que cubre esas necesidades. Ése es el motivo por el cual solemos asistir a “disrupciones”, cuando un nuevo tipo de producto (espacio de solución) cubre mejor esas necesidades de mercado (espacio de problema).

En las siguientes entregas de este post pasaremos revista a las técnicas para entender los problemas de los clientes y a cómo expresarlos en forma de requisitos.

El post “Definiendo tu producto: explorando el espacio del problema (1)” se publicó primero en “Marketing & Innovación”.

[¿Quieres aprender a aplicar estas ideas en tu empresa? Nuestros talleres sobre Marketing estratégico para empresas tecnológicas y Product Management de productos tecnológicos te pueden ayudar.]

Deja un comentario

La transición desde un modelo de negocio basado en proyectos a medida hacia otro basado en producto estándar es difícil. Seguimos repasando los escollos de origen interno que nos impiden convertirnos en una empresa de producto.

En esta segunda parte del post vamos a seguir desgranando algunas de las barreras que nosotros mismos nos ponemos en el camino hacia un negocio basado en producto. Estas barreras provienen de ideas como las siguientes:

Producto sin Mercado

“Ya le hemos vendido esto a dos clientes: ya tenemos un producto”

Es una versión ampliada y corregida del caso anterior: si ya hemos conseguido vender algo a varios clientes, con mayor motivo deberíamos poder explotarlo como un producto. Y lo que dijimos para aquel caso sigue siendo válido aquí: convertir ese “producto” en un negocio escalable puede ser difícil debido a la carencia de la propiedad intelectual, a un diseño funcional, experiencial y técnico deficiente que hace imposible su evolución y mantenimiento, y a la inexistencia de un mercado real para el potencial producto.

Pero además puede darse una circunstancia adicional, y es que lo que la empresa proveedora considera un producto no es percibido como tal por el mercado. Como todo, es cuestión de perspectiva y aquí vale la pena recordar esa famosa frase de Drucker de que “el comprador raramente compra lo que el vendedor cree que está vendiendo”). Y en general el cliente compra una solución, no ve el producto que va dentro.

Me explico. Muchas veces ocurre que las empresas tecnológicas comienzan desarrollando tecnologías que en el mejor de los casos llegan a cristalizar en “herramientas” o componentes reutilizables en varios de sus clientes. Estas herramientas les sirven para optimizar y abaratar la entrega de soluciones a medida para sus clientes en un cierto ámbito, por ejemplo, en el campo del software suelen tomar la forma de “motores” o bibliotecas de programas.

En esta etapa algunas empresas consideran que han desarrollado un “producto” porque lo han instalado en varios clientes e, incluso, le han dado una identidad y unas especificaciones que lo hacen más tangible, fiable y creíble.

Pero ¿una herramienta para desarrollar soluciones a medida es un producto? En muchos casos, en realidad no se trata más que de una pieza reutilizable en sus desarrollos que dista mucho de la solución completa que necesita el cliente y carece de la estandarización, documentación y soporte que caracterizan a un producto real.

Y para estos proveedores, no invertir lo suficiente para lograr un producto “completo” y estandarizado crea barreras para escalar. Hasta cierto punto, continúa siendo un negocio de desarrollos a medida camuflado como negocio de producto, pero sustancialmente menos escalable y rentable. Un negocio que no escala bien porque sigue siendo muy intensivo en actividades a medida del cliente y en la utilización de personal especializado (encargado de desarrollar las soluciones).

(Nota: sin embargo, los servicios alrededor de un producto estándar pueden constituir un negocio muy lucrativo, especialmente si se trata de servicios especializados basados en tecnologías más o menos propietarias.)

Este comportamiento puede ser una trampa para algunas empresas tecnológicas que, por no apostar e invertir en estandarizar y replicar, siguen estancadas en un negocio en el que se renuncia a las posibilidades de diferenciación (y rentabilidad) que proporciona un producto.

La clave para que un producto “incompleto” pueda constituir la base de un negocio escalable y rentable está en estos factores:

  • Qué proporción de la solución al problema de los clientes es “producto” directamente disponible y estándar, frente a la proporción que consiste en configuración/ adaptación/ desarrollo complementario sobre él
  • El nivel de madurez, estandarización, documentación y soporte de la parte de “producto reutilizable” y, como consecuencia, quién puede realizar la adaptación/ desarrollo sobre él: la empresa proveedora del producto, sus partners, los clientes finales.

Si lo que ofrece el producto está muy lejos de la solución que necesitan los clientes y el nivel de estabilidad y documentación de ese producto hace difícil que otros puedan desarrollar la parte que falta, la empresa proveedora estará obligada a realizar ese trabajo siempre y su negocio -aunque pueda ser rentable en ese ámbito- no va a escalar bien.

Y en mi experiencia, sólo si se tiene un producto base líder es posible construir un ecosistema escalable en el que tanto la empresa como sus partners (revendedores de valor añadido, integradores) ganen dinero con el desarrollo de soluciones alrededor de dicho producto.

“Alguien nos ha pedido esta funcionalidad adicional: vamos a añadírsela al producto”

Un negocio basado en producto conlleva tensiones, especialmente entre los objetivos del corto plazo (sobrevivir) y el largo (desarrollar nuestra visión), y eso es fuente de conflicto y fricciones dentro de la empresa.

Una de las más típicas es que se produce ante peticiones de nuevas features & functions  por parte de potenciales clientes (y otros stakeholders tanto internos como externos). Con frecuencia, la decisión suele consistir en acceder a la petición sin mayor análisis, lo que inevitablemente lleva a convertir el producto en una especie de monstruo de Frankenstein, un popurrí de atributos y experiencias de uso inconexas.

Estos productos se caracterizan por resolver el 50% del problema del 100% del mercado, pero no llegan a resolver el 100% del problema de nadie, y suelen incorporar múltiples atributos que luego no tienen demanda del mercado (y que invariablemente acaban resultando más caros de implementar de lo previsto).

Además, un  crecimiento desordenado  de features distrae nuestros escasos recursos, nos impide concentrarnos en aquéllas que son verdaderos drivers de valor para el cliente y nos aleja de nuestra visión de producto. Como hemos dicho en otras ocasiones la “featuritis” conlleva una baja usabilidad y como consecuencia una baja satisfacción a largo plazo del cliente que perjudique la vida del producto. Sin olvidar que constituye la máxima cause de deuda técnica.

Tener una estrategia y una visión de producto significa decir “no” muchas veces… Sin embargo a veces decir “no” también puede ser señal de una carencia de estrategia. Por ejemplo, a veces nos negamos a desarrollar una nueva feature no porque no encaje en nuestra visión, sino porque no hemos encontrado un cliente que costee completamente dicho desarrollo. Pero muy pocos clientes potenciales van a pagarnos ese desarrollo o a comprometerse con nosotros si ya hay otros proveedores que les ofrecen esos atributos como parte de un producto estándar y a un precio razonable hoy. Para el que no tiene un roadmap, todas las solicitudes de features son como proyectos a medida que deben ser rentables de manera inmediata

Pero si esa nueva feature nos acerca a nuestra visión, aporta valor a nuestros clientes objetivo y va a generar negocio en el largo plazo, el no tener a alguien que pague el desarrollo completo no debe ser un obstáculo: deberíamos captar los recursos necesarios para desarrollarla.

Y por eso en una empresa basada en productos son tan importantes la visión, la estrategia y el roadmap, temas sobre los que volveremos pronto por aquí.

¿Cuál es vuestra experiencia en la transición de una empresa de un modelo basado en proyectos a otro basado en productos?

El post “Los escollos que nosotros mismos nos ponemos para convertirnos en una empresa de producto (2)” 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.]

Deja un comentario

Embarcarse en el desarrollo de un producto para un mercado es difícil. No todas las empresas tienen la visión, el liderazgo y los recursos necesarios. Pero en muchas ocasiones los escollos que nos impiden convertirnos en una empresa de producto salen de nosotros mismos en forma de falta de visión a largo plazo y malas decisiones.

En muchas empresas de base tecnológica el paso de un modelo de negocio basado en desarrollos a medida a otro basado en producto es un paso natural y obligado, forzado por la propia evolución del mercado. Aún así, en la mayoría de los casos cuesta cambiar a un “pensamiento basado en producto”, sobre todo si la empresa ha disfrutado de una existencia rentable vendiendo proyectos a medida.

Wishful ThinkingEl nuevo modelo de negocio exige invertir recursos de todo tipo y desarrollar el producto (al menos parcialmente o en una versión “mínima”) antes de tener clientes. Para ello, los requisitos en cuanto a conocimiento del mercado y necesidades de financiación son más exigentes. Y aunque existen ciertos tipos de productos donde estos requisitos son menos severos que en otros (p.ej., los productos basados en contenidos digitales pueden necesitar una menor inversión y adaptarse bien a un desarrollo iterativo) el paso a un modelo de producto exige un “salto de fe” -y de financiación- que para muchos es insalvable.

Pero no todos los escollos para pasar a una filosofía de producto provienen del exterior. Muchos de ellos nos los creamos nosotros mismos con ideas preconcebidas, una visión a largo plazo miope y juicios optimistas. En este post (al que seguirá una segunda parte) vamos a desgranar algunos de esas barreras que nosotros mismos nos ponemos en el camino hacia un negocio basado en producto.

Estas barreras provienen de ideas como las siguientes:

“Los clientes van a seguir comprando nuestros desarrollos a medida: no necesitamos desarrollar un producto”

Muchas empresas piensan que su negocio de proyectos a medida todavía tiene futuro y postergan la decisión de desarrollar un producto. Y eso puede ser cierto… hasta que en nuestro mercado empiezan a aparecer productos estándar que resuelven razonablemente bien el problema del cliente.

Si existen productos estándar aceptables, la mayoría de las ocasiones los clientes pueden conseguir un encaje entre sus necesidades y un producto (adecuadamente personalizado), con los beneficios que eso conlleva en cuanto a funcionalidad, prestaciones, rendimiento, fiabilidad, evolución, soporte… y, sobre todo, precio.

Ciertamente, los clientes suelen preferir la credibilidad, estabilidad, referencias y (en muchos casos) menor coste total de propiedad de un producto frente a un desarrollo a medida. ¿Te comprarías un equipo/dispositivo/software/instrumento desarrollado a medida cundo tienes un producto que se ajusta tus necesidades, avalado por cientos o miles de clientes como tú y que además tiene más funcionalidad y es más evolucionable y más barato?

En este escenario, los proveedores de soluciones a medida tienen más difícil justificar su valor aportado y su (habitualmente) mayor precio. Eso lleva en el corto plazo a una erosión de la rentabilidad del negocio y a largo a una posible expulsión del mercado.

Por este motivo, muchas empresas basadas en modelo orientado a proyectos se ven forzadas a dar el paso a un negocio de producto: basta con que aparezcan en su sector proveedores de producto fiables en una categoría.

¿Es posible que en tu mercado no aparezcan productos estándar? Eso depende de diversas características estructurales (empezando por el tipo de clientes y sus necesidades), pero ten presente algo: si en tu mercado hay potencial de rentabilidad siempre va a haber un inversor dispuesto a poner el dinero para crear un negocio escalable y capturar ese valor, de modo que ese producto va a aparecer tarde o temprano.

“Este desarrollo para un cliente nos va a servir como producto”

¿Quién no ha pensado alguna vez que ese desarrollo que tenemos que realizar para un cliente se va a poder vender sin más a muchos otros clientes similares? La realidad es menos favorable por varios motivos.

En primer lugar, es posible que en virtud del contrato del proyecto toda la propiedad intelectual de los desarrollos recaiga en el cliente y por lo tanto no podamos (legalmente) vender esos resultados a otros posibles compradores.

Pero además, cuando se desarrolla a medida no se tienen en cuenta aspectos de “productibilidad” (es decir de poder convertir el en futuro ese desarrollo en un producto replicable para un mercado). Un proyecto para un cliente tiene su propia agenda y sus propios requisitos, especialmente en cuanto a plazos y rentabilidad. Se trata de resolver el problema de ese cliente lo más rápido y con los menores costes posibles, y cualquier otro condicionante pasa a un segundo plano.

Facetas como la arquitectura, la modularidad, la adaptabilidad, la evolucionabilidad, la posibilidad de crear de manera eficiente productos derivados… en definitiva, lo que constituiría una buena plataforma de producto se deja de lado y corremos el riesgo de empezar a generar una deuda técnica difícil de pagar en el largo plazo.

Y finalmente -pero no por ello son menos importantes- están los aspectos comerciales y de negocio: ¿Hay un mercado detrás de esto? ¿Cuántos clientes existen con la misma necesidad? ¿Cómo de urgente e importante es la necesidad en esos casos? ¿Puedo llegar desde el punto de vista de marketing y ventas a todos esos potenciales clientes? ¿Cuánto me puede costar esa replicación y comercialización? ¿Puedo construir un negocio rentable con ello?

A veces un cliente no es síntoma de un mercado y el presunto producto puede no llegar a convertirse nunca en un negocio escalable.

En la segunda parte de este post seguiremos desglosando los escollos que nosotros mismos nos ponemos al convertirnos en una empresa de producto.

El post “Los escollos que nosotros mismos nos ponemos para convertirnos en una empresa de producto (1)” 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.]

Deja un comentario

Dos de las características principales de los productos para un mercado son sus costes de desarrollo y de replicación, que impactan en la rentabilidad de su negocio. Pero esas características no son las únicas que separan a los negocios basados en producto de los basados en desarrollos a medida.

En la anterior entrada hablamos sobre modelos de negocio basados en producto y destacamos la condición de que para que un producto sea tal debe ser repetible e ir enfocado a un mercado de clientes.

En esta entrada seguimos analizando los negocios basados en producto y nos centramos en dos aspectos clave: la influencia que tienen los costes de desarrollo y replicación del propio producto en dicho negocio y las diferencias entre los modelos basados en productos y en desarrollos a medida.

Costes de desarrollo frente a costes de replicación de producto

Dos de los parámetros que marcan absolutamente un modelo de negocio basado en producto son sus costes de desarrollo (lo que en su día definimos como crear la “unidad 0”) y de replicación (crear las siguientes unidades), y es llamativa la enorme diversidad que se da entre unos sectores y otros.

Por ejemplo, si estás acostumbrado a trabajar en el sector del software -donde los costes de replicación son muy bajos- te sorprenderá comprobar hasta qué punto los costes de desarrollo y replicación en otras industrias como farmacia o automoción son diferentes y cómo condicionan su potencial rentabilidad.

Costes Desarrollo vs. Costes Replicación Producto

En este cuadro se presentan cifras orientativas de estos costes para tres tipos de producto:

  • En los costes de desarrollo recogemos las actividades de investigación, definición, diseño, construcción, pruebas, certificación administrativa (muy importantes en productos relacionados con la salud)… de una versión replicable y comercializable del producto.
  • En replicación incluimos los costes incrementales de fabricación y entrega de una unidad adicional de producto. (No se incluyen costes de comercialización ni soporte.)

Por ejemplo, los fármacos suelen tener unos costes de desarrollo altísimos debido a las dificultades de descubrir la molécula de su principio activo y a los riesgos en las actividades de pruebas clínicas y de aprobación administrativa por las autoridades sanitarias, pero sus costes de replicación son bajos (se da la paradoja de que muchas veces el coste del envase es muy superior al de los componentes).

Por el contrario, en el caso de un automóvil los costes de desarrollo no son tan altos, pero los de replicación son comparativamente muy superiores debido al peso de los materiales directos y el proceso de fabricación.

Finalmente, el software (y otros contenidos digitales) se caracterizan por su mínimo coste de replicación, que en su versión más elemental consiste en copiar el contenido en un servidor accesible desde Internet para que los clientes se lo descarguen desde ahí (otras variantes, como la prestación en modo servicio, son más complejas y caras).

Estos dos parámetros, tan característicos de cada producto, influyen sobre su modelo de negocio: corrientes de ingresos y costes, estrategias comerciales… Por ejemplo, para un producto que no cuesta prácticamente nada replicar es posible utilizar un marketing basado en la prueba gratuita generalizada y en modelos fremium, estrategias que resultarían mucho más difíciles cuando el coste de cada unidad es alto. Este es el caso de ciertos productos farmacéuticos y del software. Asimismo, en productos de bajo coste de replicación y costes de desarrollo no muy altos el potencial de rentabilidad es muy elevado.

Los negocios basados en productos y proyectos son muy diferentes

Este análisis de los costes de desarrollo y replicación nos da pie a discutir cuáles son las diferencias entre los modelos de negocio basados en proyectos de desarrollo a medida y en productos para un mercado, que se resumen en la siguiente tabla:

Modelos de Negocio Producto vs. Proyecto

Esta comparación resalta varias diferencias sustanciales entre los negocios basados en desarrollos a medida y producto, especialmente en los siguientes elementos del modelo:

  • Los clientes y sus problemas/necesidades. En el caso de un desarrollo a medida el cliente es conocido y resulta accesible y podemos (no sin dificultades) entender su necesidad o problema. A partir de ahí desarrollamos la solución, sea mediante procesos lineales o iterativos.
    Por el contrario, en un producto para un mercado los clientes son desconocidos y generalmente heterogéneos e inaccesibles. El gran reto es entender cómo los clientes se segmentan en distintos grupos de necesidades, convertirlas en requisitos y decidir cuáles se van a resolver mediante el producto. Y a partir de ahí, por supuesto, diseñar y construir la solución. Un producto nunca va a ser capaz de resolver el 100% de las necesidades de todos los clientes que podrían integrar su mercado porque sería poco usable y muy caro. Por eso tenemos que decidir en qué segmentos y personas de clientes vamos a enfocarnos y -para ellos, sí- a intentar resolver el 100% de su problema. En resumen, en el caso del producto se da mucha más incertidumbre en cuanto a los clientes y sus problemas.
  • Fórmula del beneficio. Las corrientes de ingresos y costes son diferentes: un desarrollo a medida es esencialmente una iniciativa singular, que atiende a los requisitos particulares de un cliente concreto en un momento dado. Para el proveedor representa una iniciativa generalmente intensiva en recursos especializados y caros. De modo que -para que el proyecto sea rentable- el precio a cobrar al cliente debe compensar con creces esos costes. Y aunque siempre hay componentes comunes que se pueden repetir a través de varios proyectos, en muchas condiciones los derechos de propiedad intelectual sobre los desarrollos -que suelen corresponder al cliente- impiden su replicación (legal) por parte del proveedor.
    Los productos para un mercado son todo lo contrario: difícilmente un cliente nos va a pagar los costes completos de desarrollo y éste va a requerir una inversión sustancial, con lo que los productos sólo son rentables con la repetición. Y debe enmarcarse en un modelo de negocio escalable, para que, a medida que aceleramos el negocio y aumentamos los volúmenes, la rentabilidad no sólo no se deteriore sino que mejore.
    Pero también hay una influencia mutua entre las rentabilidades de estos dos negocios cuando compiten en un mismo mercado: especialmente cuando en un mercado hay proveedores vendiendo productos estándar, los precios tienden a bajar y la rentabilidad de las soluciones desarrolladas a medida se reduce.

Estas diferencias entre un negocio y otro implican un cambio de pensamiento y de filosofía de gestión que provoca que a muchas empresas les resulte difícil pasar de un modelo basado en desarrollos a medida a otro basado en producto para un mercado. En la próxima entrega hablaremos de los escollos que nosotros mismos nos ponemos para convertirnos en una empresa de producto.

El post “Modelos de negocio basados en producto: características y diferencias respecto al negocio de desarrollos a medida” 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.]

4 comentarios

Un modelo de negocio basado en producto se caracteriza por una propuesta de valor repetible, que pueda comercializarse y entregarse de manera escalable y rentable en un mercado. Para muchas empresas orientadas al desarrollo a medida  este cambio de mentalidad  plantea grandes retos.

Muchas compañías tecnológicas tienen problemas para evolucionar a un modelo de negocio basado en producto. Por ejemplo, una empresa biotecnológica que quiere plasmar su tecnología de análisis de biomarcadores en un kit para la detección del cáncer o una empresa experta en procesamiento del lenguaje natural que se plantea crear una herramienta software de e-discovery para departamentos legales tienen por delante un camino lleno de retos, muchos de ellos de origen interno.

Frecuentemente habituadas a aplicar sus nuevas tecnologías en soluciones más o menos a medida de cada cliente, les resulta difícil dar el salto hacia una “mentalidad de producto” con todo lo que ello implica en cuanto a centrarse en un tipo de cliente, desarrollar una oferta estándar… e incluso (dependiendo del sector) fabricar y almacenar bienes que todavía no han vendido.

En las próximas entradas vamos a hablar sobre estos problemas, empezando en este post por analizar qué significa realmente tener un negocio basado en producto.

Las dos características que definen un negocio basado en producto

Un modelo de negocio basado en producto tiene algunos atributos que lo caracterizan y que lo diferencian de un negocio basado en el desarrollo de soluciones a medida. Aún a riesgo de simplificar demasiado, son básicamente dos:

  • Producto RepetibleUn producto es repetible / replicable. Eso significa que debemos poder vender unidades del producto (con las mínimas modificaciones) al mayor número de clientes posible. Desarrollar nuestro producto consiste básicamente en crear esa “unidad 0” que luego será replicada y entregada masivamente mediante los procesos de operaciones (manufactura, logística…) más adecuados. (Estamos simplificando mucho: con las nuevas filosofías de desarrollo basadas en la iteración y la experimentación en el mercado y los modelos de prestación en modo servicio resulta difícil decir dónde termina la “unidad 0” y empieza la fabricación y la comercialización.) Por el contrario, un desarrollo a medida es específico para un cliente particular y en general tiene unas posibilidades de replicación limitadas.
  • Producto para MercadoUn producto va dirigido a un mercado. Los productos no se desarrollan a medida de un cliente particular y cercano, sino que deben servir para un mercado de clientes que rara vez son idénticos. Los clientes de un producto no sólo son heterogéneos, sino que pueden resultarnos desconocidos e inaccesibles, lo que dificulta la labor de entenderlos y diseñar ofertas para ellos. Probablemente la decisión más importante en la gestión de producto es en qué clientes nos enfocamos (y a cuáles renunciamos). Las empresas de producto sufren tensiones entre centrarse en un segmento homogéneo -para el cual sea fácil definir un producto- y atacar a un mercado amplio, que a cambio de la promesa de un mayor volumen plantea retos causados por su heterogeneidad y dispersión. Las técnicas de investigación de mercados y clientes y herramientas como segmentos y personas son imprescindibles para entender, caracterizar y modelar a los clientes de nuestro mercado, sus necesidades y sus objetivos.

La base de un modelo de negocio escalable y rentable radica en encontrar un mercado suficientemente amplio y homogéneo para el cual desarrollar un producto replicable que podamos vender masiva y eficientemente sin grandes adaptaciones ni modificaciones.

Muchos tipos de producto según su nivel de estandarización-personalización

En realidad, cuando hablamos de producto no nos referimos a algo fijo y sin opciones, al estilo del Ford T (disponible “en cualquier color que desee, siempre que sea negro”). En muchos mercados, sus dinámicas han obligado a los proveedores a ofrecer productos configurables y con múltiples variantes: el ejemplo típico es el de un automóvil con opciones a medida, que se ensambla bajo pedido.

Especialmente en el caso de necesidades de cliente complejas, el eje proyecto a medida – producto estándar es un continuo con todas las situaciones intermedias, que van desde las herramientas para productizar la entrega de soluciones a medida hasta los productos configurables (p.ej.: software corporativo tipo ERP). Hablaremos de ello en un próximo post.

Lo importante en cualquier caso desde un punto de vista de cliente y negocio es qué proporción de la solución es estándar (y qué parte debe ser entregada más o menos a medida de las necesidades del cliente) y quién puede realizar esa personalización: el proveedor del producto, sus partners, el propio cliente… Esto da lugar a modelos de negocio y a perspectivas de rentabilidad muy diferentes.

En el próximo post hablaremos de cómo los costes de desarrollo y replicación influyen en el modelo de negocio de un producto y de las diferencias entre éste y un negocio basado en desarrollos a medida.

El post “Producto: repetible y para un mercado” 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.]

Deja un comentario

Las nuevas filosofías de desarrollo de productos y negocios tienen muchos puntos en común pero también algunas contradicciones. En realidad, cada una de ellas representa una visión parcial de un nuevo proceso de innovación que está emergiendo y cuyas piezas todavía tienen que acabar que encajar.

Una de las primeras cosas que vienen a la cabeza cuando uno intenta profundizar y aplicar las diversas filosofías de la “nueva innovación” (Agile, Diseño, Customer Development, Lean Startup…) es una curiosa sensación de déjà vu. Cuando se ha familiarizado con las iteraciones y los experimentos de Customer Development (o de Diseño, o de Agile) y empieza a estudiar los otros enfoques es difícil evitar un pensamiento de “todo esto me suena mucho” y “una vez que dominas una, las dominas todas”.

Pero ¿realmente esto es así? ¿Cuánto hay de similar y de diferente en estas filosofías? Vamos a estudiarlo para el caso de empresas orientadas a producto (repetible, para un mercado, no proyectos a medida de un cliente).

Customer Development, Diseño y Agile

Si no son lo mismo al menos lo parecen…

La realidad es que por diversas razones (entre ellas la contemporaneidad) todas ellas comparten muchas ideas. Esencialmente, son filosofías que tratan de enfrentarse a los retos del desarrollo de nuevos productos y negocios en escenarios de gran riesgo y velocidad, que se han desarrollado prácticamente a la vez –a partir de finales del pasado siglo– y que se han “interfertilizado” mutuamente (por no decir que en ocasiones se han copiado sin demasiados miramientos). Y aunque cada una de ellas posee un lenguaje propio, en conjunto presentan muchas coincidencias y temas recurrentes:

  • Foco en el cliente
  • Experimentación (Producto Mínimo Viable, prototipos…)
  • Feedback
  • Aprendizaje
  • Iteración (sprints, ciclos…)
  • Coordinación y comunicación (interna y externa)
  • Equipos multidisciplinares

En realidad, estas filosofías ofrecen puntos de vista diferentes y parciales de lo que esencialmente es un mismo proceso: el que tiene por objetivo desarrollar un nuevo producto/empresa. Pero ahora ya no se trata de un proceso que siga un modelo lineal, por fases o en cascada, como los que han venido utilizándose con cierto éxito en el desarrollo de innovaciones incrementales.

Este nuevo modelo que va emergiendo es más adecuado para el desarrollo de productos y negocios verdaderamente nuevos – situaciones donde ni los clientes, ni sus necesidades, ni las soluciones que podrían cubrirlas ni las tecnologías que se aplicarían son totalmente conocidas o están en evolución– y es mucho más flexible y centrado en el mercado.

Agile, Diseño, Customer Development, Lean Startup son diferentes…

La realidad es que estas filosofías son diferentes (incluso complementarias) en cuanto a sus objetivos y alcance. A fin de distinguir entre unos enfoques y otros, si tuviéramos que resumir cada uno de ellos en un slogan o un par de frases el resultado podría ser el siguiente:

  • Customer Development – Sal fuera de la oficina y pon a prueba iterativamente las hipótesis de tu negocio. Después, constrúyelo y escala.
  • Diseño (y Design Thinking) – Crea productos (y negocios) que los clientes deseen a través de la empatía y el prototipado.
  • Agile – Entrega rápidamente valor a los clientes mediante una construcción iterativa e incremental que incorpora continuamente el feedback del mercado.
  • Lean Startup – Integra y aplica las filosofías anteriores en un contexto de emprendimiento: aplica ciclos rápidos de Construir-Medir-Aprender para que tu empresa sea flexible y rápida y use sus recursos de la manera más eficiente.

Dejando a un lado Lean Startup, que es una filosofía de empresa y hasta cierto punto engloba los demás enfoques, los otros representan perspectivas diferentes (y en ocasiones solapadas) del desarrollo de nuevos productos y negocios pero ninguno aporta una solución completa a todo el proceso de desarrollo. Por ejemplo:

  • Customer Development representa eminentemente una óptica de (modelo de) negocio. Es imprescindible validar la Propuesta de Valor y las otras hipótesis del modelo de negocio, pero en paralelo necesitamos saber cómo “poblar” esa propuesta y definir, diseñar y construir el producto. Los propios promotores del Customer Development aclaran que es necesario complementarlo con un proceso de “Product Development”. En particular Steve Blank y Eric Ries proponen que ese desarrollo de producto consista básicamente en una Ingeniería Ágil pero desde mi punto de vista eso no es suficiente.
  • El Diseño, especialmente el Diseño UX, recoge –como no podía ser de otra manera– la visión del diseñador y se centra en encontrar la solución para el problema/necesidad del mercado. Pero en general no entra en las actividades de definición del modelo de negocio ni de evaluación de la oportunidad de mercado y tampoco en la construcción del producto real.
  • Agile, por su parte, representa la visión del ingeniero y se enfoca en la construcción/implementación de la solución. Pero tampoco entra en las actividades de definición del modelo de negocio ni de evaluación de la oportunidad de mercado y trata de evitar las de investigación de clientes y diseño.

… e incluso contradictorias

Pero además, lo que es innegable para alguien que haya estudiado con un mínimo espíritu crítico estas filosofías (algo no habitual entre muchos de sus apóstoles)  es que entre ellas hay algunas diferencias y contradicciones muy relevantes:

Todos estos enfoques son las piezas de un puzzle que conforma un nuevo proceso de desarrollo de productos y negocios. La buena noticia es que muchos creemos que este proceso nos va a ayudar a innovar de manera más flexible y con mayores probabilidades de éxito. La mala noticia es que las piezas todavía no encajan muy bien… pero seguro que entre todos lo vamos a conseguir.

El post “Agile, Diseño, Customer Development, Lean Startup… ¿es todo lo mismo?” 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.]

2 comentarios

Hablamos mucho de la visión de producto pero ¿qué forma debería tener? ¿Una frase, un documento, un prototipo…? En este post proponemos un formato.

Supongo que cada uno tendrá sus preferencias pero estaréis de acuerdo en que idealmente la visión de producto debería expresarse mediante un artefacto que la haga fácil de compartir, comunicar y debatir.

Y recordando lo que decíamos en un post anterior, una buena manera de enfocarnos en 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 es guiarnos por el valor que vamos a crear y entregar a esos clientes.

Una Visión de Producto centrada en el Valor para el Cliente

Recordando nuestras ideas sobre el valor, la visión debería reflejar estos puntos:

  • La funcionalidad y características del producto sólo son valiosas en tanto que producen una utilidad y resultados para el cliente
  • El valor del producto viene dado por sus beneficios (funcionales, económicos, emocionales) pero también por sus costes, tal y como los percibe el cliente
  • El valor del producto es contextual (depende del cliente y la aplicación) y sobre todo es relativo (se percibe frente a las alternativas existentes).

Teniendo en cuenta esos requisitos, trabajando con algunos clientes he encontrado que un formato útil para expresar la Visión de Producto es el siguiente: Lienzo de Visión de Producto El formato se compone de estos elementos:

  • Frase resumen: una breve expresión (1-2 frases) de la propuesta de valor. Puede ser útil expresarla como una analogía con un negocio conocido, p. ej., “el 7-Eleven de los seguros”.
  • Cliente: ¿Para quién es el producto? Perfil demográfico (si es persona). Perfil psicográfico (valores, estilo de vida, personalidad, actitudes…) y de comportamiento. Perfil “firmográfico” (si es empresa). Identificación de Compradores vs. Usuarios.
  • Necesidad / problema / objetivo: ¿Qué necesita el cliente? ¿Qué desea? Una manera de expresarlo es como el trabajo que desea realizar, las mejoras que desea obtener y los inconvenientes y dificultades que desea eliminar. Este apartado nos da una idea de la oportunidad para crear valor en el cliente.
  • Solución: ¿Qué es el producto? ¿Qué hace? Descripción del concepto. Experiencia de cliente. Funcionalidades y características más relevantes. Precio.
  • Valor para el cliente: ¿Para qué usar el producto? ¿Cuáles son los resultados previsibles? ¿En qué medida se cubren las necesidades? Beneficios frente a Costes (funcionales, emocionales, económicos), considerados siempre desde la perspectiva del cliente. Nuestro objetivo debería ser entregar y que el cliente percibiera ese valor.
  • Rivales: ¿Contra quién competimos (no necesariamente productos equivalentes) por ese dinero? En la mayoría de los casos va a ser el statu quo, estrategias de mitigación, soluciones parciales/provisionales. Y también productos competidores, sustitutivos y alternativos.
  • Diferenciadores: Puntos de diferenciación frente a principal/es rival/es. Cómo vamos a desbancar al statu quo. Cómo vamos a conseguir ser “10 veces mejores” que las alternativas existentes, para que el mercado adopte nuestro producto.

Como se puede ver, la mitad izquierda de la plantilla recoge información acerca del mercado, mientras que la mitad derecha recoge información desde la perspectiva del mercado. El contenido de estos apartados puede ser textual pero también incorporar bocetos, mockups, etc. El objetivo es que posea un carácter gráfico y mínimo que facilite su uso, comprensión y comunicación.

Alternativas a nuestra Visión de Producto

Existen en la literatura otros artefactos que sirven para expresar una “visión” de producto:

  • Value Proposition Canvas de Alex Osterwalder: es una complemento/extensión de su famoso Lienzo de Modelos de Negocio, que detalla dos de los elementos de éste: Segmentos de Clientes y Propuestas de Valor. Este lienzo de propuesta de valor aplica el enfoque de Jobs-To-Be-Done popularizado por Clayton Christensen y en el lado del cliente se enfoca en los trabajos que estos desean realizar y los resultados que desean obtener (aumentar las “ganancias” y mitigar los “dolores”). En el lado de la solución, el lienzo recoge el concepto del producto/servicio y los atributos de éste que contribuyen a crear esas mejoras y a reducir esas pérdidas. Aunque el planteamiento es bueno debo decir que en conjunto el lienzo me resulta un poco reiterativo y confuso y no va más allá del concepto de producto y de sus features&functions.
  • Lean Canvas de Ash Maurya: una especie de Lienzo de Modelos de Negocio parcial, complementado con elementos relacionados con el producto y optimizado para su aplicación en Lean Startup. Es útil si necesitas manejar los aspectos de modelo de negocio y de producto en un único lienzo, pero a mi modo de ver insuficiente en ambos campos: le falta la visión de la “trastienda” del modelo de negocio y su orientación al valor para el cliente es mejorable.
  • Vision Board de Roman Pichler: Roman es una referencia en el mundo del Agile Product Owner (aunque discrepo de muchas de sus ideas, en especial las que se refieren al Agile Product Manager). Su Vision Board es un buen intento de artefacto ligero y conciso, pero que llega a ser contradictorio porque mezcla los problemas y soluciones del cliente con el valor para el proveedor.

Todos ellos son artefactos bastante aceptables y en su momento me sirvieron de inspiración (aunque ninguno me acabe de convencer plenamente). Por su parte creo que nuestra Visión de Producto

  1. Incorpora esos aspectos mínimos que deben guiar la estrategia, el roadmap y el desarrollo del producto
  2. Añade diversos elementos expresamente relacionados con el valor para el cliente (p.ej.: explicita beneficios y costes, resalta diferenciadores) que son críticos para el éxito de la propuesta.

Finamente, seguro que habréis notado el paralelismo de nuestra plantilla con la clásica expresión de posicionamiento de Geoffrey Moore en “Chrossing the Chasm”:

Para <segmento clientes>
que tienen <problema / objetivo / necesidad>
<Nombre producto> es un <categoría de producto>
que aporta <razón única para comprar / beneficios clave>.
A diferencia de <alternativa principal>
proporciona <diferenciación>.

Esta coincidencia no es necesariamente mala (ni casual). Lo que si debemos tener claro es que el objetivo y el uso de ambos artefactos son diferente. La Visión está orientada a futuro y expresa dónde querríamos estar dentro de unos (pocos) años en términos de Producto-Mercado; el Posicionamiento está orientado al presente y expresa qué lugar queremos que nuestro producto ocupe en la mente de nuestros clientes.

¡Espero que os sea útil!

El post “Vision de Producto: una propuesta de formato” 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.]

7 comentarios

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. Iterando sobre la Visión de Producto

 

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.

A partir de ahí 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.

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.]

4 comentarios
A %d blogueros les gusta esto: