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