Categoría: Product Management

Product Briefing

~ Diego Mariño

A menudo recibo «preguntas del millón» para las que no tengo respuesta. «¿Dónde encuentro (cerca de este código postal, a poder ser) product managers con años de experiencia, solvencia técnica y sensibilidad comercial?, suele ser una de las más escuchadas. Otra es: «¿cómo transiciono mi empresa que ha sobrevivido a base de consultoría+licencias a ser una empresa de producto?». Y sobre las respuestas a esta pregunta vamos a hablar hoy.

Lamentablemente, por si alguno quiere ahorrarse minutos de lectura, no hay una respuesta generalmente válida para todas las empresas que quieran pasar por este trance. Cada cultura y organización son un mundo que requieren ser entendidos en detalle en su contexto. No hay balas de plata, más allá de recordar que no hay transición sin fricción, y por tanto daños. Por tanto, think it twice. La hierba verde del vecino, el cementerio lleno de empresas de consultoría rentables que un día empezaron a soñar con la escalabilidad a coste marginal nulo y todo eso.

Así que en estas ocasiones en las que alguien se acerca preguntando :»¿cómo puedo acabar teniendo ‘una empresa de producto'», mi respuesta (gallega, por supuesto) es: «¿por qué no empiezas escribiendo un product briefing?».

Así que aquí viene una aproximación rápida, con el necesario disclaimer de que uno tiene su experiencia en el fascinante mundo del SaaS B2B y para otros sectores/modelos todo probablemente sea muy diferente.

¿Qué es un “product briefing”?

Llamaremos “product briefing” (PB) a un documento que resume la estrategia y planificación detrás de un producto, con un formato y contenido dirigidos a ser consumidos por cualquier empleado o stakeholder.

Su principal objetivo es responder a cualquier pregunta derivada de:

¿Por qué es un buen uso de los recursos de la empresa el trabajar en este producto (o gran funcionalidad) de este modo en este momento?

El PB debiera mantenerse actualizado con mínimos cambios, pero sería muy mala señal necesitar a menudo cambiar el contenido (bien porque el documento se ha compartido mucho antes de tener resueltas incógnitas relevantes, bien porque la dirección de producto es demasiado inestable manteniendo las decisiones acordadas).

Las principales ventajas que se obtienen de escribir un PB son:

  1. Obliga al liderazgo de producto a sintetizar sus ideas estratégicas en un único documento.
  2. El PB nos permite compartir esta estrategia con toda la organización para alinearla hacia los objetivos.
  3. El hecho de sintetizar y compartir esta estrategia reduce en magnitudes los «conflictos políticos internos» a gestionar. Ya tú sabes.

¿Qué *no* es un Product Briefing?

Al ser principalmente un documento que recoge las decisiones estratégicas y ser de lectura transversal, deberíamos evitar sumergirnos demasiado en detalles irrelevantes para el conjunto de la organización.

En general, debiera siempre mantener la mínima información indispensable y útil para toda la organización, y enlazar a documentos más detallados cuando sea necesario.

Un PB está pensado para sintetizar la estrategia a nivel de producto. Como documentos previos a implementar diferentes funcionalidades, en Basecamp, Intercom o Drift tienen buenos ejemplos (que no dejan de tener objetivos similares pero a otra escala más táctica).

Contenido

El contenido varía por empresa/producto, pero debería estar orientado a responder a la pregunta remarcada en el punto anterior: “¿por qué es un buen uso de los recursos de la empresa el trabajar en este producto (o gran funcionalidad) de este modo en este momento?”. O mejor dicho: debería estar orientado a responder y además a convencer.

Changelog

Al principio del documento, presuponiendo que no estará en un formato como Markdown que nos permita seguir los cambios en un repositorio de código, debiéramos tener una tabla que nos muestre tanto la fecha y responsable de la última actualización del documento, así como los estados por los que ha ido pasando.

Por tanto, se recomienda añadir una tabla como la siguiente e ir actualizándola con cada cambio de estado o modificación relevante en el mismo:

FechaEditorComentario
 … … …
 … … …
………

Nota de Prensa

