Curso de Instrumentación en Santiago

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

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?


..


SeedRocket – Instrumentación de Producto (101)

Me invitaron a hablar en SeedRocket sobre product management y en vez de hablar de procesos generales y validación de hipótesis, les hice una rápida introducción a cómo empezar a instrumentar un producto para tomar decisiones en base a datos y automatizar tareas.

Por otro lado, no puedo satisfacer toda la demanda de amigos que me piden consultoría de instrumentación, así que aprovecharé que tengo un blog (nuevo!) para escribir en detalle al respecto.

A nivel de producto

Desde que soy LP, a veces me piden mi opinión sobre startups que están analizando. “Mariño… a nivel de producto, ¿cómo la ves?“.

Es cousa de meigas tener una opinión sobre el encaje en el mercado para fases iniciales (quién hubiese creído que te podías hacer billonario con la idea de alquilar sofás para pasar la noche o conducir en los ratos libres para sacarse un sobresueldo), pero observando artifacts y procesos podemos evaluar la madurez del equipo relacionado con el producto. Así que aquí viene una lista más o menos genérica de elementos para valorar al analizar un producto SaaS. Y además, el jueves voy al SeedRadar a contar batallitas de product manager, por lo que me viene bien escribir esto para ordenar ideas.

Obviamente, la lista está claramente influenciada por el famoso “The Joel Test” de Spolsky. Y por el Technical Due Diligence Framework de Rodrigo Martinez (que por cierto, es realmente cojonudo como análisis técnico).

Dudo que haya existido alguna empresa que cumpla muchos puntos para una serie A (y casi ninguna los cumple todos todos aún mucho más adelante), pero es interesante discutir con los fundadores qué puntos han decidido cumplir, cuáles no y sobretodo el porqué. Insisto, no es un checklist sino una prueba de madurez.

Dice Javi Santana en este megapostazo sobre escalar equipos técnicos, que estas cosas han de implantarse “cuando eres tres pericos metidos en una habitación con mesas de ikea”. Sin sobreoptimizar, pero teniendo claro que lo que no ha arraigado bien al principio, no crecerá nunca. En el fondo, supongo que simplemente es ponerle cariño y visión a largo plazo a lo que uno hace.

Y un recordatorio para los que leen en diagonal:

  1. Estos puntos sólo empiezan a tener sentido al plantearse una serie A. Si sois dos programadores en un garaje, lo único importante es iterar como locos hasta encontrar palancas de crecimiento.
  2. Y están enfocados principalmente a B2B/B2b. Mucho del contenido será válido para B2C, pero recordad que son modelos muy diferentes. Por generalizar, creo que ser Product Manager en B2C es menos complejo, pero a la vez resulta más difícil encontrar esas palancas.

Pero antes de empezar, citaremos a George Soros:

If investing is entertaining, if you’re having fun, you’re probably not making any money. Good investing is boring.

Pues en el caso de gestionar productos, más de lo mismo.  Vamos allá:

  • (1) ¿Existe un repositorio de entrevistas con clientes?
  • (2) ¿Tienen un roadmap sustentado con datos?
  • (3)  ¿Está la aplicación suficientemente instrumentada?
  • (4) ¿Hay un proceso documentado de onboarding?
  • (5) ¿Han automatizado los informes de métricas?
  • (6) ¿Tienen funnels para los eventos más importantes?
  • (7) ¿Está el lanzamiento de features condicionado a acciones de marketing?
  • (8) ¿Está el PM involucrado en ventas?
  • (9) ¿Pueden definir claramente su mercado y competidores?
  • (10) ¿Está el PM unido al equipo de desarrollo?
  • (11) ¿Se guarda un changelog de cada feature lanzada?

(1) ¿Existe un repositorio de entrevistas con clientes?

Probablemente este sea el artifact más básico de todos: notas tras cada reunión de cliente. Si no dedican unos minutos tras cada llamada/visita a apuntar brevemente lo discutido y cuáles han sido los requerimientos… pues es muy mala señal. Sobre el contenido de estas reuniones se decidirá el roadmap, y es conveniente tener notas detalladas (a saber qué carallo se recuerda pasadas unas semanas). Además, facilitan el onboarding de nuevos empleados (tienen una fuente de datos relevante para tomar contexto) y simplifican la toma de decisiones: “en caso de duda, lo que hayamos escuchado de primera mano que podamos vender”.

  • Bonus: han intentado cuantitativizar las entrevistas.
    • Si además de tener notas, han llevado los requerimientos más relevantes a un formato que les permita operar con ellos, pues es un puntazo. Idealmente, no es para sólo decir “X clientes nos han pedido Y”, sino para poder darle profundidad a esos números en base a múltiples atributos: segmento de los clientes (lo piden SMBs o Enterprise?), stage del funnel (lo piden durante el POC o una vez son clientes?), ARR, etc.
  • Superbonus: pueden demostrar que han contactado a todos los clientes que han pedido algo tras lanzarlo al mercado
    • Porque (aparte de un convertible note sin cap), pocas cosas hay más bonitas que poder decirle a un cliente “tal día pediste esto y acabamos de lanzarlo en base a tus sugerencias”. O mejor aún, que esto sirva para retomar contactos con oportunidades que no convirtieron “aquello que pediste acabamos de lanzarlo, así que puedes echarnos otro vistazo de nuevo (y si decides suscribirte antes de final de mes tenemos esta promoción)“.

