Un día en la vida de un gerente de producto (B2B SaaS, edición honesta)

La descripción de puesto decía que usted sería "dueño de la estrategia de producto, impulsaría resultados y se asociaría con ingeniería en un roadmap unificado". Son las 8:47 de un martes y su realidad son tres hilos de Slack apilados uno sobre otro: Ventas quiere saber si puede "simplemente añadir" SSO para un trato que cierra el viernes, un ingeniero senior pregunta si los borrados deben hacerse en cascada o con borrado lógico en el nuevo registro de auditoría, y el CEO ha dejado una nota de voz con una "idea rápida de anoche" sobre el dashboard. Un diseñador también está esperando el texto para un estado vacío. Aún no ha abierto el documento de su roadmap y probablemente no lo hará durante otros noventa minutos.

Esto no es un modo de fallo. Es el rol en esta etapa. Un PM de B2B SaaS en algún punto entre la Serie A y una Serie B tardía no dirige el tipo de organización de producto sobre la que lee en los libros de empresas que están cinco rondas por delante. Usted hace trabajo de PM, algo de trabajo de PMM, algo de desviación de reuniones de soporte, y una buena cantidad de "dueño de aquello que nadie más es dueño". Si lleva seis meses en el puesto y siente que va atrasado en su "trabajo de verdad" cada día, el problema no es usted. La forma del trabajo es la forma.

Lo que hace esta guía: recorrer un martes real en una empresa de 5M a 100M de ARR, nombrar los patrones, y darle una estructura semanal defendible por encima del caos.

Por qué su día se ve así

La matemática de la plantilla es implacable. En la Serie A a menudo es el único PM para 8 a 15 ingenieros repartidos en dos squads, además de un equipo de GTM de 4 personas que todos quieren aportar al roadmap. Para la Serie B quizás tenga un segundo PM, pero la superficie se ha triplicado. Ahora también es dueño de las herramientas internas, de un flujo de autoservicio, y de lo que el fundador haya lanzado antes de que usted entrara y que nadie ha tocado en un año.

Aún no tiene un Product Marketing Manager, así que el texto de los lanzamientos aterriza sobre usted. No tiene una persona de Product Ops, así que el marco de priorización, la plantilla de notas de versión y el consejo de clientes viven todos en su Notion. El equipo de CS escala todo lo que no puede responder en dos respuestas, que es mucho. El CEO lo usa como caja de resonancia porque es la única persona del edificio con suficiente contexto entre producto, cliente e ingeniería para dar una respuesta útil en menos de cinco minutos.

Medio PM, medio PMM, medio desviador de reuniones suma más del 100% a propósito. Esa es la matemática. La habilidad no es encajarlo en 40 horas; es decidir qué recibe su atención real y qué recibe un pase "lo bastante bueno".

8:00am: revisión de llamadas con clientes (20 minutos, innegociable)

Antes del standup, antes de Slack, abre Gong o Chorus y elige una llamada de ayer. Normalmente una llamada de discovery o la salida de un cliente que abandonó. Repasa las partes donde el cliente habla más de 30 segundos seguidos. Ahí está la señal real. El resumen del representante de Ventas es casi siempre o demasiado generoso ("¡les encantó la demo!") o filtrado a través de la objeción que más preocupa al representante ese trimestre.

He visto a un PM darse cuenta de que lo que Ventas describió como "quieren mejores reportes" era en realidad el prospecto diciendo "no puedo mostrarle a mi CFO por qué compraríamos esto en lugar de quedarnos con la hoja de cálculo". Problema distinto. Funcionalidad distinta. La funcionalidad se habría lanzado mal.

Registra el insight en Productboard o Aha, normalmente como una nota de una línea etiquetada a la iniciativa correcta, con la marca de tiempo de la llamada enlazada. Veinte minutos, cada día laborable, sin excepciones. Este es el hábito de mayor palanca del rol y es lo primero que se abandona cuando la semana se vuelve ruidosa. No lo abandone.

Media mañana: async con ingeniería sobre preguntas de especificación

El standup es a las 10. Pasa veinte minutos después de él respondiendo comentarios en Linear o Jira. La mitad son limpios: "sí, trata ese caso como un no-op". La otra mitad es el impuesto de la ambigüedad de las especificaciones: preguntas que parecen aclaraciones pero que en realidad son cambios de alcance disfrazados de aclaración.

Una real de la semana pasada: "Solo para aclarar, cuando se elimina a un usuario de un workspace, ¿también revocamos sus tokens de API?". Eso no es una aclaración. La especificación no lo cubría porque nadie lo pensó. La respuesta "sí, revócalos" son doce horas de trabajo, una revisión de seguridad, y una nota de comunicación de cara al cliente. La respuesta "no, déjalos" son tres líneas de código y un futuro ticket de soporte. Cualquiera de las dos es defendible. Ninguna es lo que decía la especificación.

