atlas es el resultado de una startup que no funcionó (Palabra). Palabra surgió desde las ganas de desarrollar un producto y sin pensar quiénes eran los clientes o si existía una oportunidad de negocio detrás. creo que el año de trabajar en Palabra e intentar hacer el camino inverso (intentar vender algo que ya estaba desarrollado con un equipo a cuestas) hizo que Atlas solo naciera hasta haber tenido clientes.
el primer producto de Atlas fue una herramienta para solucionar la contabilidad de personas que trabajan desde Latam para Estados Unidos. nos pusimos de objetivo no desarrollar nada hasta tener la validación de que existía un interés por comprar una solución de este tipo. mi prototipo fue tener un link de Stripe por una suscripción mensual de USD25 y mi forma de validarlo fue agendar reuniones con gente que conocía (la mayoría de Twitter) e intentar vendérselo. no había app, no había scripts ni ningún tipo de desarrollo. literalmente todo lo que había era un link de cobro y mis llamadas agendadas. en esas llamadas yo les explicaba a estos potenciales clientes qué problema les solucionaríamos (altas y presentaciones fiscales, soporte mensual, facturación, etc) y mi objetivo era que compraran. en el segundo día de intentar venderlo tuvimos dos compras en la llamada misma (los esperaba a que buscaran su tarjeta de crédito) y vendimos 40 suscripciones al cabo del primer mes. eso nos sirvió para entender qué había una necesidad y solo ahí decidimos que Atlas (que al principio tenía otro nombre) empezara a existir.
no desarrollar producto hasta no tener clientes está en ADN de lo que hacemos y hoy, 2 años más tarde, me hago algunas preguntas en relación a esto:
- cómo conservar esta práctica teniendo ya un equipo establecido.
- al probar ideas nuevas sin producto introducimos mucho trabajo manual. me pregunto cuál es el momento justo para escalarlo y abandonar las tareas manuales.
- qué significa que haya una validación. ej: si hay un cambio en el ICP ¿hay que volver a validar como si estuviéramos en cero?
una pregunta que me hago aledaña pero no estrictamente relacionada es cuál es el sweet spot entre desarrollar producto nuevo (es decir: pensar ideas que pueden servirle a un cliente out of thin air) y solo desarrollar lo que un cliente necesita/pide. habiéndolo escrito pienso que seguramente la respuesta sea el proceso descrito arriba: no se desarrolla producto hasta no tener una validación y la única forma de tener una validación es con un cliente comprando.
las etapas del proceso
me parece importante identificar cuáles son las etapas que tiene este proceso. voy a hacer un primer borrador:
1. idea: pensamos qué queremos desarrollar y para quién. el desarrollo tiene que ser un producto único y chico y tiene que tener un ICP definido.
ejemplo: los empleados de las empresas quisieran poder disponer de su salario antes de la fecha de cobro. el cliente ideal es una persona que trabaja en una empresa por un sueldo menor a $X y que tiene deudas o gasta más de lo que gana.
2. definir un prototipo: el prototipo tiene que cumplir con algunas condiciones:
- rápido: desarrollarlo no nos toma más de una tarde. hay que recordar que no estamos validando una app sino que un problema exista y que nuestro usuario ideal está dispuesto a pagar por solucionarlo. hay un supuesto detrás de esto que es que si este problema es verdaderamente un pain para el usuario y no existe ninguna otra solución en el mercado el usuario va a estar dispuesto a usar un producto defectuoso e incompleto (esto siempre termina siendo cierto si hay un *pain real* y no hay competencia, por eso tomarse el tiempo de desarrollar una app para validar que existe un problema es una pérdida de tiempo).
- no-code: el prototipo nunca es una app. normalmente son cosas como un form de Google Forms, una landing page hecha en Carddd, una conversación de whatsapp. Obligatoriamente tiene que ser algo que se pueda crear en un mismo día.
- convierte: el último paso del prototipo es que la persona compre. un prototipo que solo valida un interés (por ejemplo: que un usuario nos agende una llamada o nos deje su dirección de email) no valida que exista un mercado para nuestra solución. la única forma de validar una idea es con $$.
ejemplo de prototipo: para validar que los empleados quieren tener su sueldo on-demand compramos una línea de whatsapp y creamos una conversación con cada empleado y le pedimos que nos solicite un adelanto de su sueldo cuando lo necesite. Por cada operación le cobramos $X. Validamos cuántas conversaciones y compras tenemos a lo largo de una/dos semanas.
3. validar: buscamos clientes potenciales y les presentamos nuestro prototipo.
ejemplo: en el caso de la app de sueldo on-demand vemos cuántas conversiones tenemos a lo largo de X tiempo (nunca más de un par de semanas). hay una variable cualitativa que es difícil de recoger e informal: la variable de qué tanto pull sentimos del mercado, qué tanto la gente nos comunica que esto le cambia la vida, cuánto nos recomiendan en esas primeras semanas a conocidos. Es difícil de medir pero es muchas veces lo que determina (en conjunto con haber tenido muchas operaciones exitosas en lo que dura el experimento) que el prototipo sea un éxito.
4. escalar: con la solución validada y solo cuando no demos a basto en nuestra forma de ofrecer el prototipo podemos empezar a desarrollar una solución que nos permita escalar. este paso es que el que más me cuesta y creo que normalmente paso mucho tiempo en el paso 3. el riesgo de mantenerse mucho tiempo en el paso 3 y sobre todo con un equipo de trabajo es que la gente se habitúa a que las cosas se hacen de ese modo y pierden de vista que siempre estuvimos probando un prototipo y que el trabajo manual no es la solución final. poder determinar en qué momento hay que empezar a escalar una solución es algo que todavía me escapa. mi primera intuición es que debería ser automáticamente después de haber tenido un número X de validaciones (no puede ser después de la primera porque la primera puede ser un outlier); otro indicador puede ser si el equipo que ejecuta el prototipo manualmente está al borde del burn-out. eso es un indicador de que nuestro prototipo se extendió demasiado tiempo. otra forma que creo válida para saber cuándo escalar es ponerle una fecha de fin al prototipo. la fecha es siempre arbitraria y creo que no importa. lo importante es que una vez que el prototipo se valida hay que comenzar una solución (tal vez la parte difícil es identificar cuándo algo está validado?).
diferencia entre validación y product-market fit
últimamente pienso cada vez pienso en la irrelevancia del concepto de product-market fit. mi conclusión es que todos los productos tienen un mercado dispuesto a comprar pero que normalmente los problemas son otros: no saber cuál es ese mercado; saber cuál es el mercado pero no tener acceso a él; que el mercado sea demasiado chico; que existan demasiadas soluciones iguales para ese mismo mercado y que la nuestra por falta de positioning no pueda competir, etc.
creo que usamos la idea de PMF para hablar de soluciones con clientes pagos, que aman el producto, lo recomiendan, no churnean, etc. lo escribo y pienso: esta idea es válida y me gusta que exista pero al mismo tiempo tiene un componente mágico que me gustaría que no tuviera; que la vuelve poco concreta.
creo que la idea de validar un producto en un mercado es más concreta y es más binaria: un producto tiene un comprador determinado o no lo tiene y un comprador está dispuesto a usar una solución incompleta solo cuando realmente tiene un problema que no tiene solución mejor. lo bueno de esto es que si esta validación se da esto implica que tenemos un producto para quien encontramos un cliente dispuesto a pagar y que además es monopólico que creo que es lo mejor de ambos mundos.
algo a notar de esto es que nuestro proceso de validación no valida que exista “product-market” fit, sino más bien “product-customer” fit porque nuestra validación solo nos indica que este producto es necesario para un cliente determinado, que responde a un mensaje determinado y un pricing determinados. si cualquiera de estas variables se toca el proceso comienza de nuevo.
por esta razón un producto que funcionaba muy bien para un ICP puede no funcionar por completo para otro ICP distinto. eso no implica que el producto no tenga PMF, solo quiere decir que tal vez no tiene fit para ese customer en particular. un cambio de ICP al igual que un cambio de producto es volver a cero en el proceso de validación y tenemos que tomarnos el mismo trabajo que si estuviéramos empezando una startup nueva.
tengo la intuición por esto de que el proceso de PMF/validación nunca termina. cada nuevo feature, cada nuevo mercado al que nos queramos expandir, cada cambio de posicionamiento requiere el mismo trabajo que si estuviéramos empezando con una idea nueva porque nuestro “PMF” solo validaba un conjunto de supuestos distintos/anteriores.