Notas: 3 decisiones de producto que arruinan todo lanzamiento

Llevo una lista mental callada de las razones por las que los lanzamientos se tuercen, y casi ninguna es la que preocupa a los fundadores. La gente se agobia con la tecnología, con la escalabilidad, con un fallo que tire la app el primer día. Esas cosas pasan, pero rara vez son mortales. Las decisiones de producto que arruinan un lanzamiento se toman meses antes, con calma, por gente inteligente, y solo enseñan su coste al final. Tres de ellas aparecen tan a menudo que suelo detectarlas en la primera conversación. Este es el patrón, contado con honestidad, para que te pilles a ti mismo cometiéndolas antes de que te cuesten un lanzamiento.

Decisión uno: construir para todos en vez de para alguien

La primera decisión que descarrila todo es negarse a elegir para quién es el producto. Siempre suena responsable. Si la app sirve para autónomos y para pequeñas agencias y para equipos grandes, el mercado es mayor, así que ¿por qué estrecharlo? El problema es que un producto hecho para todos no tiene forma para nadie. Cada pantalla se convierte en un término medio, cada función tiene que estirarse para cubrir casos que tiran en direcciones distintas, y aquello que habría encantado a una persona concreta se lija hasta quedar en algo que a todos les resulta simplemente aceptable.

La amplitud también infla el desarrollo sin avisar. Cada nuevo tipo de usuario que prometes atender añade flujos, ajustes y casos límite, así que el alcance crece mientras el foco se encoge, que es el peor cambio posible antes de un lanzamiento. He visto a fundadores sumar tres meses y una cifra de cinco dígitos a un proyecto solo por conservar un segundo público con el que nunca habían hablado. La solución es incómoda pero barata: nombra a una persona, la que sufre el problema con más dolor, y construye la primera versión solo para ella. Luego puedes ensanchar desde un producto que la gente adora, pero no puedes estrechar para salir de un producto del que nadie está seguro de si va con él. Poner el alcance honesto pronto es justo lo que fuerza nuestra checklist para definir el alcance de un proyecto de app.

Decisión dos: tratar el lanzamiento como una meta

La segunda decisión que descarrila es tratar el lanzamiento como el final del trabajo y no como el principio. Se nota en cómo está montado el plan. Cada hora va a lanzar, y después de la fecha de salida no hay nada salvo la vaga esperanza de que los usuarios lleguen y le cuenten al fundador qué opinan. Llega el día del lanzamiento, la app se publica, y se instala un silencio que nadie planificó, porque llegar a la tienda se trató como la meta en lugar de como el pistoletazo de salida.

Un lanzamiento no es una meta, es el primer día en que obtienes información real. Los fundadores a los que les va bien ya han decidido cómo llegarán a sus primeros usuarios, qué quieren aprender de ellos y cómo harán un cambio cuando llegue el feedback, porque siempre llega. Los que sufren gastaron todo en el desarrollo y no guardaron nada para la parte que de verdad decide si el producto funciona. Si no tienes un plan para conseguir tus primeros 100 usuarios, no tienes un plan de lanzamiento, tienes una fecha de salida. El desarrollo es el precio de la entrada. Lo que haces en las semanas siguientes es el producto.

Decisión tres: añadir funciones para sentirte listo

La tercera decisión es la más seductora, porque se disfraza de diligencia. A medida que se acerca el lanzamiento y suben los nervios, el instinto es añadir. Una función más, un ajuste más, una cosa más que un usuario hipotético podría pedir, todo atornillado en la recta final para sentirte listo. Parece progreso. Casi siempre es lo contrario, porque cada añadido tardío está sin probar, sin pulir, y aleja aún más la fecha en la que por fin conoces a usuarios reales, que es lo único que no te puedes permitir.

Lo que de verdad ocurre es que añadir se siente más seguro que exponerse. Mientras haya otra función que construir, el fundador nunca tiene que enfrentar el momento en que el producto se encuentra con el mercado y podría quedarse corto. Así que el alcance se desborda, el lanzamiento se retrasa y la app se vuelve más pesada sin volverse mejor. La disciplina que salva lanzamientos es el reflejo opuesto: ante la duda, recorta. Lanza la versión más pequeña que resuelve el único problema de la única persona, y deja que el uso real, no la ansiedad, te diga qué añadir después. Es el mismo instinto que hay detrás de probar una idea antes de construirla y de tratar la palabra MVP como una disciplina y no una lista de deseos más pequeña.

El hilo que une las tres

Míralas de cerca y las tres decisiones son el mismo miedo con distinta ropa. Construir para todos, retrasar más allá del lanzamiento y amontonar funciones son formas de no elegir, y no elegir se siente seguro porque no se ha descartado nada y nada puede juzgarse todavía. Pero un producto es una serie de elecciones sobre para quién es y qué no hará, y un lanzamiento es el momento en que esas elecciones se encuentran con la realidad. Posponer la elección no elimina el riesgo, solo lo mueve al punto más caro posible, cuando el dinero ya se ha gastado.

Los fundadores cuyos lanzamientos van bien no son más valientes ni más afortunados. Simplemente han hecho las paces con elegir pronto, cuando es barato, en lugar de tarde, cuando no lo es. Eligen a un usuario, planifican el día después del lanzamiento con el mismo cuidado que el lanzamiento, y recortan antes de añadir. Nada de esto es técnico, que es justo por lo que se pasa por alto en favor de la tecnología, la escalabilidad y el fallo del primer día que probablemente no importará.

Qué hacer ahora

Si te reconoces en alguna de estas, es buena noticia, porque las tres son baratas de arreglar antes de un desarrollo y caras de arreglar después. Nombra a la única persona para la que es tu primera versión. Escribe cómo llegarás a tus primeros usuarios y qué quieres aprender de ellos. Y cada vez que sientas el impulso de añadir algo en la recta final, pregúntate si resuelve el problema del usuario o calma tus nervios. Haz esas tres cosas y habrás esquivado las decisiones de producto que arruinan la mayoría de los lanzamientos antes de que lleguen al código.

Si quieres un segundo par de ojos sobre esas elecciones antes de encargar nada, cuéntanos qué estás construyendo y te ayudamos a poner honestos el alcance y el plan de lanzamiento primero. Es el trabajo más barato de todo el proyecto, y es el que decide si el resto merece la pena.