Product Maker: quizá Product Manager y Product Designer nunca debieron ser dos personas

Hace unos meses estuve hablando con gente de Mercadona Tech y me explicaron un rol que llaman Product Maker. Reúne en una misma persona buena parte de lo que solemos repartir entre un Product Manager y un Product Designer. Me pareció una idea muy buena y me hizo pensar en cómo dividimos el trabajo de producto.

Lo que sigue es mi lectura del concepto y por qué creo que ahora tiene más sentido que hace unos años.

Un rol que me resultó familiar

Tal como lo entendí, lo importante no es que una persona reúna dos oficios, sino que pueda sostener el contexto de un problema durante casi todo el recorrido. Empieza por entenderlo, con su discovery, su research y el contexto de negocio, formula hipótesis sobre qué aportar y en qué orden, y define cómo medirlo. Después explora soluciones, trabaja flujos y experiencia, prototipa, valida e itera, y deja algo lo bastante claro para trabajar con ingeniería, a la que sigue acompañando mientras se construye.

Me resultó familiar porque he trabajado durante años como diseñador y después como director de diseño, antes de centrarme más en Product Management. En algunas etapas trabajé de una forma parecida: entendía el problema, participaba en el discovery, pensaba en producto, diseñaba, prototipaba y hablaba directamente con desarrollo, iterando con menos intermediarios.

No digo que hiciera ese mismo rol. Sí he experimentado las ventajas de mantener mucho contexto desde el problema hasta la solución. Cuando me lo explicaron reconocí una forma de trabajar que en algunos momentos me había resultado especialmente efectiva. Mi paso de diseñador a Product Manager fue más una continuación que un cambio, y quizá por eso me cuesta ver producto y diseño como oficios tan separados.

Producto y diseño no ocurren por turnos

A menudo se cuenta el trabajo de producto como una secuencia: primero se piensa qué hacer y después se diseña cómo. En muchos problemas no funciona así. Mientras entiendes el problema ya estás imaginando soluciones, y mientras prototipas descubres cosas que no habían salido en ninguna conversación. A veces, al probar algo, hay que volver atrás y replantear una decisión de producto que parecía cerrada.

Es un bucle, y por eso me atrae que pueda llevarlo una sola persona. Cada vuelta cuesta menos cuando no hay que explicarle a otro lo que se acaba de descubrir. También explica el peso del prototipado, que sirve para pensar y que ya no es una habilidad exclusiva del diseñador.

Por qué ahora

Hace unos años era difícil que una misma persona abarcara con calidad tantas partes del proceso, porque cada una pedía su propio oficio y mucho tiempo de ejecución. Hoy la IA amplía lo que puede hacer alguien que ya tiene criterio. No sustituye el conocimiento de producto ni el criterio de diseño, los amplifica, así que sin ellos no hay mucho que amplificar. Por eso creo que a un Product Maker le hacen falta tres cosas.

La primera es un conocimiento profundo de producto, que incluye discovery de verdad, priorización, métricas, experimentación, negocio y relación con stakeholders e ingeniería. No consiste solo en tener ideas y hacer pantallas.

La segunda es un criterio de diseño que no dependa de la herramienta. No basta con saber usar Figma o con pedirle a una IA que genere una interfaz. Hay que entender UX, arquitectura de información, interacción y accesibilidad, y saber ver cuándo una interfaz resuelve bien un problema y cuándo solo lo parece. La ejecución se acelera con IA, pero el criterio no aparece solo, y aprender a mirar como un diseñador sigue llevando tiempo.

La tercera es soltura con la IA. Una persona con una base sólida de producto y de diseño que además la maneje bien puede abarcar hoy una superficie de trabajo que hace pocos años habría sido difícil. La IA ayuda a sintetizar investigación, explorar hipótesis, generar alternativas, prototipar o construir interfaces, y se lleva buena parte del trabajo más mecánico.

Creo que la combinación de producto, criterio de diseño e IA puede ser especialmente potente, siempre que los dos primeros elementos existan de verdad.

El sistema importa

Todo esto funciona mejor cuando la organización ya tiene una base sólida. Me refiero a un design system maduro, con sus componentes, patrones y principios, y también a guías, criterios compartidos y equipos de ingeniería fuertes. Cuando muchas decisiones básicas están resueltas, nadie reinventa el diseño en cada funcionalidad y queda tiempo y atención para el problema, el valor, la experiencia y la iteración.

