Programar en vez de vender es la forma de procrastinar más convincente que tiene un fundador, porque deja algo real detrás. Añades una función, la app es de verdad mejor y sientes que trabajaste. Pero si nadie ha usado las últimas cinco cosas que construiste, la sexta no es trabajo de producto.
Es procrastinar con historial de commits. La señal honesta de que lo estás haciendo es simple: sigues mejorando un producto que casi nadie ha visto.
¿Debo añadir funciones o buscar clientes?
Si tienes que preguntarlo, ya lo sabes. La pista no es la pregunta, es tu reflejo cuando la prospección se pone incómoda. La petición de función parece urgente, el roadmap parece atrasado y construir lo siguiente parece lo responsable. Nada de eso tiene que ver con el cliente.
Tiene que ver con que estás más cómodo en el editor que en la bandeja de entrada de alguien.
La versión simple es esta. Antes de que gente real haya usado lo que tienes, más funciones no te pueden decir nada. Estás añadiendo respuestas a preguntas que nadie ha hecho todavía. La única información que importa al principio viene de alguien de fuera de tu cabeza que toca el producto y se queda o se va.
Hasta que eso pasa, cada función es una suposición encima de otra suposición.
¿Cómo distingo el trabajo de producto real de evitar vender?
El trabajo de producto real parte de una persona. Alguien usó el producto, se topó con un muro, te lo dijo o te lo enseñó con lo que hizo, y tú arreglas ese muro concreto. Evitar vender parte de personas imaginarias. Te imaginas a un usuario que querría esto y construyes para él.
La diferencia está en si puedes decir para quién es la función y señalar el momento en que la necesitó. Si la respuesta es hipotética ("a un usuario le podría interesar exportar a CSV"), es una suposición.
Si la respuesta es concreta ("tres de las siete personas que lo probaron pidieron CSV la misma semana"), es trabajo. Siete personas bastan para actuar. Cero personas no es una versión más pequeña de siete. Es otra categoría, y por mucho que construyas eso no cambia.
Una función que nadie pidió no es progreso. Es una apuesta hecha antes de que nadie se sentara a la mesa.
Añadir funciones sin parar cuando no tienes usuarios
Añadir funciones sin parar con usuarios es un problema de disciplina. Hacerlo sin usuarios es un problema de esconderse, y es peor, porque se siente como lo contrario de esconderse. Estás produciendo. El repo está activo. El changelog es largo.
Y todo ese tiempo, el cuello de botella real, conseguir que un desconocido mire el producto, sigue intacto porque es la única tarea que no tiene código que escribir ni una sensación clara de terminado.
Yo he rehecho una página de ajustes para no enviar cinco mensajes. Los mensajes me habrían enseñado algo. La página de ajustes no me enseñó nada, salvo que se me da muy bien evitar mensajes.
Si alguna vez reorganizaste el esquema de tu base de datos el día que te habías prometido hacer prospección, conoces exactamente la sensación, y sabes que no es una virtud.
Deja de programar y empieza a vender: la regla que sí aguanta
La fuerza de voluntad no arregla esto, porque construir se siente bien de verdad y vender se siente mal de verdad. Necesitas una regla que te quite la decisión, así que aquí está la que uso yo. Tiene una sola pieza móvil a propósito.
Ninguna función nueva hasta que N personas adecuadas hayan visto la actual.
Esa es toda la regla. La mecánica alrededor:
- Elige N y la persona. Pequeño y real. Algo como "veinte fundadores en solitario que llevan su propia prospección". No un mercado, una persona que te puedas imaginar. Si no te la puedes imaginar, no la puedes contar.
- "Verlo" significa usarlo, no visitarlo. Una visita a la página no es una persona. Se registró, hizo clic por ahí o vio cómo se lo enseñabas. Eso cuenta como visto.
- La función que tienes queda congelada hasta que llegues a N. Los bugs que impiden usarla sí se pueden arreglar. El pulido, las partes nuevas, eso que te mueres por construir, todo bloqueado.
- Cuando llegas a N, lees lo que pasó antes de construir. Qué hicieron, dónde se atascaron, qué pidieron dos veces. Ahora tienes una cola que vino de fuera de tu cabeza.
- Entonces, y solo entonces, construyes lo primero de la lista. Y el contador vuelve a cero. La siguiente función espera al siguiente N.
La regla funciona porque hace que la tarea incómoda sea la única desbloqueada. Quieres construir, y el único camino de vuelta a construir pasa justo por la prospección que llevas tiempo evitando. Deja de ser una pelea de fuerza de voluntad y se convierte en una puerta.
Dónde encaja una herramienta, y dónde no
Puedes aplicar esta regla hoy con nada más que una hoja de cálculo y tu propia bandeja de entrada, y deberías, al menos hasta que conseguir que la gente vea el producto sea el único paso que sigue fallando. Si tu problema es que sigues construyendo en vez de lanzar, ningún software lo arregla. La puerta de arriba es gratis, y es todo el arreglo.
El único sitio donde una herramienta se gana su lugar es el paso dos, donde "verlo" tiene que significar que N personas reales miraron de verdad. A mano eso no escala. Un recorrido de verdad para una persona son diez minutos, y veinte de esos son tu semana entera, así que poco a poco se degrada hasta ser un envío genérico que nadie ve.
Ese es el muro para el que construí Personade, lo que lo convierte, sí, en una cosa más que construí en vez de vender. La diferencia es que existe para empujarte a volver a enviar.
Lleva tu prospección en LinkedIn: la invitación, el mensaje y los seguimientos, enviados desde tu propia cuenta, y se detiene en cuanto alguien responde. Si tu mensaje es un recorrido en video, un complemento de video encima da a cada lead su propia versión con una apertura pensada solo para él, y te dice quién lo vio. Esa es la señal de "lo vio", contada para ti.
Lo que no hará es escribir tus mensajes, elegir tu N ni convertir un producto que nadie quiere en uno que la gente sí quiere. Esas partes siguen siendo tuyas.
Si quieres la versión larga de por qué pasó este cambio, escribí sobre por qué construir se volvió gratis y vender no, y si el problema de fondo es que te saltaste la distribución por completo, empieza por ahí.
Preguntas frecuentes
¿Debo añadir más funciones o centrarme en conseguir clientes? Primero clientes, casi siempre. Una función solo te enseña algo cuando gente real ha usado el producto y te ha mostrado dónde se rompe. Sin usuarios, una función nueva es una suposición sin nada con qué comprobarla. Ponte una regla que puedas cumplir: ninguna función nueva hasta que un número fijo de personas adecuadas haya usado la actual.
¿Cómo sé si estoy programando para no tener que vender? Hazte dos preguntas sobre la función. ¿Para quién es, y cuándo se topó con el muro que arregla? Si puedes nombrar a personas reales y el momento exacto, es trabajo de producto. Si el usuario es hipotético y el momento es "algún día", es evitar vender. Un repo activo y un changelog largo parecen progreso, pero no miden nada mientras nadie haya visto el producto.
¿Qué regla sirve para dejar de añadir funciones cuando no tienes usuarios? Congela el producto hasta que un número fijo de personas adecuadas haya usado lo que ya construiste. Elige algo pequeño y real, como veinte. "Usarlo" significa que se registraron e hicieron clic por ahí, no que visitaron una página. Solo cuando llegas a ese número lees lo que hicieron y construyes lo más pedido. Luego el contador vuelve a cero y empiezas otra vez.
Las funciones de las que estás orgulloso son invisibles para todos menos para ti hasta que alguien de fuera de tu cabeza tenga un motivo para tocarlas. Eso no es un problema de construir, y el problema de construir ya lo resolviste.
Es la única tarea sin una sensación clara de terminado, y justo por eso sigue perdiendo contra la que sí la tiene. Pon la puerta delante de ti esta semana y deja que decida ella.