El trabajo del PM aquí es reconocer que la pregunta es una bifurcación en el camino, no un letrero, y o decidir rápido o escalar a una llamada de decisión de 15 minutos con el ingeniero líder y la persona de seguridad. Lo que mata a los equipos es que el PM diga "sí, haz lo que sea más fácil" porque va atrasado en Slack, y luego se entere dos sprints después de que el camino "más fácil" creó una brecha de cumplimiento.

Las respuestas en Loom son una buena herramienta aquí. Un Loom de 90 segundos que responda "esto es lo que pienso, este es el trade-off, contradíceme si me equivoco" le consigue una respuesta más rica que escribirlo, y el ingeniero puede volver a verlo.

Mediodía: una llamada de discovery que no es votación de funcionalidades

Bloquea de 12:00 a 12:45 para una llamada con un cliente o prospecto. No una llamada liderada por Ventas donde usted es el cerrador; una conversación de discovery de verdad. Documento de Notion abierto, dos preguntas preescritas, y la disposición a seguir el hilo.

La mayoría de las llamadas de discovery son malas porque son votación de funcionalidades disfrazada. Usted pregunta "¿usaría una integración con Salesforce?" y responden "sí, claro", porque decir que sí no les cuesta nada y quieren ser serviciales. Eso no son datos. La buena pregunta de discovery está antes de las funcionalidades: "Cuénteme la última vez que intentó hacer X. ¿Qué hizo en realidad? ¿Qué se rompió? ¿Qué hizo en su lugar?". Usted quiere la historia reciente y específica, no la preferencia abstracta.

La trampa es tratar la llamada como una sesión de feedback. No lo es. Es una sesión de investigación, y la investigación tiene una pregunta que usted entró tratando de responder. Escriba la pregunta en la parte superior del documento de Notion antes de que empiece la llamada. Después de la llamada, escriba tres cosas: qué escuchó, qué le sorprendió, qué cambia respecto a lo próximo que va a construir. Si nada cambia, la llamada no fue útil, lo cual es útil en sí mismo, porque significa que está en un punto en el que debería validar con prototipos, no con entrevistas.

Para una versión más profunda de esto con un guion, vea Cómo realizar llamadas de discovery que no son votación de funcionalidades.

Tarde: sincronización semanal con las partes interesadas

2:00pm. Líder de Ventas, líder de CS, líder de Marketing, usted, en una sala de 45 minutos. Esta es la reunión donde las solicitudes de "podemos simplemente añadir" se archivan, se priorizan o se descartan. Si no tiene esta reunión un día fijo, la tiene en fragmentos a lo largo de la semana en Slack y pierde tres horas en ella en lugar de cuarenta y cinco minutos.

Muestra el roadmap en Productboard o Aha, no diapositivas. Las diapositivas implican finalidad; el roadmap en vivo implica "este es el estado actual, puede moverse, aquí están los trade-offs". Recorre lo que está en marcha, lo que viene a continuación, y qué elementos se movieron esta semana y por qué. Luego toma de tres a cinco solicitudes nuevas, hace la pregunta que las decide ("¿cuántos clientes y qué peso de ARR hay detrás de esto?"), y o se compromete a evaluar, rechaza con un motivo, o aparca.

Decir que no sin ser el PM del no consiste sobre todo en darle al no una forma clara. "No vamos a hacer esto en el Q3 porque nos comprometimos con la velocidad de onboarding y esto lo retrasaría tres semanas; revisémoslo en la planificación del próximo trimestre" es un no que su líder de Ventas puede vender internamente. "No podemos hacer eso ahora mismo" es un no que vuelve mañana como un mensaje directo de Slack.

El encuadre al que sigo volviendo: cada sí también es un no a otra cosa. Haga visible esa otra cosa. Muestre el intercambio. Los intercambios son la conversación.

Fin del día: depuración del backlog

4:30pm. Cuarenta y cinco minutos en Linear o Jira cerrando tickets obsoletos, sacando candidatos para el próximo sprint, y revisando el lanzamiento de ayer en Amplitude o Mixpanel. Figma abierto en la siguiente pestaña para comentarios de diseño sobre lo que entra en el sprint posterior a este.

La higiene del backlog es poco glamorosa y es la diferencia entre un equipo de ingeniería que confía en su priorización y uno que no. Si un ticket lleva seis semanas abierto sin movimiento, ciérrelo con un comentario que explique por qué. Los tickets obsoletos en un backlog son ruido que ahoga la señal de lo que de verdad viene a continuación. Los ingenieros dejan de leer el backlog cuando el backlog deja de ser fiable, y una vez que eso pasa vuelve a dirigirlo todo a través de Slack.

