Idea principal

Se abre una brecha de capacidad entre los Product Managers que vienen de una trayectoria técnica y los demás. No afecta ni a la comprensión del mercado, ni a la calidad del juicio, ni a la capacidad de nombrar un problema — los terrenos donde el oficio se juega habitualmente.

Afecta a un acceso. Quien sabe leer un repositorio, seguir merge requests e interrogar un historial de commits puede trabajar directamente sobre la materia del producto: generar un artefacto a partir de ella, verificar que un documento dice la verdad, contradecir una afirmación mostrando el código. Quien no sabe hacerlo tiene que pasar por alguien, y la ida y vuelta cuesta lo bastante como para que renuncie en la mayoría de los casos.

La brecha es, por tanto, una brecha de herramientas y no de valor. Es una distinción importante, porque ambas piden remedios opuestos: un déficit de aptitud se recluta, un déficit de acceso se aprende o se dota de herramientas.

Capa aportada por "PM, desarrolladores e IA: los roles se difuminan, las responsabilidades permanecen" (2026-08-01). La brecha de acceso se abre aún más cuando el Product Manager se pone a construir. Leer un repositorio, entender un error, dialogar con un agente de código, detectar un absurdo en lo que se ha generado y pedir la revisión técnica adecuada condicionan todo lo que va más allá de la maqueta: mientras las herramientas sigan siendo falibles, no se puede ignorar lo que pasa bajo el capó. La frontera tiene fecha y puede invertirse — si los agentes se vuelven claramente más fiables, perfiles venidos de la psicología, las letras, el diseño o la investigación recuperarían la ventaja por su capacidad de expresar con finura una realidad humana y de negocio.

Por qué es importante

Esto evita la lectura identitaria — "los PM técnicos son mejores" — que cierra la discusión, y la sustituye por una pregunta tratable: ¿qué acceso necesita un PM no técnico, y a qué precio puede adquirirlo?

También dice lo que pasa si no se hace nada: la brecha no se cierra sola, porque se acumula. Cada verificación hecha directamente afina la comprensión del producto, que hace más rápida la verificación siguiente.

Matices y límites

El acceso no es una ventaja sin reverso: el PM técnico puede ponerse a tratar los problemas que sabe resolver con código, en detrimento de los que dependen del mercado.

Y la frontera se mueve. Las herramientas que hacen interrogable un repositorio en lenguaje natural bajan el coste del acceso sin suprimirlo — la cultura técnica sigue siendo necesaria para saber qué pedir y para juzgar la respuesta.

Preguntas abiertas

• ¿Qué forma de aprendizaje da a un PM no técnico el acceso útil sin convertirlo en desarrollador?