How to gain traction

Valida antes de construir

El error más fácil es pasarte semanas construyendo sin enseñárselo a nadie. Y ahora es todavía más fácil, porque construir cuesta muy poco.

Antes de meterte a fondo, busca una primera señal de que a alguien le importa. No necesitas una encuesta ni una landing perfecta. Un mockup, una captura, un prototipo o un vídeo corto de cómo funcionaría suelen bastar, aunque por detrás todavía no haya nada. Es lo que se llama un fake product test.

Lo que tienes que enseñar es qué conseguiría la gente si lo usara.

Publica la idea donde ya esté tu gente (X, LinkedIn, comunidades, Reddit) y deja una forma clara de levantar la mano: pedir acceso, dejar el email, apuntarse a la beta, contestar al post o escribirte por privado. Luego mira qué pasa.

Los likes y las impresiones te dicen si el mensaje llama la atención. Poco más. Las señales buenas son otras: gente preguntando cuándo puede probarlo, gente etiquetando a alguien que lo necesita, DMs pidiendo acceso, gente dispuesta a probar algo a medio hacer.

Haz el test lo más barato posible

Antes de meterle horas (o días) a una funcionalidad, contéstate esto:

• ¿Puedo explicar el producto en una frase?
• ¿Puedo enseñar el resultado sin haberlo construido entero?
• ¿Dónde está la gente que tiene este problema?
• ¿Qué pueden hacer para demostrar que les interesa?
• ¿Está pasando algo más allá de likes y comentarios por compromiso?

No hay un número mágico para decidir si sigues. Cada producto, audiencia y canal es un mundo. Lo que buscas es algo de pull: gente que se acerca al producto sin que tengas que ir convenciendo uno por uno.

Si no pasa, la idea no tiene por qué ser mala. Puede fallar el problema, la propuesta, cómo lo cuentas o dónde lo enseñas. Cambiar cualquiera de esas cosas antes de construir sale baratísimo. Cambia una y vuelve a probar.

Levantar una catedral sin saber si va a entrar alguien no tiene mucho sentido.

Después del interés viene el uso

Que la idea guste en redes solo te dice una cosa: que da curiosidad suficiente para dar el siguiente paso. No te dice que el producto sea bueno.

Cuando tengas una primera versión, dásela a un grupo pequeño y mira qué hace. ¿La usan? ¿Vuelven? ¿Terminan la acción principal? ¿Se la enseñan a alguien? Ahí empieza la segunda validación.

Con ATSKiller el valor se entendía al momento: subes tu CV y ves un análisis. Que a la gente le pareciera buena idea estaba muy bien, pero la prueba de verdad llegó cuando empezó a usarlo y a recomendarlo. Hoy lleva más de 40.000 análisis de CV.

Primero compruebas que hay interés. Luego, que el producto lo convierte en uso. Son dos pruebas distintas y hacen falta las dos.

Sin uso no hay tracción.

Que se entienda en 5 segundos

Puedes tener un producto buenísimo y perder a casi todo el mundo porque no se entiende qué hace.

Cuando alguien llega a tu landing, ve un post o abre un vídeo, tienes muy poco tiempo. Si tiene que leerse tres párrafos para saber de qué va, ya le has puesto fricción antes de probar nada.

Tiene que pillar casi al momento qué hace, para quién es y qué saca de ello. Y cuanto más intentas explicar, peor suele salir. Con una línea debería bastar.

Empieza por una frase

Describe tu producto en una frase. Como se lo contarías a alguien que podría usarlo mañana. ATSKiller cabe en esto:

Subes tu CV y ves la puntuación que te daría un ATS.

Luego ya contarás cómo funciona, qué analiza o qué tecnología lleva. Pero lo importante está hecho: esa persona sabe por qué seguir mirando.

Una pregunta que ayuda: si alguien usa tu producto hoy y mañana se lo recomienda a un amigo, ¿qué frase va a usar? Tu mejor mensaje suele andar muy cerca.

Enseña el resultado antes que las funcionalidades

Los que construimos tendemos a explicar lo que hemos construido. Un dashboard, tres integraciones, agentes, una API, veinte opciones de configuración. Al usuario le importa otra cosa: qué saca él de todo eso.

