Marcos de discovery y validación que evitan las funcionalidades muertas

Son las 4:47 PM de un jueves. El CRO deja un mensaje de Slack: "Acaba de abandonar un logo grande. Querían enrutamiento de aprobaciones personalizado. Necesitamos esto en el roadmap del Q3". Para la sincronización de liderazgo del viernes, "enrutamiento de aprobaciones personalizado" es un entregable comprometido del Q3. Se asigna a dos ingenieros. Seis meses después se lanza, el 9% de las cuentas lo toca en los primeros 60 días, y nadie sabe explicar qué problema resolvió en realidad.

He lanzado esa funcionalidad. Dos veces. Una en una herramienta de flujos de trabajo, otra en un CRM. Ambas veces el diagnóstico fue el mismo. Nos saltamos el discovery porque alguien con un cargo convirtió un único dato en una estrategia. El trimestre de ingeniería no fue el costo. El costo fueron las tres oportunidades que no exploramos porque el equipo estaba ocupado construyendo la funcionalidad preferida del cliente más ruidoso.

Si usted es un PM que sigue lanzando cosas que nadie adopta, esta guía es el stack de discovery que ojalá alguien me hubiera entregado hace tres años.

Por qué lanzar la primera idea fracasa

Los benchmarks de producto de Pendo han sido deprimentemente constantes durante una década. Entre el 60% y el 70% de las funcionalidades en productos de B2B SaaS ven menos del 15% de adopción en los primeros seis meses. Algunos estudios sitúan la tasa de funcionalidades muertas aún más alta. Eso no es un fallo de un solo equipo; es la tasa base de construir antes de validar.

Llamemos a esto por su nombre. Adopción por debajo del 15% tras 60 días = funcionalidad muerta. No "necesita más enablement". No "el motor de GTM está mal". Muerta. La cohorte que la necesitaba no la usó, la cohorte que no la necesitaba la ignoró, y ahora tiene superficie que mantener para siempre.

Un trimestre muerto no son 12 semanas de tiempo de ingeniería. Son 12 semanas de tiempo de ingeniería, más tiempo de PM, más tiempo de diseño, más QA, más la deuda técnica que arrastrará durante años, más el costo de oportunidad de las otras tres apuestas que no hizo. Un squad de cuatro ingenieros que lanza una funcionalidad muerta quema aproximadamente 400K USD de costo totalmente cargado. No tendrá muchos de esos antes de que alguien en finanzas empiece a hacer preguntas incisivas en el QBR.

La solución no es "investigar más". Es una práctica de discovery que corre cada semana, no como un sprint.

El árbol de oportunidades y soluciones (Teresa Torres)

El árbol de oportunidades y soluciones de Teresa Torres es el único artefacto que más ha hecho por mi sentido de producto. La estructura es brutalmente simple:

                Outcome
                   |
         +---------+---------+
         |         |         |
    Oportunidad Oportunidad Oportunidad
         |         |         |
      +--+--+   +--+--+   +--+--+
      |     |   |     |   |     |
    Sol   Sol Sol   Sol Sol   Sol
      |
   Pruebas de suposiciones

Outcome en la cima: un resultado de negocio o de producto medible, como "aumentar los workspaces activos semanales en un 20%". No una funcionalidad. No un lanzamiento. Un resultado.

Oportunidades son problemas del cliente, formulados en el lenguaje del cliente, que (si se resuelven) moverían el resultado. "Los nuevos admins no pueden saber qué proyectos están atascados" es una oportunidad. "Construir un dashboard de salud de proyectos" no lo es. Eso es una solución.

Soluciones se sitúan bajo las oportunidades, de tres a cinco por oportunidad. Baratas, múltiples, y compitiendo explícitamente entre sí.

Pruebas de suposiciones se sitúan bajo cada solución. Estos son los experimentos reales (fake doors, prototipos, MVP de conserjería) que deciden si la solución se construye.

La razón por la que la mayoría de los equipos fracasan con el árbol no es la estructura, es que lo tratan como un artefacto de una sola vez. Lo construyen en un tablero de Miro, lo presentan en una reunión de planificación trimestral, y luego muere. Se supone que el árbol vive en una pared (física o digital), y usted pasa junto a él cada semana. ¿Ocurre una entrevista nueva? Añade una rama de oportunidad. ¿Falla una prueba de suposición? Poda una solución. ¿Cambia el resultado? Sub-ramas enteras mueren.

Reviso mi árbol cada jueves por la mañana, a solas, durante 30 minutos. Añado lo que aprendí esa semana y elimino lo que dejó de tener sentido. Si no hace esto, el árbol se vuelve papel tapiz.

Discovery continuo: al menos 3 entrevistas con clientes por semana

Esta es la regla que le robo a Torres: un PM que no hace al menos tres entrevistas con clientes por semana no está haciendo discovery.

