Descartar una funcionalidad antes de que cueste semanas

Para descartar una funcionalidad, prueba barato su supuesto más arriesgado, decide de antemano qué resultado significa parar y después para de verdad. Escribe lo que aprendiste para que la idea no se cuele de nuevo dentro de seis meses. Cada idea que matas te devuelve semanas de tardes.

Cómo descartar una funcionalidad

Nadie te va a hacer una fiesta por la funcionalidad que no construiste.

Ese es el problema. Cuando lanzas, hay un registro de cambios, un tuit, una pequeña dosis de orgullo. Cuando matas una idea, hay silencio. Estás solo, así que no hay con quién celebrarlo, y la decisión queda sin registrar. A lo largo de unos meses, el descubrimiento empieza a parecer improductivo junto a tanto lanzamiento visible.

No lo es. Matar la idea correcta suele ser lo más valioso que produce tu semana. Te devuelve semanas de tardes, y las tardes son el único presupuesto que un negocio de una persona no puede reponer.

Así que aprende a hacerlo a propósito. Aquí está el método.

Por qué cuesta tanto matar las ideas

Porque ya la has construido en tu cabeza.

Puedes ver la pantalla. Has nombrado el botón. Sabes qué clientes la van a adorar. Para cuando «evalúas» la idea, no estás juzgando una suposición. Estás defendiendo un plan.

Y la IA lo ha empeorado. Antes, construir lo equivocado llevaba meses y un desarrollador, así que el coste te obligaba a ser cuidadoso. Ahora lleva un fin de semana. La tentación es saltarte la pregunta e ir directo a una respuesta preciosa. El coste ya no te protege. Tienes que protegerte tú a propósito.

Una funcionalidad que descartaste en una tarde es un fin de semana que conservaste.

Guía gratuita · 21 páginasSigue descubriendo. Sigue construyendo.Cómo seguir descubriendo mientras sigues construyendo, como una sola persona, sin parar ninguna de las dos.Consigue la guía gratuita →

Paso uno: quita la solución, encuentra el supuesto

Una idea llega como funcionalidad. «Añadir un panel.» «Construir el nuevo onboarding.» Eso es una solución, y las soluciones no se pueden probar. Los supuestos sí.

Así que dale la vuelta. Pregunta qué tiene que ser verdad para que esto funcione:

• La gente de verdad tiene el problema.
• Cambiará su comportamiento para usar la solución.
• La entenderá.
• Pagará, o al menos la valorará lo bastante como para que importe.

Ordénalos por cuál dolería más si fuera falso. Y ve a por ese. No el cómodo. Casi todos probamos si la cosa es usable, porque lo usable es medible y agradable. Que a alguien le importe es el supuesto que de verdad mata ideas, y suele quedar sin probar hasta el lanzamiento. Nuestro artículo sobre encontrar el supuesto más arriesgado muestra cómo detectarlo.

Paso dos: decide qué aspecto tiene «muerta» antes de probar

Este es el paso que hace honesto todo lo demás.

Antes de hacer la prueba, termina esta frase por escrito: «Si veo ___, dejo esto.»

Luego haz la pregunta de verdad. Si esto sale negativo, ¿voy a parar de verdad?

Si la respuesta honesta es no, no hagas la prueba. Construye la cosa. Al menos es honesto. Una prueba que ignorarías es peor que ninguna: te cuesta una tarde y fabrica falsa confianza.

Si la respuesta es sí, tienes un interruptor de muerte de verdad. Ahora elige la prueba más barata que podría moverte. Una conversación. Una página con precio. Un prototipo tosco. Hacerlo a mano para una persona. O mirar datos que ya tienes. El artículo sobre pruebas baratas repasa las opciones.

Paso tres: lee el resultado como un escéptico

Cuando el resultado es malo, tu cerebro empieza a regatear. «No entendieron la pregunta.» «Mala semana.» «Quizá con un mejor diseño.»

A veces es verdad. La mayoría de las veces es la parte de ti que quería construir, presentando un recurso.

Usa esta tabla para mantenerte honesto.

Mira otra vez la segunda fila. Si escribiste el listón primero, este argumento termina en una línea. Ese es todo el valor de escribirlo.

Paso cuatro: escribe el obituario al descartar una funcionalidad

Cuatro líneas. Nada más.

1. Qué pregunté o supuse.
2. Qué hice para probarlo.
3. Qué encontré.
4. Qué decidí, y por qué.

Guárdalo en un sitio que puedas encontrar dentro de seis meses. No en tu cabeza. No en un hilo de chat que nunca reabrirás.

Hay dos razones. Primera, protege tu trabajo de descubrimiento de tu propia acusación de que no produce nada. Una lista de ideas descartadas es resultado. Prueba que el filtro funciona. Segunda, evita que la misma idea vuelva. Sin registro, la misma sugerencia regresará dentro de seis meses, parecerá nueva y te costará la misma prueba otra vez.