Así que en la landing, en el post o en la demo, empieza por el resultado. Mira estas dos formas de contar ATSKiller:

La primera cuenta lo que hemos hecho nosotros. La segunda, lo que ganas tú. Lo que hay por detrás (la tecnología, la IA, lo que sea) casi nunca es lo que hace que alguien lo pruebe.

Una pieza, una idea

No intentes meter todo el producto en el mismo vídeo o post. Si una demo enseña seis funcionalidades, no se acuerda nadie de ninguna. La pieza principal tiene que enseñar la mejor funcionalidad, la que más le da al usuario.

Haz varias piezas pequeñas con una idea cada una: un problema, una funcionalidad, un resultado, un caso concreto. Y de regalo tienes más material para distribuir. En vez de «el vídeo del lanzamiento», tienes varias excusas para hablar del producto.

Para vídeos y demos, cuatro reglas que te ahorran mucho tiempo:

1. Menos de 30 segundos. Si necesitas más, seguramente estás enseñando dos cosas.
2. El primer frame ya enseña el resultado. Nada de intro, ni logo, ni «hola, he construido esto».
3. Grabación de pantalla del producto haciendo lo que hace de verdad.
4. Que se entienda sin sonido, porque así lo va a ver casi todo el mundo. Si hace falta, subtítulos.

Que se distribuya solo

Conseguir usuarios de uno en uno funciona al principio, pero escala fatal. Si cada usuario nuevo depende de que publiques otro post, mandes otro DM o pagues otra campaña, la distribución siempre va a depender de ti.

Antes de lanzar, pregúntate: ¿hay algo dentro del producto que haga que un usuario traiga a otro?

No todos los productos pueden ser virales (ni les hace falta). Pero muchos pueden llevar dentro pequeños mecanismos de distribución.

Busca qué merece la pena compartir

La gente no comparte productos porque se lo pidas. Comparte cosas que dicen algo de ella, que la dejan bien, que le sirven a otro o que simplemente tienen gracia: un resultado, una puntuación, un perfil, una comparación, algo que ha creado, un logro, una invitación.

La clave es que compartirlo tenga sentido aunque a esa persona tu producto le dé exactamente igual.

En mutuals.cards esto salía solo. Podías encontrarte a ti mismo (o a alguien que conoces) convertido en carta, abrir sobres, conseguir cartas raras y enseñar tu colección. Publicar una captura era parte del juego y nadie lo sentía como hacer publicidad. Y cada publicación era una puerta de entrada para gente nueva.

Con ATSKiller pasaba algo parecido. La gente subía su puntuación después de analizar el CV, o después de mejorarlo, y eso hacía que otros entraran a probar.

Que compartir traiga usuarios nuevos es de los mejores hacks que hay para que un producto despegue.

Que el producto viaje con contexto

No basta con que algo se pueda compartir. Quien ve esa captura, ese enlace o ese resultado tiene que entender de dónde sale y poder llegar al producto sin buscarlo.

Si alguien comparte una puntuación, la imagen tiene que enseñar qué la ha generado. Si comparte un perfil, tiene que haber un enlace. Si crea algo dentro de tu producto, otra persona tiene que poder verlo o probarlo.

Parece obvio, pero es facilísimo acabar con una experiencia chula que termina en una captura sin ninguna pista del producto que la creó.

Por eso una de las mejores herramientas es la card social (la OG card): la imagen que aparece cuando pegas un enlace. Bien hecha, explica el producto y lo enseña. Así, cuando alguien publica que le ha tocado Álex Vaughtton en mutuals.cards, debajo sale esto:

Quita fricción

Cuando encuentres algo que la gente ya quiere compartir, pónselo fácil. Que el botón se vea. Que no haya que copiar cinco datos a mano. Que la imagen que se genera no sea fea. Cuanto menos curro le pidas al usuario, más probable es que lo haga.

A veces arreglar el flujo de compartir te trae más distribución que una funcionalidad nueva. Parece una tontería. Pues es lo que hace que tus primeros usuarios trabajen por ti.

No fuerces la viralidad

También es fácil pasarse. Pop-ups cada dos por tres, «invita a tres amigos para continuar» o publicaciones automáticas te dan alguna métrica a corto plazo y te destrozan el producto.