(2) ¿Tienen un roadmap sustentado con datos?

Muy unido al punto anterior. Un roadmap no debiera ser (sólo) una lista de tareas que encajar a martillazos en tu producto, sino una base de datos sobre la que tomar decisiones. En muy muy muy pocos momentos se deben primar las decisiones individuales (Steve Jobs hubo uno y sólo uno) sobre lo que te muestre tu recolección de datos. Idealmente, al menos se tendría que analizar el ROI de cada feature (priorizando ese unicornio llamado “features que traen mucho dinero y se hacen en dos patadas”), aunque los modelos que mejor funcionan suelen ser algo más complejos (ponderando más variables, como si las features van a ayudarnos a posicionarnos en el mercado objetivo, si encajan o no con la visión de la empresa, etc). Adjunto un diagrama (adaptado a millenials) para que se entienda mejor:

  • Bonus: enlazan peticiones con datos de negocio (por ej. ARR de cliente).
    • Idealmente, debiéramos poder acercarnos al hipotético impacto económico de añadir al roadmap una feature o descartarla. Tanto positivo (nuevos clientes, expansión interna), como negativo (probabilidad de que churneen o estancamiento de ventas). Para ello, una aproximación razonable (aunque no hay ninguna perfecta) es ponderar el ARR previsto con el potencial impacto (idealmente, que tu cliente más grande te pida una feature de modificar colores en la UI debiera tener menos peso que algo que piden constantemente clientes más pequeños).
  • Superbonus: herramientas pro integradas como Aha o Wizeline.
    • Se empieza con un bloc de notas, se lleva el contenido a un Jira, de ahí pasa a un spreadsheet para tener más flexibilidad, y al poco no hay nadie que pueda manejar tanta complejidad. Si tienen sus datos/procesos integrados en plataformas así (y realmente las usan) van por el buen camino.

(3) ¿Está la aplicación suficientemente instrumentada?

Si alguien me pregunta si fue más importante el día en que nació mi primer hijo, o el día en que instalamos Mixpanel en Ducksboard por primera vez… pues me quedaré un rato dudando. El salto cuántico de poder medir cualquier evento en la aplicación, cambia tu forma de ver el mundo. Y poder correlacionar. Y filtrar. Y crear funnels. Y ver cohortes. Y ver que paths siguen los usuarios que convirten…  Y dejar de tener discusiones absurdas sobre opiniones para empezar a tenerlas con datos.

Hace años no había tanta herramienta, pero a día de hoy nada impide poder guardar tranquilamente millones de eventos. Amplitude tiene un trial con 10M de eventos al mes, y Heap eventos ilimitados para 50k sesiones al mes.

  • Bonus: Usan Segment para manejar la complejidad.
    • No recuerdo que me aposté con mi manager a que Segment valdría $10B en menos de 5 años, pero sin duda debí forzar un all-in. Lo que empezó como una forma de evitar desplegar docenas de scripts, ha acabado siendo la pieza core de cualquier empresa moderna para construir y simplificar su data pipeline. Y si estás dominando ese hueco, tus clientes no se dan de baja ni a tiros. Así que Segment es muy necesario (y sin competencia relevante) por lo que su instalación implica madurez.
  • Superbonus: Tienen un documento actualizado para la taxonomía de eventos.
    • Si alguien me enseña algo así, probablemente recomiende invertir sin derecho político alguno. Que hayan decidido mantener un system of record de todos los eventos que guardan, que atributos envían (y si tienen valores por defecto o limitados) y cómo se relacionan entre sí es probablemente la señal más clara de que se toman el análisis de producto en serio. Si queréis empezar, en Amplitude escribieron una guía con los primeros pasos.

Si cumples este punto, puedes pedirte esta taza y pasearla con orgullo


(4) ¿Hay un proceso documentado de onboarding?

