Ser PM no es (¿sólo?) gestionar backlog

¿Te has parado a pensar en cuál es la creencia, el principio o la convicción en la que más has evolucionado como profesional?

Yo es algo que hago de manera concienzuda cada vez que abro una etapa laboral: pienso en cómo era mi forma de trabajar cuando llegué y en qué he aprendido y cambiado (a mejor) cuando me voy. Cada trabajo lo vivo como una historia que quieres contar, de objetivos que tenías, de retos que superaste (? o no) y de aprendizajes que te llevas (de cosas a repetir y de cosas a evitar ?).

Si pienso en qué es lo que más ha cambiado mi visión de qué significa trabajar en un rol de producto, creo que sin duda es mi entendimiento de que el foco principal de un Product Manager no es gestionar el backlog, hacer refinamiento de iniciativas ni planificar los ciclos de desarrollos o liderar las dailies.

Recuerdo bien cuando en Aplazame, al empezar a crecer hasta ser 5 equipos de producto, contratábamos a Product Manager pero los llamábamos ? Product Owners. Incluso me recuerdo hace más de 5/6 años dudando sobre si debía sacarme alguna certificación o contratar un Scrum Master. ¡Sí que ha llovido desde entonces!

? Hoy resumo el foco de un PM en algo sencillo: vender productos que solucionan problemas por los que un número suficiente de clientes está dispuesto a pagar un precio rentable.

Solucionar problemas

Si trabajas en producto, tienes que estar más enamorado de los problemas de los clientes que de las soluciones que busques para ellos.

Enfócate en descubrir qué problema existe ahí fuera que merece la pena resolver, para quién quieres resolverlo, por qué ahora y por qué el mejor para resolverlo eres tú (tu equipo, tu división, tu compañía).

A un número suficiente de clientes

Parte de asegurarte que el problema que has elegido merece ser resuelto es validar que existe un mercado potencial suficientemente grande.

  • ¿Has calculado cuál es el mercado disponible total (TAM – Total Available Market) que existe para ese problema?
  • ¿Y cuál es el mercado al que crees que tú podrías servir (SAM -Serviceable Available Market) teniendo en cuenta barreras de distribución, de precio, culturales, de idioma, etc?
  • ¿Y qué porcentaje del mercado tendrías que conquistar (SOM – Serviceable Obtainable Market) para tener unos números relevantes y sostenibles?

Si encuentras un problema pero es tan nicho o tan pequeño que es irrelevante, no podrás montar un negocio alrededor de él.

Dispuestos a pagar

Espero que algún día dejemos de debatir sobre lo de empresas sales-led o product-led¿Cómo puede ser una empresa no sales-led? Salvo que tu objetivo no sea generar negocio, no te queda otra que estar hablando de ventas.

Un recordatorio: no todos los problemas merecen ser solucionados si quieres hacer negocio con ellos.

  • Tus potenciales clientes deben ser conscientes de que tienen ese problema.
  • El problema debe ser grande o lo suficientemente recurrente como para que crean que les merece la pena invertir en un producto que les ayuda a solucionarlo.
  • Deben tener presupuesto y estar dispuestos a invertirlo en solucionar ese problema.

Cada 2 jueves con el café?. Descubre, cuestiona y nútrete de experiencias de Producto contadas #desdelbarro

Un precio que para ti sea rentable

Ser capaz de encontrar, junto con los equipos de ventas, de operaciones y de finanzas, el esquema de precios que te hace competitivo a la vez que te salen buenos Unit Economics.

No es sólo que el número de clientes sea lo suficientemente grande, que estén dispuestos a pagar por el problema y que estén dispuestos a pagarte a ti…. es también que lo que te paguen te permita desarrollar un negocio que sea escalable y rentable.

? Si como PM tienes que estar enfocado en todo esto ¿cómo de importante es para ti la gestión del backlog y cuánto foco tienes que poner en el delivery? Nuestro trabajo va más del “do the right thing” que del “do the things right”.

Es fácil como PM caer en la urgencia de lo más inmediato y enfocarte en cosas muy tácticas: escribir una bet, refinar una iniciativa, redactar una épica, convocar una reunión de refinamiento o ponerte a hacer algo de QA o reporte de bugs. Todas esas tareas son necesarias, pero no te necesitan a ti como PM con todo tu foco.

Algunos mantras que me repito día tras día para re-enfocarme en lo que de verdad puede mover la aguja.

1 Pasa más tiempo “fuera del equipo” que dentro.

En tu día a día, deberías estar interactuando más con clientes, prospects, ventas o CX que con los Product Designers, los Engineering Managers o los Product Engineers. Ahí es donde vas a aprender qué problemas necesita seguir resolviendo tu producto, cómo compara con competidores y qué es lo que aporta más valor.