La distribución que funciona se siente como una consecuencia de usar el producto. Olvídate de cómo hacer que cada usuario invite a cinco personas. Pregúntate qué pasa dentro de tu producto que alguien tendría ganas de enseñarle a otro. Si la respuesta es «nada», piénsalo antes de lanzar.

Ojo, que no todo se comparte igual. Las herramientas para empresas rara vez se comparten. En producto B2C es mucho más fácil conseguir ese loop.

No lances a una sala vacía

Un lanzamiento funciona mucho peor cuando todo arranca de cero. Una comunidad sin conversaciones, un marketplace sin oferta, un directorio sin contenido o una red social sin gente dicen lo mismo: aquí todavía no pasa nada. Y nadie quiere ser el primero en salir a la pista.

Antes de abrir, prepara el terreno.

Siembra tú la primera actividad

No esperes que los usuarios creen todo el valor desde el minuto uno. Si es un directorio, mete tú las primeras entradas. Si es una comunidad, arranca conversaciones. Si es un marketplace, consigue oferta. Si depende de contenido, crea el suficiente para que alguien pueda explorar sin darse de bruces con una pantalla vacía.

Que el primer usuario llegue a un sitio que ya parece vivo.

Con mutuals.cards esto era clave. El producto tenía gracia porque ya había gente conocida convertida en carta. Si hubieras entrado y te hubieras encontrado cinco perfiles de desconocidos, habría sido otra historia.

Invita antes a las personas correctas

Tus primeros usuarios no deberían ser aleatorios. Busca gente con motivos para participar: porque tiene el problema, porque es de la comunidad, porque sale dentro del producto o porque puede aportar algo que mejore la experiencia de los siguientes.

No necesitas cientos. Un grupo pequeño bien elegido vale mucho más que un montón de registros fríos. Habla con ellos directamente, dales acceso antes, pregunta qué no entienden y mira cómo lo usan.

Además de pillar problemas, consigues algo muy valioso para el lanzamiento: gente que ya sabe lo que has hecho y puede hablar de ello desde el primer día.

La beta es el ensayo general

La beta no está para conseguir el máximo de usuarios. Está para preparar mejor el lanzamiento de verdad. Úsala para ver dónde se atasca la gente, qué se entiende peor, qué funcionalidades usan de verdad, qué comparten sin que se lo pidas, qué preguntas se repiten y qué errores tienes que arreglar antes de abrir.

También te sirve para saber quiénes son tus usuarios más activos. Esas personas acaban siendo los primeros testimonios, los primeros casos y muchas veces las que te ayudan a mover el producto el día que lances.

Llega al lanzamiento con movimiento

Lanzar desde cero o lanzar con 30 personas dentro parece poca diferencia, pero cambia mucho cómo se ve. Ya tienes usuarios, actividad, feedback, capturas y sabes qué enseñar. Con suerte, hay alguien esperando a que abras. Esos 30 beta testers hacen el trabajo sucio de ser los primeros.

Así el día del lanzamiento ya no va de empezar a buscar tracción. Va de amplificar algo que ya se movía.

Prepara a quien te va a ayudar

Un lanzamiento casi nunca despega porque publicas un post y esperas. Normalmente hay un grupo pequeño que hace que empiece a moverse: gente de la beta, de tu comunidad, amigos del proyecto, cuentas con audiencia o personas que tienen algún motivo para compartirlo.

La clave es no improvisar ese grupo el mismo día.

Encuentra a tus primeros amplificadores

En la beta ya has visto quién participa más, quién te da feedback, quién comparte sin que se lo pidas o quién está especialmente enganchado. Empieza por ahí. Un puñado de personas que entienden el producto vale más que una lista enorme de contactos a los que vas a mandar el mismo mensaje.

Piensa también en quién tiene un motivo natural para hablar de lo que has hecho.

En mutuals.cards mucha gente salía dentro del producto. Compartirlo era hablar de sí mismos, así que nadie sentía que te estaba haciendo un favor.

No pidas ayuda sin dar material

Si quieres que alguien comparta tu lanzamiento, que le cueste lo mínimo. Ten preparado un enlace claro, una buena captura, un vídeo corto, una frase que explique el producto, ejemplos concretos y cualquier dato que ayude a entender por qué probarlo.

