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