más ideas sobre PMF

Escribí sobre cómo hicimos un producto con PMF en Atlas en un posteo anterior. Últimamente estuve pensando en otros modos de construir productos que tengan PMF y me he encontrado con otros ejemplos de cómo hacerlo y quería dejarlo anotado por acá.

  • Vender antes de construir producto (the Atlas way). Un MVP que se pueda hacer en una tarde (un link a Stripe should be enough si el pain es lo suficientemente grande) y vender suscripciones. Empezar a desarrollar producto solo cuando hay suficiente volumen y no escala seguir resolviendo el problema a mano vs. hacerlo con tecnología. El problema de este approach es que no sirve para cualquier tipo de industria (pienso en productos que son complejos de desarrollar como biotech o hardware) y también con el tiempo pienso cada vez más que es un approach 'fuerza bruta' cuando uno no tiene ni idea de quiénes son sus clientes o dónde están. Creo que hay mejores maneras. Más sobre este modelo acá.
  • Desarrollar producto dentro de otra empresa (the spin-off way). El principal problema de quienes hacemos producto es que muchas veces hacemos producto porque nos gusta aunque no haya nadie dispuesto a comprar. La ventaja de ser un producto adentro de una empresa más grande es que desarrollamos necesariamente para un cliente (aka la empresa dentro de la que estamos) y podemos tener la certeza de que el producto estamos haciendo es necesario y alguien pagaría por él. 

(Voy a contar un ejemplo de una idea que es así porque creo que puede servir a otros para pensar si una idea tiene PMF:).

En Atlas los equipos siempre necesitan más tecnología y algunas veces aparece una idea que pienso que podría ser una empresa en sí misma. Tengo una idea en la que pienso mucho últimamente de este tipo. Mis indicadores de que tendría PMF son que: 1) entiendo perfectamente el problema y sé for a fact que no existe una solución porque ya buscamos en las herramientas disponibles )(por lo que este producto sería un "Category-defining product") 2) sé que es necesario porque nuestro equipo lo necesita y entrevisté suficientes perfiles en ese rol que sé que esto siempre es un pain 3) creo que es una industria que se puede actualizar y una herramienta así lo haría (mejor UX/UI que lo disponible; otro appoach a las soluciones que ya hay) 4) conozco los primeros 20 clientes de esta empresa y sé que lo usarían (empezaría por nuestros clientes de hoy con quienes ya hice vínculo y que tengo confianza) 5) puede describir perfectamente el ICP de los primeros 100 clientes (creo que serían founders ingenieros que tienen este problema en empresas chicas de < 100 empleados, B2B, US based) 6) sé que es un producto sticky pq se integra con todo tu stack actual 7) sé que es para un equipo en empresas que tiene budget y al que sería fácil vender.

Creo que hay otro approach pero todavía no termino de sacarle la ficha: the Notion/Figma way. Desarrollar algo a puertas cerradas durante años y salir y tener un muy buen producto al que le va bien. Creo que el problema de este approach es que todos se piensan Ivan de Notion o Dylan de Figma y la verdad es que pocas personas hacen producto de esa calidad teniendo cero feedback de usuarios. La pregunta que me hago porque no lo sé es si efectivamente estas personas no tuvieron feedback o fueron lanzando pequeñas iteraciones. Con la info que tengo hoy pienso que la única manera de hacer esto y que salga bien es conocer suficiente sobre una industria como para saber que ese producto es necesario. Creo que si uno es un experto en un problema puede desarrollar algo solo con base en lo que sabe de ese problema y la solución va a estar on point. Tal vez la pregunta es si las personas que desarrollan productos con este approach son expertos absolutos en ese problema. Si me guío con mi experiencia con Palabra (mi startup sin PMF) la rta es no. Yo no era experta en ese problema. Necesitaba feedback para poder desarrollar un producto mejor.

  • Ser un experto absoluto en un problema y desarrollar algo a puertas cerradas (the Notion way). Como dije antes creo que este approach solo funciona si uno es un experto en un problema y además es increíble ejecutando. No me animo a poner las manos en el fuego por este approach porque lo vi salir mal muchas más veces de las que lo vi salir bien (pienso en Humane y el producto que lanzaron hace poco). Creo que tengo que seguir pensando en esta opción pero si fuese unx founder sin experiencia sin duda iría por alguna de las dos primeras.