No hace falta mandar un copy para pegar tal cual. Funciona mejor que cada uno lo cuente a su manera. Lo importante es que nadie tenga que investigar qué has lanzado ni buscar una imagen decente.

Personaliza los mensajes importantes

No es lo mismo escribir a alguien de confianza que a una cuenta grande. Si hay personas que pueden marcar la diferencia, escríbeles una a una: por qué crees que les puede interesar y, si tiene sentido, acceso antes que nadie.

Aun así, cuenta con que la mayoría no te va a contestar. Escribes a veinte y te responden cuatro. Es normal y no quiere decir que el producto sea malo. Si esperas otra cosa, lo intentas dos veces y lo dejas justo cuando empezaba a funcionar.

No aparezcas solo cuando necesitas algo

Si la primera conversación que tienes con alguien es para pedirle que te comparta, llegas tarde. La distribución también se construye antes: participa en comunidades, ayuda a otros, comparte sus proyectos, habla con gente de tu sector. No hace falta llamarlo networking. Los lanzamientos funcionan mucho mejor cuando formas parte de algo (de esto hablo más en Haz las cosas desde el corazón).

Haz la lista antes del día D

Antes de lanzar, ten claro a quién vas a escribir. No te fíes de acordarte sobre la marcha. Una forma sencilla de dividirlo:

Beta users

Ya han probado el producto.

Comunidad

Te sigue, participa contigo o está cerca del proyecto.

Cuentas relevantes

Personas o medios cuya audiencia encaja.

Amigos del proyecto

Gente que sabes que va a querer ayudarte.

El día D

Un error muy común es tratar el lanzamiento como una sola publicación. Terminas el producto, escribes un post, publicas y a esperar.

Un buen lanzamiento se parece más a una secuencia: distintos canales, distintos momentos y varias ocasiones de volver a poner el producto delante de la gente. No hace falta pasarte una semana haciendo ruido, pero sí ordenar bien las primeras horas.

Antes de nada: comprueba que todo funciona

El día antes, entra en tu producto como si fueras un usuario nuevo. Registro, email de bienvenida, enlaces, pagos si los hay y la analítica midiendo de verdad. En un navegador limpio, sin tu sesión abierta.

Parece un detalle menor. No lo es. El hype solo se gasta una vez. Si llevas tres semanas generando expectativa y el día D el registro se cae dos horas, lo que pierdes es a la gente que más te había ayudado a llegar hasta ahí, que es justo la que entra primero.

Primero: avisa a los más cercanos

Antes de publicar para todo el mundo, avisa a quien ya conoce el producto: beta testers, usuarios activos, gente que te ha dado feedback. No les pidas que compartan nada. Diles que ya está abierto y ya. Si has hecho bien lo anterior, algunos lo compartirán solos, y te llevas una primera capa de actividad justo antes de que llegue el resto.

Después: lanza en tu canal principal

Luego publica donde tengas más alcance: X, LinkedIn, tu newsletter, una comunidad. El post principal, simple: qué has hecho, para quién, qué consigue y dónde probarlo. No metas todo el producto ahí, para eso están la landing y las demos. Lo único que quieres es que la persona dé el siguiente paso.

A la vez: abre conversaciones

Buena parte de la distribución del principio pasa por privado: gente que sabes que tiene el problema, usuarios de antes, cuentas a las que de verdad les puede interesar. Nada de spam. Unos pocos mensajes con contexto funcionan mejor que cien mensajes idénticos.

Escribe también a quien interactuó con tus publicaciones anteriores sobre el producto. Ya han mostrado interés, no partes de cero.

Durante el día: crea nuevas oleadas

Si tienes varios vídeos, demos, casos o ejemplos, no los quemes todos en la primera hora. Repártelos:

Lanzamiento

La idea principal y el producto.

Unas horas después

Una demo concreta.

Más tarde

Un caso de uso, un resultado o la reacción de un usuario.

Al día siguiente

Primeros números, aprendizajes o cómo ha ido el lanzamiento.

Cada pieza llega a gente distinta y vuelve a llevar atención al producto.

Mientras pasa: deja hueco para reaccionar

El día del lanzamiento no debería estar lleno de reuniones. Yo he lanzado algo que se rompió y, como tenía el calendario hasta arriba, no pude arreglarlo en el momento. No lo hagas.

