La Feature Factory, diez años después: John Cutler revisa su célebre texto sobre fábricas de funcionalidades

El contenido recibido es una versión parcial del artículo: se interrumpe justo al comienzo de la sección «AI Amplifies Both Directions» (la IA amplifica en ambas direcciones). Por tanto, este resumen cubre solo lo que aparece en el texto descargado y no puede decir nada fiable sobre lo que el autor concluye acerca de la IA.

John Cutler, autor del boletín The Beautiful Mess, publica la entrega número 445 con fecha del 15 de octubre de 2026. Es una retrospectiva sobre el texto que escribió hace diez años en Medium sobre las «feature factories». Cuenta que lo redactó en pocos minutos para demostrar a un investigador de Medium que los textos más contundentes y críticos obtienen más tráfico que los matizados. El texto se hizo viral, llegó a Hacker News y, según él, le ayudó a conseguir un trabajo que le gustaba. Desde entonces ha escrito cerca de mil publicaciones. Admite que ahora no escribe así, pero le gusta volver sobre el tema cada pocos años.

Su primera tesis es que todos trabajamos en una fábrica de funcionalidades: alguien en la empresa piensa el producto en términos de lo que se ha lanzado. Según Cutler, esas personas no son tontas. Simplemente no han visto otra forma de trabajar o no la han visto funcionar. Añade que existen fábricas de otros tipos («una fábrica de ___») con mentalidades igual de dominantes. El reto es saber qué hacer al respecto sin perder la cordura.

Segunda idea: está cansado de los esquemas «X contra Y», como resultados contra entregables o proyectos contra productos. Reconoce que él mismo los usó mucho. Sostiene que presentan el trabajo como algo binario cuando casi siempre se hace todo a la vez. Relata la anécdota de un equipo de una empresa que suele citarse como referente de producto. Allí les hacía mucha gracia que el resto del mundo estuviera atrapado en esas falsas tensiones. En su empresa también usaban proyectos, tenían productos y se preocupaban por entregables y por resultados. Según ese equipo, la presión ejecutiva por «lanzar más rápido» existe en todas partes. Cutler critica que la idea de pasar de proyectos a productos llevó a muchas empresas a llamar «producto» a cualquier cosa, a contratar en exceso perfiles de gestión de producto y a «instalar» un modelo operativo como si fuera plug and play. En su opinión, esto relegó el diseño y la UX y convirtió en ciudadanos de segunda a las plataformas y los equipos más abajo en la pila. También menciona la convergencia, la contratación y la marca prematuras en torno a «nuevos equipos de producto», y afirma que muchos despidos tuvieron que ver con esa lógica. Prefiere apuestas de varios trimestres con un caso de negocio real, y dice que el factor que muchas organizaciones pasaron por alto fue el cambio en los mecanismos de financiación y gobernanza.

Sobre los proxies y la confianza, Cutler sostiene que las funcionalidades no son el mejor indicador de progreso, pero tampoco el peor. Una fábrica de funcionalidades bien engrasada, que entrega cosas razonablemente usables sin acumular una montaña de errores, sería un gran avance para algunos equipos. Al revés, observa equipos expertos en discovery y marcos de trabajo que no logran entregar. Señala que pueden sentirse más cómodos en tableros de Miro, documentos y reuniones de estrategia que tomando decisiones difíciles, y dice que reducen la incertidumbre hasta sentirse cien por cien cómodos en lugar de dar el salto. Cuando hay poca confianza, poca familiaridad o muchas dependencias, afirma, los equipos se apoyan en proxies, y las funcionalidades son lo más tangible que pueden acordar. Advierte además que los enunciados de problemas, las métricas, las oportunidades y los OKR también pueden ser proxies, un juego pactado para tapar la angustia y el miedo a trabajar juntos. Menciona equipos que dicen «centrarse en problemas» pero nunca admiten que no los resolvieron, y el desarrollo orientado a conseguir ascensos («promotion-driven development») en empresas supuestamente orientadas a resultados.

En el apartado sobre lo humano, Cutler reconoce que el texto original no está bien escrito: tiene repeticiones y es cascarrabias sin profundidad. Sin embargo, mucha gente le ha contado lo que sintió al leerlo: la sensación de estar atrapado en una máquina a la que no le importan las personas, o de que tu valor se reduzca a las casillas de funcionalidades marcadas. Para él, lo que está en juego es el deseo de tener impacto, honestidad epistémica y respeto por el oficio. Atribuye el problema a la ignorancia, a líderes desconectados que solo quieren producción y también al desafío constante de dar sentido al trabajo y a la identidad profesional.