2 Tu momento clave con tu equipo es definir qué queréis resolver y cuánto tiempo queréis dedicar a ello.

Con el equipo de diseño y desarrollo, asegúrate de tener dinámicas de trabajo que te permitan hacerles partícipes del problema que decidáis atacar en cada momento, que entiendan por qué lo vais a atacar ahora, para quién lo vais a resolver, qué impacto consideras que puede tener en el negocio y qué métricas clave os ayudará a mejorar.

Una vez que prioricéis juntos el problema y los porqués, deja que ellos se encarguen de la solución. ¡Ojo! Que esto no significa que como PM te despegues de la solución. Parte de tu trabajo es vigilar que la solución que el equipo proponga resuelve el problema y lo haga de forma global y escalable… pero no aportas nada metiéndote hasta el detalle más fino en la ejecución.

3 No hagas babysitting ni project management

Es una obviedad, pero trabajas con gente lista y muy capaz. Decidid qué vais a priorizar, por qué y cuánto tiempo queréis dedicar a resolverlo.

Con eso, la definición del scope, el delivery y el QA es de ellos. Los EMs y los Product Engineers deben empujar por sacar cosas a producción; no necesitan que estés preguntando cómo van continuamente.

4 Una funcionalidad no se termina cuando sale a producción.

He escuchado a Simón Muñoz repetir mucho su “entregar no es suficiente” y no puedo estar más de acuerdo. Una funcionalidad que se lanza pero no se vende o no se usa no será nunca un éxito. No tendrá impacto. No moverá la aguja.

Mientras el equipo trabaja en el desarrollo, enfócate en preparar que sucedan varias cosas

  • Estrategia de release. ¿La vas a activar para todos los clientes a la vez? ¿Vas a hacer un soft release para validar bajo una feature flag primero y la abrirás a todos después? ¿Es una funcionalidad que activarás sólo a clientes con un plan de precios concreto? ¿Tienes que dejar fuera a clientes con planes de precios legacy?
  • Estrategia de Go-To-market. ¿Cómo se va a anunciar esa funcionalidad a clientes y prospects? Habla con el equipo de product marketing y de demand generation para ver cómo vais a posicionar ese nuevo producto y funcionalidad y convénceles de si tiene que formar parte del GTM de las próximas semanas o el próximo trimestre.
  • Product Enablement. ¿Cómo te vas a asegurar de que toda la compañía conozca esta nueva funcionalidad? ¿Requiere de materiales de venta? ¿Tienes que añadir un nuevo artículo al Help Center? ¿Requiere de una sesión de training para el equipo de Customer Success? ¿Tienes que formar a los Account Managers para que puedan guiar a los clientes?
  • Feature discoverability. ¿Cómo vas a guiar a tus clientes para que descubran esa funcionalidad dentro del producto? A veces una newsletter o un webinar no son suficientes. ¿Qué puedes hacer para ayudarles a auto-descubrir esa funcionalidad? ¿para impulsar que comiencen a usarla? Si implica algún set-up ¿cómo les convences de invertir ese tiempo en configuración y aprendizaje a cambio del valor que les vas a entregar?
  • Product Usage. ¿Cómo vas a medir el uso de la funcionalidad? ¿Cuál va a ser la regla que defina tu métrica de uso? ¿Necesitas medir sólo la activación de la funcionalidad o también la retención? ¿Es una funcionalidad que esperas que utilicen todos tus usuarios o quizás necesitas hacer análisis por cohortes si sólo esperas que la usen unos pocos?
  • Pricing. Recuerda: estás solucionando problemas para hacer dinero con ello. Cada funcionalidad que lances es una oportunidad de ampliar el valor que capturas por el valor que entregas. ¿Vas a utilizar ese lanzamiento para hacer upselling a tus clientes de un plan business a uno entreprise? ¿Quizás la vas a usar para subir el precio de todos los planes? Planifícalo.

5 Mide el éxito (o el fracaso) y se crítico

Pregúntate qué métricas de negocio quieres impactar y mide el éxito que has tenido.

  • ¿Cuánto nuevo MRR (Monthly Recurring Revenue – una métrica que mide el total de ingresos recurrentes que logras en un mes) o ARR (Annual Recurring Revenue – lo mismo que el MRR * 12 meses) has cerrado gracias a esa funcionalidad?
  • ¿Te ha ayudado a incrementar tu Win Rate sobre el número de propuestas enviadas? Tu Win Rate es una métrica que te ayuda a saber cuántas oportunidades ganas o cuántas ventas cierras en relación con el total de oportunidades que luchas o de propuestas de contrato que envías.
  • ¿Te ha servido para reducir las closed lost opportunities y ser más fuerte frente a tus competidores? Si una funcionalidad te bloquea oportunidades de ventas, la estarás identificando como un motivo de closed lost (una oportunidad de ventas perdida).
  • ¿Has lanzado algo cuyo impacto ha estado en la reducción de bugs, incidencias o número de llamadas a tu call center?

