Cómo detecté que la landing hablaba a todo el mundo y no le decía nada a nadie. Y lo que hice para arreglarlo.

Savia llevaba unos días en producción y algo no cuadraba. Las visitas llegaban — mucho más de lo que esperaba para ser un proyecto que acabo de lanzar. Pero esas visitas venían de mis redes y de esta newsletter. Gente que me sigue, que quería ver qué estaba montando, pero que no tenía en muchos casos una intención real de registrarse. Era curiosidad, no demanda. Y eso era completamente normal y esperado.

Lo que no era normal era que, entre los que sí tenían intención, la conversión era bajísima. Un 17%. No tenía claro cuál era el problema exacto. Así que antes de tocar una sola línea de código, había que invertir tiempo en entender qué estaba pasando.

Esta era la landing en aquel momento, para que entiendas al final todos los errores que cometí y que no vi a tiempo.

Antes de tocar nada, hicimos wireframes y preguntamos

Diseñé tres versiones alternativas de la landing con conceptos y copy distintos para entender qué funcionaba y qué no, y qué dirección merecía la pena explorar antes de invertir tiempo en implementación.

Un concepto más funcional y directo. Uno con más voz personal, casi narrativo. Y uno híbrido que intentaba combinar lo mejor de los dos.

Con los tres conceptos listos, los mandé a una pequeña encuesta. La conclusión cuantitativa decía que la landing actual era la que más claridad y confianza generaba. Pero cuando leí los comentarios abiertos, vi algo diferente:

«El titular de la actual + el contenido de la versión híbrida». «Me gusta la fuerza del mensaje actual, pero la otra explica mejor cómo funciona». «Las frases que hablan a dos personas distintas a la vez no casan».

Y entre las respuestas, un tuit de David Alarcón, un ex-compañero de Factorial y un máquina de hacer landing pages, que me lo dijo sin filtros: «Tu landing habla a dos públicos a la vez. La información está mezclada.»

Yo había pensado en eso al diseñarla. Había procurado poner titulares que hablasen a los dos targets a la vez. Había puesto una sección que diferenciaba explícitamente entre mentor y mentorizado. Lo había resuelto, pensé. Pero era obvio que no.

Lo que se me había escapado es que esa sección diferenciada estaba demasiado abajo en el scroll. Todo lo que venía antes — el hero, el mensaje principal, la primera impresión — hablaba principalmente a uno de los dos públicos. Epic fail. El que llegaba con el interés equivocado se iba antes de llegar a la parte que era para él.

Eso es lo más valioso que puede salir de una encuesta pequeña: no el dato, sino el patrón. Y aquí el patrón era clarísimo: hablar a dos audiencias en el mismo espacio, sin separación explícita, no le habla a ninguna.

El insight que cambió la dirección

El aprendizaje que más me quedó es deceptivamente sencillo: un hero, un target. Cuando intentas hablar a dos audiencias en el mismo párrafo, no le hablas a ninguna.

Cada persona que llega a tu landing busca verse reflejada — quiere leer algo y pensar «esto es para mí». Si el primer mensaje que recibe mezcla dos necesidades distintas, ninguno de los dos se siente interpelado.

Para un marketplace two-sided como Savia, esto es especialmente relevante. Necesitas atraer a los dos lados. Pero intentar hacerlo simultáneamente, en el mismo espacio, con el mismo copy, no funciona.

Tienes dos audiencias con problemas y motivaciones completamente distintas, y una sola landing para captarlas. La tentación es hablar a las dos a la vez para no dejar a nadie fuera. El resultado es que no conectas con ninguna.

Lo que decidí hacer

Haciendo research de landings dirigidas a dos públicos distintos, encontré un patrón que resolvía exactamente esto: una sola landing con dos narrativas completas que se alternan según quién está mirando.

No dos páginas distintas. No dos rutas distintas. Una sola página que cambia todo su contenido — hero, explicación, pasos, CTA — dependiendo de si quien la visita es mentor o mentorizado. Y lo hace de forma explícita, con un toggle visible que dice: «Quiero mentorizar» / «Busco un mentor».

Es un patrón que tiene mucho sentido para nuestro caso. Cada audiencia ve exactamente lo que necesita ver. El mentor no tiene que filtrar información que no le es relevante. El mentorizado tampoco. Y nosotros no tenemos que elegir a cuál de los dos le hablamos — les hablamos a los dos, pero por separado.

