La trampa del scope creep: cómo decir que no a las funciones que suenan bien pero no lo son

Lanzaste una app. La gente llegó. Y ahora tu bandeja de entrada está llena de peticiones de funciones que suenan todas como buenas ideas.

“¿Podemos agregar exportar a Excel?” Razonable. “¿Las facturas pueden enviarse automáticamente?” Tiene sentido. “¿Podemos integrar con Stripe?” Ahí es donde está el dinero de verdad. “¿Puedes agregar una app móvil?” Todos piden eso. “¿Podemos ponerle marca blanca para nuestros propios clientes?” Ah, ahora sí hay un modelo de negocio.

Cada petición, por separado, suena inteligente. Juntas, suenan a que estás construyendo cinco productos distintos.

Esto es scope creep —el crecimiento descontrolado del alcance— y mata más apps pequeñas hechas con IA de lo que jamás lo harán los problemas técnicos. No porque construyas las funciones, sino porque te quedas sin tiempo, sin dinero o sin cordura intentándolo.

Cómo el scope creep mata una app que funciona

Esto es lo que pasa. Dices que sí a las primeras tres peticiones porque parecen razonables. Le pides a tu creador de apps con IA que las agregue. Toma dos semanas en lugar de una porque cada función nueva choca con el código que ya existe. Ahora tienes una app que hace cinco cosas, hace tres de ellas bien y dos más o menos.

Luego llega la petición número cuatro: “¿Podemos tener distintos niveles de permisos?”. De repente necesitas replantear quién puede ver qué en cada pantalla. Eso no es una función; es un cambio de arquitectura. Le pides a tu creador de apps con IA que lo haga. Toca todo. Dos semanas se vuelven tres. La app se pone más lenta porque le agregaste lógica a cada vista.

Para la petición número ocho, dejaste de lanzar cosas nuevas para tus usuarios originales porque estás demasiado ocupado manteniendo girando la máquina de peticiones. La gente que amaba la app hace tres meses está frustrada porque nada de lo que pidió está terminado. La gente que hace peticiones nuevas está frustrada porque las funciones tardan una eternidad.

Construiste algo que funciona. Lo rompiste tratando de serlo todo.

El marco para decidir

Necesitas un filtro. Cada petición de función pasa por tres preguntas:

Pregunta 1: ¿Esto pertenece a esta app, o es una app distinta?

Tu primera app hace un trabajo realmente bien. Una app de agendado agenda cosas. Una app de facturación factura. Son apps distintas. Si alguien le pide a tu app de agendado que facture, no le estás agregando una función —le estás pidiendo a una app de agendado que haga contabilidad. Eso es un producto distinto.

Una buena prueba: “Si tomara esta función y la lanzara por su cuenta, ¿la gente querría comprarla?”. Si la respuesta es sí, probablemente pertenece a una app distinta. Si la respuesta es “no, solo tiene sentido como parte de la cosa más grande”, entonces estás construyendo dentro del alcance correcto.

Vas a recibir peticiones como “intégralo con nuestro CRM”. Lo que eso quiere decir en realidad es “sé tu propio CRM”. Eso es una app distinta. Puedes integrarte con un CRM más adelante. No puedes agregar las funciones de todo un CRM sin convertirte en un CRM.

Pregunta 2: ¿Esto resuelve un problema para la mayoría de tus usuarios, o solo para este?

Un cliente ama tu app y tiene una idea de función. Es un problema real que tiene. También es un problema real que solo él tiene.

Si tienes veinte usuarios y uno está pidiendo algo, comprueba: ¿los otros diecinueve también lo están esperando, o esta persona simplemente se le ocurrió? Puedes preguntarles directamente: “Antes de ti, ¿has pensado en preguntarle a alguien más si necesita esto?”. Por lo general la respuesta es no.

Esta es la pregunta peligrosa porque el único cliente que pide podría ser tu cliente más importante. Quizá necesites mantenerlo contento. Eso es una decisión de negocio, no una decisión de producto. Pero entra con los ojos abiertos: si construyes algo para un solo cliente, no estás haciendo crecer tu app, estás montando un servicio de consultoría.

