Español

Sus primeros 30/60/90 días como nuevo gerente de producto

Recibirá el mensaje en la semana 2. A veces el día 4. Aterriza en Slack de parte de alguien senior, normalmente un líder de ventas o el CEO, y dice algo como: "oye, ¿puedes dimensionar esto para el próximo sprint? Un cliente grande lo está pidiendo."

Decir que sí se siente como el trabajo. Es la trampa.

Los PMs que lanzan en la semana 2 son los PMs que quedan desmontados en el mes 6. No porque lanzaran lo equivocado (aunque normalmente lo hicieron), sino porque gastaron su credibilidad en la primera funcionalidad que alguien pidió, en lugar de comprarla de vuelta a través del discovery. Para cuando descubren el problema real, ya han quemado un sprint y medio de buena voluntad de ingeniería en una funcionalidad que solo el 11% de los clientes llegará a tocar.

Este es el playbook para el otro camino. Es como dirigiría mis primeros 90 días si empezara el lunes.

Por qué 30/60/90 importa más para los PMs que para cualquier otro rol

Un nuevo ingeniero lanza un PR en la semana 1 y el equipo se lo agradece. Un nuevo diseñador sube un archivo de Figma en la semana 2 y el equipo elogia la artesanía. Un nuevo PM lanza una funcionalidad en la semana 2 y el equipo... espera a ver si funciona, y luego baja en silencio su puntuación de confianza cuando no funciona.

Los PMs no tienen autoridad directa. No escribimos el código, no dibujamos las pantallas, y no firmamos los contratos. La única moneda que tenemos es confianza + evidencia. La ventana de 90 días es la ventana en la que su líder de ingeniería, su diseñador, su mánager, y sus 2 principales partes interesadas deciden en silencio si usted es un estratega que da la casualidad de que usa Jira, o un movedor de Jira que da la casualidad de que se llama a sí mismo estratega.

Los primeros 30 días son cuando compra esa credibilidad. Los siguientes 30 son cuando empieza a gastarla con cuidado. Los últimos 30 son cuando empieza a componerla.

Sáltese la fase uno y el resto se derrumba.

Días 1-30: escuche, no lance

El primer mes tiene un solo trabajo: construir una teoría privada del producto, los clientes y el equipo que sea mejor que la de su mánager. No puede hacer eso desde su escritorio.

Reserve 10 entrevistas con clientes en los primeros 21 días

Cinco power users. Tres clientes que abandonaron. Dos prospectos que no compraron. Esa es la mezcla.

Pida a su equipo de CS los power users, los que renuevan sin negociar y responden a Slack en 10 minutos. Pida a quien sea dueño de la retención la lista de abandonos, y luego pida específicamente los que se fueron en los últimos 90 días, no el año pasado. Pida a ventas los prospectos que llegaron a la demo y se quedaron en silencio.

El objetivo de estas llamadas no es validar soluciones. Es encontrar el lenguaje que sus clientes usan cuando nadie escucha. Los power users le contarán los flujos de trabajo que han apañado con cinta adhesiva. Los clientes que abandonaron le contarán qué los rompió finalmente. Los prospectos le contarán qué faltaba en la demo que nadie del equipo del trato notó.

Unas pocas reglas que aprendí por las malas:

  • 30 minutos máximo. No está dirigiendo un proyecto de investigación empresarial. La disciplina de calendario vence a la profundidad en el primer mes.
  • Grabe con consentimiento, transcriba con Otter o Granola. Volver a escuchar a 1,5x es donde aparecen los patrones.
  • Pregunte "¿qué intentó antes de esto?" de cinco maneras distintas. Ahí es donde viven los disparadores de compra y los apaños.
  • No presente nada. Ni siquiera de forma sutil. Su trabajo es escuchar, no probar ideas que aún no tiene.

Para la entrevista 7 empezará a escuchar la misma queja formulada de tres maneras distintas. Eso es señal. Anótelo literalmente. Copie las palabras del cliente, no su traducción de ellas. Los PMs pierden el 60% del significado original en el momento en que parafrasean.

