Cómo ponerle el precio a un producto software
Creo que uno de los errores más comunes que he visto cometer a los emprendedores del sofware es la metodología empleada para ponerle precio a su producto. Yo mismo he cometido errores de “pricing” suficientes veces como para darle un repaso por escrito a las lecciones aprendidas.
Para empezar creo que el error más frecuente es asignar un precio al producto que está de alguna manera relacionado con lo que cuesta fabricarlo, o con las cifras de clientes y precios que se ven bonitas en el business plan. Idealmente debería haber dos equipos en una empresa, el de las personas que se dedican a fabricar el producto sin tener ni idea de cuánto podría valer en el mercado, y el equipo de personas dedicadas a hallar el valor de mercado y explotarlo sin saber en absoluto de costes de producción, y en una segunda ronda, si resulta que los resultados de ambos estudios de costes y beneficios son compatibles, entonces y sólo entonces hay que lanzar el producto al mercado.
Los productos hay que venderlos por el valor que percibe el cliente que tienen, no por el coste de producción más un margen o cualquier otro método de estudio de mercado. El valor que percibe el cliente no es el valor real del software. El software tiene valores diferentes para clientes diferentes dependiendo de su poder de comprar. Incluso para el mismo cliente el mismo software puede tener valores muy diferentes dependiendo del momento del tiempo. Hubo unos años durante la primera burbuja de Internet en los cuales cualquier producto que prometiera servir para “ganar la web” se vendía más caro que el oro. La teoría económica dice que los clientes perciben el valor usando puntos de referencia, como los precios del software de la competencia, o incluso el precio de otros productos de tu mismo catálogo que ya conocen bien. En la realidad es mucho más lucrativo vender a los clientes que tienen dinero y están asustados. Normalmente dicha situación se produce durante las burbujas, cuando amordazan al responsable de compras y lo encierran en el sótano.
Para obtener el máximo beneficio económico con la venta de un producto, en teoría, hay que usar una curva de demanda junto con una segmentación adecuada de clientes. Hay una buena explicación de ambas cosas en el artículo Camels and Rubber Duckies de Joel Spolsky (2004). En resumen la curva de demanda indica cuántos clientes comprarían el producto a un precio dado. Además, la segmentación, es una técnica complementaria para cobrar más al cliente que más puede pagar y ofrecer ofertas a los de menor poder adquisitivo, para de ese modo exprimir hasta el último céntimo de todos ellos. La segmentación aplicada al software suele traducirse en versionado, estilo Windows Home vs. Windows Business o a una variante que a mi me gusta aún más: el core wrapping.
Un buen versionado incrementará el beneficio, aunque llevado a extremos, como el que explica Spolsky en su artículo, puede llevar a productos cuyo precio oficial es imposible de obtener por ninguna parte dado que la estrategia comercial del fabricante es realmente y únicamente meterle el rejón pueda a quien pueda. Ya he comentado en posts anteriores que gran parte del negocio del software va precisamente de trincar y tirar. Lo cual me conduce a otro error común, la falta de percepción del valor actual neto de una venta. El software que da dinero no está pensado para que el cliente lo pague una vez y lo use para siempre, esta pensado para que lo pague una vez y otra y otra y otra y lo siga pagando y pagando y pagando… El software no son sólo bytes sino que incluye muchas otras cosas como mantenimiento evolutivo, soporte a incidencias, etc. Aunque tampoco hay que caer en el error de pensar que el software es sólo servicios y soporte que fue el que hizo a muchos fabricantes Open Source volver al modelo de licencias.
Otra cosa que, en general, creo que no se debe hacer con una startup es seguir una estrategia de ofrecer el producto de más bajo coste para el cliente, a menos, claro está que la disrupción esté en el precio, lo cual no suele ser el caso. Hay emprendedores que creen que lanzar productos “low cost” es bueno porque ellos no tienen mucho dinero y echan en falta productos baratos que les resulten asequibles. Incluso hay inversores a quienes les gustan los productos low cost porque en una coyuntura económica desfavorable como la actual son los que tienen mejor salida al mercado o incluso los únicos con salida. Tengo, en general, una opinión desfavorable sobre el low cost por dos motivos: 1º) porque para cobrar poco hay que tener muchos clientes, invertir una burrada en marketing y dar un servicio pésimo, circunstancias ninguna de las tres que suelan darse en una startup; y 2º) porque vendiendo low cost se pierde la posibilidad de exprimir el jugo a la gama alta del mercado donde se concentran los clientes de mayor poder adquisitivo. Haciendo cualquier pequeño estudio de mercado es fácil comprobar que hay muchos productos por debajo de 1.000€/año y también bastante, aunque no tantos, por encima de los 30.000€/año pero la franja entre 1.000€ y 30.000€ (en EE.UU. es entre 3.000$ y 75.000$) está prácticamente desierta porque los gastos comerciales de la venta B2B son tan elevados que impiden ofrecer ningún producto por debajo de varias decenas de miles la unidad. La venta a grandes corporaciones es todo un arte que merecería un post en si misma, pero en esta ocasión sólo me detendré en un aspecto concreto. Las grandes empresas cuentan con compradores expertos en negociar hasta el último centimo a la baja. He visto a lo largo de mi carrera muchos contratos que eran fabulosos en el volumen pero ridículos en los márgenes, sobre todo por la comisión del comercial suele ir ligada a la cifra de venta y no al margen neto. Además, los sicarios de una mesa de compras son auténticos profesionales de las maniobras para pagar menos. Spolsky comenta la de esperar al último día del trimestre, o del año, cuando saben que necesitas su compra para redondear tus cuentas y entonces pedir un descuento. Pero hay otras aún peores, como aplazar los plazos de pago sin previo aviso y de un plumazo, o incluso anunciar que compraran sólo a menor precio si se enteran de que dependes de ellos para sobrevivir, dejando al proveedor a margen cero en un estado de empresa zombie en la cual no quiebra pero tampoco obtiene ningún beneficio neto.
Por último, por las tendencias actuales, es inevitable comentar el caso del software como servicio. Ya he comentado con anterioridad que, en mi opinión, el cash flow del software como servicio es malo, y se necesita tener un bolsillo bastante más profundo de lo que parece a primera vista para soportar el tirón de lanzamiento de un SaaS. Pero, yendo a lo práctico, dos cosas a tener en cuenta: 1ª) en muchas empresas da lo mismo 29€/mes que 99€/mes de igual manera que no importa si un billete Madrid-Barcelona les cuesta 90€ o 200€ porque un software que no genera 60€/mes de valor o un viaje que no sirve para ganar +110€ no vale la pena hacerlo; y 2ª) pese a que el precio mensual pueda ser muy variable a veces no es lo mismo 600€ que 900€ porque 600 puede ser el límite de la tarjeta de crédito de la empresa exento de explicaciones detalladas a compras.
Más información: vale la pena leer el eBook gratuito Don’t just roll the dice the Neil Davidson si te encuentras en el proceso de ponerle precio a tu software.
El estado del arte del software 2012
Creo que cada semana –aproximadamente– alguien me pregunta si conozco algún desarrollador de aplicaciones para móviles. Iba a hacer un repaso de las tecnologías que estarán están de moda en 2012, pero podría resumir lo esencial en tres palabras: móviles, móviles, móviles… Casi el único dilema es si desarrollar las aplicaciones en los novísimos (y complejos) HTML5+CSS3 o tirar de API nativos para aprovechar a tope las características de cada dispositivo, o tirar por la vía de en medio escribiendo aplicaciones híbridas cuando ello es posible. En los móviles se incluyen por descontado los tablets y sus nuevas posibilidades de interfaz de usuario ¡por fín! gracias a Dios, nos hemos desecho del ratón, ese artilugio del siglo pasado, a ver si hay suerte y a lo largo de esta década nos deshacemos también del vetusto QWERTY del XIX.
De la mano de las aplicaciones móviles han llegado el fenómeno de la “appificación” y las tiendas de aplicaciones privativas.
Es indicativo de las tendencias que en el ßetabeers del 13 de enero (el evento de moda de los desarrolladores en España) las tres aplicaciones presentadas fuesen una app de música para móviles, una herramienta de marketing online basada en gamification, y un componente SaaS para ejecutar acciones de marketing y comercio electrónico. Google hace ya tiempo que lanzó “los APIs de tu vida“, pero, además, rediseñó el API de Google Maps (entre otros) en su versión 3 para adaptarlo al uso en móviles aún a costa de ir hacia atrás en algunas funcionalidades ofrecidas por la versión 2 del mismo API.
En el entorno empresarial, hay tres trendencias que creo que vale la pena observar: la integración contínua, PaaS y clouds híbridos.
La integración contínua se originó ya hace tiempo de la necesidad de automatizar los tediosos procesos de hacer builds de software y ejecutar pruebas de humo de manera repetitiva. Sin duda, la era del lanzamiento semestral, anual o plurianual de versiones, es historia, y ahora lo habitual es sacar una nueva vesión cada dos o tres semanas en sprints Scrum. Pero las herramientas como Jenkins se están usando también cada vez más para integrar datos mediante ETLs. Personalmente, opino que los web services nacieron muertos debido a lo complejo que resulta implementarlos, y han sido substituidos por servicios HTTP REST más sencillos. Las SOA ya estaban pasadas de moda en 2006 debido a que prometían, en principio, integrar aplicaciones heterogéneas pero resolvían sólo una parte del problema, el transporte de datos mediante un bus; dejando muchas herramientas sin cubrir la parte a menudo más compleja, que es la traducción semántica de los datos entre las aplicaciones. Los data mash ups como Denodo también tuvieron su hype pero tampoco parece que hayan acabado de cuajar del todo. Al final del día lo que la mayoría de las empresas necesitan son pequeños procesos que muevan datos de una aplicación a otra, que se puedan ejecutar y monitorizar fácilmente a diario y que resulten sencillos de mantener evolutivamente.
El PaaS (Platform as a Service) es una respuesta evolutiva a las devops. Desplegar aplicaciones se había convertido en tal carajal que empezaron a buscarse perfiles profesionales que tuviesen competencias tanto de desarrollador de software como de administrador de sistemas para que pudiese depositarse en la misma persona la responsabilidad de coordinar ambas tareas. Pero como siempre, las soluciones basadas en usar materia gris de calidad para resolver un problema son caras y difíciles, puesto que tal tipo de materia escasea. La idea del PaaS es que el programador pueda escribir su aplicación en un entorno de desarrollo que es completamente indistingible del entorno de producción –excepto por su escalabilidad– y, además, mover la aplicación de un entorno a otro de forma totalmente automatizada y sin riesgo de errores.
El PaaS puede apoyarse en los clouds híbridos, los cuales pueden serlo en dos sentidos: a) empezar con un cloud privado que luego se externaliza, o b) empezar con una infraestrutura externa tipo Z Cloud y luego traérsela “in-house” para abaratar costes y conocer con más exactitud la disponibilidad y calidad del servicio.
Hispalinux: "Megaupload: la TV China"
The FreeNet Project, una red anti SOPA y Sinde
El modelo de “software extraído”
Suele ser la tónica habitual que los desarrollos de software realizados a medida se queden en propiedad del cliente. En realidad, da igual si se quedan o no, porque lo que se desarrolla suele estar hecho tan a medida que es imposible en la práctica reutilizarlo en otro sitio. Más aún, yo he visto muchos proyectos de software desarrollado internamente con la intención de venderlo también fuera después y casi siempre es un fracaso. Existen algunas excepciones, por ejemplo Stephen O’Grady menciona en un post cómo la base de datos IMS de IBM surgió del Programa Apolo de la NASA, a esto O’Grady lo denomina el modelo del software extraído.
El modelo del software extraído es extraordinariamente atractivo para el emprendedor ya que es una alternativa a la financiación de capital riesgo. Es por ello que repasaré a continuación en qué se basa.
1º) Un cliente no va a hacer un desarrollo a medida parecida a ningún software estándar que ya esté en el mercado. Entonces, mi primera idea es que no se puede “extraer software” de un nicho de mercado que ya esté “commoditizado”.
2º) Para que un proyecto a medida se apruebe internamente, debe proporcionar una ventaja competitiva muy clara, o, alternativamente solucionar un problema muy perentorio y preocupante. Ello suele conseguirse mediante el empleo de alguna novedosa tecnología o técnica procedimental. Segunda idea pues, no se puede extraer software empleando sólo tecnología madura. No quiero decir con ello en absoluto que lo contrario sea cierto, que sólo se deba emplear tecnología experimental. Nosotros mismos hemos extraído mucho software Java y .NET, es más, resulta más sencillo extraer Java o .NET que extraer Ruby o Python. Lo que sí sucedía es que dicho software además de estar escrito en un lenguaje maduro, contenía innovaciones técnicas y de proceso de negocio que sí eran claramente diferenciales.
3º) El proyecto debe empezar por algo pequeño por lo que sólo un puñado de gente apueste un céntimo y, si el piloto tiene éxito, entonces extenderlo rápidamente. Esto es porque si el software a extraer empieza con un megaproyecto de alcance corporativo entonces empezarán a implicarse demasiados departamentos cada uno arrimando el ascua a su sardina y al final lo que salga será un híbrido que hará todo pero no servirá para nada por ser el fruto de que en comercial querían un Ferrari y en producción querían una furgoneta. Además, si el proyecto es grande, se convertirá en objetivo de los tiburones de consultoría quienes argumentarán que es demasiado grande e importante como para que lo haga una startup.
4º) El cliente debe ganar más cediendo el software al proveedor que manteniéndolo él mismo en solitario. Hay varias formas de regular esto. Cliente y proveedor podrían pactar un acuerdo de reparto de beneficios por la venta. Pero yo creo que lo mejor es persuadir al cliente de que se quede con una parte y permita que el proveedor tome propiedad del resto con la condición de liberarlo como Open Source. Esto es porque a fin de cuentas el negocio del cliente no es vender software, ergo un acuerdo de reparto de royalties puede provocar que la agenda de desarrollo y comercialización de futuras versiones dependa de intereses del cliente contrarios a los del proveedor.
5º) Los competidores deben de poder adoptar el software sin que ello resulte lesivo para ninguna de las partes. Se suele tener mucho miedo de que la competencia copie mejores prácticas, y es una preocupación razonable. La mala noticia es que lo van a hacer de todas formas. Ninguna ventaja competitiva ganada invirtiendo en tecnología dura para siempre. La única oportunidad que tiene el primer cliente es la de llevarle entre 3 y 5 años de ventaja a la competencia en cuestiones de eficiencia tecnológica. Por otro lado, el ecosistema de clientes debe de ser de tal naturaleza que les permita compartir software. Compatir secretos técnicos siempre parece a priori del todo inviable, pero recordemos que hasta las armas más modernas están disponibles en el mercado para quien pueda pagar su alto precio.
6º) El software debe estar diseñado, desarrollado e implantado desde el principio para extraerlo. Ello implica que debe ser más modular de lo que sería un software a medida estrechamente acoplado a las necesidades del cliente. Y también que todos los interfaces entre los módulos deben de estar totalmente exentos de “dependencias raras”. Por último, hay que hace run esfuerzo mayor en generar documentación durante el proceso de desarrollo que sirva como guía para los implantadores que vendrán detrás.
Si se cumplen las condiciones anteriores, el software extraído puede ser una forma fantástica de lanzar una empresa porque cuando el primer proyecto termina, la startup tiene:
1º) Una estructura de costes que se autofinancia con los ingresos del cliente.
2º) Un producto terminado.
3º) Una referencia comercial importante.
4º) Cero deuda.
Sólo hay que tener cuidado con una cosa más, cuando termina el proyecto del primer cliente, hay que reducir los gastos al mínimo, siendo frecuentemente necesario reducir plantilla (a veces es posible hacerlo fácilmente traspasándo mano de obra al cliente). Esto es debido a que aunque la startup sepa cómo fabricar software y ponerlo a funcionar, corre el peligro de escalar demasiado pronto cuando aún desconoce otros aspectos clave por ejemplo sobre cómo contratar comerciales y hacer marketing para ganar prospectos. Tras el primer proyecto exitoso puede ser un buen momento para coger deuda, pero dicha deuda no debe utilizarse para mantener a un equipo sobredimensionado de programadores ociosos mientras esperan a que alguien cierre la siguiente venta.