Con lo que cuesta (y no sólo económicamente) que alguien caiga en tu web y decida abrirse un trial, lo menos que puedes hacer es todo lo posible para que entienda el valor lo antes posible. Han aparecido cientos de herramientas en los últimos años para medir y hacer un onboarding en condiciones (segmentando mensajes, no insistiendo en probar features avanzadas si no se han finalizado procesos básicos, etc), así que no hay excusa para no hacer algo mejor que una serie de reglas en Mailchimp de “el día n envía este mensaje estático”. Aunque mejor es enviar eso que no enviar nada.

  • Bonus: el onboarding está unido al sales funnel.
    • En el B2B hay 2 tipos de empresas: las que ya tienen a comerciales trabajando, y las que los necesitan. Si ya tienes madurez suficiente como para usar un CRM (y creo que nunca es lo suficientemente pronto como para configurar uno) debieras ir actualizando en él el estado de la oportunidad. Porque no tiene mucho sentido invertir en contactar personalmente a usuarios nuevos con poca actividad, pero no tiene excusa el no contactar a los que han entendido la propuesta de valor para intentar acelerar el cierre o proponer pagos anuales.
  • Extrabonus: han implementado tests para evitar que se interrumpa la recogida de datos.
    • Pocos son los que no tienen tests para este proceso (o incluso para instrumentación más genérica), pero muchísimos los que lamentan no haberlos tenido antes. Si empiezas a ver números que no tienen sentido durante el onboarding, probablemente el motivo sea que haya desaparecido instrumentación en alguna parte. Y esos datos no los volverás a tener nunca más. Y cuando te pase, porque te va a pasar, te acordarás de este párrafo.

(5) ¿Han automatizado los informes de métricas?

Si pides una hoja de cálculo con los KPIs más relevantes y “van a tardar unos días” porque “la han de generar/preparar/…” sal corriendo en cualquier dirección. No creo que sea necesario tener datos en tiempo real, pero al menos un update nocturno podría hacerse. Si una empresa no los tiene a mano o no confía lo suficiente en que esos datos sean correctos, huye. Lejos.

  • Bonus: les es sencillo combinar datos de diferentes herramientas
    • Además de KPIs generales, idealmente deberíamos poder crear otros que combinen datos de diferentes herramientas (CRM, customer success, pasarela de pago, ads y campañas, etc). Si es posible importar esos datos, y además alguien les ha puesto suficiente cariño como para que tengan un formato que te permita operar con ellos, sabes que has de ir pidiendo hora en el notario.
  • Superbonus: consolidan en  un spreadsheet sencillo de entender (pero lleno de código a medida por detrás).
    • Uno nunca debiera conocer los entresijos de la política, las fábricas de salchichas, o los informes de métricas. Porque nunca son perfectos (o mejor dicho, siempre hay que masajear bastantes datos). El tratamiento de excepciones (como quitar ingresos que no son reales porque se hicieron tests en producción, meter ingresos que se facturan a mano y no por la pasarela de pago, etc) debería automatizarse. Bueno, idealmente no, se ha de hacer y punto. Así que si no hay código que se encargue de tratar anomalías de datos, desconfía del informe.

(6) ¿Tienen funnels para los eventos más importantes?

Muchas empresas guardan datos de forma relacional, pero sin atributos suficientes como para entender qué es lo que ocurre. Por ejemplo, no tienen problemas en hacer una query para darte datos de usuarios, pero difícilmente te podrán explicar cómo esos mismos usuarios han llegado al estado actual. Y si entender usuarios uno a uno ya les resulta complicado, que no intenten sacar datos agregados (“qué principales atributos tenían los usuarios que considerábamos activos y no llegaron a suscribirse durante esta fecha?”). Y si ya les metes desfases temporales (esos modafocas que se abren cuenta en diciembre y te empiezan a pagar en enero), se complica más. Pensaba que los funnels estaban más extendidos, pero la realidad nunca dejará de sorprenderme.

  • Bonus: sus funnels no son estáticos sino que guardan métricas temporales.
    • Hay que ir consolidando numéricamente los resultados de cada funnel, para entender cómo varían a lo largo del tiempo. Si tienes los datos, siempre puedes ir a buscarlos con la granularidad que quieras, pero es tan sencillo ir consolidando datos que debiera hacerse.
  • Superbonus: facilitan comparaciones entre funnels.
    • Con el AB testing no sé si soy más un descreído o un cínico (o simplemente alguien que entiende que no sirve para todo y que tener datos estadísticamente significativos cuesta de narices). Pero aún así, no es mucho pedir que se puedan sliceanddicear los funnels. ¿Verdad que no? Por ejemplo, si vendes a USA desde Europa intenta comparar los datos entre diferentes estados: probablemente (para mismo tamaño de empresa) los estados de la costa este te conviertan mejor (más overlap de horarios implica menor tiempo de respuesta de mails, ciclos más cortos de soporte, mayor facilidad para cuadrar llamadas, etc).