Pregunta 3: ¿Cuánto cuesta esto y cuál es el costo para la idea original?

Todo cuesta algo. Exportar a Excel te cuesta tiempo de ingeniería. Le cuesta complejidad a tu app. Le cuesta enfoque. Construye eso en lugar de una optimización de rendimiento de la que tus usuarios se quejan a diario, y ya tomaste una decisión.

Pregúntate en concreto: “Si construyo esto, ¿qué no construyo?”. Si la respuesta es “nada, tenemos tiempo infinito”, no estás siendo honesto. No lo tenemos. El tiempo es finito.

El costo para la idea original suele ser invisible. Cuando estás metido hasta el cuello en peticiones de funciones, dejas de mantener lo central que la gente amaba de ti. Lo central se pone más lento. Lo central se llena de errores. Lo central se siente descuidado. Y al final la gente se va porque la app que funcionaba de maravilla ahora funciona más o menos y hace cosas para las que nunca fue diseñada.

Un ejemplo real: el formulario de admisión

Alguien construyó un sencillo formulario de admisión para clientes. Los clientes lo llenan, el coach lo revisa, agendan. Esa es la app.

Petición uno: “¿Puedo marcar las admisiones urgentes?”. Sí, es una variación del flujo central. Constrúyela.

Petición dos: “¿Puedo exportar las admisiones a Excel para mis registros?”. Esto es una función de documentos. No es el trabajo de la app. Las admisiones viven en la app. Si necesitan Excel, pueden copiar y pegar. Pero bueno, exportar quizá tenga sentido como comodidad. Constrúyela.

Petición tres: “¿Pueden las admisiones crear automáticamente eventos de calendario?”. Ahora estás haciendo agendado. La app era para admisión, no para agendar. Si alguien quiere ambas cosas, probablemente quiere un sistema de agendado de verdad, no un parche que le pega uno encima. Recházala con amabilidad.

Petición cuatro: “¿Pueden los coaches enviar seguimientos de admisión por SMS?”. Ahora eres un sistema de comunicación. No.

Para la petición tres ya llegaste al límite. La app es admisión. Cualquier otra cosa es una app distinta. Puedes integrarte con esas apps más adelante. No puedes agregarlas sin convertirte en esas apps.

Cómo decir que no

La parte más difícil es de verdad decirlo. No quieres frustrar a tus usuarios.

Sé honesto: “Es una gran idea, pero es un producto distinto del que estamos construyendo aquí. Lo que estamos construyendo es [tu único trabajo]. Si intentamos hacer agendado o facturación o cosas de CRM, vamos a quedar más o menos en todas y geniales en ninguna”.

A menudo el cliente lo entenderá. Lo pidió porque se le ocurrió la idea, no porque te esté poniendo a prueba.

A veces te van a insistir. “Pero necesito las dos cosas”. Ahí es cuando recomiendas: usa la app de agendado de verdad. Usa la app de facturación de verdad. Usa el CRM de verdad. Y luego usa esta app para lo que hace bien. Esa es la respuesta honesta.

La tentación de serlo todo

La parte más difícil de construir un producto pequeño es decir que no. El no se siente como dejar dinero sobre la mesa. ¿Y si ese cliente de verdad habría pagado por las dos cosas? ¿Y si esa función te habría hecho diez veces más grande?

Quizá. Pero no eres un producto diez veces más grande si no lo lanzas. Eres un producto a medio terminar que hace cinco cosas mal. La gente que amaba lo central está frustrada. La gente que quería las funciones nuevas está frustrada. Y te metiste en un callejón donde agregar cualquier cosa nueva implica primero refactorizar cinco cosas viejas.

Los productos que crecen son los que hacen un trabajo realmente bien, y luego agregan con cuidado. No intentan ser Salesforce desde el primer día. Son la app que tomas cuando necesitas hacer esa una cosa, y la app en la que confías para que sea rápida y confiable cuando la haces.

Di que no. Protege lo central. Haz eso, y construirás algo que la gente de verdad quiere usar.