Sus primeros 30/60/90 días como nuevo diseñador de producto

Día 4. Su PM le envía un archivo de Figma por DM con "¿puedes pulir esto para el viernes?" Lo pule. Se siente bien: lanzó algo en el día cuatro, el PM le da las gracias en el standup, el EM hace un emoji de pulgar arriba. Bienvenido a bordo.

También acaba de perder la única ventana que tenía para cuestionar el problema subyacente. Cuando lleva tres meses, ha pulido dieciséis specs, no puede nombrar a un solo cliente con el que haya hablado y su manager le pregunta qué ha lanzado que sea realmente suyo. La respuesta honesta es: nada. Ha sido un operador de Figma con título de Senior.

Esta es la trayectoria predeterminada. El patrón del PM-como-lanzador-de-specs es la gravedad de la organización, y no se escapa de ella por accidente. Se escapa entrando con un plan de 90 días, ejecutándolo deliberadamente y teniendo un pequeño logro temprano que le compra la credibilidad para seguir diciendo que no.

Por qué los primeros 90 días no son negociables

No existe un período neutro en una empresa B2B SaaS. Las reorganizaciones ocurren. Los resets de OKR llegan en la semana 8. El ciclo de evaluación de desempeño referencia lo que hizo en su primer trimestre. Los diseñadores que se promueven en el segundo año son los que reservaron tiempo de descubrimiento antes de que la cola de Jira los encerrara.

Me incorporé una vez a una empresa de Serie C donde el diseñador de producto anterior duró nueve meses y se fue "quemado". Leí su historial de Figma. Lanzó 47 specs. Hizo cero llamadas con clientes. No contribuyó nada al design system. Cuando la organización se reorganizó en el mes siete, el liderazgo no podía articular qué era lo suyo, así que lo reasignaron a un producto en declive. Ese es el coste de saltarse los primeros 30 días.

El patrón que se describe a continuación es lo que ejecutaría desde el primer día de un nuevo puesto. Es opinionado. Ajuste los números, no la estructura.

Días 1-30: Escuchar y mapear

El único objetivo del mes uno es entender el sistema antes de cambiarlo. Se sentirá tentado a lanzar en la semana 2. No lo haga. El lanzamiento ocurre en el mes dos, y será mejor si pasó el mes uno haciendo cuatro cosas específicas.

Haga 10 llamadas con clientes

No "entrevistas con usuarios". Llamadas. Siga al CS en tres llamadas con clientes en vivo. Siéntese en dos demos de ventas. Lea 50 tickets de soporte y llame a cinco de ellos. Únase a una conversación de renovación si su empresa se lo permite. Total: 10 conversaciones con clientes de pago, registradas con citas.

No está ejecutando un proceso de descubrimiento aquí. Está calibrando. Quiere escuchar el lenguaje que usan los clientes, las soluciones alternativas que han construido, las pantallas que maldicen, las funcionalidades que creen que existen pero no existen. Para la llamada 10, debería poder terminar la frase de un cliente sobre su producto.

Un script práctico para las llamadas que usted inicia:

Hola [nombre], acabo de incorporarme como diseñador de producto trabajando en [área]. Estoy pasando mi primer mes hablando con 10 clientes para entender cómo usan realmente el producto. Esta no es una sesión de feedback y no lanzaremos nada de esta llamada. Me encantaría tener 30 minutos para verle hacer [tarea] y hacer algunas preguntas. ¿Le viene bien el martes o el jueves?

Este script hace tres cosas: es honesto sobre su rol, elimina la ansiedad de "¿me van a hacer un pitch?" y pide comportamiento (verle hacer X), no opiniones.

Audite las tres pantallas con más tráfico

Consulte los análisis del producto. Elija las tres pantallas con más usuarios activos semanales. Para cada una, documente: el trabajo que el usuario está intentando hacer, el flujo actual, los puntos de fricción y los datos a nivel de pantalla (clics de rabia, abandono, tiempo en pantalla).

No proponga rediseños todavía. Ni siquiera esbozar. La auditoría es un documento de referencia que usará en los meses dos y tres cuando alguien pregunte "¿deberíamos rediseñar el dashboard?" Ya tendrá la respuesta.

Aprenda el design system de principio a fin

Cada token. Cada componente. Cada excepción documentada. Si su DS tiene 80 componentes, necesita conocer los 80 para la semana tres. Es un trabajo poco glamuroso. Hágalo de todas formas.

