Feature creep: el founder suele ser la fuente

Una guía de campo para founders no técnicos que llevan meses viendo el producto ganar features más rápido de lo que gana usuarios: qué es feature creep en realidad, por qué el consejo clásico de “solo decir que no” no te sirve, y el diagnóstico de tres fuentes más el test de una pregunta que lo frena antes del próximo sprint.

El CEO abrió el laptop y empezó a contar. Veintitrés features lanzadas en los últimos seis meses. Tres de ellas se usaron. Las otras veinte fueron pagadas, diseñadas, construidas, probadas, puestas en producción, y ahora había que mantenerlas hasta que la empresa muriera o alguien sacara el tiempo para borrarlas.

Levantó la vista. “Llevo gastados ciento cincuenta mil. ¿Cómo pasó esto?”

Nosotros sabíamos exactamente cómo había pasado. Habíamos estado en cada una de esas calls. El inversor que sugirió “deberían tener un agente de AI en el dashboard”. El cliente flagship que preguntó, en una call de renovación, si el export no podía también empujar a Slack. La PM que volvió de un evento con un Notion titulado “lo que aprendimos”. El propio founder, un domingo en la noche, viendo el video de lanzamiento de un competidor y mandando un screenshot al Slack del equipo con el caption: “necesitamos esto”.

Veintitrés síes. Tres que importaban. Los otros veinte eran feature creep.

Qué es feature creep

Feature creep es la expansión lenta, casi invisible, del alcance de un producto más allá de lo que se había planificado, alimentada por una acumulación de decisiones individualmente razonables. Cada feature añadida, por sí sola, parece inofensiva. El peso sumado es lo que mata al producto, al presupuesto, o a los dos.

El término viene de la literatura de ingeniería y de diseño de juegos de los años 70 y 80, cuando los equipos empezaron a nombrar el patrón que hace que los sistemas ambiciosos colapsen bajo su propio peso. Frederick Brooks escribió sobre un hermano de ese patrón, el second-system effect, hace cincuenta años. El vocabulario es viejo. La enfermedad no cambió.

Lo que cambió es quién carga el virus. En la visión antigua, feature creep era algo que un equipo de ingeniería se hacía a sí mismo cuando nadie miraba. En la startup moderna, el equipo de ingeniería tiene muy poco que ver. El founder es quien aprueba las features. El equipo solo ejecuta.

Si eres un founder no técnico y tu producto tiene más features que tus usuarios casos de uso, no eres víctima de feature creep. Eres la fuente.

Feature creep vs scope creep: por qué la diferencia importa

Los dos términos se usan como sinónimos y no deberían. La solución de uno no es la solución del otro.

Scope creep es un problema contractual. Firmaste un SOW con un proveedor por cinco features, y ahora hay nueve en el build. Alguien dijo que sí a cuatro cosas que no estaban en el trato original. Normalmente tú. A veces el comercial. A veces un PM que quiso quedar bien. El costo aparece en la factura. La solución es contractual: change order escrita, reestimación, precio renegociado. La elección de precio cerrado vs tiempo y materiales que hiciste al principio decide qué tan dolorosa es esa conversación.

Feature creep es un problema de producto. El producto, a lo largo de meses y años, acumula features por las que nadie pelea y que nadie remueve. No hay un momento único en que se cruzó la línea. El costo aparece en tres lugares, todos invisibles hasta que dejan de serlo: cuentas de mantenimiento que componen, una UI que confunde a quien entra nuevo, y un equipo que cada vez menos logra entregar la única cosa que de verdad importaría porque está ocupado manteniendo las veinte que no.

Scope creep es una pelea que puedes perder en una sola conversación. Feature creep es una pelea que pierdes por no tener la conversación. La primera tiene un proveedor del otro lado de la mesa. La segunda te tiene solo a ti.

Las tres fuentes de feature creep

Una vez que aceptas que eres la fuente, el siguiente paso es dejar de pensar en feature creep como una sola enfermedad. Son tres. Desde tu silla se ven idénticas. Todas llegan como “también deberíamos construir X”. La respuesta correcta depende de cuál estés mirando.

Fuente 1: pull de cliente (a veces real)

Un cliente pide la feature. Está usando tu producto, chocó con un muro, quiere que el muro se quite. Esta es la única fuente donde la respuesta a veces es un sí limpio.

La trampa: un solo cliente no es una señal. Hemos visto founders entregar un build de seis semanas por un pedido que vino de exactamente una call de renovación, donde el cliente iba a renovar igual, y donde ningún otro cliente volvió a pedir esa misma cosa. La feature termina usada por cero personas el resto de su vida y le cuesta al equipo un dev-mes cada vez que el framework de abajo cambia.

El test no es “un cliente lo pidió”. El test es “otros cinco clientes van a churnear o se van a negar a hacer onboarding sin esto”. Si la respuesta es sí, constrúyelo. Si la respuesta es “bueno, este cliente lo quiere mucho”, estás negociando una feature de contrato custom, no una feature de producto. Cóbralo distinto o di que no.

Fuente 2: carnada de venta (casi nunca real)

