Faire convierte a sus ingenieros en «product builders» para que la IA no deje el diseño de producto como cuello de botella

El artículo, publicado en el blog de ingeniería de Faire (The Craft) y firmado por Thuan Pham, Jorjena Dankha y Matt Bolohan, describe cómo la empresa ha reaccionado al hecho de que la IA haya acelerado enormemente la escritura de código. Según el texto, durante décadas programar fue tan caro y lento que los buenos equipos invertían mucho al principio en requisitos de producto, diseño de flujos y prototipos para reducir el riesgo antes de construir. Con la IA automatizando buena parte del trabajo de código, esa lógica ha cambiado.

El dato central que ofrece Faire es que, durante el último año, el ingeniero típico aproximadamente triplicó su rendimiento de PRs ponderado por complejidad, y mucho más los mejores. La métrica se calcula para 214 ingenieros presentes en ambos periodos, con un servicio de puntuación basado en IA que pondera la complejidad para que los PRs pequeños no inflen las cifras, usando el mismo modelo en ambos periodos. Cada persona se compara con su propia línea base en dos ventanas de 12 semanas: del 24 de octubre de 2025 al 15 de enero de 2026, frente al 31 de julio al 22 de octubre de 2026.

El problema que identifican es que el proceso pesado de diseño de producto, que antes seguía el ritmo del código, se convirtió en el nuevo cuello de botella. Descartan la solución simple de contratar muchos más PMs y diseñadores, porque más gente implica más traspasos, y los traspasos ya ralentizaban el trabajo. En su lugar, apostaron por desarrollar a sus ingenieros como «product builders»: ingenieros con comprensión del negocio, buen criterio sobre qué construir y no solo cómo, y responsabilidad compartida sobre el éxito del cliente.

En Faire llaman «product engineers» a estos perfiles para distinguirlos de otras especializaciones (plataforma, infraestructura, seguridad). Los autores señalan que la idea se aplica también a esas áreas: sus clientes son otros ingenieros y, para ellos, el pensamiento de diseño equivale a la elegancia y usabilidad de una API o de una arquitectura de componentes. La diferencia entre un ingeniero y un «builder» sería ese nivel añadido de pensamiento de producto y diseño, en cualquier dominio.

La secuencia básica del desarrollo (ideas, requisitos, diseño, código, lanzamiento) sigue existiendo; lo que cambia es cómo se recorre. En lugar de pasar cada funcionalidad por PMs y diseñadores para requisitos y especificaciones, los product engineers asumen de extremo a extremo la mayoría de las funcionalidades, muchas en paralelo. Esto libera a PMs y diseñadores para centrarse en los problemas de cliente más espinosos, donde ellos mismos pueden usar IA para prototipar y refinar requisitos y decisiones de diseño con rapidez.

El programa arrancó el 1 de julio con un plazo de seis meses para llevar a todos los product engineers por la curva de aprendizaje. El artículo destaca tres tácticas. La primera es la franqueza: la dirección fue explícita con los equipos sobre lo que implicaba el cambio, comparando la IA con olas previas de productividad (compiladores, código abierto, la nube, frameworks modernos) y reconociendo que es a la vez emocionante e intimidante, porque todos deben aprender nuevas habilidades o arriesgarse a quedarse obsoletos. Según los autores, esa honestidad generó más confianza que intentar edulcorar la situación.

La segunda táctica es la orientación práctica basada en experiencia real. En la primera mitad del año crearon un par de «pods» denominados «AI Amplified», pequeños equipos de producto multifuncionales, como experimento para descubrir dónde están los verdaderos cuellos de botella del ciclo de desarrollo en la era de la IA. A partir de ello fijaron el objetivo de que cada product engineer fuera dueño de una funcionalidad de principio a fin y la lanzara, y construyeron un centro de capacitación con habilidades para agentes de programación con IA, recursos, formación en directo y un «playground» para prototipado rápido. También establecieron un «Complexity Tier Framework» de tres niveles que ajusta la complejidad multifuncional de una tarea a las capacidades actuales del ingeniero. Aclaran que el nivel refleja la complejidad multifuncional, no la dificultad de ingeniería: una tarea técnicamente difícil dentro de un solo equipo y con una UX conocida puede seguir siendo de Nivel 1.

La tercera táctica es el compromiso con el coaching. Los autores advierten que, con la IA haciéndolo todo más rápido, es fácil que el entusiasmo se convierta en impaciencia improductiva, y que a veces hay que frenar un poco para reequiparse y luego ir mucho más rápido. Reconocen una tensión: querían a los ingenieros en los problemas de mayor impacto, pero estaban limitados por su nivel de desarrollo de habilidades, así que dirigieron parte de la capacidad a oportunidades de menor alcance. Ahora, con más competencia, abordan los grandes problemas dividiéndolos en subproblemas que un product engineer pueda asumir de extremo a extremo.

Para hacerlo de forma deliberada, actualizaron las expectativas de desempeño por escrito, involucraron a PMs y diseñadores sénior como mentores en los principios del pensamiento de producto y diseño (apoyados en kits de herramientas de producto, diseño, análisis y experimentación) y establecieron evaluaciones cada dos meses. Los responsables de ingeniería valoran cada dimensión como Developing, Capable o Strong, con aportaciones de sus contrapartes de producto y diseño. Los propios managers se evalúan con el mismo rasero por parte de sus directores y de sus socios de producto y diseño.

En cuanto a resultados, a los cuatro meses del nuevo modelo, dos meses después del inicio el 71 % de los product engineers ya había lanzado una funcionalidad de extremo a extremo, y en la primera evaluación el porcentaje calificado como Capable o Strong en pensamiento de producto y diseño pasó del 41 % al 65 %. La segunda evaluación está en curso y el objetivo es alcanzar el 85 % o más a final de año.

El artículo aporta dos ejemplos. En uno, un ingeniero detectó que las recomendaciones de un programa beta para minoristas no estaban lo bastante personalizadas, analizó los datos, redactó el PRD, se alineó con su PM y con un socio de ciencia de datos, y lanzó fuentes de recomendación más ricas que aumentaron el volumen de pedidos del programa en un 1,5 %. En otro, un ingeniero propuso refactorizar el registro de minoristas, entendió que requería una nueva superficie de producto, diseñó los flujos con un diseñador y ejecutó un experimento; cuando la tasa de finalización del registro salió negativa, investigó y halló un fallo en cómo se medía el experimento, y una vez corregido el resultado fue positivo.

La conclusión de los autores es que, cuando la IA mueve el cuello de botella, las personas pueden moverse con él: los ingenieros inteligentes y motivados aprenden rápido si se les habla con franqueza, se ajusta el trabajo a su nivel y reciben coaching real de producto y diseño. Conviene tener en cuenta que se trata de un texto corporativo de la propia empresa, que además termina con una oferta de empleo, y que las métricas (rendimiento ponderado por una IA, evaluaciones internas de competencias realizadas por los propios managers) son internas y no verificables externamente.