Por qué: la forma más rápida de perder la confianza de ingeniería es diseñar algo que "parece ligeramente desajustado" porque usó una sombra personalizada cuando había un token para eso. La forma más rápida de ganar confianza es lanzar un archivo de Figma donde la nota de revisión de ingeniería diga "sin cambios, todos componentes del DS". Eso ocurre una vez, y habrá acumulado un crédito que gastará en el mes tres.

Siéntese con ingeniería y producto

Dos sprints completos con ingeniería. Eso significa standups, planificación, retro y al menos una revisión de PR donde alguien le muestre el código base. Objetivo: entender qué es caro de cambiar y qué es barato.

Dos ciclos de planificación y refinamiento con el PM. Objetivo: entender cómo se hace realmente el roadmap, de dónde viene la presión (ventas, liderazgo, un cliente específico) y qué batallas ya están perdidas.

Para finales de la semana cuatro, debería poder dibujar el grafo de toma de decisiones de la organización en una pizarra. Quién decide realmente qué se lanza. Casi nunca es quien pensaría según el organigrama.

El plan semana a semana del mes uno

Ese último entregable es el puente hacia el mes dos.

Días 31-60: Lanzar pequeño, ganar confianza

El mes dos es donde los nuevos diseñadores de producto pierden el rumbo. La tentación es tomar el resumen de una página de la semana cuatro y presentar una visión de rediseño de seis meses. No lo haga. Presente una pequeña apuesta. Ejecute un sprint de descubrimiento. Contribuya un patrón al DS. Tres cosas, todas pequeñas, todas lanzadas.

Ejecute un sprint de descubrimiento en un problema acotado

No el epic del roadmap. Algo adyacente: un sprint de 2 semanas en un problema que ha sido ignorado porque es "demasiado pequeño para priorizar" pero que notó en las llamadas con clientes. El criterio para el problema: tiene al menos tres citas de clientes sobre él, y la solución probablemente cuesta menos de dos semanas de ingeniería.

Ejemplos que funcionan:

• La página de configuración donde 4 de sus 10 clientes dijeron que no podían encontrar el botón de exportación
• El estado vacío de una funcionalidad que solo tiene un 12% de activación
• El breakpoint móvil de un flujo que convierte al 40% en escritorio pero al 8% en móvil

El resultado de su sprint de descubrimiento es un resumen de una página: problema, evidencia, dirección propuesta, métrica de éxito, estimación del coste de ingeniería. Muéstreselo a su PM y EM. Pida dos semanas de ingeniería.

Cuando el PM diga "pero el roadmap..." (y lo dirá), use el script:

Lo entiendo, el epic del roadmap es la prioridad. No estoy pidiendo intercambiarlo. Estoy pidiendo dos semanas de ingeniería en esta corrección acotada que tiene [X citas de clientes] detrás, moverá [métrica] un [Y%] estimado y me da algo a lo que señalar en mi informe de 90 días. Si lo lanzamos y no mueve la aguja, redirigiré el 100% al roadmap para el Q3.

Esto funciona porque es pequeño, con tiempo limitado, respaldado por evidencia y le da al PM una salida. La mayoría de los PMs dirán que sí. Los que dicen que no le están diciendo algo útil sobre si este equipo le va a dejar hacer diseño.

Lance una pequeña apuesta de extremo a extremo

Su sprint de descubrimiento produjo un resumen de una página. Ahora lánzelo. De extremo a extremo significa: escribió el spec (con el PM, no por él), lo diseñó en componentes del DS, lo lanzó a través de la revisión de código, definió la métrica de éxito antes del lanzamiento y la está rastreando.

Elija algo donde el antes/después sea medible en 30 días. Una corrección de patrón. Una simplificación de flujo. Un rediseño de pantalla única. El criterio no es "transformador". El criterio es "lanzado, medido y puede contar la historia."

Un ejemplo real de una diseñadora a la que mentoricé: lanzó un rediseño del estado vacío de una función de automatización de flujos de trabajo. Antes: el 12% de los nuevos usuarios construyó su primer flujo de trabajo en la semana uno. Después: el 31%. El rediseño fue de cuatro pantallas. Dos semanas de ingeniería. Usó ese único gráfico en cada conversación durante el año siguiente.

Contribuya un patrón reutilizable al DS

Su design system tiene vacíos. Los detectó en la auditoría del mes uno. Elija uno, preferiblemente uno que surgió mientras diseñaba la pequeña apuesta, para que sea estructural en lugar de especulativo.