Tienes que poder contestar comentarios, arreglar errores, hablar con usuarios y aprovechar lo que esté pasando. Si alguien importante lo comparte, métete en la conversación. Si una duda se repite, aclárala. Si una demo funciona, empújala. Si algo se rompe, arréglalo rápido.

Planificar está muy bien, pero un lanzamiento también tiene mucho de improvisar.

Elige el canal por el producto, no por costumbre

Product Hunt, Hacker News, Reddit, LinkedIn, X, TikTok, comunidades, newsletters… No todos los productos tienen que estar en todos los canales, ni un canal sirve igual para todo.

La pregunta buena es: ¿dónde habla ya la gente que tiene este problema?

Una herramienta para developers puede encontrar a sus primeros usuarios en X, Hacker News, Reddit o una comunidad técnica. Un producto para recruiters seguramente tiene más sentido en LinkedIn. Algo muy visual puede viajar mejor en TikTok o Instagram. Y para un producto muy de nicho, una comunidad de 2.000 personas correctas puede valer más que 100.000 impresiones en un canal generalista.

Empieza donde ya tengas distribución o donde se concentren tus usuarios potenciales. Después mira qué canal trae gente que usa el producto, no solo visitas.

Hacer mucho ruido en un sitio que importa rinde más que el mismo mensaje en diez sitios donde no te conoce nadie.

Habla con todo el mundo

El día del lanzamiento no se acaba cuando publicas. Mucho de lo importante empieza justo después: preguntas, bugs, gente que no entiende algo, gente intentando hacer cosas que no habías previsto y gente contándote por qué ha decidido probarlo.

Ese día cambia tu trabajo. Ya no construyes para usuarios imaginarios. Estás viendo a usuarios de verdad usar lo que has hecho.

Responde rápido

Si alguien pregunta, contesta cuanto antes. Si encuentra un error, míralo. Si no entiende una parte del producto, no des por hecho que es culpa suya.

Los primeros usuarios te perdonan bastante que el producto no sea perfecto. Lo que llevan mucho peor es sentirse ignorados. Y una respuesta rápida cambia por completo cómo ven el producto, sobre todo cuando saben que les contesta quien lo ha hecho.

Mira dónde se atascan

Lo que te dice la gente es útil. Lo que hace, más. Fíjate en las preguntas que se repiten, en los pasos que nadie termina y en las funcionalidades que tienes que explicar una y otra vez.

Si diez personas te preguntan dónde está un botón, no necesitas una FAQ mejor. Necesitas mover el botón.

No construyas todo lo que te pidan

En un lanzamiento te llueven ideas. «Estaría bien que hiciera esto.» «¿Y si añadís aquello?» «Yo necesitaría esta integración.»

Escúchalo todo, pero no conviertas cada comentario en una tarea. Busca patrones. Una petición suelta puede ser una necesidad muy particular. Si cinco personas distintas te señalan el mismo problema, eso ya merece atención. La pregunta que importa es qué está impidiendo que más gente saque valor del producto.

Guárdalo todo

Ese día vas a generar más material del que crees: capturas, preguntas, reacciones, usos que no esperabas. Que no se pierda entre comentarios y DMs. Ve guardándolo en un sitio según pasa, aunque sea un documento feísimo. Lo vas a necesitar en el capítulo siguiente.

El lanzamiento no acaba el día 1

El día del lanzamiento concentra la atención, pero la distribución no se acaba cuando baja el pico. De hecho, los días siguientes suelen ser mejores para decidir qué merece la pena seguir empujando: ya tienes usuarios reales, preguntas reales, datos y material que antes no existía.

Piensa en la primera semana como parte del lanzamiento. No vuelvas a construir en automático.

Día 1: observa antes de sacar conclusiones

El primer día sirve para pillar señales, no para decidir si ha sido un éxito o un fracaso. Mira qué entra, qué se rompe, qué preguntas salen y qué piezas están trayendo gente.

El trabajo de ese día es el del capítulo anterior: contestar, arreglar lo que bloquea y estar ahí. Las conclusiones, después.

Días 2 y 3: vuelve a distribuir con algo nuevo

No repitas el post del lanzamiento. Ahora tienes cosas mejores que contar.