Audite las 3 métricas por las que se mide su producto, y encuentre una en la que no confíe

Cada producto tiene 3 números por los que se le juzga. Activación. Retención. ARR. O alguna variante. Encuéntrelos. Luego vaya a buscar las consultas de SQL, los dashboards, y las personas que son dueñas de ellos.

Está buscando una cosa específica: una métrica que nadie pueda explicar del todo. Quizás es "usuarios activos semanales" pero la definición se actualizó por última vez hace 14 meses y excluye un segmento de clientes que ahora es el 30% de la base. Quizás es una tasa de activación que cuenta cuentas de demo. Quizás nadie puede decirle qué significa "comprometido".

Encuentre esa métrica. No la arregle todavía. Solo anote la pregunta y llévela a su check-in con el mánager del día 30. Cuando entré en mi última empresa, la métrica en la que no podía confiar resultó ser la North Star a la que estaba anclado todo el roadmap. Sacar a la luz esa única pregunta me compró tres meses de credibilidad antes de haber lanzado nada.

Siéntese con ingeniería un sprint, con diseño una crítica, con soporte un día

Invitaciones de calendario, no mensajes directos de Slack. En concreto:

  • Ingeniería: pida asistir a su sprint completo (planificación, daily standups, retro). No hable a menos que se lo pidan. Está aprendiendo la arquitectura, los rencores de la deuda técnica, y qué tickets hacen gruñir al equipo.
  • Diseño: asista a una crítica de diseño, o dos. Está aprendiendo el vocabulario de diseño del equipo, cómo se ve lo bueno, y de qué partes del producto los diseñadores están calladamente avergonzados.
  • Soporte: acompañe a un agente de soporte un día entero, idealmente un miércoles (pico de volumen de tickets en B2B SaaS). Verá los mismos 4 problemas surgir 30 veces. Esos problemas son su roadmap oculto.

Este es el reconocimiento más barato que jamás ejecutará. La mayoría de los PMs se lo saltan porque no genera artefactos. Ese es el punto.

Aprenda el dominio del codebase, no el código

No necesita escribir un PR. Sí necesita poder leer uno sin entrar en pánico.

Consiga acceso al repositorio el día 3. Pida a su líder de ingeniería que le guíe por la arquitectura de alto nivel en 30 minutos. Lea los últimos 10 PR fusionados. Marque el modelo de datos. Conozca los nombres de los tres servicios principales y aproximadamente qué hacen.

El listón es: cuando un ingeniero dice "tendríamos que tocar el servicio de facturación para hacer esto", usted sabe si eso significa un martes o un trimestre.

Una regla dura: no proponga nada en su primer all-hands

No comparta una visión. No presente un roadmap. No suelte una "opinión polémica" en su Slack de presentación. Cada palabra que diga en los primeros 30 días se está calibrando contra cero evidencia, y una vez que pone una postura sobre la mesa pasará los siguientes 60 días defendiéndola en lugar de refinándola.

Preséntese. Diga qué está escuchando. Prometa una opinión para el día 60. Luego vaya a escuchar.

Días 31-60: gánese la señal

Para el día 31 tiene una teoría privada del producto. Los siguientes 30 días tratan de poner a prueba esa teoría sin apostar toda su credibilidad en ella.

Lance una pequeña apuesta que usted no propuso

Este es el truco: herede algo ya dimensionado. Una funcionalidad que su predecesor especificó. Un proyecto de caza de bugs que lleva tiempo en el backlog. Una pequeña migración que el equipo acordó que era necesaria pero de la que nadie es dueño.

Elija algo con una definición de hecho clara, láncelo en tres semanas, y use el proyecto como su jugada de credibilidad rápida. No está apostando su criterio en ello (usted no lo eligió), pero sí está demostrando que puede dirigir un sprint sin dejar caer el testigo. Los líderes de ingeniería notan esto. Lo notan más de lo que notan su trabajo de discovery, porque es tangible.