Un prospect en una call de venta dice “si tuvieran X, firmaríamos mañana”. Tu head de ventas trae el pedido de vuelta al equipo de producto como bloqueador de deal. El founder, que en esta etapa también suele ser el head de ventas, autoriza el build.

El prospect nunca firma. Nunca firma porque X no era en realidad la razón por la que no firmaba. X era la versión educada de “no estamos listos”, o “su precio está equivocado”, o “ya usamos un competidor y cambiar es complicado”. La feature se construye, el deal no cierra, y ahora eres dueño de X para siempre.

El test cabe en una frase: el prospect va a firmar una orden pagada hoy, condicionada a la entrega de X en Y semanas, con cláusula escrita de cancelación si la entrega se atrasa. Si sí, tienes una señal real, y tienes un cliente pagando que financia el build. Si no, tienes una objeción educada disfrazada de pedido de feature. Ya corrimos este test en decenas de features “deal-blocker”. La conversión de “dijeron que firmaban” a “firmaron cuando se les ofreció el contrato” está en un dígito bajo.

Fuente 3: inquietud del founder (la asesina silenciosa)

El founder está despierto tarde. Tiene una hora de silencio. Abre el producto, lo mira, y siente esa insatisfacción de baja intensidad que viene de mirar demasiado tu propio trabajo. El producto se ve chiquito, plano, callado. Abre el Slack del equipo y escribe: “también deberíamos construir X”.

Esa es la fuente que entrega más features. No llega disfrazada de pedido de cliente. Llega disfrazada de gusto. El founder genuinamente cree que el producto necesita X para mejorar. A veces tiene razón. La mayoría de las veces está aburrido, y el antídoto del aburrimiento es construir.

El test para esta fuente es el más duro de los tres. Espera siete días. Si la feature sigue en la cabeza del founder al día siete, y puede nombrar tres clientes que la pidieron específicamente en la misma semana, constrúyela. Si alguna de las dos condiciones falla, archiva el pedido. Tenemos un canal privado donde estos pedidos se van a morir. El ochenta por ciento nunca resucita. El founder ni se acuerda de haber escrito el mensaje original.

Por qué el consejo clásico (“solo di que no”) no funciona para founder no técnico

Todo otro artículo sobre feature creep termina llegando a la misma conclusión: el equipo debería decir que no, el PM debería defender el backlog, el lead de ingeniería debería empujar de vuelta. Es un consejo bueno para una empresa con un PM real y un líder de ingeniería senior, ambos seguros para pasar por encima del founder.

Esa no es la empresa que está firmando los cheques aquí. El founder no técnico es quien financia el build, atiende a los clientes, y aprueba el roadmap. El equipo no puede pasarle por encima. El equipo construye lo que le dicen. Si el equipo es un partner externo o contratado (que es la mayor parte de nuestro mundo), la dinámica es peor, porque el equipo tiene un incentivo comercial para decir que sí. Cada sí es más hora facturable.

Entonces el consejo “solo di que no” está estructuralmente invertido. Tú, founder, eres el único que puede decir que no. Nadie lo va a hacer por ti. La defensa contra feature creep no es un proceso que el equipo corre. Es una disciplina que el founder construye.

Esa disciplina tiene nombre en nuestro trabajo, y se reduce a una sola pregunta.

El test de una pregunta: el test de los siete días

Antes de que cualquier pedido de feature entre al roadmap, el founder lo pasa por una pregunta:

¿Puedo nombrar, por nombre de empresa, tres clientes actuales que pidieron esta feature en los últimos siete días, por escrito o en call grabada?

Eso es todo. Tres clientes. Por nombre. Por escrito. En siete días.

Si sí, la feature es candidata. Todavía tiene que pasar por la conversación de build, buy o esperar, pero se ganó el derecho a esa conversación.

Si no, el pedido va a la carpeta de muerte. No al backlog. No a la columna de “después”. A la carpeta de muerte. El backlog es donde las features van para hacerse. La carpeta de muerte es donde van para olvidarse.

Este test hace cinco cosas útiles al mismo tiempo. Obliga al founder a anclar el pedido en clientes reales, no en su propio gusto ni en la deflexión de un prospect. Pone un filtro de recencia sobre la demanda, así los entusiasmos viejos expiran solos. Exige evidencia en un formato que el founder puede mostrarle al equipo, lo que mata el patrón de “confía en mí, es lo que quieren”. Trata la carnada de venta por lo que es: una objeción educada de prospect no es un cliente pidiendo, por nombre, por escrito, la última semana. Y hace visible la inquietud del founder, porque el founder tiene que admitir, en voz alta, que ningún cliente está esperando aquello que él quiere construir.

El primer mes después de que un founder adopta este test, normalmente mata el setenta por ciento de los pedidos que habrían entrado al roadmap. El segundo mes, la velocidad del equipo en el treinta por ciento restante se duplica. Al tercer mes, el producto empieza a sentirse más chico, y los usuarios empiezan a usarlo más.

Cómo evitar feature creep cuando el equipo es externo

El riesgo es más alto cuando el equipo que construye el producto no es interno. Ya vivimos esto desde los dos lados: como el equipo que recibe el mensaje de Slack el domingo en la noche, y como el operador que solía mandarlos.

