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:

“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 principal causa 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.]

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.

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

El nuevo Product Manager debe basarse en un foco obsesivo en el cliente, en gestionar el producto como un negocio, en la experimentación y la iteración para ir aprendiendo en el mercado y en equipos multidisciplinares integrados.

En la primera parte de este post hablamos de cómo estos nuevos tiempos dominados por el poder de los clientes y la volatilidad reclaman una nueva gestión de producto. En esta segunda parte vamos a ver cómo este movimiento implica cambios en las filosofías, los procesos y los artefactos del Product Management.

Filosofía y principios del nuevo Product Management

A mi modo de ver, estos son los pilares filosóficos de la nueva gestión de producto.

• Foco obsesivo en el cliente. El “enfoque hacia el cliente” debe dejar de ser una frase vacía. Las necesidades, problemas y objetivos de los clientes y el valor que les podemos aportar deben ser la “medida de todas las cosas” en la gestión de producto. La colaboración con el mercado y el valioso feedback que podemos obtener de él deben ser constantes a lo largo de todo el proceso de desarrollo  y en todo el ciclo de vida del producto.
• Gestionar el producto como un negocio. Si quiere aspirar a ser el “CEO del producto” el Product Manager debe convertirse en un experto en su modelo de negocio. No es sólo que para que un producto tenga éxito debe estar sustentado por un modelo de negocio rentable y escalable. El mayor potencial de disrupción en cualquier sector no está en productos más o menos nuevos, sino en modelos de negocio innovadores que revolucionan las industrias.
• Experimentación e iteración. La nueva gestión de productos debe estar más basada en datos y evidencias de mercado y menos en opiniones y convenciones. Y para conseguirlo debemos identificar lo que no sabemos sobre nuestro negocio, expresarlo como hipótesis y validarlo (o refutarlo) mediante la experimentación en el mercado. Las nuevas tecnologías han permitido multiplicar la fiabilidad y la velocidad y reducir el coste de estos experimentos.  Y mediante iteraciones sucesivas este proceso nos permite ir avanzando en el descubrimiento y validación de nuestro producto.
• Equipos multidisciplinares e integrados. Hay que romper los silos organizativos y construir equipos multifuncionales que permitan integrar conocimientos y puntos de vista y favorezcan la mejora y el aprendizaje continuos. Como se decía en este artículo pionero, el desarrollo (y la gestión) de productos no debe funcionar como un equipo de relevos que se van pasando el testigo sino como una melé de rugby que avanza de manera solidaria. Estos equipos priman la interacción y la adaptación frente a los procesos predefinidos y fomentan el uso de unos artefactos sencillos que favorecen la transparencia y la colaboración.

Procesos, tácticas y artefactos del nuevo Product Management

Vamos a pasar revista a algunas de las actividades clave de la gestión de producto y a analizar cuáles serían sus procesos, tácticas y artefactos.

Búsqueda y evaluación de oportunidades de mercado

La búsqueda de oportunidades de negocio trata de identificar problemas y necesidades de mercado que valga la pena resolver. Pero la evaluación de oportunidades no consiste en un business case estático, construido sobre unas previsiones financieras a largo plazo totalmente irreales (cuando no ilusorias). Debemos realizar una evaluación ligera y dinámica, basada inicialmente en un bosquejo preliminar del modelo de negocio y en unas simulaciones financieras básicas, que nos ayuden a identificar los riesgos más importantes y a decidir si vale la pena lanzar el proceso de descubrimiento y validación de producto. El concepto de Plan Máximo Inviable  (propuesto aquí) puede resultar útil.

Desarrollo de nuevos productos y negocios

El desarrollo de nuevas ofertas y negocios es un proceso iterativo, guiado por la evidencia del mercado y el feedback de los clientes y protagonizado por un equipo multidisciplinar. Personal de Product Management, Diseño de Experiencias y Tecnología/Ingeniería colaboran con diferentes grados de involucración en las iteraciones del proceso, cuyo objetivo último es validar un producto que valga la pena escalar y un proceso comercial replicable (Encaje Producto-Mercado).