Si es de nivel senior o staff, el proyecto heredado puede ser una pequeña migración o el retiro de una funcionalidad obsoleta. La forma importa menos que el plazo. Tres semanas. Hecho. Visible.

Ejecute un sprint de discovery sobre un problema que encontró en las entrevistas

Ahora gasta un poco de credibilidad, deliberadamente. Elija la señal más fuerte de sus entrevistas con clientes (la que escuchó de al menos 6 de los 10) y ejecute un sprint de discovery estructurado sobre ella.

Dos semanas. Un PM (usted), un diseñador, un ingeniero una hora al día. Resultados: un planteamiento del problema, tres bocetos de solución, y una decisión sobre si invertir un sprint completo en alguno de ellos.

El objetivo no es lanzar. El objetivo es hacer el discovery legible para su equipo. Nunca le han visto dirigir uno antes. Muéstreles cómo se ve lo bueno. (Tenemos un playbook de sprint de discovery que recorre la estructura si quiere una plantilla.)

Proponga la v1 de su árbol de oportunidades y soluciones, solo a su mánager

Para el día 50 ha escuchado a 10 clientes, auditado 3 métricas, se ha sentado con ingeniería, y ha ejecutado un sprint de discovery. Eso es suficiente material para construir una v1 del árbol de oportunidades y soluciones: el resultado deseado en la cima, las oportunidades (problemas) que ha validado debajo, y unas pocas soluciones candidatas en la base.

Muéstreselo primero a su mánager. No al equipo. No a las partes interesadas. A su mánager, en un 1:1, con la petición explícita: "dime dónde está mal esto antes de que lo socialice."

Dos razones. Una: los árboles construidos en el vacío son torpedeados en público. Dos: su mánager conoce el mapa político que usted no. Le dirá qué oportunidad es propiedad de otro equipo, contra cuál tiene el CEO un rencor personal, y cuál está a punto de ser descartada por una reorganización de la junta.

Refine el árbol, luego planifique un recorrido más amplio para el día 75. (Si quiere el manual estructural, el árbol de oportunidades y soluciones explicado para PMs de B2B lo cubre.)

Empiece a escribir notas de producto semanales: hallazgos de discovery, no actualizaciones de estado

Cada viernes, envíe un documento breve a su mánager y a su líder de ingeniería. No una actualización de estado extraída de Jira. Una nota de discovery. Qué escuchó de los clientes esta semana. Qué métrica investigó. Sobre qué cambió de opinión.

De 300 a 500 palabras. Sin lista de proyectos. Sin burndown del sprint. La nota lo posiciona como alguien con un punto de vista, no como alguien con un backlog.

Este hábito se compone. Para el mes 6, su líder de ingeniería leerá sus notas antes del standup. Para el mes 12, su CEO las reenviará a los candidatos como un artefacto de reclutamiento.

Días 61-90: asuma la propiedad

La propiedad en PM significa tres cosas: una métrica de la que es públicamente responsable, un roadmap con una lista explícita de "noes", y la voluntad de descartar cosas que no se ganan su lugar.

Sea dueño de una métrica públicamente, y elija un input, no un output

Para el día 65, publique en el canal de Slack de su equipo: "Asumo la tasa de activación semanal de los nuevos registros de autoservicio. Objetivo: subirla del 22% al 30% para el final del Q3. Publicaré semanalmente."

Dos notas sobre la elección de la métrica:

  1. Elija un input, no un output. La tasa de activación es un input de la retención. La retención es un output. Los inputs son cosas que puede mover directamente con cambios de producto. Los outputs son cosas por las que le culparán cuando ventas tenga un mal trimestre. Sea dueño del input. (Profundizamos en esto en Métricas de PM: resultado frente a producción.)
  2. Elija algo que no se vaya a mover por una campaña de marketing. Si su métrica puede inflarse con un envío masivo de email, usted no es dueño de ella. Marketing lo es.

