Construir a oscuras antes del product-market fit

Primera semana en Sell2Rent. A las 10 a. m. estoy en una reunión de marketing y a las 11 en un standup de desarrollo. El equipo de marketing habla de adquisición de leads. El de desarrollo habla de arquitectura de formularios. Nadie en ninguna de las dos salas sabe de qué acaba de hablar la otra.

No hay roadmap de producto. No hay design system. No hay documentación que conecte lo que marketing promete con lo que el producto entrega. La VP de Marketing está a punto de irse. El CRM lleva cuatro meses pagado y nadie lo ha usado.

La mayoría de los diseñadores vería eso y pensaría: necesitamos proceso. Necesitamos estructura. Necesitamos un roadmap. Después de 8 años en startups de etapa temprana aprendí que es lo contrario. Antes del product-market fit, la habilidad más importante no es el diseño. Es saber qué tan poca estructura necesitas en realidad.

Cómo se ve de verdad el product-market fit (no es un lanzamiento)

Marc Andreessen describe el PMF como una sobrecarga sistémica. Clientes comprando más rápido de lo que puedes atenderlos. El uso amenazando la estabilidad de los servidores. Tickets de soporte acumulándose porque a la gente le importa lo suficiente como para quejarse.

Hasta que llegues a ese umbral, la única métrica que importa es qué tan rápido estás aprendiendo. No cuántas features lanzaste. No qué tan limpios están tus archivos de Figma. No qué tan completo está tu design system. Qué tan rápido estás aprendiendo lo que los usuarios realmente necesitan y si lo estás construyendo.

En Sell2Rent perdimos a nuestro principal socio de leads. Más del 50% de los leads desapareció. La respuesta no fue un documento de estrategia de tres meses. Fueron cientos de pruebas de CRO, variaciones de landing pages y experimentos de conversión. 76% más de leads orgánicos en cuatro meses. Esa velocidad de iteración solo fue posible porque no cargábamos con un proceso que no le servía al problema.

Por qué el proceso tradicional te mata antes del PMF

He trabajado en proyectos con roadmaps completos, user stories detalladas y decisiones centralizadas. Algunos igual fracasaron.

Keller Offers tenía 64 pantallas, un design system construido sobre MUI y pruebas de prototipo con usuarios reales. El NPS salió en 90. El proyecto fue retirado por el cliente en la entrega final. No porque el diseño estuviera mal. Sino porque el proceso estructural alrededor estaba roto de maneras que ninguna cantidad de documentación habría arreglado.

Las dos trampas de proceso que veo matar equipos de etapa temprana:

La trampa del roadmap. Cualquier plan de más de dos a cuatro semanas antes del PMF es ficción. Estás adivinando lo que los usuarios van a necesitar con supuestos que nadie ha validado. El plan da una falsa sensación de avance mientras el aprendizaje real se estanca.

La fricción de abstracción. De esta nadie habla. Documentación detallada, user stories exhaustivas, wireframes anotados. A veces el spec toma más tiempo en escribirse que la feature en construirse. Eso no es proceso. Es deuda intelectual disfrazada de rigor.

Esto no significa trabajar sin ninguna estructura. Significa que la estructura tiene que ser mínima, rígida en la cadencia y flexible en la dirección.

El ritmo operativo que sí funciona

Después de pasar por Mentive, Customela, Keller Offers y Sell2Rent, este es el ritmo en el que me quedé para equipos pre-PMF:

Ciclos de dos semanas con una sola meta. No una lista de features. Una meta: mejorar retención, subir activación, reducir el time-to-value. Todo lo que el equipo lanza en esos 14 días sirve a esa meta. Si una idea no se conecta con ella, espera.

Califica todo antes de construirlo. Los ingenieros etiquetan las ideas como fácil, media o difícil. Nada que tome más de un ciclo se aprueba. Si es muy grande, se parte o se mata. Así evitas el scope creep que se come a las startups sin hacer ruido.

Medición antes del código. Las analíticas de una feature se definen antes de que alguien escriba una línea de código. No después. No durante. Antes. Es el mismo principio de hablar con desarrollo antes de abrir Figma: alinearse en cómo se ve el éxito antes de empezar a construir.

En Sell2Rent, este ritmo me permitió correr experimentos de CRO, migraciones de CRM y diseño de producto en paralelo sin ahogarme. La cadencia fue la restricción que volvió manejable el caos.

El diseñador fundador: ser especialista es un lujo que no te puedes dar

En una empresa madura puedes ser «product designer» y eso significa una cosa. En una startup pre-PMF significa todo.

En Sell2Rent mi cargo decía Senior Product Designer. Mi trabajo real era product design, CRO, automatización de marketing, arquitectura de HubSpot, SEO, estrategia de marca y, al final, herramientas de IA. Eso no es scope creep. Eso es lo que significa «product designer» cuando eres el único en una empresa de 35 personas.

El rol de diseñador fundador exige tres capacidades que la escuela de diseño no enseña:

Programar lo suficiente para prototipar en el medio real. Yo uso v0 para tomar diseños de Figma y generar componentes de React funcionales. El back-end se queda con desarrollo. Pero cuando entregas un prototipo funcionando en vez de un mockup estático, la conversación con ingeniería cambia por completo. La brecha entre la intención de diseño y el producto construido, la brecha que hundió a Keller Offers, se comprime.