A pesar de repetirme todos estos mantras, hay una regla de oro que utilizo para saber si tengo el foco en lo que debería. Al arrancar el lunes, hago una lista de los objetivos que tengo y, sobre todo, las cosas que me preocupan esa semana.

Si las cosas que te preocupan apuntan a algunas de todas estas cosas que hemos hablado, estás en el buen camino. Si las tareas que te estás planificando tienen que ver con hablar, escuchar, pensar y analizar, la cosa pinta bien. Si al contrario estás planificando cosas que tienen que ver más con hacer seguimiento, algo parece estar fallando.

Los pre-mortems: cuando pensar como un gafe te ayuda a mitigar riesgos

Estaba hoy leyendo este artículo en el que hablan de cuándo y cómo hacer pre-mortems con equipos de producto. Y, aunque creo que un buen pre-mortem puede hacerse de una forma bastante menos compleja de la que la autora sugiere, comparto su definición del pre-mortem como una herramienta del equipo para intentar anticiparse al error y mitigar riesgos.

Many engineering teams run post-mortems when there is a failure or error. The team needs to come together to discuss what went wrong and how to prevent it from happening again (not to assign blame or point fingers).

But what if we could anticipate and prevent these failures before they happen? Enter the pre-mortem. Pre-mortems are a powerful tool to increase the probability of a successful product launch and avoid difficult-to-recover failures. 

Yue Zhao

A los pre-mortems a mi me gusta llamarlos hacer un gafe time. Es un nombre más divertido para el equipo y creo que se explica muy bien qué es lo que persigue una dinámica de este tipo:

  1. Anticiparte a analizar qué podría ir mal.
  2. Montar un plan para intentar prevenir que ese escenario suceda.

Un “gafe time” no es más que sentarte con el equipo a analizar con cierta profundidad todas las razones por las que el lanzamiento de una nueva funcionalidad, un nuevo producto, un refactor… podría ir mal.

Te pones en ese escenario en el que las cosas fallan y te pones a pensar en cómo las solucionarías de la manera más rápida y eficaz posible. Con eso, montas un plan que incluyes en la propia iniciativa.

Estamos más acostumbrados a los post-mortem que a los pre-mortem. Y eso no mola.

Las compañías en las que he trabajado siempre estaban bastante acostumbradas a hacer post-mortems, un análisis en el que cuando algo falla y siempre después de haberlo solucionado, intentas aprender de qué ha ido mal y reflexionas sobre cómo podrías evitar que vuelva a suceder una próxima vez.

Sin embargo, considero en demasiadas ocasiones evitamos hacer ese ejercicio de reflexión previo a un lanzamiento porque pecamos de optimistas o quizás sencillamente porque tenemos demasiado interiorizada esa cultura de “no blame”, de evitar la parálisis por análisis o de que está bien “aprender equivocándote”.

Y sí, lo comparto. Tenemos que poder equivocarnos en el trabajo y en la vida y saber que está bien. Pero si parte del trabajo de los perfiles de producto es mitigar riesgos y anticiparse a lo que puede ir mal ¿por qué no usar más los pre-mortems para ello?

¿Cuándo hacer pre-mortem?

Obviamente no te paras a hacer un pre-mortem con cada iniciativa que intentas mover. A mi hay algunos casos concretos en los que creo que aportan especial valor:

  1. Iniciativas que toquen piezas core del producto y que, de salir mal, puedan tener un alto impacto en operaciones (centenares de llamadas de clientes cabreados), churn de clientes y pérdida de ingresos.
  2. Iniciativas donde, que algo salga mal, sabes que significará tener muchos hotfixes y P0. Aquí entran las típicas iniciativas que suponen refactor de código importante, migración de servicios críticos, etc.
  3. Iniciativas que implican que varios equipos trabajen de forma coordinada. Si te esfuerzas en todo lo que puede ir mal, caerás en la cuenta de lo importante que es que todos los equipos estén bien sincronizados y pondrás mucho foco en hacer que suceda.
  4. Iniciativas con alta incertidumbre y donde hay ciertas dudas (del equipo o de stakeholders) de que se vaya a trabajar en lo correcto.

¿Cómo hacer pre-mortems?

No pretendo dar con una fórmula mágica. Siempre digo que soy poco de frameworks y mucho de entender cómo lo hacen otros pero crearte tu propia versión según el estado de tu empresa, la madurez de tu equipo o la fase en la que esté tu producto.

Pero por si te sirve, esta es la template que suelo utilizar yo.

Y tú ¿haces pre-mortems? ¿Cómo? ¡Cuéntame que seguro aprendo algo!