Con un sistema de diseño maduro y herramientas de IA, una persona puede abarcar bastante más sin sacrificar necesariamente la calidad. Esa base, además, no aparece sola. Alguien tiene que mantenerla y hacerla evolucionar.

Menos cambios de manos

En el flujo tradicional el trabajo pasa de research a producto, de producto a diseño y de diseño a ingeniería, y cada salto obliga a transferir contexto. De ahí salen reuniones, tickets, PRDs, anotaciones en Figma y aclaraciones. No creo que todo eso sea inútil. Pero una parte existe porque intentamos pasar lo que sabe una persona a la cabeza de otra, y eso es lo que convierte a los handoffs en una deuda organizativa.

Cuando una misma persona mantiene el contexto desde el discovery hasta el prototipo, esa deuda se reduce. Se gana velocidad y coherencia, se pierde menos información y la conexión entre problema y solución es más directa. Las iteraciones se aceleran y hay más ownership, porque quien decide cómo se resuelve algo es quien ha entendido por qué había que resolverlo.

Dónde puede fallar

No creo que sea un modelo para todas las empresas ni para todos los equipos. Depende de la base que acabo de describir, del tipo de producto y de la cultura de la empresa. En problemas muy especializados puede ser mejor contar con especialistas profundos en cada disciplina.

Tampoco es fácil encontrar a alguien con fondo real en producto y en diseño, y además con visión de negocio, cultura tecnológica y soltura con la IA. Es un perfil poco frecuente, y existe el riesgo de que, al querer reunirlo todo en una persona, el resultado sea una visión amplia pero superficial de cada cosa.

El riesgo que más me interesa es la pérdida de contraste. Cuando Product Manager y Product Designer son dos personas, una cuestiona a la otra y aparecen preguntas y desacuerdos. Es más fácil que alguien detecte un punto ciego que el otro no veía. Si todo ocurre en una sola cabeza, esa fricción desaparece, y con ella una parte de la forma en que un equipo se corrige. Por eso un Product Maker no debería trabajar aislado.

Cuanta más autonomía, más contraste necesitas

Cuanta más autonomía tiene una persona, menos la contradice nadie por defecto, y por eso necesita disciplina para comprobar desde fuera que no se desvía. No basta con validar una pantalla. Hace falta enseñar pronto el trabajo a usuarios, compañeros de diseño e ingeniería y negocio, y contrastarlo con datos y resultados reales, para que lo que no funciona falle cuanto antes.

También ayuda volver a preguntarse con frecuencia si la solución sigue resolviendo un problema real, qué evidencia hay de que aporta valor, qué se está asumiendo y qué se puede estar pasando por alto. Conviene hacerlo sobre todo cuando uno empieza a encariñarse con lo que ha hecho.

La IA ayuda a cuestionar una decisión, y a veces lo hace bien, pero tiende a acompañar lo que uno ya piensa. Además, un prototipo sale pulido en poco tiempo y es fácil tomar su buen aspecto por evidencia de que funciona. Ninguna de las dos cosas sustituye a un compañero que discrepa, a un usuario que no entiende lo que has hecho o a un dato que no sale como esperabas. Para mí es una de las condiciones para que el modelo funcione.

Más allá del nombre

Product Maker tampoco es la única etiqueta que apunta en esta dirección. En algunas empresas empieza a aparecer Product Builder, que comparte buena parte de la filosofía. Hay mucho ownership, menos handoffs y un uso intensivo de la IA para llevar una idea más lejos antes de necesitar otra especialidad. La diferencia es de alcance. El Product Maker del que hablo está sobre todo entre Product Management y Product Design, mientras que Product Builder suele usarse de forma algo más amplia y, según la empresa, puede incluir implementación o código.

Ninguno de los dos títulos está estandarizado, así que más que la etiqueta me importa el movimiento que hay detrás, y el rol que me explicaron no surge en el vacío.

No sé si Product Maker será un título que veamos con frecuencia dentro de unos años, y creo que importa menos de lo que parece. Lo importante es la idea. Cuando ejecutar cuesta menos, una persona con criterio de producto, criterio de diseño y soltura con la IA puede mantener mucho más contexto y llevar un problema bastante más lejos. Para eso necesita una base sólida alrededor y gente que la contraste. Me parece una evolución muy interesante de cómo construimos producto, y me alegro de que me la explicaran.

---

Las opiniones expresadas son personales y no representan la posición de ninguna organización.