Saltarte los wireframes cuando la velocidad importa más que la documentación. En etapa temprana, pasar de un boceto en papel a un prototipo de alta fidelidad en un día le gana a gastar tres días en wireframes anotados que nadie lee. La meta es validar, no documentar.

Pulir con estrategia. Hay investigación seria que muestra que la calidad estética construye confianza temprana incluso con un set de features incompleto. Una interfaz limpia y profesional compensa bugs y funciones que faltan de una forma que un producto funcional pero feo no logra. Esto importa especialmente cuando cada lead potencial en Sell2Rent representa ingresos reales.

Haz cosas que no escalan (y no es una metáfora)

El consejo de Paul Graham de «hacer cosas que no escalan» es el principio más repetido y menos seguido en las startups. Todo el mundo lo cita. Casi nadie lo hace.

En Sell2Rent, antes de automatizar el matching de inversionistas en HubSpot, lo hacíamos a mano. Yo construí la lógica del CRM, las etapas del ciclo de vida, las secuencias de email y los disparadores de automatización. Pero antes de que nada de eso existiera, el equipo emparejaba inversionistas con deals manualmente. Ese proceso manual nos enseñó más sobre lo que la automatización necesitaba hacer que cualquier planificación previa.

Lo mismo aplica a la investigación con usuarios. El Mom Test lo dice sin rodeos: no le preguntes a los usuarios «¿usarías esto?». Pregúntales «¿qué hiciste la última vez que tuviste este problema?». Conversaciones manuales, una por una, con usuarios reales.

La tentación siempre es escalar antes de entender. Mandarle una encuesta a 500 personas en vez de hablar con 15. Grabar un walkthrough de 45 minutos en Loom en vez de tener una conversación de 10. La versión que no escala casi siempre es la que produce aprendizaje de verdad.

Deuda de diseño a propósito

La velocidad pre-PMF exige lanzar cosas que sabes que no son perfectas. La distinción clave es entre deuda intencional y deuda no intencional.

La deuda de diseño intencional significa lanzar una UI subóptima para validar si el valor central de la feature resuena. Sabes que el diseño visual no es el final. El modelo de interacción está en bruto. Pero la pregunta central —¿esto resuelve el problema?— se responde antes de invertir en pulido.

La deuda no intencional es lo que pasa cuando la comunicación se rompe. El equipo de desarrollo escoge una librería de componentes sin consultar a diseño. Los cambios de alcance ocurren sin documentación. La brecha entre lo diseñado y lo construido crece hasta que nadie sabe qué decisiones fueron intencionales y cuáles fueron accidentes.

He vivido las dos. La deuda intencional en Sell2Rent, donde lanzábamos experimentos de CRO sabiendo que se refinarían después, produjo aprendizaje real. La no intencional en Keller Offers, donde se adoptó Devias Kit Pro sin discutirlo, dejó una brecha permanente entre Figma y producto que contribuyó al fracaso del proyecto.

La regla que sigo: toda la deuda se anota. Qué se lanzó, qué se comprometió y cómo se ve el arreglo cuando llegue el momento. La deuda sin libro de cuentas no es estrategia. Es negligencia.

Cuándo sabes que llegó la hora de una estructura real

La estructura pre-PMF es mínima a propósito. Pero hay señales que te dicen que la fase mínima se está acabando y que debe entrar proceso de verdad:

Las curvas de retención se aplanan. Dejas de perder usuarios después de la primera semana. Un grupo central se queda y usa el producto de forma constante. Eso significa que la propuesta de valor está pegando y ahora toca optimizar, no solo descubrir.

Aparece el voz a voz orgánico. Los usuarios recomiendan el producto sin que se los pidan ni los incentiven. En Sell2Rent, cuando los inversionistas empezaron a referir a otros inversionistas a la plataforma sin ningún programa de referidos, esa fue la señal.

Los usuarios se enojan por las caídas. Cuando a la gente no le importa tu producto, no nota que está caído. Cuando le importa, lo nota al instante. La sensibilidad a la interrupción es un indicador de product-market fit.

En ese punto el design system importa. La documentación importa. El roadmap importa. Pero solo porque te ganaste el derecho de planear aprendiendo qué vale la pena construir.

El framework real: aprende rápido, documenta liviano, lanza sin parar

Después de 8 años construyendo producto en seis startups, desde UI puro en Mentive hasta manejar todo el stack de producto en Sell2Rent, esto es lo que sé del pre-PMF:

La meta no es un producto bonito. La meta es aprender en qué tiene que convertirse el producto.

Ciclos cortos, una sola meta a la vez, medición antes del código, procesos manuales antes de la automatización y deuda intencional con libro de cuentas. Esa es la estructura mínima que maximiza el aprendizaje.

Todo lo demás —los roadmaps, los design systems, la documentación completa— es una herramienta para la siguiente fase. Meterlo demasiado temprano no te vuelve riguroso. Te vuelve lento. Y antes del PMF, ser lento es lo más caro que puedes ser.

¿Quieres ver cómo aplico estos principios en proyectos reales? Mira mis case studies o conéctate conmigo en LinkedIn.