El descubrimiento como diseñador de producto (no solo ejecutar specs del PM)

Pasó tres días trabajando en un flujo. Abrió Figma a las 9 del lunes y no salió a respirar hasta el miércoles por la tarde. Le entrega al PM un solo archivo. Lo ojea, dice "se ve bien, lánzalo" y sigue adelante. Nada en su spec cambió. Nada en el roadmap se movió. Se siente útil pero invisible. Y seis meses después, su evaluación de desempeño dice "ejecuta bien" en lugar de "moldea el roadmap".

He visto a diseñadores culpar al PM de esto. El PM está ocupado. El PM no entiende el diseño. El PM tiene favoritismos. Ninguno de esos es el problema real. El problema real es el artefacto que entregó. Un solo diseño significa una sola decisión: lanzar o no lanzar. Los PMs no rechazan opciones únicas. Las aprueban sin pensar. A esto lo llamo la trampa de la opción única, y casi todo diseñador "solo de ejecución" está atrapado en ella sin darse cuenta.

La solución no es trabajar más. Es cambiar lo que aterriza en su escritorio.

Por qué esto importa más que hace dos años

Dos tendencias colisionaron en los últimos 18 meses. Primero, los diseñadores de descubrimiento (los que moldean qué se construye, no solo cómo se ve) ganan significativamente más que los diseñadores de ejecución en el mismo nivel. Según los últimos estudios públicos de salarios (el Informe de Salarios de Diseño de Producto 2025 de Pencil & Paper, la Base de Datos de Salarios de Dribbble y el hilo de salarios de diseño de Read the Docs), la brecha ronda el 18-30% en nivel medio y se amplía más allá del nivel senior. Un diseñador de producto senior en una empresa de Serie B que moldea el spec se acerca a los $190K de compensación total. El mismo título, la misma empresa, el mismo nivel, solo ejecutando: cerca de $150K. Esa no es una diferencia pequeña. Es un coche.

Segundo, los PMs están lanzando cada vez más sin diseñadores. Cursor, Linear, Lovable, v0 y la ola de herramientas de diseño con IA significa que un PM con buen criterio puede lanzar un flujo competente por su cuenta. Los diseñadores que sobreviven ese cambio son los que contribuyen en la parte superior, en la capa de definición del problema, no en la capa de pulido. Si su único valor añadido es "hacer que el archivo de Figma quede bonito", está compitiendo con la IA hacia abajo.

Esto no es catastrofismo. Es una aclaración. El trabajo se está desplazando hacia el descubrimiento, y los diseñadores que ya operan de esa manera se están distanciando más. La mecánica de cómo lo hacen se puede aprender. Eso es lo que cubre el resto de este playbook.

Descubrimiento frente a ejecución: la verdadera división de mentalidad

El modo de ejecución responde una pregunta: "¿Cómo debería verse y comportarse esto?" Recibe un problema, un alcance y restricciones. Hace algo. Lo devuelve.

El modo de descubrimiento responde una pregunta distinta: "¿Es este siquiera el problema correcto a resolver?" Recibe un brief y lo cuestiona antes de abrir Figma. Habla con clientes. Esboza alternativas que no coinciden con el spec. Aporta evidencia a la conversación.

Ambos modos importan. El error no es hacer trabajo de ejecución. La ejecución es la mayor parte de la semana de cualquier diseñador, incluso a nivel staff. El error es hacer solo trabajo de ejecución y sorprenderse cuando lo tratan como un servicio de apoyo.

Comportamientos concretos por modo:

Diseñador en modo de ejecución:

• Abre Figma en cuanto recibe un spec
• Pregunta "¿cómo debería quedar el estado vacío?"
• Entrega un solo archivo
• Registra los flujos lanzados en su portfolio
• Informa hacia arriba: "Lancé X, Y, Z este trimestre"

Diseñador en modo de descubrimiento:

• Lee el spec, luego cierra el portátil y sale a caminar
• Pregunta "¿para quién estamos construyendo esto y qué sabemos sobre ellos?"
• Entrega tres opciones con sus compromisos
• Registra los cambios en el spec que su trabajo causó
• Informa hacia arriba: "Cambié cómo abordamos X. Aquí está la evidencia del cliente y el resultado."

Observe los verbos ejecutivos. Los diseñadores de descubrimiento dicen "cambié", "desplacé", "redirigí". Los diseñadores de ejecución dicen "lancé", "completé", "entregué". El primer conjunto suena a ownership. El segundo suena a throughput.

La regla de los 3 caminos

Este es el único cambio mecánico que hace más trabajo. Cada vez que entregue un diseño a un PM, entréguele tres opciones:

1. El camino seguro: el más cercano a lo que el PM especificó. Menor riesgo, menor recompensa. Lo que esperaba.
2. El camino ambicioso: lo que construiría si tuviera dos semanas más y un poco más de alcance. Mismo problema, solución más ambiciosa.
3. El camino inesperado: la opción que resuelve un problema diferente, o resuelve el mismo problema de una manera que nadie ha considerado. Generalmente inspirado por una entrevista con un cliente o un flanco de la competencia.

Cada camino viene con tres etiquetas: coste en tiempo, riesgo y ventaja potencial. Solo eso. Sin un documento de Notion de 10 páginas. Un resumen de una página con tres frames de Figma y una pequeña tabla.

¿Por qué tres? Porque así es como los PMs deciden realmente. Con una opción, el veredicto es binario: lanzar o cancelar. Los PMs casi siempre lanzan, y ese es el ciclo de aprobación automática. Con dos opciones, ha creado un falso binario. El PM elige la más segura y usted ha entrenado al PM a esperar una elección entre seguro y arriesgado cada vez. Con tres opciones, ha creado una conversación real. El PM tiene que articular por qué prefiere una. Y una vez que articula el porqué, usted ha pasado de "ejecutar un spec" a "codescidir una estrategia".

Nunca he tenido un PM que rechace una entrega de 3 caminos. He tenido muchos que eligen el camino seguro. Pero la conversación es distinta. Discutimos los compromisos en lugar de aprobar el pulido.

Una plantilla funcional que uso:

Problema: [una frase: qué estamos tratando de hacer para el usuario]

Camino A, Seguro (1 semana)
  Qué: [lo que el PM esperaba, diseñado de forma limpia]
  Riesgo: bajo
  Ventaja: lanza a tiempo, cumple el OKR

Camino B, Ambicioso (2 semanas)
  Qué: [solución más ambiciosa al mismo problema]
  Riesgo: medio, requiere cambios en el backend
  Ventaja: aborda el problema de segundo orden que afrontaremos en Q3 de todas formas

Camino C, Inesperado (3 semanas)
  Qué: [resuelve un encuadre completamente diferente del problema]
  Riesgo: alto, no está claro si los clientes quieren esto
  Ventaja: 10 veces el impacto si es correcto; aprendizajes de todas formas
  Evidencia del cliente: [mencione una entrevista con un cliente que apuntara aquí]

Eso es una página de resumen. Quince minutos para escribirla una vez que ha hecho el pensamiento de diseño. Adóptela para cada entrega durante un trimestre y observe lo que le ocurre a su evaluación de desempeño.

El árbol de oportunidad-solución, edición para diseñadores

El árbol de oportunidad-solución de Teresa Torres es el framework más limpio que he encontrado para mantenerse en la parte superior de la ejecución. La versión original: resultado en la cima, oportunidades (dolores y deseos del cliente) en el medio, soluciones que se ramifican desde cada oportunidad en la parte inferior.

La adaptación para diseñadores: su trabajo es poblar la capa del medio, no solo la inferior. La mayoría de los diseñadores viven completamente en la capa de soluciones (esbozando, prototipando, puliendo cosas que resuelven oportunidades conocidas). Los PMs viven principalmente en la capa de resultado (OKRs trimestrales, métricas de negocio, narrativas ejecutivas). La capa del medio (los problemas reales del cliente) es el territorio en disputa. Quien la pobla bien, controla el roadmap.

Un ejemplo real. Trabajé en un flujo de checkout para un B2B SaaS que quería aumentar las tasas de activación.

Capa de resultado (territorio del PM): Aumentar la activación a 30 días del 38% al 50%.

Capa de oportunidades (la pelea real):

• Los usuarios abandonan durante la asignación de plazas porque no saben a quién invitar todavía
• Los usuarios se saltan el paso de integraciones porque creen que es opcional
• Los usuarios completan el registro pero nunca regresan porque el producto se siente vacío hasta que invitan a compañeros
• Los usuarios invitan a compañeros pero estos ignoran el correo porque los asuntos son genéricos

Un diseñador junior habría recibido el encargo de "rediseñar la pantalla de asignación de plazas" y la habría dejado bonita. El movimiento de descubrimiento fue mapear las cuatro oportunidades y luego hacer una ronda rápida de entrevistas para averiguar cuál era realmente la restricción determinante. (Era la tercera, la sensación de producto vacío, y era 4 veces mayor que las otras tres combinadas. Nadie había especificado para ello porque nadie había preguntado.)

El artefacto para esto es simple. Abra FigJam. Tres filas: resultado, oportunidades, soluciones. Post-its. La regla es que ninguna solución se adjunta a una oportunidad que no fue validada en al menos una conversación con un cliente. Esa regla sola separa a los diseñadores de descubrimiento de los de ejecución.

