Una feature factory es un equipo que mide su éxito por cuánto entrega, features lanzadas y story points cerrados, en lugar de por qué cambia de verdad en el usuario. El término lo popularizó John Cutler en 2016, y según su propio relato lo tomó de un amigo desarrollador que sentía que estaba en la fábrica sacando features y mandándolas por la cinta.
La señal es sutil: una feature factory suele parecer productiva. Lanza rápido, mantiene la velocidad alta y tiene un historial visible de trabajo terminado. Ha optimizado la actividad de construir, no el resultado de construir.
Señales de que estás en una
- El éxito se mide en entrega (releases, puntos, features), no en cambio de comportamiento ni en resultados de negocio.
- Se añaden features porque la competencia las tiene, porque un cliente grande las ha pedido o porque alguien ha dicho “estaría bien tenerla”, cada una con su lógica local y ningún comportamiento objetivo detrás.
- Nadie sabe responder “¿qué comportamiento nuevo instalamos este trimestre?”.
- El roadmap crece. La razón para que un usuario concreto se quede, no.
- El discovery existe como presentación del trimestre pasado, no como decisiones que cambian lo que se construye esta semana.
- En la demo se enseñan features funcionando. Nunca se enseña a un usuario haciendo algo que antes no podía hacer.
Por qué los equipos caen ahí
No a propósito. Productizar genera señales de progreso inmediatas, demos, changelogs, reuniones donde enseñar algo nuevo, mientras que cambiar comportamiento es invisible durante meses. Casi ninguna organización premia lo invisible. Premia la actividad. Y añadir superficie es actividad.
Qué cuesta
En torno al 80% de las funciones de un software medio se usan rara vez o nunca, y solo un 12% genera la mayor parte del uso diario (Pendo. El informe Standish Chaos lo deja cerca del 64%, metodologías discutibles, dirección consistente). Eso es superficie que existe sin cambiar nada, más el equipo creciente que hace falta para mantenerla. No es gratis. Cada línea viva cuesta algo cada día, se use o no.
Qué sustituye a las métricas de entrega
La salida no es dejar de medir. Es cambiar qué cuenta como marcador. Un equipo empieza a salir de la fábrica cuando cambian sus preguntas por defecto.
feature factory
- features lanzadas
- velocidad por sprint
- longitud del roadmap
- demo del build
equipo de producto
- comportamiento cambiado
- tiempo hasta evidencia
- decisiones registradas
- demo del aprendizaje
Tres sustituciones hacen casi todo el trabajo:
- “¿Lo hemos lanzado?” pasa a ser “¿quién hace algo distinto desde que lo lanzamos?”. Cada elemento del roadmap lleva un comportamiento objetivo, o no entra.
- La velocidad pasa a ser tiempo hasta evidencia, lo que tarda el equipo en saber si una apuesta ha funcionado. Una fábrica puede lanzar cada semana y no aprender nada en un año.
- Las features lanzadas pasan a ser decisiones registradas con la evidencia detrás, para que la siguiente apuesta arranque de lo que enseñó la anterior en lugar de arrancar de cero.
La entrega se sigue midiendo. Solo deja de ser el marcador, igual que las líneas de código se siguieron midiendo mucho después de que todo el mundo dejara de tratarlas como productividad.
Los agentes de código han subido la apuesta
Todo lo anterior es previo a las herramientas de IA. Lo que ha cambiado es el precio de la superficie.
Cuando una feature costaba tres sprints, la fábrica tenía un freno natural. Alguien tenía que defender ese coste, así que al menos algunas malas ideas morían en la estimación. Con agentes, el build que costaba un mes cuesta días, y el freno ha desaparecido. La entrega siempre fue un proxy del progreso. Ahora es un proxy que cualquiera puede inflar a voluntad, y eso la remata como medida de nada.
La misma velocidad corta en el otro sentido. Construir barato significa experimentar barato para el equipo que ejecuta contra una asunción explícita y lee el resultado. La fábrica y el equipo de producto usan ya herramientas idénticas y lanzan a ritmos parecidos. La diferencia ya no se ve en el changelog. Solo se ve en qué cuenta cada equipo, y en si alguien puede rastrear una feature lanzada hasta el comportamiento que debía instalar.
El único test que te saca
Antes de meter nada en el roadmap, completa esta frase:
Gracias a esto, [tipo de usuario] pasará de hacer [X] a hacer [Y], y lo sabremos cuando veamos [métrica Z].
Si no puedes rellenarla, tienes una idea de feature, no de producto. Hacer producto es instalar un comportamiento, no acumular superficie. Esa distinción es la diferencia entre un moat y deuda de atención, y en la era de la IA, cuando copiar una feature cuesta una tarde, es la única que importa.
Preguntas frecuentes
¿De dónde viene el término “feature factory”? Lo popularizó John Cutler en 2016. Según su propio relato, un amigo desarrollador se quejó de estar en la fábrica sacando features, y el nombre se quedó.
¿Lanzar features es siempre malo? No. A veces productizar es lo correcto: alcanzar paridad, no perder un cliente, ganar tiempo. El problema es hacerlo en modo automático, sin saberlo.
¿Qué tiene que ver con el desarrollo con IA? La IA abarata generar features casi a cero, lo que acelera la feature factory salvo que la intención y la verificación estén aguas arriba. La disciplina que lo contrarresta es la misma idea un nivel más abajo: un build en verde no es una feature correcta.
¿Qué métricas usa un equipo de producto en su lugar? Cambio de comportamiento por apuesta (la frase de X a Y, observada en una métrica con nombre), tiempo hasta evidencia por decisión, y la parte del trabajo lanzado que se puede rastrear hasta una decisión registrada. La entrega se sigue midiendo. Ya no es el marcador.