Es una buena idea para sintetizar el contenido del PB el redactar una nota de prensa anunciando el lanzamiento de los objetivos marcados, dado que en un par de párrafos podemos dar respuesta a los principales elementos de un PB (¿qué se anuncia?,¿cuándo está previsto publicarla?,¿a quién interesa?,¿qué ofrece?, ¿por qué es relevante?, etc).

Contenido estratégico

A nivel estratégico el PB debería, como mínimo, responder a las siguientes preguntas:

  • ¿Por qué invertimos en construir este producto? – Recordando la máxima del product management “Only build solutions for problems that are urgent, pervasive and that the market will pay to solve”, el documento debería transmitir (y convencer) a su audiencia que el camino propuesto es el que retorna los mayores beneficios posibles, ya que cumple los principios de urgencia, generalidad y está orientado a clientes con capacidad de compra. Confío en que a vuestra edad ya sepáis que una empresa es lo que puede llegar a ser rentable gracias a producir, y no el envoltorio que necesitamos para poner un producto en el mercado. Que no es lo mismo, ni parecido.
  • ¿Qué necesidades resuelve? – En lugar de orientar el contenido a mostrar las principales funcionalidades, deberíamos orientarlo a detallar los principales problemas que tendría que resolver.
  • ¿Qué no hace este producto? ¿Qué hemos decidido no ofrecer jamás? – En el mundo real, trabajamos con restricciones. La principal ventaja de tenerlas es que evitan revisar continuamente opciones, y ayudan mucho a posicionarnos en un mercado (o contra soluciones alternativas). Ejemplos de restricciones serían “en nuestro SaaS nunca ofreceremos una versión on-premise” o “únicamente ofreceremos una API para interactuar con nuestro servicio”.
  • ¿Cómo se alinea este trabajo con los objetivos de la empresa? – El producto desarrollado, no deja de ser un medio para conseguir los objetivos corporativos. Por tanto, hemos de concretar para qué objetivos, iniciativas o proyectos estamos invirtiendo, y cómo esperamos ayudar a conseguir esos objetivos. Quizá otro día tocará escribir sobre objetivos>iniciativas>proyectos>tareas.
  • ¿Cómo sabremos si tiene éxito? ¿Cómo definimos lo que consideramos éxito a corto/medio/largo plazo? – A la hora de iniciar cualquier actividad, hemos de definir (al menos) una métrica que nos permita visualizar el éxito o no del trabajo que vamos desarrollando, para poder tomar decisiones que cambien el rumbo, o incluso cancelarlo. Además, estas métricas pueden variar a lo largo del tiempo. Por ejemplo: si lanzamos un producto, a corto plazo puede ser un indicativo de éxito el número de clientes conseguidos, a medio plazo llegar a cierto nivel de facturación, y a largo plazo el porcentaje de mercado capturado.
  • ¿Cómo nos posicionamos en el mercado? – En el apartado siguiente se detallará este punto, pero convendría tener concretado el posicionamiento estratégico en el mercado: a cuál nos dirigimos, cómo lo satisfacemos, cómo lo distribuimos, etc.

Contenido práctico

A nivel más práctico el PB debería cubrir (al menos) los siguientes puntos:

KPIs

  • Listado de las métricas más relevantes que se monitorizarán. En cada una de ellas, detallar los segmentos y objetivos actuales acordados (si los hubiera).

Al ser el PB un documento relativamente estático, tiene mucho sentido aquí enlazar a otro documento (como por ejemplo el plan de instrumentación) para acceder a todos los detalles detrás de las mismas.

Marketing

  • Definición del mercado y los segmentos a los que nos dirigimos . Recordad aquí que el que segmenta el mercado por variables demográficas y no por necesidades es un parguela.
  • Entorno competitivo (solo para empresas de un único producto), e idealmente un análisis resumido de las 5 fuerzas de Porter.
  • Comparativa contra competidores
    • Listado de empresas consideradas competencia directa y análisis de los principales puntos que se resaltarán contra ellos.
    • Enlace a un análisis detallado comparando funcionalidad.