Eso suena agresivo hasta que hace la cuenta. Tres entrevistas × 45 semanas = 135 conversaciones con clientes al año. La mayoría de los PMs hacen 30. El efecto compuesto sobre el reconocimiento de patrones es enorme. Para el final del primer año, puede predecir lo que un cliente va a decir en los primeros cinco minutos, y ahí es cuando empieza a realizar entrevistas que presionan suposiciones específicas en lugar de pescar dolor vago.

Los sprints trimestrales de investigación son lo opuesto a esto. Acumula sus incógnitas, contrata a un proveedor de investigación, recibe una presentación de 40 páginas, e intenta adaptar los hallazgos a un roadmap que ya está medio comprometido. Para cuando la presentación aterriza, el mundo ya se ha movido.

Las entrevistas semanales arreglan tres cosas a la vez:

1. Recencia. El dolor que escuchó la semana pasada vence al dolor que escuchó el trimestre pasado.
2. Iteración. Puede ajustar su guion de entrevista según lo que escuchó ayer. Los sprints no le dejan hacer eso.
3. Credibilidad ante las partes interesadas. Cuando el CRO dice "los clientes quieren X", usted ha hablado con nueve de ellos en las últimas tres semanas y puede decir "en realidad, tres de ellos mencionaron X, pero el patrón más grande era Y". Esa es una conversación distinta.

Reclutar entrevistas sin agotar a los CSMs

El problema del reclutamiento es real. Tres fuentes sólidas, clasificadas por calidad:

• Prompts de reclutamiento dentro de la app. Un banner simple ("Soy PM, ¿me podría dar 25 minutos de su tiempo? Tarjeta de regalo de Amazon de 50 USD.") convierte aproximadamente al 1-2% de los activos semanales en B2B. Si tiene 10K WAU, eso son de 100 a 200 conversaciones disponibles por semana. La mayoría de los PMs nunca aprovechan esto porque tienen miedo de pedirlo.
• Presentaciones de CSM. Negocie de antemano una cuota ("necesito 5 presentaciones por mes de tu cartera") escrita en los objetivos mensuales del CSM. Sin una cuota, esto se desmorona en la tercera semana.
• Entrevistas de tratos perdidos. Hable con personas que lo evaluaron y lo rechazaron. Le dirán cosas que los clientes actuales no dirán, porque no tienen nada que perder.

Una tarjeta de regalo de 50 USD es el umbral correcto para la mayoría de los segmentos del ICP. Por debajo de eso, obtiene curiosos que solo quieren charlar. Por encima de 100 USD, finanzas empieza a hacer preguntas. Para perfiles ejecutivos (VP o superior en empresas de más de 500 empleados), normalmente necesita entre 150 y 200 USD o una donación benéfica, porque 50 USD les resulta insultante.

Qué cuenta como entrevista

Una entrevista con cliente no es una llamada de discovery de ventas, un check-in de CSM, ni una demo. La entrevista liderada por el PM tiene un solo trabajo: entender un comportamiento o dolor pasado específico. Si está mostrando diapositivas, haciendo demos o presentando cualquier cosa, no está entrevistando. Está vendiendo. Pause y empiece de nuevo.

Mapeo de suposiciones

Cada idea de producto descansa sobre cuatro grupos de suposiciones. El marco de mapeo de suposiciones de David Bland, popularizado en Testing Business Ideas, toma prestada la clásica lente de deseabilidad/viabilidad/factibilidad de IDEO y añade la usabilidad:

Para cada suposición, puntúela en dos ejes:

• Riesgo. Si esta suposición es incorrecta, ¿se derrumba toda la idea?
• Evidencia. ¿Cuánta evidencia real tenemos ahora mismo? (No opiniones. No "hemos hablado de esto". Evidencia.)

Trácelas en una matriz 2x2. El cuadrante superior derecho (alto riesgo, baja evidencia) es donde enfoca primero el trabajo de discovery. La prueba más barata que podría matar la idea va primero. Si la deseabilidad es endeble, ejecute un fake door antes de construir nada. Si la factibilidad es lo que mata, construya un spike de 2 días, no un MVP de 6 semanas.

Mantengo el mapa de suposiciones en el mismo tablero de Miro que el árbol de oportunidades y soluciones, un marco a la derecha. Cada rama de solución apunta a sus tres suposiciones principales. Cuando una suposición se prueba y se falsea, la tacho en rojo y la solución baja de rango o se elimina.

El fake door / smoke test

Un fake door es la herramienta de discovery de mayor palanca que ejecuto. La premisa: construir el punto de entrada a una funcionalidad sin la funcionalidad detrás. Medir si alguien hace clic. Si no lo hacen, la funcionalidad está muerta antes de escribir una sola línea de código.