Puede ser una demo de la funcionalidad que más interés generó, un caso de uso que salió durante el lanzamiento, una pregunta que se repitió, el resultado de un usuario o una cifra que diga algo.

Cada pieza debería dar una razón nueva para descubrir el producto. Así el lanzamiento deja de depender de un único pico.

Yo suelo contar qué tal ha ido: números y los comentarios bonitos de la gente que lo ha usado.

Días 3 a 7: empuja lo que funciona

A estas alturas ya deberías ver diferencias. Igual una demo está trayendo usuarios. O una comunidad responde mejor que las demás. O un caso de uso se entiende especialmente bien. O una parte del producto se comparte mucho más de lo que esperabas.

No repartas el esfuerzo a partes iguales por inercia. Si encuentras una fuente de tracción, exprímela. Haz más contenido alrededor, habla con esos usuarios y pon todavía más fácil lo que ya está pasando.

Con ATSKiller pasó eso. Era útil, la gente empezó a compartirlo y siguió circulando mucho después del lanzamiento. El día del lanzamiento solo fue el principio.

Convierte lo que pasa en piezas nuevas

Aquí usas todo lo que guardaste el día del lanzamiento. Tus primeros usuarios explican el producto mejor que tú. Una reacción buena puede ser un testimonio. Una pregunta que se repite, una demo. Un uso inesperado, un post. Un usuario con un buen resultado, un caso.

Es la forma más barata de seguir distribuyendo: contenido que te han escrito tus usuarios y que, encima, suena mucho mejor viniendo de ellos.

Eso sí, pide permiso antes de usar mensajes, capturas o historias de nadie.

Al final de la semana: decide dónde va el siguiente esfuerzo

Después de unos días sabes bastante más que antes de lanzar. Puede que haya una señal clara que merezca más distribución. Puede que el problema principal esté dentro del producto. O puede que hayas conseguido atención pero poco uso.

No vuelvas al backlog sin más. Decide qué toca hacer según lo que ha pasado.

A mí hablar directamente con usuarios me ha llevado a construir mejores funcionalidades después del lanzamiento, y eso es lo que mantiene vivo el producto.

Tracción o ruido

Después de lanzar es muy fácil quedarse con los números que mejor lucen: visitas, likes, registros, impresiones, menciones. Todos cuentan una parte de lo que ha pasado, pero ninguno demuestra por sí solo que tengas tracción.

La pregunta importante es otra: ¿qué hizo la gente después de llegar? ¿Usó el producto?

Yo lo miro en cuatro capas.

1. Atención

Es la capa que más se ve: impresiones, visitas, menciones, gente entrando en la landing. Te dice si has conseguido distribución y si el mensaje ha despertado interés.

Un lanzamiento puede llamar mucho la atención porque lo compartió una cuenta grande, porque una pieza funcionó especialmente bien o porque acertaste con el momento. Buena señal, pero todavía dice poco del producto.

2. Activación

Aquí empieza a importar lo que pasa dentro. ¿La gente entiende el producto? ¿Completa la acción principal? ¿Llega al momento en el que recibe valor?

Si tienes muchas visitas y casi nadie llega hasta ahí, toca averiguar qué falla: la promesa, el onboarding, el producto o que estés trayendo a la gente equivocada.

3. Retención

La activación demuestra que alguien ha sacado valor una vez. La retención te dice si hay un motivo para volver.

No todos los productos necesitan uso diario ni semanal. Lo importante es definir qué significa volver en tu caso: abrirlo otra vez, terminar otro proyecto, repetir una compra o volver a usarlo cuando reaparece el problema.

Un lanzamiento fuerte puede tapar una mala retención durante unos días. Mientras entra gente nueva parece que todo crece, aunque los de ayer se estén yendo.

Retener es lo más difícil de todo. Si tu producto tiene motivos para volver de vez en cuando, aprovéchalos y premia a quien vuelve.

En mutuals.cards se regalan 5 sobres de cartas cada 2 horas. Así que la gente vuelve todos los días a recogerlos y abrirlos.

4. Referral o revenue

En algunos productos la señal fuerte es que los usuarios traen a otros. En otros, que pagan. En algunos, las dos.

No necesitas tener todas las métricas perfectas. Necesitas saber qué comportamiento demuestra mejor que alguien ha sacado suficiente valor como para seguir, recomendarlo o pagar.