Personas y casos de uso:

  • Listado de personas que vayan a usar el producto unido a lo que esperan conseguir/satisfacer con el mismo. Para cada una de estas personas, debiéramos responder: ¿qué usaba hasta ahora?, ¿cómo se le manifestaba el dolor?, ¿cuál es nuestra competencia directa?.
  • Listado de personas que no vayan a usar el producto, pero cuyos requisitos hemos de incorporar al mismo.
    • Por ejemplo, es posible que un producto digital no lo vaya a usar el CISO de una organización, pero su aprobación en base a ciertas funcionalidades del producto es crítica para poder ser usado.

Listado de principales necesidades que solventará el producto

  • Intencionadamente, no es una lista de funcionalidades, sino de necesidades (dado que la funcionalidad será detallada más adelante por los diferentes equipos que trabajen en la misma).

Por ejemplo, una necesidad por solventar podría ser “el poder exportar datos” del producto porque el cliente tiene la necesidad de importarlos a otra solución. Si hoy decidiésemos que la funcionalidad es “Exportar a CSV” estaríamos obviando otras quizá también necesarias como “Actualizar Google Sheets”.

Roadmap sugerido

  • Principales necesidades que solventará, en un escenario temporal estimado.
  • Enlace al roadmap detallado que se comparte internamente con la organización.

Principales dependencias del proyecto

  • Tanto internas como externas (si fuese necesario).

Aquí hablaríamos de coordinar el trabajo de diferentes equipos internos, si alguna parte del trabajo podría llegar a ser un bloqueo (y a priori que alternativas se plantean), etc.

Resumen y enlace a los diferentes planes:

  • Plan de desarrollo
  • Plan de lanzamiento
  • Plan comercial
  • …

Concluyendo

Como he dicho arriba, cada empresa es un mundo y manteniendo el objetivo de sintetizar y compartir las ideas del liderazgo de producto utilizando un documento que permita convencer a la organización de que se están tomando decisiones meditadas (y ojalá acertadas).

Para mí, la mejor prueba de que se tiene una cultura de producto sana y alineada (o de que un Product Manager está haciendo correctamente su trabajo) es cuando no hay reparos en decir «no» a una petición. Si un lead o cliente importante, (o hasta un equipo de desarrollo), solicita incluir algo en el roadmap y no hay reparos en negarse porque todos tenemos claro que «no sería un buen uso de los recursos el trabajar en eso ahora», señal de que vamos por el buen camino. Y ojalá lo veamos.

Tres negocios para un proyecto

~ Diego Mariño ~ 1 comentario

Una de mis taras mentales más grandes es que creo que para cada producto hay un mercado. Estará escondido, o será reducido. Igual es complejo de encontrar o está en nuestras antípodas geográficas y culturales (“It’s hugely popular in Indonesia!”), pero algo me dice que hagas lo que hagas siempre tendrás la oportunidad de encontrar un puchero rebosante de oro al final del arco iris.

– «¿A qué no encuentras la forma de vender bolsas de hielo en el polo norte?».
– «Sujétame el cubata».

Y te pones a pensar en casos de uso, dolores y necesidades, si realmente aunque creamos que el hielo allá arriba es omnipresente en algunos casos no lo es, etc. Ya avisé al principio de que era una tara. Y bastante entretenida, por cierto.

Pensar así es un problema, porque te has de recordar a menudo que encontrar resultados no está en absoluto relacionado con la rentabilidad de la iniciativa. Hay una gran diferencia entre tener éxito y tener razón… más o menos la misma que hay entre darse cabezazos machacando el mismo sector con la misma estrategia y enfoque durante años, o ajustar las velas hasta que te sangren los dedos de contar billetes. Porque, otra de las cosas en las que también creo es que si te vas a dejar la salud, las pestañas y las relaciones tras una iniciativa empresarial, al menos asegúrate de que tenga un gran potencial de retorno. De esas en las que hasta el último becario acaba gestionando su patrimonio desde Luxemburgo. De las que molan.

¿Y toda esta introducción a qué viene? A que a menudo ves startups con tecnologías impresionantes arrastrándose por sobrevivir. Y no dejas de pensar, benditas taras, en que quizá con algún pequeño cambio que nos acerque a la principal máxima de la gestión de producto («Only build solutions for problems that are urgent, pervasive and that the market will pay to solve«), podrían cambiar la tradición cultural de los viernes del «friday casual» a «los viernes al acabar tenemos sobredosis de percebes y raro es el día en que no vienen tres ambulancias».