Cómo funciona en la práctica:

1. Añada un botón, un elemento de menú, o una tarjeta dentro de la app que prometa una capacidad, como "Programar reportes recurrentes".
2. Cuando los usuarios hacen clic, muestre un formulario de "Próximamente, ¿quiere acceso anticipado?" que capture el email y una línea de "¿para qué lo usaría?".
3. Rastree la tasa de clics (CTR) contra la cohorte que lo vio.

Los umbrales que realmente uso

Estos son los números que he calibrado en tres empresas. Su experiencia variará, pero son un punto de partida:

El umbral del 5% importa porque es aproximadamente la tasa a la que puede justificar la inversión de ingeniería para una funcionalidad que aborda un dolor claro. Por debajo del 2%, está persiguiendo a 1 de cada 50 que levanta la mano, y la cohorte no es lo bastante grande para impulsar resultados de negocio significativos aunque cada clicador convierta.

Las salvaguardas éticas

No puede mentirles a sus clientes. El estado de seguimiento "Próximamente" es obligatorio, sin excepciones. Dos reglas más:

• Envíe siempre un email a todos los que hicieron clic, incluso si la respuesta es "decidimos no construir esto". Dígales qué hace en su lugar. Esto le cuesta 20 minutos y protege el próximo fake door que ejecute.
• Nunca ejecute un fake door para algo que nunca construiría. Si está haciendo pura minería de curiosidad, haga entrevistas. Los fake doors son herramientas de validación, no encuestas de investigación de mercado.

Una vez descarté una funcionalidad en la fase de fake door que el equipo ejecutivo llevaba seis meses impulsando: un módulo de upsell de "puntuación predictiva de leads". Lanzamos el punto de entrada a una cohorte de 1.400 admins del mercado medio, esperando al menos un 8-10% de CTR según las anécdotas de ventas. Obtuvimos un 1,7%. De los 23 clicadores, 14 pensaban que "puntuación predictiva de leads" significaba algo completamente distinto de lo que planeábamos construir. Retiramos la funcionalidad del roadmap un viernes, redirigimos el squad a una oportunidad distinta, y la nueva apuesta se lanzó seis meses después con un 41% de adopción. El fake door nos costó cuatro días de tiempo de diseño y desarrollo. La funcionalidad habría costado un trimestre.

Validación impulsada por prototipos

Cuando un fake door supera la barra del 5%, ha demostrado la demanda. No ha demostrado que la solución funcione. Ese es el trabajo del prototipo.

Igualo la fidelidad del prototipo a la suposición que estoy probando:

• Prototipo navegable de Figma. Para probar usabilidad y arquitectura de la información. Cinco usuarios probados mediante tests no moderados de Maze sacarán a la luz la mayoría de los problemas catastróficos de UX. Costo: 1-2 días de diseño.
• MVP de conserjería. Cuando la factibilidad o las suposiciones de flujo de trabajo son lo que mata, haga el trabajo manualmente para 5-10 clientes. Si un cliente quiere un reporte automatizado de análisis de competidores, genere los primeros diez a mano y envíeselos por email. Si los clientes dejan de abrir los emails para la tercera semana, el valor subyacente no está ahí.
• Wizard of Oz. El front-end es real, el back-end son humanos. Útil cuando necesita validar datos de comportamiento (¿los usuarios realmente suben el archivo? ¿vuelven?) sin construir infraestructura real.
• Vertical slice hardcodeada. Una construcción real pero estrecha. Un perfil, un flujo de trabajo, fea pero funcional. Lánzela a 10-20 socios de diseño. Esta es su última prueba barata antes de una inversión real de ingeniería.

No se salte niveles. No pase de "el CRO lo pidió" a "vertical slice" sin un fake door y un prototipo en medio. Cada nivel saltado es un multiplicador de su radio de impacto si la suposición era incorrecta.

El Mom Test (no inducir al testigo)

The Mom Test de Rob Fitzpatrick arregló mi práctica de entrevistas más que ningún otro recurso. La premisa: la gente le miente en las entrevistas, sobre todo cuando le aprecian. Su trabajo es hacer preguntas que le den la verdad incluso de su propia madre.

Las tres reglas:

1. Hable de su vida, no de su idea. "¿Cuál es la peor parte de su lunes por la mañana?" vence a "¿Usaría una herramienta que arregla los lunes por la mañana?". A la primera pregunta no se la puede halagar. A la segunda sí.
2. Pregunte por detalles del pasado, no por generalidades sobre el futuro. "Cuénteme la última vez que esto pasó" vence a "¿Haría X?". El comportamiento pasado son datos. La intención futura es fantasía.
3. Escuche más de lo que habla. Una buena entrevista es 80% ellos, 20% usted. Si está explicando su producto, ha terminado. Termine la llamada, tome notas, hágalo mejor la próxima vez.