(7) ¿Está el lanzamiento de features condicionado a acciones de marketing?

¿Quién no ha invertido semanas de desarrollo en una feature, y luego la ha anunciado al mundo únicamente con un par de miserables tuics? Tranquilo, no estás solo. Pero empieza a plantearte además de un “esto a quién se lo vamos a vender” un “esto cómo lo vamos a anunciar”. Y dale vueltas a qué mensajes vas a utilizar en qué canales para comunicar a qué personas. Y cómo vas a medir que tengan impacto (si no se mide, no es marketing), y cómo vas a correlacionar todas esas acciones con datos de negocio.

  • Bonus: tienen un checklist de acciones estandarizado.
    • En fases iniciales no debiera ser muy extensa esta lista, pero que exista sirve para invocar a ese unicornio llamado “planificar con tiempo”. Porque si lo dejas todo para el final, con suerte lanzas ese par de tuics. Pero igual con tiempo te puedes plantear enviar newsletters (con mensajes diferentes para diferentes “personas”), gastarte dos duros en VoiceBunny para ponerle voz profesional a un video demostrando la feature, hacerte unos docs técnicos detallados (y con gifs mostrando procesos en vez de fotos con flechas), etc etc. No se puede poner cariño sin planificar.
  • Superbonus: Cumplen el 100% del checklist en cada lanzamiento
    • Esto ya es para hacer un all-in. Pero si no sólo planifican, sino que además cumplen todas las tareas sistemáticamente, cásate. En gananciales si hace falta.

(8) ¿Está el PM involucrado en ventas?

O si no hay tanta estructura: ¿está el final-decision-maker de producto involucrado en los deals más relevantes? Aunque este punto parezca muy unido al primero de entrevistarse con clientes para entender necesidades, en realidad sirve para principalmente obtener otros conocimientos: (1) cómo nos perciben los clientes al compararnos con otras soluciones/productos similares y (2) que características son un blocker para seguir vendiendo. Este último punto es precisamente el que menos se plantea mucha gente: mucho foco en ganar en número de features a la competencia, pero poco en trabajar producto para eliminar fricción durante el proceso de venta. Porque aunque no te lo creas, que tengas más integraciones o cuestes dos duros menos que tu competidor no te hará ganar más deals si, por ejemplo, no permites SSO.

  • Bonus: Escribe battlecards para ventas y win/loss scenarios
    • Son 2 artifacts básicos durante el proceso de venta: los battlecards son la información más relevante para que cualquier rep pueda compartir información de producto a la vez que planta unos landmines majos a la competencia. Por ejemplo “Nosotros nos integramos con 60 servicios y ellos sólo con 10. Igual hoy esto no te parece importante porque empezarás utilizando pocos, pero a medida que diferentes departamentos de la empresa nos empiecen a utilizar también, de golpe explotará la necesidad y si no nos has escogido previendo este uso, alguien te señalará con el dedo y momentos después vendrá una office manager a buscarte con una caja de cartón. Firma aquí.” Los win/loss son parecidos a las entrevistas: una retrospectiva que nos ayude a pensar en el proceso y en los motivos que nos han hecho ganar (para repetirlos) y en los que no.
  • Superbonus: forma regularmente al equipo de ventas.
    • ¿Tienen producto y ventas reuniones periódicas? ¿Empiezan con un “cómo os puedo ayudar a vender maś”? ¿Escriben conjuntamente los scripts de las demos? ¿Crea producto materiales para ellos? Pues eso.

(9) ¿Pueden definir claramente su mercado y competidores?

La definición de mercado es estratégica como para que no la decida sólo producto. Pero dependiendo de la decisión (nicho, volumen, integración, etc) la forma de ofrecer el producto puede variar sustancialmente. Así que es importante saber en qué mercado se va a estar. Y mucho más importante es que a todo el mundo le quede meridianamente claro qué mercados no se van a tocar ni con un palo de tres metros.

  • Bonus: tabla actualizada una tabla comparativa.
    • Sin necesidad de obsesionarse, recopilar (y actualizar) qué features tienen nuestros competidores ayuda a entender el tipo de decisiones que van a tomar. Muchos juniors se plantean que para triunfar se ha de “ofrecer lo mismo y alguna cosa más”, pero realmente no tiene mucho sentido. Ni suele ser posible ofrecerlo todo, ni (salvo en RFPs) los clientes están interesados en todas las features (hola Pareto!).
  • Superbonus: Han escrito documentos extremadamente en detalle sobre ellos (y los van actualizando).
    • Empieza a ser recurrente lo de crear documentos en esta lista 🙂 Pero más allá de la tabla de arriba, no viene mal un par de veces al año abrirse una cuenta en Mailinator y hurgar en la competencia. Insisto en lo de sin obsesionarse, pero no les quites ojo y si vas a hacer análisis, que sean en detalle (sin comparar features sino propuestas de valor).