La revisión en Amplitude es corta: ¿la funcionalidad que lanzó la semana pasada movió la métrica que dijo que movería? Si sí, escriba una nota de una línea en el ticket de lanzamiento y siga. Si no, pregunte por qué antes de lanzar lo siguiente encima. La mayoría de los PMs lanzan lo siguiente sin revisar lo anterior, que es como surgen las fábricas de funcionalidades.

Las dos trampas

La fábrica de funcionalidades. La velocidad es alta. El equipo está lanzando. Los standups se sienten productivos. Pero cuando revisa las métricas de resultado (activación, retención, expansión, las que el roadmap prometió mover) están planas o tendiendo en la dirección equivocada, y nadie del equipo ha tenido una hora tranquila para pensar por qué en tres meses. La prueba del olfato: si le preguntara a su ingeniero senior "¿qué problema estamos resolviendo este sprint y cómo sabremos que lo resolvimos?", ¿tendría una respuesta limpia? Si la respuesta es "estamos lanzando la especificación", está en una fábrica de funcionalidades.

La solución no es ir más despacio. La solución es poner las métricas de resultado junto a cada iniciativa del roadmap y negarse a empezar la siguiente hasta haber revisado si la anterior funcionó. Diez minutos de "¿movió el número?" antes de cada arranque. Barato de hacer. Casi nadie lo hace. Vea Cómo escapar de la fábrica de funcionalidades para la versión más larga.

Ventas secuestra el roadmap. Cada trato se convierte en un compromiso personalizado. El producto se fragmenta porque el cliente A obtuvo un flujo de trabajo que el cliente B no tiene, y ahora está lanzando lógica condicional en ocho lugares distintos. Seis meses después tiene una deuda técnica que no puede saldar porque cada parte de ella tiene un nombre de cliente adjunto.

La señal temprana: si sus últimos tres cambios de roadmap vinieron cada uno de un solo trato, lo están secuestrando. La solución es una regla clara que toda la empresa conoce. La mía es "consideraremos un compromiso personalizado solo si el trato supera 5 veces el ACP actual y la misma solicitud ha venido de tres clientes distintos". Ajuste los números a su etapa. Lo importante es tener una regla, por escrito, que Ventas pueda citarle a un prospecto sin escalárselo a usted. Vea Cómo decir no a Ventas sin convertirse en el PM del no.

El stack que tocará cada día

No necesita todas las herramientas. Sí necesita una en cada categoría, y necesita que los datos fluyan entre ellas.

Para la comparación más larga y qué elegir en cada etapa, vea Herramientas y stack tecnológico del gerente de producto.

Una forma semanal defendible

No puede controlar cada notificación de Slack. Puede decidir qué bloques defiende y cuáles deja que el caos se coma.

Aquí hay una forma semanal que sobrevive al contacto con la realidad en la mayoría de las empresas de B2B SaaS:

Protegido significa que va en el calendario antes que cualquier otra cosa y lo defiende como una reunión con un cliente. El bloque de tiempo para pensar es el que más PMs se saltan, y también es el que decide si opera un trimestre por delante o siempre una semana por detrás. Dos horas, sin Slack, una pregunta en la que pensar, un documento que escribir al final. Protéjalo.

Comprimido significa que lo acepta pero lo acepta rápido. Las reuniones de estado pasan a async. Las solicitudes de "¿tienes un segundo?" reciben un "mándame un Loom o un documento y te respondo antes del final del día". Lo importante no es ser inaccesible; es hacer que el costo de involucrarlo a usted en algo sea el mismo que el de involucrar a cualquier otra persona.

Cierre

El trabajo tiene esta forma porque la empresa tiene esta forma. Un PM en una empresa de 12 personas con cuatro clientes tiene un día distinto al de un PM en una empresa de 200 personas con cuatrocientos clientes, y pretender lo contrario es como acaba intentando copiar un proceso de una presentación que no aplica a su etapa.

Lo que sobrevive a través de las etapas: proteja el ritual de las llamadas con clientes, nombre el impuesto de la ambigüedad de las especificaciones cuando lo vea, realice llamadas de discovery con una pregunta y no con una lista de funcionalidades, muestre su roadmap como un trade-off en vivo y no como una diapositiva, y revise si lo anterior funcionó antes de lanzar lo siguiente.

Una frase para pegar en su revisión del calendario mañana por la mañana: qué recibió atención real esta semana, qué recibió un pase "lo bastante bueno", y ¿es eso lo que elegiría si empezara la semana de nuevo?

Si la respuesta es no dos semanas seguidas, la forma necesita cambiar.

Más información

• Plantilla de descripción de puesto para gerente de producto
• PM frente a Product Marketing Manager: dónde está realmente la línea
• Cómo realizar llamadas de discovery que no son votación de funcionalidades
• Cómo decir no a Ventas sin convertirse en el PM del no
• Cómo escapar de la fábrica de funcionalidades