Otra tesis central es que se trata de un espectro. Cada problema es la solución anidada de un problema de orden superior, y cada entrada es en algún grado una salida. Según Cutler, siempre se es en alguna medida una fábrica de funcionalidades, incluso cuando se hacen experimentos validados. Cita a Greg LeMond, con variación: «No se vuelve más fácil; simplemente te centras en un nivel de abstracción superior». Los equipos de plataforma lo entienden bien. Si nadie acepta su cadena causal hacia ingresos y costes, dice, quizá les convenga más operar como fábrica de funcionalidades mientras hacen experimentos y mediciones paralelos. Y avisa de que el «paraíso del foco en el problema» no existe: siempre habrá que justificar lo que se lanza y cómo contribuye a los ingresos.

Desde su perspectiva de investigador y diseñador de UX, Cutler critica también la «centricidad en resultados performativa». Dice que tanto aparato de resultados, metas y «trabajos por hacer» (jobs) puede llevar a justificar diseños casi inutilizables apoyados en investigación endeble. Describe un círculo completo. Por un lado hay matemáticas de alto nivel y vagas, y por el otro prompts y especificaciones, sin que ya haya experimentación, modelado ni trabajo con las manos. Si aparece algo, es porque alguien «construyó un prototipo por diversión» y el equipo responde «vale, lánzalo», lo que según él no es un prototipo. Añade, aclarando que quizá reacciona al caos actual de la IA, que los PM incentivados por el «caso de negocio» usan IA para crear «tornados de basura», porque los LLM conectan todo de forma aparentemente realista.

Tampoco descarta que a veces las funcionalidades sean la respuesta. Hay situaciones, sobre todo en dominios resueltos desde hace décadas, donde lo razonable es hacer una lista de funcionalidades y entregarlas. Pone como ejemplo bueno a AppFolio, donde trabajó. Entraron en un dominio con software local ya establecido, hicieron ingeniería inversa de la contabilidad de gestión inmobiliaria y a la vez apostaron por la segmentación con menos funcionalidades y por nuevas tecnologías. Se pregunta dónde está la línea entre una capacidad de siempre y «la funcionalidad» de resolverla hoy con IA. Menciona que su anterior empresa, Dotwork, apostaba a que muchas funcionalidades de cola larga de proveedores heredados de SPM dejarían de ser necesarias o cambiarían con la IA, y admite que no sabe si esa apuesta se sostendrá.

Sobre lo que frena a los equipos, enumera factores estructurales: acceso directo a clientes y a datos, autonomía suficiente para evitar la convergencia prematura, formación (a veces sí es un problema de habilidades) y la estructura de promoción. Afirma que muchas de estas cosas no son actitud sino inversión de dinero, tiempo y capital político. Pide salir del pensamiento 0/1: un «resultado» puede ser agendar una llamada corta con un cliente, instrumentar un dato o conseguir una narrativa sobre si algo funcionó. Critica las historias de éxito y los «resúmenes de resúmenes» de empresas que imprimen dinero, y recuerda que la realidad es un continuo de cosas que salen mal, otras mediocres y algunos éxitos.

En experimentación y convicción, Cutler sostiene que cualquier funcionalidad adyacente a costes o ingresos y con un ciclo de experimentación corto debería ser ya objeto de experimentos. Pero muchos retos de producto no admiten experimentos controlados y requieren otras formas de reducir la incertidumbre, más parecidas a pseudoexperimentos. Defiende el papel de la convicción: los datos pueden reforzarla, pero a escalas de tiempo largas es necesaria. Según su experiencia, los equipos que superan la fábrica suelen hacerlo por convicción en su forma de trabajar, a menudo tras errores graves del pasado. Reconoce que la convicción también puede llevar un producto al abismo.

Finalmente, sostiene que el juego empieza antes que el equipo. Para él, derrotar a la fábrica de funcionalidades comienza con la justificación para crear el equipo y con cómo se plantea el juego desde el inicio, incluyendo el caso de negocio y la economía básica. Es muy difícil volver atrás y cambiar el juego una vez establecido. De ahí la importancia del diseño organizativo, más allá de cajas y flechas, mapas de recorrido y asignaciones de equipos por JTBD.

El texto recibido termina al empezar la sección sobre cómo la IA amplifica ambas direcciones («apparently factories are all the rage right now. Software facto…»), por lo que no es posible resumir esa parte final ni sus conclusiones.