Antes de empezar algo que te suene familiar, revisa el registro. Puede que ya esté muerto.

Evaluación gratuita¿Hasta qué punto estás atrapado?Haz el Índice de Asfixia Corporativa, la evaluación gratuita para saber si estás listo para ser solopreneur.Hacer la evaluación →

Paso cinco: rechaza al zombi

La idea que mataste intentará volver con otro disfraz.

Vuelve como versión «lite». Como experimento. Como algo que un cliente preguntó de pasada. Cuando aparezca, pásala por la misma puerta que cualquier cosa nueva: cuál es el supuesto, qué me haría dejarla, qué decía el registro.

Si ha aparecido evidencia nueva, bien. Reábrela. Si no ha cambiado nada salvo tu humor, sigue muerta.

Una nota sobre los clientes. Una sola petición es un dato, no un mandato. Trátala como un motivo para preguntar por su comportamiento pasado, con los hábitos de hablar con clientes sin guiarlos. No la trates como una especificación.

Lo que obtienes al descartar una funcionalidad

Digamos que vendes un servicio convertido en producto por tu cuenta. Una idea de funcionalidad aterriza un martes. Llevaría casi un mes de tardes construirla. Gastas dos conversaciones y un vistazo a los datos que ya tienes, y la idea no supera el listón que fijaste. ¿Qué costó eso? Una tarde o dos. ¿Qué devolvió? Un mes. Un mes que ahora puedes gastar en algo con mejor evidencia detrás. Cada idea matada con dos conversaciones es un mes de tardes redirigido. Esa es la economía de toda la práctica. Construir es, con diferencia, la forma más cara de probar un supuesto. El descubrimiento existe para responder barato lo que de otro modo responderías en tardes. Un descarte es la prueba más limpia de que funcionó.

Hay también un beneficio más silencioso. Trabajando solo, la incertidumbre no tiene adónde ir. O construyes lo que dudas o discutes contigo mismo a las once de la noche y pierdes. Un proceso de descarte te da una tercera opción: esta es una pregunta de verdad, aquí está la prueba barata, lo sabré el viernes. Un bucle de ansiedad se convierte en una pregunta con fecha.

Guía gratuita · 21 páginasSigue descubriendo. Sigue construyendo.Cómo seguir descubriendo mientras sigues construyendo, como una sola persona, sin parar ninguna de las dos.Consigue la guía gratuita →

Cómo saber si descartas lo suficiente

Aquí tienes una comprobación directa. Mira atrás tus últimos meses de descubrimiento. ¿Cuántas decisiones de no construir produjo?

Si la respuesta es ninguna, el descubrimiento no es un filtro. Es un proceso de aprobación. Tu lista de construcción se alimenta sin examinar, con unas reuniones extra pegadas. Ocurre sobre todo cuando metes funcionalidades decididas de antemano en la vía de descubrimiento: validar una solución que ya elegiste produce de forma fiable la confirmación que ibas buscando.

Una vía sana descarta cosas. No todo, y no por costumbre. Pero con regularidad, y de forma visible. Cuéntalo. Pon las ideas descartadas junto a las lanzadas y mira qué lista es más larga. Si quieres saber si tu idea llega alguna vez al listón, el artículo sobre validación lo trata desde el otro lado.

Evaluación gratuita¿Hasta qué punto estás atrapado?Haz el Índice de Asfixia Corporativa, la evaluación gratuita para saber si estás listo para ser solopreneur.Hacer la evaluación →

Preguntas frecuentes

¿Cómo sé que una idea merece descartarse en lugar de probarse más?

Si el supuesto más arriesgado se probó y salió por debajo del listón que escribiste de antemano, descártala. Si nunca probaste el supuesto peligroso, solo el cómodo, prueba otra vez antes de decidir nada.

¿Y si un cliente pide la funcionalidad?

Trátalo como una pista para una conversación, no como una instrucción. Pregunta qué hacen hoy con el problema, cuándo se lo encontraron por última vez y qué probaron. El comportamiento pasado es evidencia. Una petición es una predicción.

¿Debo registrar ideas en las que solo pensé un minuto?

Registra las que probaste o sopesaste en serio. Cuatro líneas bastan. El objetivo es que nadie, tú del futuro incluido, desperdicie otra tarde reaprendiendo lo mismo.

¿Puedo volver después de descartar una funcionalidad?

Sí, si la evidencia cambió. El registro te dice qué suponías y por qué paraste, para que veas si algo es de verdad distinto. Si solo ha cambiado tu entusiasmo, déjala en paz.

¿No me hace menos ambicioso descartar una funcionalidad?

No. Dirige tus tardes limitadas a las ideas con mejor evidencia. Construir lo equivocado de forma preciosa es la opción poco ambiciosa, porque parece progreso y no lo es.

El método completo, con las listas de comprobación, está en El Playbook de Dual Track Agile, una guía gratuita de 21 páginas.