Imagen motivacional absurda y obtenida de los internecs, puesta expresamente para reducir el bounce-rate entre el público millenial. Que llevábamos ya demasiados párrafos seguidos.

Hace años que en algunas de las presentaciones que hago pongo como ejemplo el mercado de informar sobre qué tecnologías se están usando en una web. Y la base tecnológica para servir el mercado es sencillo:

  1. Visitamos un dominio
  2. Descargamos y parseamos el contenido de sus HTMLs (y cabeceras!) para ver qué librerías se están cargando o qué tecnologías se están usando
  3. Comparamos esos resultados contra un diccionario. Por ejemplo, si en una web se está cargando «https://www.google-analytics.com/analytics.js» podemos asegurar que utiliza «Google Analytics».

Sobre esta base tecnológica podemos analizar el cómo la están llevando al mercado 3 empresas diferentes. O mejor, cómo la llevaban al mercado hace unos años (que no he seguido sus trayectorías actualizando la presentación, pero como ejemplos nos valen). Estos screenshots que os pongo ya han envejecido. </disclaimer>

En primer lugar, tenemos a Wappalyzer. Que curiosamente en estos años no ha cambiado su claim: «Identify technology on websites». 🤔

Es un servicio tremendamente útil si por ejemplo, estás leyendo este blog y te preguntas: «¿Qué tecnologías tendrá detrás?». Así que te instalas una extensión para el navegador, y ya puedes dormir tranquilo.

¿Cómo se podría monetizar algo así? ¿Suscripción para tener un número de checks al mes? ¿Micropagos? ¿Cómo de grande es el mercado de geeks con impulsos para comprobar las tecnologías detrás de una web (y necesitar un servicio para ello)? Hace unos años en su web pedían donaciones, aunque acabo de comprobar que ahora tienen planes en su web para recibir informes de sitios enviados por API o CSV (aunque los precios para este mercado global los tienen en dólares australianos 🤦🏽‍♀️).

El siguiente en la lista es un clásico: Builtwith. El claim tampoco ha cambiado en estos años, pero en su portada ya salía un concepto interesante: «lead generation».

Nosotros en la patoaventura, allá por el 2013, lo usábamos de vez en cuando para hacer outbound. «Dame un listado de webs que se gasten el dinero en estas 3 tecnologías, que así afinamos el tiro para ir a vender paneles para consolidar datos de esos servicios». Si mal no recuerdo, cada informe nos costaba $300 y los planes con esos servicios tenían un LTV cercano a los $3.000… así que hacíamos negocio todos. En 2015 salió la noticia de que el fundador, él solo, sin empleados ni perro que le ladre, se facturaba más de $1M al mes. Supongo que cuando te has aburrido de contar billetes, dejas saltar esa cifra para que se te embarre el mercado y poder dedicarte a otra cosa. Bendito aburrimiento.

Y finalmente, el tercer ejemplo es el de Datanyze. Salieron al mercado en 2014 definiéndose como el «Google of sales and marketing» (puaj!), y levantaron una ronda seed de $2M que les sirvió para, IMHO, hacer una cosa mala y una muy buena:

La mala: intentar crearte un segmento de mercado en el que estás tu sólo… «Somos unos visionarios liderando el vertical de technographics!!! Hooray!!!
La buena: sintentizar la propuesta de valor en algo tan apetecible como «te voy a avisar en cuanto uno de tus clientes empiece a probar la herramienta de un competidor». ¿Qué «vipí of seils» de cualquier tecnológica se negaría a contratar un producto así? Le pones un envoltorio «corporate» a esta propuesta y a contar billetes. O mejor aún: que te los cuenten, que te lo puedes permitir.

Recapitulemos, que esto se acaba. Tenemos una base tecnológica común: parsear el contenido de webs para conocer que tecnologías usan. Y tenemos 3 formas de paquetizar esa tecnología para tres casos de uso:

  1. Necesito ir comprobando a demanda las tecnologías de las webs que visitas. Con un mercado menos claro que el modelo de ingresos.
  2. Necesito leads, razonablemente cualificados, para nutrir a mis equipos de venta en acciones outbound.
  3. Necesito que se me avise cuando uno de mis cliente empiece a utilizar la tecnología de un competidor.