El proceso de escribir el copy para cada versión me obligó a frenar y reflexionar. Cuando te obligas a pensar solo en el mentor, la pregunta cambia: ¿por qué alguien con experiencia debería dedicar tiempo a esto? La respuesta no es la misma que ¿por qué alguien que busca orientación debería fiarse de Savia? Son conversaciones distintas, y merecen contenidos distintos.

Después de muchas iteraciones de copy — más de las que me gustaría admitir — llegamos a los titulares que mejor capturaban cada perspectiva:

  • Para el mentorizado: «Aprende de quien ya está donde tú quieres llegar.»

  • Para el mentor: «Si crees que tu experiencia puede ayudar a alguien, probablemente tengas razón.»

Son frases que hablan a una sola persona. Y eso, al final, era lo que necesitábamos. La conversión ha mejorado. El feedback de personas a las que les pasé el resultado final es que funciona mucho mejor para entender de un vistazo que Savia va de dos tipos de personas que quieren hablar entre sí.

Si tienes curiosidad por ver cómo quedó completa, puedes verla en savia.company. De paso, puedes registrarte si te apetece mentorizar a alguien o ser mentorizado. O incluso si quieres ser la dos cosas 😉 Y si estás construyendo algo con dos audiencias distintas y tienes dudas de cómo comunicar a las dos sin diluir el mensaje, me encantaría saber cómo lo estás pensando.

Artículos anteriores de la serie:

Le pedí a la IA que me dijera qué había hecho mal. Y convertí su respuesta en instrucciones.

Hace unos días publiqué un post sobre un bug que me costó 15 rondas arreglar. Un formulario que mostraba un error en rojo pero creaba el perfil correctamente. Una hora larga de ida y vuelta con Claude. Un fix de pocas líneas.

Ahora te cuento lo que hice después y cómo lo he convertido en instrucciones que ahora se aplican a cada nuevo bug del proyecto.

Cuando terminamos de arreglar el bug, no cerré la conversación. Le escribí algo a Claude que no le había escrito antes: “Ayúdame a aprender de esto. Tardamos demasiadas rondas. ¿Cómo podría haber guiado mejor el troubleshooting para resolverlo más rápido?”.

El prompt literal fue éste:

Help me learn from this bug fixing. It took too many developments and testing to understand what was broken and how to fix it. We had to try different approaches and we made several mistakes. How could I have better guided the troubleshooting to solve it more effectively and faster?

Y la IA se autoevaluó con una honestidad brutal. Disclaimer: esa honestidad brutal con la que se autoevalúa no es casual. Es algo que tengo definido en el OperatingSystem.md que es el archivo donde Claude y yo tenemos definidas las rules of engagement de cómo trabajamos juntos.

“Mostly my fault”

La primera línea de la respuesta de Claude fue: “Let me be honest about what went wrong on my side.” Y a continuación, tres errores concretos que admitió haber cometido.

Error 1: No escuchó mi descripción. Yo dije “aparece un error PERO el perfil se crea.” Claude ignoró el “se crea” y asumió un bug estándar de validación que bloquea el envío. El bug más probable, no el que yo estaba describiendo. Su autocrítica textual: “You had to correct me. That cost us the first round.”

Error 2: Propuso soluciones sin entender la causa. Cuatro o cinco enfoques distintos — cambiar el modo del formulario, useEffect, prevenir la tecla Enter — cada uno razonable por separado, pero todos basados en hipótesis, no en diagnóstico. “Each was a guess, not a diagnosis.”

Error 3: No pidió datos. Fui yo quien sugirió “vamos a poner console.logs y lo testeo.” Esa debería haber sido su primera propuesta, no la mía. “I should have asked for console debugging from the start.”

Lo más interesante no fue que Claude identificara estos errores. Es que me dijo exactamente qué frases debería haberle dicho yo para frenarle antes.

Las frases que frenan a la IA