Ritmo de entrevistas con clientes: 3 o más por semana es el mínimo

Los diseñadores me dicen que "no tienen acceso a los clientes". Esto casi nunca es verdad. Generalmente es uno de tres problemas reales:

1. Nunca le han pedido al equipo de CSM presentaciones informales (un mensaje de Slack de 5 minutos de distancia)
2. Creen que necesitan permiso del PM para programar una charla (no es así)
3. Les preocupa parecer que le están pisando los talones al PM (también es una idea equivocada, como se aborda más adelante)

Tres conversaciones con clientes a la semana es el mínimo. No el techo. La encuesta de diseñadores 2025 de Pencil & Paper situó la mediana para diseñadores de nivel senior en cinco entrevistas semanales durante el descubrimiento activo. Tres es el mínimo absoluto para llamarse diseñador de descubrimiento.

Cómo llegar ahí de verdad:

• Escriba a los CSMs una sola vez. "Hola, estoy tratando de hablar con 3 clientes a la semana sobre [área de problema]. ¿Puede ir haciendo presentaciones?" Ese único mensaje produce entrevistas para las próximas 6-8 semanas. A los CSMs les encanta porque sus clientes se sienten escuchados.
• Aproveche las llamadas existentes. Si ventas hace llamadas de descubrimiento o CS hace QBRs, pida asistir en silencio a dos por semana. La mitad de una entrevista es mejor que ninguna.
• Escriba a 5 clientes por el mensajero dentro de la app. "Soy diseñador trabajando en X. ¿Tiene 15 minutos esta semana para contarme qué está roto?" La tasa de respuesta ronda el 30-50% si el producto tiene algún tipo de relación con el usuario.
• Lea las encuestas post-cancelación. Cuando hay abandono, el formulario de cancelación es una mina de oro. Léalos todos cada semana. Incorpore los 5 comentarios más articulados a su árbol.

Un banco de preguntas de muestra, el que tengo en una página de Notion y del que extraigo para cada entrevista:

1. Descríbame la última vez que intentó hacer [tarea]. ¿Qué pasó?
2. ¿Dónde se atascó?
3. ¿Qué probó antes de este producto? ¿Por qué no funcionó?
4. Si mañana eliminara esta función, ¿qué haría?
5. ¿Qué tendría que ser verdad para que usara esto todos los días?
6. ¿Quién más de su equipo interactúa con esto? ¿Qué hace de forma diferente?
7. ¿Cuál es la peor parte de su semana relacionada con [área del problema]?
8. Cuénteme una vez en que este producto le sorprendió (para bien o para mal).
9. Si tuviera una varita mágica, ¿qué cambiaría?
10. ¿Hay algo que debería haber preguntado y no pregunté?

Observe lo que falta: preguntas sobre su diseño. No está preguntando "¿le gusta el color de este botón?". Está preguntando sobre su mundo. Las preguntas de diseño llegan después, en la validación del prototipo.

Validación basada en el prototipo: prototipo el martes, insights el jueves

Una vez que tiene las oportunidades mapeadas y algunos bocetos de soluciones, lance un prototipo antes de que el spec esté finalizado. Sigo una cadencia que llamo prototipo el martes, insights el jueves.

Lunes-martes: Construya un prototipo de Figma de los 1-2 caminos más prometedores. No es necesario que sea perfecto en píxeles. Solo funcional para hacer clic. Entre 4 y 8 horas de trabajo, como máximo.

Miércoles: Envíelo a 5 clientes a través de Maze, UserTesting, o simplemente un Loom más un DM de Slack que diga "haga clic en esto durante 5 minutos y dígame qué esperaría que pasara." Cinco usuarios son suficientes para detectar el patrón del 80%; el estudio clásico de Nielsen se mantuvo cuando Maze lo revalidó en 2024.

Jueves: Sintetice. Tres diapositivas: qué funcionó, qué falló, qué nos sorprendió. Comparta en el canal del PM.

Viernes: Actualice el documento de los 3 caminos con los datos del prototipo. Ahora su entrega no es "aquí hay tres opciones". Es "aquí hay tres opciones, y la opción B fue probada con cinco clientes. Tres completaron la tarea, dos se atascaron en el mismo paso. Aquí está la grabación."

Eso cambia la conversación. Los PMs discuten con opiniones. No discuten con cinco grabaciones de clientes atascados. Los datos del prototipo le desplazan de "el diseñador cree" a "los clientes dijeron", y eso es un tipo de autoridad diferente.

Stack de herramientas económico para esto:

• Maze: el mejor para tests cuantitativos no moderados de prototipos. Aprox. $99/mes.
• UserTesting: el mejor para cualitativo moderado. Más caro pero vale la pena para flujos de alto impacto.
• Loom + DM de Slack a 5 clientes: gratis, sorprendentemente efectivo, solo requiere que realmente pulse enviar.