Elige una métrica pegada al valor

No hay una métrica universal. En un producto será terminar un proyecto. En un marketplace, una transacción. En ATSKiller, completar un análisis. En una suscripción, que la gente lo siga usando varias semanas después.

Cuanto más cerca esté tu métrica del valor que recibe el usuario, más difícil será engañarte con números gordos que no significan gran cosa.

Una última prueba

Imagina que mañana dejas de publicar sobre el producto. Ni DMs, ni campañas, ni newsletters.

¿Seguiría pasando algo?

¿Volvería gente? ¿Entraría gente recomendada por otros? ¿Habría uso? ¿Habría pagos?

Si la respuesta empieza a ser que sí, tienes algo que se mueve más allá del lanzamiento. Si todo se para en cuanto dejas de empujar, todavía dependes de distribución externa. Y no pasa nada. Lo importante es saberlo, porque lo siguiente que decidas cambia por completo.

Haz un post-mortem

Un lanzamiento te deja muchísima información y, si no la ordenas, en pocos días se pierde la mitad. Cuando baje el ruido, dedica un rato a repasar qué pasó de verdad. Con una página suele bastar.

1. Qué pasó

Antes de interpretar nada, apunta los números: cuánta gente llegó, cuánta completó la acción principal, cuánta volvió, cuánta pagó, cuánta llegó recomendada y qué canales trajeron usuarios que valen la pena.

No mires solo el volumen. Un canal puede darte 2.000 visitas y casi ningún usuario activo. Otro, 100 visitas y 30 personas que vuelven. El segundo es el interesante.

2. Qué movió de verdad el lanzamiento

En un lanzamiento pasan muchas cosas a la vez: una cuenta grande lo comparte, un vídeo funciona especialmente bien, una comunidad empieza a moverlo, un usuario publica una captura. No des por hecho que todo pesó lo mismo. Intenta separar lo que provocó resultados de lo que simplemente coincidió con ellos. No siempre lo sabrás con precisión, pero deberías salir con una idea bastante clara de qué repetir.

3. Qué salió mal

Es la parte más útil. ¿Qué se rompió? ¿Qué no entendió la gente? ¿Qué canal no funcionó? ¿Qué preparaste y no usó nadie? ¿Qué deberías haber tenido listo antes? ¿Qué hiciste tarde?

No hace falta justificar cada error. Apúntalo mientras te acuerdas. La idea es que el siguiente lanzamiento no empiece de cero.

4. Qué harás distinto la próxima vez

Para terminar, contesta solo a esto:

¿Qué repetiría?

Lo que funcionó lo bastante bien como para volver a hacerlo.

¿Qué cambiaría?

Lo que tenía sentido pero ejecutaste mal o se puede mejorar.

¿Qué dejaría de hacer?

Lo que se comió tiempo y apenas aportó.

Con eso tienes buena parte del plan del siguiente lanzamiento.

5. Si hay algo que contar, cuéntalo

Un buen post-mortem también es contenido. No hace falta publicar todos los números ni nada sensible, pero contar qué funcionó, qué salió mal y qué aprendiste es mucho más interesante que otro «hemos lanzado».

Y de paso vuelve a poner el producto delante de gente que igual no lo vio el día del lanzamiento. Lo que aprendes se convierte en otra pieza de distribución.

Checklist

No hace falta tenerlo todo perfecto. La idea es llegar al lanzamiento sin los errores más evitables y con señales suficientes para saber qué hacer después.

Una última cosa

Construir nunca ha sido tan fácil. Por eso lanzar ya no puede ser terminar un producto y publicarlo.

Lo difícil sigue siendo lo de siempre: que alguien se interese, lo pruebe, vuelva y se lo cuente a otra persona. No necesitas una gran audiencia ni una campaña perfecta. Necesitas enseñar las cosas pronto, fijarte más en lo que hace la gente que en lo que opina, preparar bien la distribución y estar muy cerca de tus primeros usuarios para entender qué funciona.

Y cuando encuentres algo que funciona, no tengas prisa por pasar a lo siguiente.

Empújalo.

Espero que te sirva. Si lanzas algo después de leer esto, mándamelo por X, que me hace ilusión verlo.