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 🙂

Va a hacer un mes de la #TarugoConf y ya estoy contando los días hasta la siguiente. Un evento redondo: con charlas inolvidables y la mejor sobredosis de pulpo que he tenido en mi vida. Allí estuve repartiendo Almax a 2 manos entre el público antes de salir al escenario.

El único “pero” al evento, es que desaparecieron 14 slides de mi charla. Algunas de ellas necesarias para poner contexto en cosas que se discutirían más tarde. Y dado que he pedido que no compartan ni mis slides ni el video de la charla, queda este post para aclarar algunos puntos.

Por ejemplo, esta primera slide era de lo más importante:
diego-marino-ducksboard-tarugoconf-final-002

La charla iba sobre cómo lo haría hoy para, partiendo de la misma base de Ducksboard, crear un bisnes en el que “hasta el becario acabe siendo cliente de banca privada”®. Obviamente el enfoque iba a ser SaaS (¿hay algún bisnesmodel más bonito?), y especialmente el enfoque B2(b). No B2C porque soy incapaz de hablar de lo que desconozco (y a mi edad todavía me siguen sorprendiendo las startups que consiguen cientos de miles de visitas o descargas), y no B2B puro porque si vamos a empezar en España, idealmente debiéramos buscar un enfoque que no necesite venta consultiva.

Así que un B2(b), con la segunda “b”minúscula. Si empiezas desde aquí, lo ideal es intentar exprimir únicamente el modelo transaccional (al menos hasta llegar al “default alive“), y luego ya te meterás a negociar contratos que requieran seguros de responsabilidad civil y soporte VIP 24×7.

Del mismo modo, faltaron slides por en medio que me hubisen venido más que bien para explicar mejor algunos de los puntos más conflictivos… así que intentaré alargar las conclusiones:

 

diego-marino-ducksboard-tarugoconf-final-038

 

(1) Reconsider your UI investment. Twice. Thrice.

La gente se cree que estoy de broma cuando digo que la prueba más fehaciente de que en nuestra vida será imposible viajar en el tiempo, es que mi yo del futuro no se presentó con un bate en la mano en mi cocina el día en que decidimos “hacer nuestra propia librería de charting sobre SVG”. Un bate de metal y ganas de protagonizar especiales informativos. Consejo gratuito: nunca utilicéis las palabras “librería” y “charting” unidas a cualquier pronombre posesivo en primera persona. Never. Never de never.

En todo caso, la reflexión es que inversiones en GUI se convierten rápidamente en costes irrecuperables. Más que un coche al sacarlo del concesionario. Imposible tener algo optimizado y pulido para diferentes navegadores en diferentes dispositivos con diferentes tamaños de ventana (y sin hablar de apps) al empezar una startup. Salvo que sea una capa CRUD sencilla, que entonces quizá. U ofrecer principalmente una API, que entonces es todo mucho mejor.

Igual no me expresé bien allí y el mensaje recibido fue “muerte a toda UI” en vez de “piénsate muy muy muy muy muy bien cualquier decisión que hagas en el frontend”. Y bajo ningún concepto te forkees alguna librería. O lo puedes hacer, pero si me entero de que lo has hecho tras leer esto, si te conozco igual te acollejo hasta que se me duerma la mano.

Lo de que “idealmente la principal interfaz debiera ser siempre una API”, es algo que hoy sólo decimos cuatro colgados. Pero sé que ese día cercano (si no es ya), en el que hayan desplegados más (micro)servicios, agentes de IA o dispositivos IoT que usuarios conectados a internet, vendréis llorando de vergüenza a darme la razón.  Echadle un ojo a este banco construido sobre una API (y no al revés). Canela fina.