• Para entender lo que realmente necesita el mercado no basta con “escuchar a los clientes”: es necesario aplicar un enfoque ecléctico, que incorpore técnicas orientadas a la innovación tales como la etnografía, los lead users, o la experimentación en el mercado. La filosofía de Jobs-To-be-Done aporta una manera muy inmediata de codificar la voz del cliente.
• Para diseñar y validar modelos de negocio es necesario conceptualizar y prototipar dicho modelo y aplicar un desarrollo dirigido por hipótesis, en el que podamos identificar las incertidumbres y riesgos más importantes y despejarlos mediante el contacto con el mercado. El proceso de Customer Development y sus experimentos de Producto Mínimo Viable son los pilares de estas actividades.
• Para definir y diseñar productos y servicios es imprescindible incorporar técnicas de diseño centrado en las personas / diseño de experiencias de usuario. Enfocándonos en los arquetipos de cliente (user personas y buyer personas), en sus objetivos y en sus escenarios de uso y compra podemos diseñar productos que, además de deseables, útiles o usables sean comprables.
• Para implementar nuevos productos mejor y más rápidamente teniendo en cuenta al cliente es útil incorporar técnicas de Ingeniería Ágil o mezclarlas con enfoques más secuenciales. El foco en el cliente, la cadencia y la iteración de las metodologías ágiles nos permiten entregar valor al cliente con rapidez y calidad. Y, en relación al punto anterior, las técnicas de Lean / Agile UX nos permiten conjugar los beneficios de un diseño integral con una implementación incremental.

Comercialización

En general Product Management no se ocupa de implementar programas y actividades de go-to-market: esa es la función del equipo de Marketing/Ventas (o de Growth Hacking, según la terminología al uso).

Pero lo que sí es responsabilidad del Product Manager es proporcionar a Marketing/Ventas todo el contexto de producto necesario para que estos puedan crear sus programas y campañas, habilitarles con el conocimiento de producto necesario para que puedan desarrollar sus tareas y colaborar con ellos en actividades específicas relacionadas con el producto. (Cuando la función de gestión de producto se reparte entre varios puestos, ésta es la misión específica del Product Marketing Manager).

Product Management debe aportar los siguientes resultados:

• Segmentos outbound de mercado, personas de comprador con sus necesidades, objetivos y escenarios de compra.
• Estrategia y procesos comerciales escalables y alineados con los procesos de compra, para crear una “máquina de fabricar clientes”.
• Posicionamientos y arquitectura de mensajes para los diferentes segmentos y personas, centrados en los problemas de mercado y en el valor para el cliente.
• Herramientas de marketing y ventas que den soporte a esos procesos comerciales y ayuden a crear la experiencia de compra deseada: argumentarios, comparativas respecto a la competencia, presentaciones y demostraciones de producto, referencias…

Estrategia de producto

La transición a filosofías más ágiles e iterativas no debe ser la excusa para carecer de una estrategia de producto que se alinee con la estrategia de la empresa y sea sinérgica con los restantes productos de la cartera. Pero obviamente esta estrategia no debe traducirse en un plan para ejecutar de manera inflexible, sino en un plan para aprender y descubrir nuevos mercados.

La plasmación de la estrategia de producto lo constituye un nuevo tipo de roadmap de producto, más ágil y centrado en el mercado. Frente a los roadmaps tradicionales, constituidos por  listas de funcionalidades y especificaciones técnicas y que reflejan los objetivos de stakeholders internos, el nuevo roadmap debe basarse en una lista de los problemas de mercado y objetivos de cliente que aspiramos a resolver. Pero considerados no como un compromiso ineludible o un plan inexorable, sino como un backlog priorizado de oportunidades de mercado que vayan alimentando y constituyan el input de nuestro proceso de descubrimiento y validación.

Medida y control

Si queremos gestionar el producto como un negocio es imprescindible disponer de una serie de métricas que nos permitan supervisar, analizar y optimizar continuamente su rendimiento en todas las dimensiones relevantes para garantizar el éxito del producto.

No basta con limitarnos a unas métricas de funnel (como por ejemplo, las famosas “Métricas para Piratas”, tan aplicadas en productos digitales): en cada fase del ciclo de vida hay que definir un scorecard de producto que incorpore métricas adecuadas (accesibles, auditables, accionables) en áreas como los objetivos de negocio, el go-to-market, la habilitación de la organización o la calidad del producto.

El post “Necesitamos un nuevo Product Management (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.]