El flujo de contribución:

1. Abra una propuesta en el repositorio del design system de su equipo (o archivo de Figma). Documente el vacío, tres lugares donde se usaría y un patrón borrador.
2. Consiga la revisión del responsable del DS antes de ninguna implicación de ingeniería. Su trabajo es decir no al 80% de las propuestas. El suyo es hacer que sea fácil para ellos decir sí mostrando que el vacío es real.
3. Consiga una revisión de ingeniería de la viabilidad técnica. El patrón necesita ser económico de implementar y mantener.
4. Lánzelo como parte de su pequeña apuesta, o como seguimiento independiente.

Un patrón en el mes dos. No un rediseño del DS. Un patrón. Los diseñadores que intentan "arreglar el design system" en su primer trimestre son cortésmente acompañados fuera de la conversación del DS, de forma permanente.

Lista de verificación del mes dos

• Un resumen de una página del sprint de descubrimiento, compartido con el PM y el EM
• Una pequeña apuesta lanzada, con métrica de éxito definida y en seguimiento
• Una propuesta de patrón del DS, revisada y fusionada
• El PM y el EM tienen cosas positivas que decir sobre trabajar con usted de forma espontánea

Ese último punto es cualitativo pero importa. En un 1:1, pregúntele a su manager: "¿cuál es la percepción del equipo hasta ahora?" Si la respuesta es "eres fácil con quien trabajar y lanzas", va por buen camino. Si la respuesta es "eres callado" o "te opones mucho", corrija el rumbo en el mes tres.

Días 61-90: Ser dueño de un espacio de problema

El mes tres es donde deja de ser el nuevo diseñador y se convierte en un diseñador que es dueño de algo. Tres entregables.

Elija una métrica de producto que influenciará

Tasa de activación. Tiempo hasta el primer valor. Adopción de funcionalidades en una superficie específica. Retención de un segmento específico. Elíjala con su PM. Esto no es negociable, porque si el PM no está de acuerdo en que la métrica es la suya para influenciar, estará trabajando en un objetivo paralelo del que nadie se preocupará en el momento de la evaluación de desempeño.

Los criterios para la métrica:

• Se mueve en un horizonte de 4-12 semanas (no 2 días, no 12 meses)
• Su trabajo de diseño puede plausiblemente moverla un 5% o más
• El PM y el EM dirán "sí, esa es una métrica real para nuestro equipo" sin titubear
• Se corresponde con un resultado del cliente, no con un número de vanidad

Presente un informe de 90 días

Una presentación breve. Cinco diapositivas. No una lista de archivos de Figma.

1. Qué aprendí. Los 3 principales insights de las 10 llamadas con clientes. Una frase cada uno.
2. Qué lancé. La pequeña apuesta, con la métrica antes/después. El patrón del DS, con dónde se usa.
3. En qué estoy apostando. El espacio de problema que está reclamando para el H2.
4. La métrica. La única métrica de producto, con la línea base actual y el objetivo a 90 días.
5. Qué necesito. Capacidad de ingeniería, tiempo de investigación, decisiones que necesita del liderazgo.

Preséntelo a su manager, su PM y su skip-level. 25 minutos. El objetivo no es el aplauso. El objetivo es que tres meses después, cuando alguien pregunte "¿qué hace [su nombre]?", tres personas distintas den la misma respuesta.

Proponga su plan de diseño para el H2

Un resumen de una página. Dos o tres áreas de problema en las que trabajará en los próximos seis meses. Para cada área: hipótesis, métrica de éxito, el trabajo de descubrimiento que necesitará hacer, la estimación del coste de ingeniería.

Este es el documento que protege su tiempo. Cuando el PM intente ponerle un ticket de "pulir este spec" en el mes cinco, señale el plan del H2 y pregunte "¿está esto en el plan?" Si no lo está, la conversación se convierte en una decisión real de priorización en lugar de un sí predeterminado.

Errores comunes y cómo evitarlos

Estas son las cuatro formas en que un plan de 90 días fracasa. He visto ocurrir todas ellas.

Aceptar el ciclo de "pulir este spec" en la semana 1

El PM le entrega un archivo de Figma en el día cuatro. Lo pule. Ahora usted es la persona de pulido. La solución no es negarse, porque eso arruina la relación. La solución es la redirección suave:

Con gusto le doy una pasada. Antes de tocar los elementos visuales, ¿podemos pasar 15 minutos en el flujo subyacente? Quiero asegurarme de entender el problema para que el pulido realmente ayude. Si el flujo está sólido, lo tendrá de vuelta para finales de semana.

Ocho de cada diez veces, la conversación de 15 minutos revela que el flujo tiene problemas, y termina haciendo trabajo de diseño real. Dos de cada diez, el flujo es genuinamente correcto y lo pule. En cualquier caso, ha establecido que "diseñador de producto = colaborador reflexivo" no "diseñador de producto = acabador de píxeles".

Saltarse las llamadas con clientes porque el PM ya hizo investigación

El PM hizo entrevistas. Quizás las hizo bien. No importa. Su interpretación del dolor del cliente está filtrada por un cerebro de PM. La suya necesita estar filtrada por un cerebro de diseñador. Haga las 10 llamadas de todas formas. El coste es 10 horas durante un mes. El valor es tener su propio modelo del usuario que pueda defender frente al modelo del PM cuando estén en desacuerdo.

Rediseñar el design system antes de ganarse el derecho

Su DS está "desactualizado". Sus tokens son "desordenados". Los componentes son "inconsistentes". Quizás. También: lleva aquí tres semanas. Todos los diseñadores de producto que han durado más que usted lo han intentado. Algunos tuvieron éxito en pequeñas formas. Algunos fueron despedidos.

El derecho a rediseñar el DS se gana, no se otorga. Llega después de haber lanzado 3-5 pequeñas victorias, contribuido 2-3 patrones y de que el responsable del DS confíe en su criterio. Ese es un proceso mínimo de un año. En el mes tres, su trabajo es un patrón, no una presentación de visión.

Presentar el informe de 90 días como una lista de archivos de Figma

"Aquí hay 23 pantallas en las que trabajé." A nadie le importa. Al liderazgo le importa: qué aprendió, cuánto costó, qué retornó, qué va a hacer a continuación. Resultados, no artefactos. Si su informe de 90 días tiene más pantallas que frases, lo está haciendo mal.

Plantillas para copiar

Una lista breve de artefactos que debería tener para el día 90:

• Script de entrevista de 10 llamadas (variante B2B SaaS). Preguntas basadas en comportamiento, no en opinión. "Descríbame la última vez que hizo X" supera a "¿qué le parece la funcionalidad Y?" siempre.
• Plantilla de auditoría de flujo. Una página por pantalla: tarea, flujo actual, puntos de fricción, datos, las 3 principales hipótesis de mejora.
• Resumen de "por qué esto es un sprint de descubrimiento, no un spec de funcionalidad" para su PM. Úselo cuando necesite defender el trabajo exploratorio frente a la presión del roadmap.
• Esquema de la presentación del informe de 90 días. Cinco diapositivas. Resultados, no pantallas.
• Resumen de una página del plan del H2. Dos o tres áreas de problema, hipótesis, métricas.

No necesita que ninguno de estos esté pulido. Necesita que existan y sean localizables en el Notion o Confluence de su equipo.

Medir el éxito en el día 91

Cinco cosas. Si puede marcar las cinco, el próximo trimestre empieza con base sólida.

• 10 llamadas con clientes registradas con citas que puede citar de memoria
• Una apuesta lanzada con una métrica antes/después que el PM reconoce como real
• Un patrón del DS fusionado y usado en algún lugar fuera de su propio trabajo
• El PM y el EM pueden articular su espacio de problema sin que usted esté en la sala
• Tiene una respuesta de una línea para "¿en qué está trabajando?" que no es el nombre de una funcionalidad: es un problema o una métrica

Si puede cumplir esos cinco para el día 90, ya no es un diseñador nuevo. Es un diseñador que es dueño de un espacio de problema, ha lanzado y tiene un plan. Esa es la posición desde la que negocia en el mes cuatro. Esa es la historia que cuenta su manager en su evaluación de desempeño del H2.

El patrón del PM-como-lanzador-de-specs no desaparece. Solo deja de ser la gravedad en la que está atrapado. Optó por salir, tiene evidencia de que puede hacer el trabajo más difícil, y los próximos 90 días son suyos para definir.

Más información

• Descripción del puesto de diseñador de producto
• El descubrimiento como diseñador de producto
• Responsabilidad de extremo a extremo: del problema al lanzamiento al aprendizaje
• Errores comunes del diseñador de producto