(10) ¿Está el PM unido al equipo de desarrollo?

Estar unido no simplifica estar íntimamente ligado, sino garantizar que hay un flujo de comunicación continua. Que se intercambia información sin planificar. Que no son universos desconocidos. Vamos, que se tratan.

  • Bonus: participa en el daily standup.
    • O dicho más en detalle, está callado durante el standup sólo por si aparecen dudas. Algún purista del agilismo estará echando espumarajos diciendo que sólo debería estar durante la planificación, pero me parece que esa es la semilla que planta el árbol de “los encorbatados de producto sólo sirven para dar órdenes”. El roce hace el respeto.
  • Superbonus: hay una plantilla para añadir las necesidades de negocio y los requisitos de aceptación para cada tarea relevante.
    • No para cada issue del Jira, pero las stories debieran tener una explicación de negocio de “por qué tiene sentido trabajar en esto ahora” y un script de la demo que se hará. Y una plantilla para garantizar que añadir esta información sea sistemático.

(11) ¿Se guarda un changelog de cada feature lanzada?

¿Recordáis lo comentado antes del cariño? Pues guardar un changelog con un listado de lo que se ha ido desplegando probablemente sea una de las muestras de ejemplo más grande. No sólo por ir consolidando muestras de trabajo, sino porque, llegará un día en que estés a las tantas de la mañana delante de un excel intentando entender por qué carallo una métrica empieza a desviarse desde una cierta fecha. Y ese día te arrepentirás de no haber dedicado unos segundos cada día a apuntar si se había lanzado algo nuevo. Y yo si te conozco, te iré a señalar con el dedo y a soltarte un “te lo dije” de manual.

  • Bonus: se compara con el roadmap para analizar retrasos y % de cumplimiento.
    • Tener una visión clara es la leche. Pero entregarla es inenarrable. Y además se hace camino al andar y todo eso. Por lo que tener una lista detallada te ayuda a analizar qué porcentaje de roadmap vas cubriendo para estimar y priorizar de forma más realista.
  • Superbonus: mantienen diferentes niveles de detalle.
    • El nivel de detalle debe cambiar con el público objetivo de la lista. Equipos de desarrollo probablemente requieran varios elementos por día (los de los despliegues más relevantes), clientes actuales requieran algún elemento a la semana (o ni eso), y potenciales clientes se sientan cómodos únicamente teniendo una lista de los items más relevante durante los últimos trimestres.

Y esto más o menos vendría a ser lo básico. En el fondo te quieres asegurar de que en el liderazgo de producto:

  • Se recopila conocimiento para tomar decisiones
  • Se comunica ese conocimiento continuamente
  • Y se dice NO muy a menudo.

Y todo esto sólo ayudará si antes se ha cumplido la regla de oro del product management:

“Only build solutions for problems that are urgent, pervasive and the market will pay to solve.”

Pues estos vendrían a ser unos puntos básicos para empezar a analizar. Igual extiendo el post o lo paso a otro formato que permita interactuar con comentarios a párrafos concretos (abierto a sugerencias). Aunque viendo la parrafada, igual lo mejor es que para la próxima charla haga directamente unas slides… que me ha quedado largo 🙂

Designing for badass

¿Qué harías si te quedase una hora de vida? Yo probablemente cogería a mi hijo en brazos y me sentaría a paladear con él este video de Kathy Sierra de la última BusinessOfSoftware. De nuevo. Por enésima vez.

Me preguntaba ayer un amigo por la clase de product-management más magistral que haya recibido nunca y sin duda es esta. Sólo por escuchar similar torrente de reflexiones, merece la pena comprarse una entrada e ir a soportar la lluvia de boston en Octubre.

Y si os quedan fuerzas al acabar, os recomiendo este otro de Gail Goodman en el mismo evento: How to negotiate the long, slow SaaS ramp of death. Si me quedasen dos horas de vida, probablemente sería este video el siguiente en paladear.

Ambas charlas son drogaína para fundadores con un producto en las manos. O para los que quieren serlo.