Y 2 consejos:

  1. Nunca seáis el primer ejemplo.
  2. Piensa bien en los recursos qué tienes antes de escoger el camino. Recursos de todo tipo: conocimientos, contactos, equipo y capacidades, inversión necesaria… Hay muchos caminos buenos y rentables, pero empezar uno que no puedes recorrer es tan malo como invertir horas en hacer un trabajo valioso para acabar pidiendo donaciones.

Y poco más. Si estás en una situación de esas en las que crees que tienes «un buen producto»* pero las ventas no acaban de arrancar, revisa las necesidades que estás satisfaciendo (si hay alguna) y empieza a observar casos de uso cercanos (aunque sea en otros mercados). O cualquier otra cosa menos seguir persistiendo en el error. Volviendo a la imagen original, la experiencia me dice que los que acaban encontrando diamantes tras años y años de picar son la excepción: normalmente, cuando se hacen las cosas bien, los diamantes se encuentran a los pocos metros. Y si crees que no tengo razón, revisa tu sesgo de supervivencia 🙂

[*] Un buen producto, por definición, resuelve una necesidad en un mercado. Si un producto no lo hace, no es bueno… por mucho framework de JS sobredimensionado que le pongas encima.

Charla en el ProductHackers Day

~ Diego Mariño

El pasado 4 de Julio pude (al fin!) ir a contar batallitas al ProductHackers Day (que me parece es de lejos el evento más grande para product managers de España).

30 minutos no dan para mucho, pero creo que pude transmitir lo diferente que es ser product manager en tu startup (donde la única limitación son tus recursos) a serlo en una gran empresa (donde la principal limitación es tu capacidad de generar consensos de trabajo). Por si no quedó claro en mi charla, creo que es mejor ser decisor final con pocos recursos que no serlo con recursos y magnitudes ilimitadas.

Al final recomiendo 3 libros que, sin ser propiamente de gestión de producto, son en conjunto el mejor compendio que he encontrado para encontrar respuestas en esta profesión. Y curiosamente, todos siguen vigentes más de 30 años después de haberse escrito:

Curso de Instrumentación en Santiago

~ Diego Mariño ~ Deja un comentario

Entre las ideas que hemos comentado mil millones veces los del sector tecnológico gallego, está la de «juntarnos para compartir conocimientos» más a menudo. Parece obvio, pero estando divididos entre 3 ciudades, y con focos diferentes (unos más a consultoría para cierta empresa textil de las afueras, y otros más a investigación de la mano de la universidad -por resumir mal la situación-), es complicado hacerlo.

Lo de juntarnos para recibir formación parece que puede solucionar un poco que nos veamos más (al menos es mejor excusa que simplemente unas cervezas o una charla), por lo desde Startup Galicia se han puesto manos a la obra para arrancarlo. Empiezo yo con instrumentación de producto (el contenido será el de esta presentación pero más detallado y práctico), y supongo que en breve se concretarán las próximas sesiones de gestión de equipos y de recruiting técnico.

Si te interesa es en Santiago, el próximo viernes 5 de Abril de 10 a 14h. Y como no voy a ver un céntimo, el precio es de 48 eur + comisiones para cubrir costes. Vamos, un regalazo.

Hemos arriesgado con decisiones fuera de lo común (por la mañana, en laborable, cobrando, y además en una ciudad fantasma 😜), pero creo que va a salir bien.

Así que, compra tu entrada mientras queden (hay muy pocas disponibles, y no se grabará ni habrá streaming).

Finanzas básicas para empresas de producto

~ Diego Mariño ~ Deja un comentario

Hace poco, trabajando con Teimas («o ‘carto’ do lixo»), me hicieron una pregunta que me descolocó dado su casuística especial (no tienen churn):

¿Cuánto deberíamos invertir como máximo en captar a un cliente?

La respuesta gallega es muy sencilla: depende. Dado que su LifeTimeValue es «infinito», yo les recomendé empezar a puerta fría enviando calendarios de esos de tener sobre el escritorio (como se ha hecho en España toda la vida el marketing directo), y si no funcionaba subir la apuesta y enviar un avión privado. O dos, si el tema se alargaba y había que cumplir objetivos de ventas.

