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.

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.

🤯 To worry is to work, Dragan Babic.

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.