Finalmente, pensaba en esto hace poco cuando valoraba invertir en una startup. Sin dar mucho detalle, están en el sector del marketing online… pero para mostrar sus datos tienen una GUI con las típicas tablas y gráficos, mientras que su principal competidor te lo guarda todo en tu cuenta de GoogleAnalytics. En igualdad de condiciones y sabiendo que solventan el mismo problema, ¿cuál de las dos podrá desarrollar su producto más rápido?

(2) Instrument your UX to get millions of events/mo

Yo pensaba que lo petábamos analizando varios millones de eventos al mes, hasta que Xavi y Gabi me contaron sus magnitudes. En resumen: éramos unos mindundis. Y realmente, si se organiza uno bien, no es tan complicado analizar miles de millones de eventos al mes.

Nosotros empezamos tarde a guardar tanto evento, y tardamos mucho más en tener una visión completa. Hay una diferencia muy grande entre querer saber qué porcentaje de usuarios integraban un servicio, entre saber qué % de funnel completion tiene cada servicio, y entre saber que apenas nadie llegaba a usar Stripe porque el primer batch download tardaba minutos (y los usuarios pensaban que nuestro pato estaba roto y se iban).

Idealmente, ligaría además todo evento en el servicio siempre que sea posible a acciones de negocio (en el fondo, queremos que lo usen para que nos abran la cartera, ¿no?).

Y para el que no sepa por dónde empezar, dos briconsejos:

  1. Para ir bien, una métrica razonable es gastar en analítica al mes lo mismo que el salario medio.
  2. Si no sabes por dónde empezar, arranca con Segment + Amplitude + Metabase.

(3) Raise your price. Leverage your price elasticity

El Valhalla del SaaS está lleno de gente que creía que cobrando de media $30 al mes y sin comerciales podrías tener una villa en una urbanización privada y un Lamborghini amarillo. Habréis adivinado que yo estaba en ese grupo de gilipollas. Si también os afecta, podéis estar tranquilos porque se cura.

Ahora ya no estoy en ese grupo. En mi experiencia americana trabajando para una empresa seria que vende SaaS a gente seria, estoy aprendiendo algo importante: si algo no falta en este mundo, son empresas grandes con problemas y dinero para solventarlos. En serio, un manantial que no se acaba. El mundo está lleno de gente que ve razonable llevar camiseta en día laborable, y para compensar, de empresas con más dinero que problemas.

Principalmente esas mismas empresas desconfían de las que cobran poco. Y atención, que con esto lo váis a flipar: el que decide comprar algo no lo paga de su bolsillo. ¿Cómo te quedas? Así nunca le preocupará si el precio es $29, $99 o$499. No tiene el concepto de “caro” o “barato” para magnitudes tan pequeñas. Pero le preocupará saber si os puede referenciar para que los de InfoSec de su empresa le echen un vistazo al producto, porque igual se parten la caja al ver que sólo hay forma de loguearse en vuestro servicio con user/passwd.

Si queréis grauzjáquin de ventas probad este experimento: permitid que IdPs se puedan conectar a vuestro servicio, que un abogado que sepa os redacte un privacy policy que añadir al footer, y luego enlazad ahí también a una página dedicada a explicar vuestras medidas de seguridad con un punto especial dedicado al tratamiento de datos. Grauzjáquin del que funciona… y no del de esas tontopolleces que leéis en Medium.

Finalmente algo de sentido común: es más rentable vender a 1 cliente algo por $3.000 que a 100 cobrando $30. Nosotros lo descubrimos justamente el día en que un cliente (de Dubai, como todos los grandes clientes) de alguna manera entendió que el precio era $3.000/mes (y no $30) y nos los quería transferir. Hicimos el pardillo hasta ese día.

(4) Hijack a painful step in an existing process

¿Quieres reducir el churn? ¿Subir el ARPU? ¿Esquivar ese Valhalla? Pues entonces más vale que solventes un problema doloroso. Algo que haga que principalmente se deje de perder dinero o tiempo. Y salvo en casos muy muy muy concretos (como monitorización para equipos de soporte o “war rooms”), nadie necesita dashboards en tiempo real. O dashboards a secas.