Ningún gestor de residuos se resiste a un Gulfstream G650. Palabra.

El problema, es que las respuesta de manual en esta vida no funcionan si quieres ser solvente, por lo que tocaba afinar un poco más.

Empezando porque, aunque ningún cliente se vaya por propia decisión, a veces alguno quiebra. Y luego, quizá haya que tener en cuenta que (en un caso muy muy muy hipotético), puede que algún cliente no les pague lo suficiente como para hacer frente (al menos) a las cuotas del tipo de interés de la financiación del avión. Lo cual puede, en un muy remoto caso que muchos ni se plantearían, llegar a causar algún problema de solvencia, ni que sea parcial. Por ponernos un poco pesimistas.

Así, que para dar una respuesta a una pregunta tan aparentemente sencilla, hay que revisar números entendiendo las diferentes actividades de la empresa. Empezaremos por un framework básico que mis allegados están hartos de verme dibujar:

Este gráfico, que no sólo haría vomitar a una cabra sino también a Michael Porter y a Henry Mintzberg, simplifica bastante la explicación que viene… pero antes un breve disclaimer: IANAL. Ni auditor, contable o inspector de hacienda. Esto sirve para tener en cuenta KPIs, pero por favor, no utilicéis contenido de internet para rellenar una declaración de impuestos sin comprobar antes si lo ha escrito un perro (o un indocumentado). Llamad a un adulto competente antes.

Sigamos pues.

Las empresas, captan en el mercado a otras personas/empresas a las que les venden lo que producen al precio más caro posible, y alrededor de la gente que trabaja hay un grupo especial de personas responsables de «gestionar», que beben cafés de cuatro euros en vaso de cartón y se pasan el día diciendo obviedades mientras saltan de reunión en reunión creyendo que eso es trabajo productivo.

Por otro lado, una forma sencilla de acercarse a las finanzas y de entender de dónde salen los beneficios de una empresa (por ser optimista y porque si hay pérdidas el dibujo se complica) sería:

Aquí ya tenemos que entretenernos con algo más de detalle:

  • Costes Directos: Todos los costes directamente implicados en dar el servicio, o como en su día me lo explicaron para que lo entendiese unos americanos muy majos: todo lo que has prometido en el contrato. ¿Firmaste que el cliente tendría acceso a un servicio 24×7?, pues metes las facturas de infraestructura y los sueldos del equipo de sistemas necesarios para operarlo. ¿Firmaste que tendría soporte rápido y amable?, pues metes soporte también. ¿Firmaste formación? Ídem. ¿Garantizaste por contrato una documentación actualizada? Aquí va. En el gráfico de arriba serían los costes necesarios para mantener las actividades de «mantener» y «ayudar» a los clientes. A la cantidad que queda descontando estos costes, la llamaremos (en aras de ser originales) márgen bruto.
  • Costes indirectos: Por resumir, son todos los demás. Pero los podemos meter en 3 sacos grandes:
    • Ventas y Marketing: sueldos, campañas y herramientas de las actividades de «captar», «vender» y «expandir». A veces la línea es fina entre «ayudar» y «expandir», así que mejor fijar unos criterios pronto porque los necesiraremos. E instrumentar todo bien.
    • I+D: aquí nos fijamos en la actividad de «producir» y ponemos todo lo necesario menos lo que es propiamente mantener (gente de sistemas ligada al entorno de producción y sus facturas de AWS). A futuro sería conveniente ir apuntando quienes son los conflictivos que piden refactorizar continuamente y quienes los competentes que meten líneas de código en el banco, pero hoy no nos importa.
    • Gestión: un saco grande para todo lo demás. Sueldos de gente que pasea, facturas de consultores, coches de renting con motor v12. Lo típico. Vendría bien que tuvieséis una regla clara para imputar y repartir costes de este grupo a futuro, y además tener un auditor de confianza.
  • Cosas de mayores: amortizaciones, cosas extraordinarias, magia contable… nothing to see here
  • Impuestos: obvio

Y finalmente, por no extenderme sobre los ingresos, en todos los ejemplos hablaremos de MRR (por tener un valor normalizado). Si no sabes diferenciar o convertir entre bookings/MRR/revenues/recognition etc, échale un vistazo a este post que es caviar. Y luego vuelves, que lo que sigue es interesante.