Las jugadas defensivas que funcionan:

• Un canal para pedidos de feature, una cadencia para triaje. Si los pedidos de feature pueden caer en cualquier conversación (DM de Slack, email, pasillo, call de venta), todos pesan igual, lo que significa que ninguno recibe escrutinio real. Elige un canal. Triaje semanal. Lo que no sobrevivió una semana probablemente no era real.
• Briefs escritos, no mensajes de Slack. Cada feature que sobrevive al test de siete días recibe un brief de una página antes de construirse. El brief obliga al founder a articular el cliente, el caso de uso, la métrica de éxito, y el costo de no construirlo. Alrededor de un cuarto de las features que sobreviven al test de siete días no sobreviven a la escritura del brief.
• Un roadmap en el que el equipo puede empujar de vuelta. El founder sigue siendo dueño del roadmap. Pero el equipo gana el derecho de marcar los costos de segundo orden de cada feature nueva: qué capacidad existente se va a hacer más lenta, qué bug conocido va a quedar sin arreglar, qué cuenta de mantenimiento se está firmando. El founder puede pasar por encima del aviso. No puede no estar enterado.
• Un ítem permanente de “borrar” en el roadmap. Cada trimestre, una rebanada importante del tiempo de build se va para sacar features que no se usaron en los últimos noventa días. El producto se achica a propósito. Es el único contrapeso directo al peso acumulado de cada sí anterior. A nadie le gusta construir esto. Todo founder que lo hizo lo agradeció después.

El costo de no hacer esto

Rara vez nos encontramos con un founder no técnico cuyo producto es demasiado chico. Nos encontramos con muchos cuyo producto es demasiado grande y cuya empresa es demasiado chica para mantenerlo.

Cada feature lanzada es una cuenta permanente de mantenimiento. El framework se actualiza, la API de la que depende la feature cambia, el servicio tercero deprecia un endpoint, el navegador cambia la regla de renderización. Cada uno de esos eventos es gratis para las features que no existen. Cada uno es hora facturable para las features que sí. La matemática compone en silencio. Dos años adelante, la mitad de la capacidad del equipo se va en mantener el producto vivo en vez de llevarlo adelante, y el founder no entiende por qué la velocidad se desplomó.

La velocidad se desplomó porque el founder pasó dos años diciendo que sí. El equipo hizo exactamente lo que le pidieron. Lo construyeron. Ahora están atrapados manteniéndolo. En ese punto, el founder suele empezar a escuchar una palabra diferente de su equipo: rewrite. Esa conversación casi siempre es la equivocada. La correcta es la conversación sobre borrar.

El trabajo para deshacer esto es real y sin glamour. Borrar features. Correr el test de siete días en todo lo nuevo. Escribir briefs. Triaje en cadencia. El producto se achica, la cuenta se achica, y la empresa empieza a poder entregar la una o dos cosas que de verdad moverían el negocio. Es el tipo de trabajo más barato que existe, y es el tipo que casi nadie hace hasta que ya pagó la alternativa una vez.

El CEO de la apertura de este artículo cerró el laptop. Borramos nueve de las veinte features sin uso a lo largo del trimestre siguiente. El equipo entregó la única feature que llevaba cuatro meses enterrada en la fila — aquella que, cuando miramos los datos seis semanas después, había movido la retención en once puntos.

El producto estaba esperando que él parara de construir.

FAQ

¿Qué es feature creep en términos simples?
Feature creep es lo que pasa cuando un producto acumula features lentamente, más allá del punto en que alguien puede decir por qué cada una existe. No es una mala decisión. Son docenas de decisiones con cara razonable que sumadas dan un producto demasiado caro de mantener y demasiado confuso para quien entra nuevo.

¿Cuál es la diferencia entre scope creep y feature creep?
Scope creep es un problema de contrato: trabajo extra que entra a un build que ya estaba acordado por escrito. La solución es una change order o un SOW renegociado. Feature creep es un problema de producto: features que se apilan en el roadmap con el tiempo, sin un momento único de decisión. La solución es una disciplina que corre el founder, no una cláusula contractual.

¿Cómo evitar feature creep?
Pasa cada pedido de feature por una pregunta antes: puedes nombrar tres clientes actuales que lo pidieron, por nombre de empresa, por escrito, en los últimos siete días. Si no, el pedido va a la carpeta de muerte, no al backlog. Combina esto con un único canal para pedidos, triaje semanal, briefs escritos antes de cualquier build, y un ítem permanente de borrado en el roadmap. El founder es quien tiene que hacer cumplir todo esto. Nadie más puede.

¿Por qué los founders no técnicos causan más feature creep que los técnicos?
Dos razones. Primero, el founder no técnico no siente directamente el costo de cada feature nueva: la actualización del framework, el cambio de API, la guardia. El precio queda invisible hasta que es enorme. Segundo, construir se siente productivo de una manera que podar no, así que el movimiento por defecto cuando el founder se inquieta es agregar en lugar de quitar. La combinación es lo que produce un producto con cuarenta features y tres que importan.