Ser dueño de una métrica públicamente es la jugada de mayor palanca de los primeros 90 días. Cambia cómo lo ven el equipo de ingeniería, sus pares, y su mánager. A partir del día 66, usted ya no es "el nuevo PM". Es "el PM que es dueño de la activación".

Presente su roadmap de 6 meses con 3 apuestas y 3 noes explícitos

Día 75-80. Entra a su equipo y presenta el roadmap.

No 12 funcionalidades. Tres apuestas. Cada apuesta ligada a una oportunidad del árbol. Cada apuesta con una hipótesis, un movimiento de métrica objetivo, y un criterio de descarte.

Luego (y esta es la parte que la mayoría de los nuevos PMs se saltan) enumera tres cosas que explícitamente NO va a hacer. No "ya llegaremos a eso más tarde". No "en el backlog". Un "no" real con una razón real. "No vamos a construir reportes avanzados en este semestre. Los datos nos dicen que los power users los quieren pero los power users no abandonan. Nos enfocamos en la activación."

La lista de "noes" es lo que le gana el derecho a decir no la próxima vez que ventas pregunte. Sin ella, cada petición es territorio nuevo y tiene que relitigar la prioridad cada semana.

Realice una ceremonia de descarte para 3 funcionalidades zombi

Una funcionalidad zombi es algo que se lanza, no se usa, y nadie tiene el valor de retirar. Cada producto de B2B SaaS las tiene. El suyo tiene más de las que cree.

Para el día 85, identifique tres. Criterios: menos del 5% de adopción, sin desarrollo activo en los últimos 9 meses, sin ningún cliente enterprise que la tenga en su contrato.

Luego ejecute una retirada. Anúnciela. Envíe un email a los pocos clientes que la usan (habrá menos de los que teme). Documente por qué la descartó en un documento público. Celébrelo en el standup.

La ceremonia de descarte hace tres cosas. Señala que cambiará alcance por enfoque. Libera la carga mental de ingeniería (los zombis cuestan más en mantenimiento de lo que nadie admite). Y sienta el precedente de que nada en el producto es sagrado.

Establezca su registro de decisiones

Para el día 90 tiene un único documento (Notion, Linear, donde sea) que registra cada decisión de producto significativa: la pregunta, las opciones consideradas, la elección, la fecha, la justificación.

El usted del futuro se lo agradecerá al usted del presente. La próxima vez que ventas entre con una petición sorpresa que mapea a algo a lo que dijo que no en el mes 2, tendrá el rastro documental. "Tomamos esta decisión el 14 de mayo. Esto es lo que sabíamos, esto es lo que necesitaríamos aprender para que yo la reconsidere. ¿Qué ha cambiado?"

Las dos trampas que se comerán sus 90 días si las deja

Dos patrones absorberán en silencio el tiempo que necesita para todo lo anterior. Nómbrelos ahora.

Trampa 1: la petición sorpresa de ventas

Llega el Slack. "Oye, estoy en una revisión de trato con 80K USD de ARR en juego. Necesitan [funcionalidad]. ¿Podemos meterla en el próximo sprint?"

No diga que sí. No diga que no. Diga esto:

"Este es exactamente el tipo de petición que quiero manejar de maravilla. Mándame el one-pager del trato y los dos mayores puntos de dolor del prospecto. Tendré una recomendación en 48 horas, no para el próximo sprint, pero una de verdad. Si decimos que sí, quiero asegurarme de que resolvemos para ellos, no solo para este trato. Si decimos que no, quiero que tengas el encuadre correcto para el cliente."

Tres cosas que hace este guion:

  1. Le compra 48 horas, que es la diferencia entre estrategia y estenografía.
  2. Obliga al AE a articular el problema por escrito, lo cual mata el 30% de las peticiones de inmediato (el prospecto en realidad estaba bien).
  3. Lo reposiciona de "el PM que desbloquea tratos" a "el PM que mejora cómo manejamos los tratos".