Entonces, volviendo a la pregunta original: ¿cuánto deberíamos invertir como máximo en captar a un cliente? Pues saquemos la calculadora:

  • Necesitamos conocer el nuevo MRR por cliente. Dicho de otra manera: un cliente nuevo cerrado este mes, ¿cuánto paga (de media)?
  • Necesitamos conocer nuestro márgen bruto o costes directos (de ahí lo de empezar hablando de actividades de la empresa). No tiene sentido que si hemos de gastar parte de su MRR en darle en servicio, contemos con ese dinero que se va en sysadmins e instancias x-large para otros gastos o inversiones.
  • Necesitamos conocer el churn del mes. Para ello, calcularemos el porcentaje de cuánto MRR hemos perdido por bajas este mes sobre el MRR con el que acabamos el mes anterior.

Ahora ya es sencillo. Los ingresos que creemos nos aportará un cliente nuevo este mes durante toda su vida salen de: (MRR_medio * márgen_bruto) / churn. O con un ejemplo básico, para un plan de 200 euros al mes, de una empresa cualquiera que tiene un margen bruto del 75% y un churn del MRR del 2% este mes, los ingresos que esperamos tener por cliente son de 7.500 euros. Esta empresa no tiene sentido que compre aviones si es necesario para cerrar un contrato, ni un Richard Mille… pero puede enviar un Rolex bien cuco.

O no.

Puede comprar un Rolex, como máximo en casos de verdadera necesidad de cerrar un contrato… pero si te gastas todo el presupuesto disponible en «captar», ¿quién financia el resto de actividades?

Son más de 7.5k euros, pero este humilde servidor de ustedes bien merece que sus lectores se organicen para regalarle un Explorer II modificado por Blaken.

Puedes pensar que un cliente no debiera generar más costes que los inherentes a darle el servicio, por tanto, si el coste márginal de añadirlo es conocido, casi nulo para los costes directos, y bajo para los indirectos, podrías llegar a comprarle por 7.500 euros el peluco y no perder dinero con *ese* cliente. Pero para asegurarte de que tu director financiero no tiene ataques de ansiedad, lo ideal sería no regalar demasiados. O (casi) ninguno. O mejor aún: puedes aprender a usar el dinero de forma eficiente.

¿Hay un número recomendado? Pues no. Como bien demostró PacificCrest hace unos años: hay más formas de calcular el churn entre empresas SaaS públicas que amantes de Julio Iglesias (un vecino de A Peroxa que igual conocéis). Pero Daniel Skok (en su mítico post sobre métricas SaaS) recomienda 2 cosas:

Son recomendaciones, pero escritas en piedra
  1. Como máximo, el coste de captar un nuevo cliente debiera ser 1/3 de los ingresos que nos traerá
  2. Como máximo, debieras recuperar el coste de captar un nuevo cliente en 12 meses

Volviendo al ejemplo anterior (200 euros/mes, 75% de margen bruto y 2% de churn/mes), la recomendación sería como máximo gastar unos 2.400-2.500 euros en captar a cada cliente. Lo que viene a costar un reloj majete o la captación mediante una campaña con faltas de ortografía.

¿Debiera presupuestar esa empresa 2.500 euros por cliente? Pues depende también. Dado que estamos hablando de valores medios, podemos seguir segmentando hasta buscar los mejores ratios de ingresos o rentabilidad por campaña o fuente, y volver a recalcularlo todo. O no buscar el ser tan eficiente con el capital, y simplemente buscar el hacer crecer los ingresos a cualquier precio (y nunca mejor dicho). O un término medio. O vaya usted a saber. O buscar la forma de maximizar los beneficios, teniendo en cuenta el retorno por fuente de tráfico y el coste y las necesidades de financiación del resto de la empresa a corto y largo plazo. O hacer lo que acuerde el consejo de administración.

Así que ya sabéis. La próxima vez que oigas: «¿Cuánto deberíamos invertir como máximo en captar a un cliente?», la respuesta que nunca daría un gallego sería «depende», sino otra pregunta. Así que puedes responder: ¿por qué lo preguntas? O mejor aún tras lo aprendido con este post: ¿de cuánto tiempo dispones para decidirlo?


..