El punto no es la herramienta. El punto es que probó antes de que el spec estuviera cerrado. Eso es descubrimiento. Todo lo que ocurre después de que el spec está bloqueado es pulido de ejecución.

"Pero usted no es el PM": el malentendido que mantiene pequeños a los diseñadores

Cada vez que asesoro a diseñadores sobre esto, alguien plantea el mismo miedo: "¿no pensará mi PM que me estoy extralimitando?"

El trabajo de descubrimiento no le convierte en un PM. Le convierte en un mejor diseñador. La distinción es real y vale la pena mantenerla. Los PMs son dueños de la decisión sobre qué se construye. Los diseñadores son dueños de la aportación que da forma a esa decisión. Traer evidencia de clientes, tres opciones y datos de prototipos no es quitarle el trabajo al PM. Es hacer el suyo de forma competente.

Scripts que funcionan, en mi experiencia:

• Encuadre adversarial que hay que evitar: "No creo que debamos construir lo que especificaste." (Ha convertido esto en usted contra ellos.)

• Encuadre de descubrimiento que aterriza: "Esbocé tres caminos para que podamos elegir juntos. El camino C surgió de una conversación con dos clientes que describieron un problema diferente al del brief. ¿Vale la pena verlo?"

• Adversarial: "El spec está mal."

• Descubrimiento: "Probé el spec con cinco usuarios el martes. Tres se atascaron en el paso dos. Aquí está la grabación. ¿Qué le parece?"

• Adversarial: "Debería estar en las reuniones de roadmap."

• Descubrimiento: "Me encantaría llevar los hallazgos de las entrevistas con clientes a la planificación del roadmap. ¿Quiere que prepare un resumen de 5 minutos para la próxima sesión?"

El patrón: convierta las opiniones en artefactos, convierta la confrontación en invitaciones. Los PMs no quieren realmente pelear con los diseñadores. Quieren tener menos cosas que resolver solos. Preséntese con opciones, evidencia y la postura de "decidamos juntos", y será el colaborador más fácil que tienen. Preséntese con "no estoy de acuerdo", y será el más difícil. Mismo contenido, encuadre diferente, reputación completamente diferente.

Registre sus victorias de descubrimiento, o no existirán

Aquí está la verdad incómoda sobre las evaluaciones de desempeño en la mayoría de las empresas de producto: la influencia que no está documentada no ocurrió. Encontrará diseñadores senior que rediseñaron silenciosamente tres roadmaps en un trimestre y vieron cómo un compañero que lanzó dos proyectos vistosos fue promovido antes que ellos. El compañero contó una historia. El diseñador senior no lo hizo.

Lleve un registro de descubrimientos. Una fila por victoria. Cinco columnas:

Tres columnas son descriptivas. Dos son evidencia. La columna "Reconocimiento del PM" importa: es una captura de pantalla de Slack, un comentario de Loom, una edición en el documento del roadmap. Algo con fecha y rastreable. Cuando llega la evaluación de desempeño, no está suplicando "creo que añadí valor". Está mostrando los recibos.

Este registro lleva 5 minutos por semana en mantenerse. La mayoría de los diseñadores nunca lo empiezan. Los que lo hacen entran a las evaluaciones de desempeño con una conversación diferente a la de sus compañeros.

El cambio mecánico

Esto es lo que quiero que se lleve. El cambio de ejecución a descubrimiento no es un cambio de personalidad. No se trata de ser "más estratégico", sea lo que sea que eso signifique. Es mecánico. Cambia cuatro artefactos:

1. Entregue 3 caminos, no 1 diseño
2. Mantenga un árbol de oportunidad-solución que pobló con entrevistas
3. Haga 3 o más entrevistas con clientes a la semana, cada semana
4. Ejecute un ciclo de prototipo el martes, insights el jueves en cada flujo significativo
5. Lleve un registro de victorias de descubrimiento y llévelo a la evaluación de desempeño

Cinco artefactos. Ninguno requiere un cambio de título, el permiso de un manager o un nuevo trabajo. Puede empezar todos ellos el lunes. La relación con el PM cambia como efecto secundario, no porque haya hablado con el PM sobre ello, sino porque lo que pone en su escritorio cambió.

Ese es todo el juego.

Más información

• JD complementaria: Diseñador de producto
• Un día en la vida de un diseñador de producto
• Sus primeros 30/60/90 días como nuevo diseñador de producto
• Responsabilidad de extremo a extremo: del problema al lanzamiento al aprendizaje
• Crítica de diseño que mejora el trabajo
• De diseñador de producto a diseñador staff