Necesitará este guion de tres a cinco veces en sus primeros 90 días. Guárdelo en un snippet. (Si quiere la versión más profunda de esta conversación, cómo decir no a ventas sin quemar la relación recorre el playbook completo.)

Trampa 2: el PM como project manager

Sabrá que está pasando cuando su calendario sea 70% standups, retros, planificación de sprint, y "déjame sincronizarme contigo rapidito". Su recuento de tickets de Jira sube. Su recuento de entrevistas con clientes está plano.

Esta es la versión a fuego lento del rol fracasando. Nadie le dijo que se convirtiera en el project manager del equipo. Derivó hacia ahí porque el equipo tenía un vacío y usted lo llenó.

Reinicie antes de que se asiente. Tres movimientos:

  • Rechace dos reuniones recurrentes esta semana. Elija las dos de menor palanca y simplemente diga "no creo que necesite estar en esta". El mundo no se acabará.
  • Entregue la administración del sprint a su líder técnico o scrum master. Si no tiene uno, pida uno. El PM no es el dueño de Jira.
  • Bloquee 2 horas cada mañana para discovery. Llamadas con clientes, transcripciones, trabajo en el árbol de oportunidades. Innegociable. Si no tiene 2 horas de discovery en su día, no tiene un trabajo de PM. Tiene un trabajo de coordinación con un título de PM.

La trampa es cómoda. La coordinación es visible. El discovery es invisible hasta el mes 4, cuando deja de serlo. Elija el trabajo invisible antes de lo que se siente seguro.

Plantillas: el check-in con el mánager del día 30

Cuando entre a su 1:1 del día 30, lleve este one-pager. Ancla la conversación lejos de "cómo te estás adaptando" y hacia si está construyendo la teoría privada correcta.

CHECK-IN DEL DÍA 30 (Su nombre)

LO QUE HE APRENDIDO
- 3 patrones de clientes que escuché repetidamente:
  1. [textual]
  2. [textual]
  3. [textual]
- 1 métrica en la que no confío: [métrica] ([por qué])
- 1 cosa que el equipo está resolviendo y que yo reformularía: [observación]

LO QUE ESTOY PROPONIENDO (NADA TODAVÍA)
- Día 60: v1 del árbol de oportunidades para ti
- Día 75: propuesta de roadmap al equipo
- Día 90: ser dueño de una métrica públicamente

LO QUE NECESITO DE TI
- [petición específica 1: normalmente una presentación a un cliente]
- [petición específica 2: normalmente una advertencia sobre una parte interesada]
- [petición específica 3: normalmente el alcance de la autoridad sobre una decisión]

Envíelo 24 horas antes de la reunión. Su mánager lo leerá dos veces.

Cómo se ve lo bueno en el día 90

Esta es la calibración. Para el final del día 90, tres cosas deberían ser ciertas.

Una: puede nombrar los 3 principales problemas que sus clientes realmente tienen. No los que están en el roadmap. Los reales, en el lenguaje del cliente. Puede clasificarlos por frecuencia y severidad, y puede señalar las entrevistas que validaron cada uno.

Dos: su líder de ingeniería confía en su priorización. Lo sabrá porque dejan de preguntar "¿estás seguro de que estamos trabajando en lo correcto?" y empiezan a preguntar "¿qué sigue después de esto?". Ese cambio lo es todo.

Tres: su mánager no tiene que preguntar en qué está trabajando. Está enviando la nota de discovery del viernes. Es dueño de una métrica pública. Su roadmap tiene una lista de "noes". Su registro de decisiones se actualiza semanalmente. La necesidad de empujarlo desaparece porque el impulso es fiable.

Si las tres son ciertas en el día 90, se ha ganado el derecho a hacer apuestas más grandes en el mes 4. Si ninguna es cierta, no fracasó, pero compró un trabajo de project manager, no un trabajo de PM, y tiene un trimestre más para reiniciar.

La confianza se compone. La producción se degrada. Gaste los primeros 90 días comprando la confianza que le permite hacer el trabajo de verdad durante los siguientes 900.

Más información