El antipatrón más dañino que veo en las entrevistas de PM es la demo disfrazada de discovery. Usted agenda una llamada de 30 minutos para "aprender de un cliente". A los veinte minutos, les ha mostrado tres mockups y ha preguntado "¿esto sería útil?". Dicen que sí, porque son educados, porque están confundidos, porque quieren que la llamada termine. Usted registra una "entrevista de validación" en sus notas. Lanza la funcionalidad. Muere.

Si se sorprende abriendo Figma durante una llamada de discovery, cuelgue y empiece de nuevo. Eso no es entrevistar. Eso es vender.

Cuándo descartar un hilo de discovery

Descartar sus propias ideas es la habilidad más difícil en producto. Tres señales me indican que un hilo está muerto:

• Tres pruebas de suposición fallidas seguidas. Fake door por debajo del 2%, prototipo probado con cinco usuarios y tres se quedaron atascados, MVP de conserjería sin uso repetido. Eso no es mala suerte. Es el universo diciéndole que pare.
• Sin tracción desde las entrevistas tras 6-8 conversaciones. Si ha hablado con ocho clientes sobre un problema y ni uno ha ofrecido voluntariamente "sí, este es un dolor real que pagaríamos por resolver", la oportunidad no está ahí. Los entrevistados darán rodeos durante una o dos conversaciones. Para la octava, el patrón es honesto.
• Puntuaciones de oportunidad por debajo del umbral. Clasifico cada oportunidad en mi árbol en tres dimensiones: frecuencia (con qué frecuencia golpea el dolor), severidad (qué tan grave cuando lo hace), y alcance (qué % de nuestro ICP lo siente). Si dos de tres son débiles tras un mes de discovery, la rama muere.

Cuando descarto un hilo, escribo un memo de descarte de una página. No por política. Por mí, dentro de seis meses, cuando alguien resucite la idea y necesite recordar por qué la aparqué. Plantilla:

Idea: [nombre]
Oportunidad que pretendía abordar: [oportunidad del árbol]
Suposiciones probadas: [lista]
Evidencia recopilada: [viñetas]
Razón de descarte: [el fallo específico]
Qué necesitaríamos ver para reconsiderarla: [las condiciones]
Fecha: [AAAA-MM-DD]

El memo de descarte vive en la misma carpeta de Notion que el árbol de oportunidades y soluciones. Cuando el CRO vuelve seis meses después preguntando "¿qué pasó con la puntuación predictiva de leads?", le envío el memo. Dos minutos de conversación, no dos semanas reproduciendo el mismo debate.

Mi cadencia semanal de discovery

Este es el ritmo que ejecuto, por si es útil como plantilla de partida:

• Lunes por la mañana. Se reservan tres franjas de entrevista para la semana. Las confirmo, preparo las preguntas, y actualizo el tracker de entrevistas. El reclutamiento ocurre vía prompts dentro de la app (corriendo continuamente) y presentaciones de CSM.
• Martes a jueves. Las entrevistas ocurren, 45 minutos cada una. Las notas van a Dovetail. Los reels destacados se comparten con ingeniería y diseño (clips de cinco minutos, no transcripciones). Los ingenieros sí ven los clips.
• Jueves por la mañana. Revisión en solitario del árbol de oportunidades. 30 minutos. Se añaden oportunidades nuevas, se podan ramas muertas. Se actualiza el mapa de suposiciones.
• Viernes por la tarde. Una prueba de suposición se lanza cada sprint (fake door, prototipo, o MVP de conserjería). El viernes es cuando escribo la especificación de la prueba del próximo sprint.

Eso es todo. Sin sprint trimestral de investigación. Sin presentaciones de 40 páginas. Tres entrevistas por semana, un árbol de oportunidades, una prueba de suposición por sprint. La disciplina aburrida vence al esfuerzo dramático, siempre.

Los PMs a los que más respeto no tienen mejores instintos que el resto de nosotros. Tienen una mejor práctica de discovery. Han hablado con 135 clientes este año, ejecutado 26 fake doors, descartado 18 ideas, y lanzado las cuatro que sobrevivieron. Por eso sus funcionalidades alcanzan el 40% de adopción mientras los demás miran fijamente un 9%.

No necesita un presupuesto más grande ni más investigadores. Necesita tres franjas de entrevista en el calendario de la próxima semana y la disciplina de mantenerlas reservadas cuando el trimestre se ponga ruidoso. Empiece por ahí.

Más información

• Plantilla de descripción de puesto para gerente de producto
• Cómo hacer roadmaps sin mentir a las partes interesadas
• Cómo escribir PRD que los ingenieros realmente leen
• Métricas de PM: resultado frente a producción, North Star, indicadores adelantados