Nosotros esquivamos casos de uso de nuestros usuarios (algunos nos pagaban y no usaban nunca la GUI!!!) por empujar el modelo dashboard. Error. Error que además veíamos con datos.

Así que hoy sin duda, recomendaría meterse dentro de un proceso existente y doloroso.

¿Recordáis las empresas que os comentaba en el punto 1? Cuál tendrá menos fricción para conseguir stickyness: ¿aquella que guarda sus datos en GoogleAnalytics (que es dónde vive la gente de marketing), o aquella que les muestra los datos en otra interfaz?. Otra interfaz que tendrá que permitir exportar esos datos, para masajearlos a mano, para mezclarlos con los mismos que tienes y necesitas en GoogleAnalytics.

(5) Don’t touch a bad customer even with a 10ft pole

Si vuestro abogado os ha redactado unos TermsOfService majos para SaaS, probablemente habrá una cláusula que diga que podéis suspender a cualquiera el servicio preavisando con 30 días.

Cuando un cliente de Canarias os pida que le hagáis una factura especial (aka, a mano) con IGIC para sus $9 (sí, 7 euros con algo) de gasto al mes, no dudéis en enviarle un permalink a esa cláusula. O cuando tengáis cheaters, que es habitual. Gente a la que si cobras por dashboard, pone cientos de widgets en uno y se queja del rendimiento del frontend. O se monta un bisnes sobre tu negocio y se pone a exigir features (como buen cliente de $29 al mes) con malos modos. O impresentables que conociendo al equipo no dudaban en subir quejas en tuister empezando con un “.@ducksboard”.

A todos esos, puerta.

(6) It’s better to be loved by 10 than to be liked by 1000s

Los años y las canas me han hecho enamorarme de los nichos. Tras emperrarme en Abiquo en construir plataforma en vez de solución final (vale para todo!! no vamos a cerrarnos puertas!!) me prometí que nunca volvería a enfocar una empresa igual. Luego fue Ducksboard más de lo mismo (todo tipo de integraciones para todas las empresas!!). Meh

No cometáis ese error. Es más sencillo empezar en un nicho e ir capturando verticales cuando los tengas dominados, que empezar con una plataforma que “vale” para todo y para todos. Sin ninguna “persona” sobre la que enfocar producto. Ni mercado definido al que dirigirse. Ni profundidad por desconocimiento de ambos. Ni competidores claros para ser comparado.No habrá una tercera vez. Palabra.

Y poco más.

Javier Alonso sketcheó mi charla, y esto será lo único que quede compartido de la misma.

img_2892

Un asistente ya ha comprado los dominios. Ojalá su becario pueda ir el año que viene a la #TarugoConf a contar cómo lo están petando.

 

Since 2006, inbound marketing has been the most effective marketing method for doing business online. Instead of the old outbound marketing methods of buying ads, buying email lists, and praying for leads, inbound marketing focuses on creating quality content that pulls people toward your company and product, where they naturally want to be. By aligning the content you publish with your customer’s interests, you naturally attract inbound traffic that you can then convert, close, and delight over time.

Hubspot, The Inbound Methodology

De todo el contenido insustancial que se genera diariamente, el que más me llama la atención es el que generan las startups. Supongo que mitad por ser del sector, mitad porque casi siempre midiendo un poco se debería ver que no hay apenas retorno.

Empezaremos por un ejemplo cercano: imaginad que se juntan un polaco, un andorrano y un gallego y deciden montar algo de, no sé, recoger y mostrar métricas de negocio. Tras unos meses en el que el único contenido generado, aparte de las líneas de código, son blogposts diseñados para ser #1 en HackerNews, se empiezan a plantear que igual tocaría empezar a volcar su conocimiento de alguna manera que les permita demostrar que saben de lo que hablan, y de que no hay mejor producto que el suyo para solventar ese problema del que ellos creen saber mucho.