De esa conversación salieron patrones de prompting muy concretos. No son consejos genéricos tipo “sé más específico.” Son frases exactas para usar en el momento justo.

  • Cuando la IA malinterpreta el problema: “No, you’re wrong. Re-read what I said.” Sin elaborar. Sin dar más contexto. Solo redirigir. La IA no se ofende. No necesita diplomacia. Necesita claridad.

  • Cuando propone un segundo fix sin explicar por qué falló el primero: “You’re guessing. What is the root cause? Explain it before proposing a fix.” Esta es la más importante. Si la IA no puede explicar por qué algo está roto, cualquier solución es un parche a ciegas.

  • Cuando lleva dos intentos fallidos: “Stop guessing. Add debug logs and I’ll test.” Tú eres los ojos y las manos. La IA tiene el código pero no puede hacer clic en tu pantalla. En el momento en que dejas de describir y empiezas a medir juntos, todo cambia.

Y entonces Claude dijo algo importante: “Give me constraints, not freedom.” Cuando le dije “arregla este error”, tenía demasiados grados de libertad y exploró caminos malos. Cuando le dije “ponme logs y lo testeo”, hice que se ciñese al enfoque correcto. Cuanto más específica la instrucción, más rápido converge.

Tres rondas en vez de quince. Esa era la diferencia entre describir y medir.

De conversación a sistema

Lo interesante no es haber tenido esa conversación. Es lo que hice con ella.

Hay algo fundamental que tienes que entender sobre la IA: no tiene memoria entre sesiones. Puedes tener la mejor conversación de debugging del mundo, pero la próxima vez que abras una sesión nueva, la IA empieza de cero. No recuerda que se equivocó. No recuerda que aprendió a pedir logs antes de proponer soluciones. A menos que tú lo escribas.

Depuré los aprendizajes de esa conversación y los convertí en un protocolo escrito dentro del archivo de instrucciones del proyecto — el archivo que Claude lee al inicio de cada sesión, antes de responder a nada. Cinco reglas:

  1. Escucha primero, diagnostica después. Lee la descripción completa antes de formar una hipótesis. Si algo suena raro, pregunta antes de proponer.

  2. Diagnostica antes de arreglar. No propongas un fix sin explicar la causa raíz. Si no puedes explicar por qué el bug ocurre, dilo.

  3. Si dos intentos fallan, para. Estás adivinando, no diagnosticando. Propón instrumentación — console.logs, capturas — y pide al usuario que reproduzca.

  4. Explica cada fix. Antes de implementar: qué causa el bug, por qué el código actual falla, qué cambia el fix y por qué funciona. Si no puedes articular los tres, no has diagnosticado el problema.

  5. Considera causas múltiples. Si un bug no tiene sentido con una sola explicación, probablemente hay más de una causa contribuyendo.

Esto no es una sugerencia. No es un “sería bueno que.” Es una instrucción que se ejecuta. Cada vez que alguien reporta un bug en Savia, Claude lee estas cinco reglas antes de responder. Es lo más parecido a “aprender de los errores” que puedes tener con una IA: no confiar en que recuerde la lección, sino asegurarte de que la tiene delante.

¿Funciona?

Sería fácil decir que sí y dejarlo ahí. Pero siendo honesta: funciona a medias. Seguramente porque tengo que seguir iterando.

  • Lo que ha cambiado: Claude ahora pregunta más antes de proponer. He tenido bugs después del protocolo donde la primera respuesta fue “¿puedes darme más detalle sobre qué ves exactamente?” en vez de lanzar un fix. Eso antes no pasaba. También propone debug logs más rápido, normalmente al segundo intento en vez del quinto.

  • Lo que no ha cambiado del todo: Si el contexto de la conversación es muy largo, a veces la IA pierde de vista las instrucciones iniciales. Y sigue habiendo momentos donde necesito frenarle manualmente. El protocolo no sustituye tu criterio — lo complementa.

Lo que sí noto es que el baseline es otro. El punto de partida de cada conversación es mejor. Y en debugging, empezar bien es casi todo.

La IA no aprende de sus errores entre sesiones. Pero tú puedes hacer algo que ningún tutorial te enseña: pedirle que analice qué hizo mal, convertir su respuesta en instrucciones, y asegurarte de que las lea la próxima vez.

No es un truco de prompting. Es diseño de sistemas. La diferencia entre un usuario que usa IA y uno que construye con ella está en esa capa: no solo operas la herramienta, configuras cómo opera.

¿Tú cómo gestionas los errores recurrentes con IA? ¿Tienes algún protocolo o simplemente confías en que cada sesión saldrá mejor?

Artículos anteriores de la serie: