Una pregunta casi siempre mal planteada
«¿Hay que saber programar?» presupone una respuesta binaria para una realidad continua. Entre el Product Manager que no sabe qué es un token y el que despliega él mismo un prototipo, hay una decena de posiciones intermedias, y la mayoría de los puestos se juega en el medio. La pregunta útil es otra: ¿qué profundidad de comprensión permite tomar buenas decisiones de producto sobre un sistema cuyo comportamiento no es determinista?
El desplazamiento importa. En un producto clásico, un PM puede razonar con reglas: esta acción abre esta pantalla, este cálculo devuelve este resultado. En un producto de IA, el sistema produce una distribución de comportamientos. Dos formulaciones parecidas devuelven respuestas distintas; la misma formulación puede ser excelente en un caso y mediocre en el siguiente. El alcance, las salvaguardas y la medición se convierten entonces en decisiones de producto de pleno derecho, y se toman con un vocabulario que el PM debe dominar.
Programar es una competencia. Entender un sistema probabilístico, sus datos y sus modos de fallo es otra. Se solapan en parte, pero es la segunda la que condiciona la calidad de las decisiones de producto.
Nivel 1 — imprescindible, aunque no se escriba código
Esta base no es negociable en ningún contexto. No se trata de saber cómo se entrena un modelo, sino de saber qué hace, qué no hace y qué aspecto tiene un fallo.
Lo que el sistema puede y no puede hacer
- El comportamiento es probabilístico: la misma entrada puede dar salidas distintas, y una respuesta plausible no es una respuesta verificada.
- Un modelo de lenguaje trabaja con el contexto que se le entrega; lo que no está en el contexto no existe para él, salvo como memoria de entrenamiento, sin garantía de actualidad.
- Las alucinaciones no son un error puntual pendiente de corregir: son la contrapartida de un sistema que produce texto plausible. Se reducen y se acotan; no se eliminan por decisión de gestión.
- La calidad depende ante todo de los datos accesibles: cobertura, actualidad, derechos de acceso y estructura.
- Sin evaluación, ninguna afirmación sobre la calidad vale nada. «Funciona bien» no es un resultado.
Restricciones que se convierten en arbitrajes de producto
- Latencia: un sistema que responde en varios segundos no encaja en los mismos recorridos que uno que responde al instante. Es una decisión de experiencia, no un detalle de implementación.
- Coste: cada llamada tiene un precio que varía con la longitud del contexto y el modelo elegido. Una funcionalidad puede ser excelente y económicamente insostenible a volumen real.
- Confidencialidad y derechos: qué sale de la organización, qué se conserva, qué puede ver cada usuario a través del asistente. Un asistente nunca debe ampliar los permisos de quien lo utiliza.
- Límites de un prototipo: una demo demuestra que un comportamiento es posible en casos elegidos. No dice nada sobre la estabilidad en casos no elegidos, ni sobre el coste, ni sobre el mantenimiento.
Un PM que domina este nivel ya decide mejor que muchos perfiles más técnicos: sabe cuándo una idea es inviable dentro de las restricciones del producto, y sabe por qué.
Nivel 2 — muy útil: poder comprobar por uno mismo
El segundo nivel sigue sin consistir en escribir código de producción. Consiste en acortar el bucle entre una hipótesis y una observación. Un PM capaz de probar una intuición en una hora no consume el tiempo de un ingeniero para zanjar una cuestión gruesa de viabilidad, y llega a la conversación con observaciones en lugar de opiniones.
- Probar rápido una hipótesis: pasar veinte casos reales por el sistema y mirar qué se rompe, en vez de razonar sobre tres ejemplos favorables.
- Entender qué es una API: qué se envía, qué se recibe, cuánto cuesta la llamada, qué ocurre ante un error o al superar una cuota.
- Leer documentación técnica sin miedo: límites de contexto, formatos de salida, opciones de configuración.
- Manejar una herramienta de prototipado — hoja de cálculo conectada, banco de pruebas de prompts, herramienta no-code, notebook compartido — hasta obtener algo utilizable.
- Entender la forma general de un workflow: llamada simple, recuperación de información y después generación, o encadenamiento de acciones con herramientas. Basta con saber de qué se habla; no se pide implementarlo.
- Dialogar con precisión con Engineering y Data: nombrar bien los objetos, distinguir un problema de recuperación de uno de formulación, plantear una pregunta que no obligue al interlocutor a reescribir la petición.
Este nivel tiene un efecto colateral evidente: da credibilidad. Un equipo técnico atiende de otra manera a quien ya ha mirado los datos y probado el comportamiento antes de abrir la discusión.
Nivel 3 — escribir código: un extra que depende del contexto
Saber escribir algo de Python o JavaScript, llamar a una API, montar un prototipo pequeño: es una ventaja real y sería deshonesto minimizarla. Pero es una ventaja contextual, no una condición de acceso. Pesa mucho en ciertas configuraciones y casi nada en otras.
- Startup o producto muy joven: nadie está libre para validar una intuición, y un PM autónomo ahorra semanas.
- Equipo reducido: la frontera entre roles es difusa por necesidad, y poder contribuir técnicamente amplía lo que el equipo puede explorar.
- Fase de discovery intensiva: cuando la pregunta abierta es qué sabe hacer el modelo, experimentar directamente suele ser más rápido que especificar.
- Producto muy técnico, vendido a personas desarrolladoras o a equipos de datos: la credibilidad ante esos usuarios pasa por una comprensión de primera mano.
A la inversa, en una organización con un equipo de AI Engineering consolidado, un backlog cargado y exigencias fuertes de cumplimiento o coordinación, el valor marginal de un PM que programa es bajo frente al de un PM que encuadra, prioriza y arbitra bien. Leer aquí una jerarquía universal es un error de análisis.
Escenario: dos Product Managers, dos resultados
Escenario pedagógico, deliberadamente simplificado. Una empresa quiere ayudar a sus asesores a encontrar información en una documentación interna extensa. Dos PM lo abordan de forma distinta.
PM que programa pero encuadra mal
Monta él mismo un prototipo convincente en pocos días, elige un enfoque técnico y lo presenta como la solución. Nadie ha establecido qué preguntas hacen realmente los asesores, ni qué ocurre cuando la documentación es ambigua o está desactualizada. Él mismo despliega el prototipo en producción; el uso real sigue siendo bajo, porque los asesores no pueden apoyarse en una respuesta que no tienen forma de verificar.
PM que apenas programa pero entiende el sistema
Empieza recopilando cien preguntas realmente formuladas, detecta que la mitad se refiere a tres procedimientos, comprueba quién puede ver qué y acuerda con el equipo un comportamiento ante la duda: citar la fuente o abstenerse. No elige la arquitectura. La primera versión cubre un alcance estrecho, cita sus fuentes y se usa a diario.
El segundo caso no es mejor por programar menos. Lo es porque su comprensión técnica bastaba para fijar las restricciones adecuadas y porque su energía fue al problema y no a la demostración. El caso ideal, evidentemente, combina ambos: un PM que prototipa rápido y encuadra bien. La competencia escasa es la segunda.
PM y PO: dos preguntas técnicas distintas
Confundir los dos roles enturbia el debate sobre la tecnicidad. El Product Owner trabaja a nivel de funcionalidad: especificar el comportamiento esperado, definir criterios evaluables, decidir qué es aceptable y qué no, seguir la calidad en el tiempo. Su profundidad técnica sirve a la precisión de la especificación.
El Product Manager trabaja antes y más ancho: qué problema merece tratarse, para qué usuario, con qué valor, en qué secuencia y a qué coste de oportunidad. Su profundidad técnica sirve al juicio: distinguir una vía viable de una atractiva pero cara, intuir qué hará posible un modelo dentro del alcance del producto y evitar comprometer al equipo con una promesa que el sistema no podrá sostener.
Una organización donde el PM solo se hace la pregunta del valor y el PO solo la de la especificación funciona. Una organización donde ninguno entiende el comportamiento del sistema entrega funcionalidades que nadie sabe evaluar.
Progresar sin equivocarse de objetivo
La trayectoria más eficaz no es un curso de programación, sino una comprensión utilizable, construida en este orden.
- 1
Observar el sistema con casos reales
Reunir casos del terreno — no ejemplos inventados — y mirar dónde se degrada el comportamiento. Es la fuente más rápida de comprensión técnica concreta.
- 2
Nombrar bien lo que se observa
Distinguir una mala recuperación de información de una mala formulación, un límite de contexto de una falta de datos, un error de formato de un error de fondo. Esa precisión de vocabulario mejora de inmediato los intercambios con el equipo.
- 3
Aprender a evaluar antes que a construir
Saber montar un conjunto de casos de prueba de negocio, definir qué significa «buena respuesta» y comparar dos versiones vale más, para un PM, que saber llamar a una API.
- 4
Prototipar, si el contexto lo justifica
Añadir la capacidad de montar un prototipo cuando la organización obtiene un beneficio real: equipo reducido, discovery intensivo, producto técnico. Si no, esa energía rinde más en otro sitio.
Esta progresión tiene una ventaja: cada etapa es útil de inmediato, incluso para un PM que nunca escribirá código. Y evita la trampa simétrica: un PM que aprendió a programar pero sigue sin poder decir, ante una respuesta del sistema, si el negocio puede aceptarla.
Para recordar
- La pregunta útil no es «saber programar», sino «con qué profundidad entiendes el sistema que diriges».
- El nivel 1 — comportamiento probabilístico, datos, evaluación, coste, latencia, límites de un prototipo — no es negociable.
- El nivel 2 — probar una hipótesis, leer documentación, prototipar, dialogar con precisión — cambia la velocidad del discovery.
- Escribir código acelera de verdad en ciertos contextos, pero no es un requisito de acceso al puesto.
- Un PM que programa pero encuadra mal entrega funcionalidades limpias que nadie usa.
- El PM sostiene el valor y la estrategia; el PO sostiene la especificación y los arbitrajes de la funcionalidad.
- AI Product
- Cultura de IA
- Encuadre de casos de uso