Total, que se dicen “podríamos empezar a escribir algunos blog posts“, “un success case con alguno de esos clientes tan molones que tenemos y que casi nunca comentamos” o incluso “un whitepaper explicando paso a paso como montar algo útil”. Pero ya se sabe que las ideas, cuando no están metidas en un plan crítico para obtener resultados, no tienen presupuesto ni recursos ni un bulldog que se comprometa a empujarlas día a día… pues no se hacen.

Viendo que los fundadores son los únicos con conocimiento suficiente como para contarse algo interesante, pero viven atrapados en esa dinámica tan mundana llamada subsistencia (aka pagar nóminas, desplegar features, o dar soporte personalizado a cuentas de menos de $500 de ARR), pues deciden lo que muchos: “listaremos ideas majas, les daremos unas pinceladas y buscaremos a alguien externo que las escriba”. Obviamente, que un tercero escriba sin tener demasiados insights lleva a contenido plano, enteramente insustancial y que no interesa ni a las granjas de spammers rusos. Pero oye “tenemos una estrategia inbound”. Y otra de gambas.

Y aunque este error me parece perdonable (había la mejor de las intenciones pero ningún recurso asignado), lo que me chirría a menudo es ver los recursos mal enfocados: aka, invertir en generar contenido de calidad más que dudosa.

Pongamos por ejemplo un ejemplo de un sector en el que creo todavía no me odia todo el mundo: los VCs americanos. Hay una diferencia enorme entre un post como este de Mark Suster en el que vuelca experiencias reales sobre ventas (y de ahí el valor), con el Mark que se dedica a ofrecer patochadas contenido superfluo en Snapchat. O A16Z con el análisis (para quitarse el sombrero) de Dell comprando EMC, comparado con el enésimo post recurrente de startup metrics. O este video Magistral de Lemkin sobre ventas (lo que me fijo en cómo se vende últimamente), con casi cualquier otra cosa escrita nunca por cualquiera.

Así que si estás dentro de una startup y buscas un briconsejo gratuito: huye del contenido evergreen simplón. Niégate. Sal corriendo. Salta. Por tentador que pueda parecer. Funciona en pocos casos concretos (principalmente afiliados). No dediques tiempo a explicar obviedades: o bien estás educando para crear un mercado (error), o bien te escucha un sector que nunca te va a comprar una escoba. El pensar “si yo los educo me escogerán a mí” no funciona en fases iniciales. Los early-adopters e innovators están probablemente mucho más informados que tú. Y los post de “las 7 cosas que has de saber para X (y la 4a te sorprenderá)” les dan vergüenza ajena. Palabra.

Así que cada vez que des un paso pensando en tus clientes (bien sea una feature, un nuevo canal para contactarte o incluso en generar contenido) piensa en qué superpoderes les estás dando. O incluso, el plantearte generar contenido que realmente interese a los clientes que soñarías tener. Porque funciona.

Hoy hace 10 años que se constituyó “Soluciones Grid SL”. Así que toca agarrarse a la silla para y arrancar un viaje nostálgico, que no habrá mejor día para repasar muchos de los errores que puede cometer cualquier irresponsable que funde una startup de tecnología compleja con 23 años. Obviamente, Xavi estaba conmigo el primer día, pero no hace falta que os garantice que el responsable de la mayor parte de los desaciertos (por no decir otra cosa) fui yo.

AbiquoFounders
Xavi y yo, cuando apenas íbamos al médico

La razón social era Soluciones Grid porque no quería pasarme la vida deletreando ThinkInGrid. Más allá del error de pasarse días peleando por escoger un nombre, el grave es acabar escogiendo uno relacionado con la tecnología usada. Y hablando de constituir la sociedad, nada como dividir equitativamente teniendo responsabilidades e inversiones diferentes. Y si queréis un doble mortal, sumadle el desconocimiento (e incluso la vergüenza de plantear un pacto de socios). La juventud es lo que tiene. No seáis jóvenes. O gilipollas, que es lo mismo.

521994684_a04dcdb6a1_oEmpezamos con la idea sencilla de crear una plataforma para facilitar el desarrollo de aplicaciones de cálculo intensivo. Esto ahora parece innecesario, pero hace 10 años nadie te alquilaba recursos así que lo normal era hacer desarrollos a medida para ejecutarlos sobre un clúster. O incluso sobre un supercomputador, optimizando para pagar el menor número de horas posibles.  El bisnes lo vimos claro desde el grupo de investigación de la universidad que nos unía a todos: “haremos una versión mejor para los clientes existentes y además les podremos vender soporte”. Lo malo es que en ningún momento se me ocurrió plantearme si aquellas empresas que iban a la universidad a contratar investigación (bien por necesidad real, bien por subvenciones) firmarían nada con cuatro chalados instalados en un sótano-trastero.

Así que en vez de preguntar a los clientes *antes* de constituir la sociedad si se vendrían con nosotros, lo hice después. Y allí estábamos, en esa oficina internamente conocida como “el foso”, sin ninguna estrategia ni objetivo. Tocaba hacer lo que todo emprendedor que viva en Cataluña ha de intentar alguna vez en su vida: venderle algo a LaCaixa.

Y allí que me fui, a intentar convencerles de que sabía yo más de su negocio que ellos y de que con computación intensiva iban a ser capaces de estimar mejor el riesgo de sus hipotecas. Allá por el 2006 lo de medir mejor el riesgo no les interesaba mucho, pero si les llevaba de la mano a parejas con las condiciones necesarias para hipotecarse me prometieron pagarnos unos buenos dineros. Así que entre coger billetes a dos manos o revolucionar el mercado de la computación distribuida enfrentándonos a IBM con 12k euros en el banco, escogí mal. No sería la primera vez.

Tras varios meses de desarrollo, tocaba probar el prototipo. Y comparamos cuanto nos costaría migrar un proyecto construido en 3 meses por un equipo a media jornada. Tardamos 45 minutos. Y empecé a darme cabezazos contra la pared pensando: “es tan perfecto que no vamos a poder cobrarle horas de consultoría a nadie”. Un drama.

Pasaron meses complejos de peleas internas (nada es más nocivo que no tener un objetivo) hasta que el mismo día en que decidí bajar la persiana y repartirnos las sillas conocí a Jesús Monleón. Y que nadie me pregunte si él ha sido más decisivo en mi vida que Marta, que igual dudo. Por algún motivo lo que hicimos le llamó la atención y decidió ayudarnos a buscar financiación.

IMGP0436
“Mariño: focus, focus, focus”

Obviamente, ninguno de los pocos fondos que había aquel entonces entendía a aquel colgado que pretendía vender “un framework y un middleware”. Por lo que para poder sobrevivir cerramos una primera ronda con Jesús y Helena. A valoración 100k post. Habéis leído bien. Y a pesar de lo ridícula que suena hoy esa cifra (e incluso en 2007), fue de las pocas decisiones inteligentes que tomamos: nada como en fases iniciales poder sumar a gente con conocimiento y que confiaba (casi ciegamente) en nosotros.

Jesús trajo el principal giro estratégico de la empresa: “los chinos os van a copiar el software y el dinero se hace vendiendo a volumen, así que vamos a intentar meterlo en cacharros”. La idea no estaba mal… pero llegamos 10 años pronto al internet of things. Lo de llegar pronto a los sitios nos pasaba mucho. Lo mismo nos prototipábamos un Dropbox que un IFTTT. Y de pensar en la ubicuidad de desplegar software, acabamos cambiando el nombre a Abiquo.

Como éramos unos incomprendidos en España, dimos el salto al extranjero. Y más que salir a vender, salimos a gastar. Y en Cambridge, nos alquilamos la primera oficina que tuvo Xen (bendita superstición). Y el principal recuerdo que guardo es que la compartíamos con un chico que había contratado un programador chino que se llevaba el saco de dormir a la oficina por si había que quedarse hasta tarde. Hasta Xavi (que venía de DMR) se sorprendía. Y dando vueltas por allí tras muchas reuniones en las que nos pedían la tecnología bien para meterla en sensores de misiles, túneles o cintas transportadoras, el poco sentido común nos hizo ver que no podríamos en poco tiempo hacer nada tan complejo. Y también ayudó bastante quedarnos sin dinero. Nada ayuda más a priorizar bien que no tener dinero.

team_milan
En Milán, infiltrados a la moda para vender cacharros

Por suerte en poco tiempo, además de cerrar una mega-ronda con la CAN, a algún director de marketing se le ocurrió el término “cloud computing” para aglutinar servicios distribuidos. Y allí estábamos nosotros con la tecnología y conocimientos suficientes como para tener una oportunidad. Y cambiamos a la gestión de entornos virtuales. Y decidimos invertir más que nadie en la UI. Y ofrecimos una versión de código abierto. Y creedme si os digo que por el 2009, había pocas combinaciones más potentes para los VCs de siliconválei que opensource+cloud. Potentes hasta el punto de que mi primer paseo en limousina me lo pagaron unos para llevarme a una reunión.

Cometimos muchos errores también. Yo casi lloro de vergüenza recordando el día en que decidimos no estandarizarnos con la API de Amazon y seguir con la nuestra “porque la suya no es tan rica sintácticamente como para encajar en nuestra visión”. Que hubiesen cientos de miles de programadores usándola creo que no lo valoramos lo suficiente. Sintácticamente rica era la paliza que me merecía. Aunque si le preguntáis a Xavi, os diría que a largo plazo fue un acierto.

Pero lo cierto es que durante muchos meses, tuvimos el que era considerado el mejor producto del nicho. Tanto que a principios de 2009 se nos acercó la responsable de corpdev de una gran empresa a tantearnos por 30 millones. Y si estoy escribiendo esto es porque obviamente le dije que no. El número de errores que se puede cometer cuando eres joven no lo guardas en un int32. De aquello aprendí que más que fijarte en el precio de venta, te has de fijar en lo que te vas a meter en el bolsillo. Que sale más rentable 30 en la mano que 100 tras 2 rondas de dilución.

Seguimos sobreviviendo, y mucho de lo que pasó luego está asegurado por un NDA. Probablemente lo más interesante. En poco tiempo vivimos cosas inimaginables. I-N-I-M-A-G-I-N-A-B-L-E-S.

Y tras levantar una ronda, escoger sucesor, y vivir el sueño de demostrar el producto en el stand más grande de la feria más grande del sector, allá por Mayo del 2010 salí discretamente por la puerta de atrás.

Abiquo Cloud Expo
Haciendo demos en la CloudExpo y cogiendo leads a dos manos

10 años ya. Ojalá tengáis todos socios como Xavi o Helena. O nuestras ganas de sobrevivir. O lleguéis a ganaros el respeto de Monleón 🙂

How to become #1 in your local market in less than a year

Me ha encantado este post, que cuenta cómo salir adelante mezclando conceptos la mar de interesantes: micronicho, hacks para automatizar la cualificación de leads, más automatización de procesos en el pipeline mezclado con acciones en el MundoReal… si estuviese tan loco como para volver a montar una empresa, probablemente nos enfocaríamos soluciones para mejorar eficiencia y procesos del pipeline… Pero no lo estoy 😉

Me desayuno los chocokrispis leyendo una discusión de otros camaradas sobre este artículo de ElConfidencial, en el que cuentan cómo los comerciales de las empresas de comida a domicilio de España se pelean entre ellos. Tras unos momentos de perplejidad intenando entender la situación (“¿por qué quitar pegatinas si el cliente no las ve desde su casa?”, “¿qué métrica relacionada y fiable pueden reportar?” o “¿no es triste tener que ir de noche a quitar a escondidas pegatinas en los bares para que tu jefe reconozca tu trabajo?”), me doy cuenta de que se me ha acabado el tazón y me pongo otro.

Este segundo lo paladeo ya delante de hackernoise, y allí me encuentro un post denunciando las prácticas virales de una nueva startup llamada YayView. Lectura recomendadísima. Toda una recopilación biblia de darkpatterns, ejecutada sin el más mínimo reparo. Y supongo que presentando como resultado unas métricas verticalmente asintóticas. De esas que a ti, a mí y a los de las pegatinas nos gustaría tener. Y reportar.

Y me acabo el desayuno pensando que a Jobs gracias nunca he tenido que hacer algo así. Que en este tablero B2B en el que siempre he estado, estas jugadas a ese nivel no son necesarias. Y por otro, que este tipo de conocimientos previos, antes de llegar al mundo de negociar MSAs, POs y demás artefactos pues igual no vendrían mal. O vendrían muy bien.

Pregunta seria… Sin obviamente entrar a trabajar para una empresa B2C, ¿dónde se puede aprender todo esto?

 

 

No recuerdo por qué me dio por empezar a escribir un blog. Recuerdo muy claramente otros momentos importantes, como decir “en vez de facturarles por la universidad, nos lo montamos por nuestra cuenta“. O un “si haces mi parte del trabajo de Dirección Financiera, te prometo que me caso contigo“. Pero con lo del blog, juro que no recuerdo mucho. Me pasa a menudo.

Recuerdo que al principio, escribía para traer tráfico a ThinkInGrid (hoy Abiquo). Acabábamos de fundar la empresa, y supongo que era una forma sencilla de meter contenido. Además era 2006 y la blogosfera estaba en plena eclosión. Y supongo que haber puesto el foco en contar las vivencias desgracias de montar una startup, ayudó con la tracción.

Y así pasaron varios años, hasta que un día dejó de tener sentido. O llegó twitter y se cargó la blogosfera. O me harté de contar siempre lo mismo. O maduré, que viene a ser lo mismo. Y tras pasarme meses pagando un hosting que no usaba, lo borré todo y pasamos página.

Hasta hoy.

Portland Skyline

Hace unos meses me mudé a Portland. Y entre los muchos cambios que supone una aventura así, uno de los que más he notado es que apenas puedo discutir con nadie. Mucha de la gente con la que me podía pasar horas hablando vive en un huso horario en el que es complicado coincidir. Y en mi nueva vida, además de tener la suerte de crecer en un ambiente hiper-mega-ultra-requete-super-profesional, soy una persona menos estresada con tiempo para pensar. Y con esta combinación de circunstancias, no queda otra que volver a subir la persiana. Para contarle mis neuras al viento, supongo. Y también, para qué negarlo, porque echo de menos el buscarme problemas.

Además, mi compadre Walter corre con los gastos. No se puede pedir más 🙂

PD: Feliz día de Reyes!

(La foto del skyline de Portland es de sama093)

Andaba yo felizmente leyendo HN hace unas semanas, cuando un comentario al enésimo post sobre la cultura de Valve llamó mi atención:

Do you like scenario planning? Shell “proves” it works.

Stalinist management? Apple “proves” it works.

Velvet sweatshop? Microsoft “proves” it works.

Data über alles? Google “proves” it works.

Self-directed workplace? Valve “proves” it works.

Hay tanto inútil escribiendo tantas líneas sobre “cultura” en startups tecnológicas (y servidor no es una excepción), que sonroja que nadie caiga en lo más obvio: mientras haya dinero en la caja, da igual la cultura que tengas. Casi todas triunfan.

kathy¿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.

Close