¿Debemos priorizar soluciones, problemas u objetivos?
Reflexiono sobre las distintas maneras de priorizar el roadmap de producto, porqué trabajar sobre objetivos requiere más experiencia, y comparto el estilo de liderazgo que recomiendo.
Te animo a echar un vistazo a los cursos que acabo de abrir para Mayo:
Fundamentals of Software Engineering si quieres tener una base técnica para trabajar mejor con ingeniería; puedes hacerlo a tu propio ritmo. Puedes hacerlo a tu ritmo desde ya (self-paced), o a partir del 30 de abril en un grupo con sesiones en vivo (cohort-based).
Fundamentals of Product Analytics si quieres empezar a ser analítico, empezando a analizar datos y definir KPIs y funnels. Puedes hacerlo a tu ritmo desde ya (self-paced), o a partir del 30 de abril en un grupo con sesiones en vivo (cohort-based).
Advanced Course in Product Analytics si quieres aprender a hacer análisis avanzados y conectar métricas de negocio con producto. La octava edición comienza el 30 de abril.
Advanced Course in Product Engineering si desde ingeniería o datos quieres acercarte a negocio y producto. La cuarta edición comienza el 30 de abril.
Debemos tener claro que no hay una respuesta correcta. La mejor opción depende del estado de la empresa, del tema que estés tratando y de la experiencia del equipo.
Vamos a ver un ejemplo de cada una de los tres opciones:
Un objetivo podría ser reducir el porcentaje de incidencias por horarios no realistas de un 23% a un 10%.
Un problema podría ser que los clientes introducen horarios de recogida y entrega no realistas
Una solución podría ser añadir unas reglas en el formulario de pedidos para impedir horarios no realistas.
Si estamos haciendo un roadmap o una planificación trimestral, ¿qué debemos priorizar?
Priorizando Soluciones
La mayoría de equipos de producto priorizan soluciones en sus roadmaps o planificaciones trimestrales. Una de las principales razones es que el liderazgo de la empresa y gente de negocio quiere saber exactamente qué se va a hacer para aprobar o no ese roadmap. Por tanto, la solución da la aparente tranquilidad de que eso se va a lanzar.
Si ya hemos hecho un trabajo previo de entender bien el problema y tenemos claro que impacta en el negocio y en los usuarios, es totalmente válido priorizar soluciones si ya hemos pensado que son las mejores para solucionar ese problema.
El reto normalmente viene cuando dedicamos muy poco tiempo a pensar cuál es la mejor solución, sino que priorizamos la solución que nos viene dada por alguien o la solución obvia que se nos acaba de ocurrir.
Cuando priorizamos una solución, ya estamos comprometidos con ella. Por lo que, a pesar de los problemas que nos encontremos por el camino, tenemos que tirar hacia adelante. Nos hemos comprometido con esa solución. La tenemos que hacer aunque tardemos más de lo previsto o nos demos cuenta que de que puede que no resuelva el problema. Si no la hacemos, es un fracaso en el roadmap.
En el ejemplo inicial que he compartido, la solución propuesta es añadir unas reglas en el formulario de pedidos para impedir horarios no realistas. Si fuéramos a desarrollarla, rápidamente nos daríamos cuenta que la lógica de esas reglas no es tan sencilla. En el caso de Ontruck nos pasaba que:
La velocidad media de una furgoneta y de un camión es distinta.
Los camiones por encima de cierto peso tienen que parar cada ciertas horas.
La distancia lineal es una aproximación decente en Madrid, pero no funciona en Barcelona por su terreno más montañoso.
La hora influye mucho en el tráfico que haya.
Lo correcto sería empezar por una regla simple que nos aporte el 60-80% del valor esperado. Sin embargo, como ya hemos priorizado esta solución de las reglas en el formulario, éste es nuestro universo. No pensamos en otras soluciones.
Si diéramos un paso atrás, nos plantearíamos otras soluciones:
Podemos empezar por revisar internamente aquellos pedidos que parece que tienen horarios no realistas; y cambiarlos manualmente para evitar incidencias.
En vez de impedir horarios, cuando salte la regla podemos mostrar un mensaje al cliente de que compruebe que son horarios realistas; y que los revisaremos.
O quizás nos diéramos cuenta que un porcentaje de esos casos sí son realistas si se asigna un vehículo dedicado a ese pedido y por tanto el cliente tiene que pagar por esa dedicación completa. Es por tanto, un problema de precio.
Si éstas u otras posibles soluciones las hemos evaluado antes de priorizar la solución actual, hemos hecho nuestro trabajo correctamente. Hemos apostado por una solución que esperamos que nos dé resultado. La mala práctica viene cuando priorizamos una solución sin invertir el tiempo necesario en considerar cuál es la más simple, que impacte en nuestros objetivos, y esté alineada con la visión.
Priorizando Problemas
Priorizar problemas nos ayuda a alinearnos con los usuarios cuyos problemas vamos a resolver. Al discutir qué problemas abordar, nos garantizamos que nuestras acciones son las más adecuadas y relevantes para el momento actual.
Esta forma de priorizar me ha servido para debatir con stakeholders cuáles son los problemas más relevantes que tienen, contrastarlos con datos y tener una conversación mucho más rica en vez de poner el foco en las soluciones.
Cuando priorizamos un problema, puede suceder dos cosas: 1) Tenemos que entenderlo desde cero y posteriormente pensar soluciones, o 2) Lo tenemos ya parcialmente entendido e incluso podemos tener alguna idea de cómo solucionarlo.
Un problema que todavía no entendemos
Desde mi perspectiva, esto ocurre generalmente por una de tres razones: debido a la urgencia de un asunto imprevisto, por una decisión repentina del equipo directivo, o porque el Product Manager no lo anticipó al estar demasiado enfocado en las tareas del equipo.
El gran reto en este caso es que el equipo invierta demasiado tiempo en entender el problema y se quede sin tiempo para validar e implementar soluciones. Esto es más probable que suceda en equipos donde todavía no tienen el contexto del negocio o del producto. Seguramente les falte esa intuición necesaria para decidir, o esa experiencia en esa área del producto, o quizás no tengan todavía confianza en sí mismos.
Mi recomendación es que trabajéis en dos vías. Por un lado, entended mejor el problema. Y por el otro, según tengáis algunas ideas claras, empezad a ejecutar. Debemos evitar trabajar en modo waterfall. Por ejemplo, si al cabo de dos semanas ya tenemos unas ideas que pueden impactar rápido, ejecutémoslas. Mientras, sigamos terminando de entender el problema en profundidad para poder plantear una solución global.
Una buena recomendación para evitar esa parálisis por análisis es ponerse deadlines de decisión. El día 15 del primer mes revisamos lo que sabemos, y decidimos lo primero a validar y ejecutar. Al final del primer mes, volvemos a hacer lo mismo. De esta manera, nos forzamos a tomar decisiones y evitamos hacer investigaciones demasiado largas, que posiblemente sean las correctas en la teoría y quedan muy bien sobre el papel, pero luego acaben diciendo el 80% de lo que ya sabíamos en las primeras dos semanas.
Hay que ser consciente que este modo de trabajar es más estresante y es más retador. Debemos evaluar constantemente qué información tenemos y tomar decisiones rápidas.
Ya entendemos parcialmente el problema
Lo ideal es que estemos priorizando un problema que ya hemos invertido tiempo en entenderlo durante el periodo anterior. Ya tenemos algunas soluciones planteadas, aunque quizás necesitemos profundizar aún más sobre el problema.
Para llegar a esta situación, los Product Managers – acompañados de Engineering Managers y Product Designers según sea necesario – deberían invertir la segunda parte del trimestre en entender los problemas a resolver en el siguiente periodo. Mi recomendación para los Product Managers es:
Durante la primera parte del trimestre deben estar enfocados en que las soluciones que vamos a implementar estén bien dirigidas.
Deben invertir la segunda parte del trimestre en entender y alinear con negocio los problemas que queremos resolver el siguiente periodo.
En esta situación, podemos empezar el trimestre validando y ejecutando las soluciones por las que inicialmente apostamos, a la vez que profundizamos en entender lo que todavía no sabemos y descubrimos lo no sabemos que no sabemos. Según vamos teniendo más claridad, vamos ejecutando las nuevas soluciones que planteemos.
Priorizando Objetivos
Este es el nivel más alto de abstracción y el que más nos alinea con las métricas generas del negocio y con el equipo directivo de la empresa. Es también una manera de alinearnos con los objetivos que tienen nuestros compañeros de ventas, marketing, atención al cliente, operaciones, etc. Al fijar objetivos de métricas, veremos claramente si las soluciones que implementamos tienen el impacto esperado.
En el ejemplo inicial, el objetivo era reducir el porcentaje de incidencias por horarios no realistas de un 23% a un 10%. En este caso, nosotros tendríamos que haber hecho previamente el análisis de porqué sucede este tipo de incidencia, fijar la visión y plantear diversas soluciones. Al implementar cada una, veremos claramente si hemos conseguimos reducir la métrica.
El primer gran reto cuando priorizamos un objetivo es que lo sepamos conectar con las acciones que podamos tomar en los productos. Por ejemplo, si queremos incrementar el MRR, ¿sabemos cómo podemos impactar desde el producto en ello? Si no tenemos claridad en cómo podemos impactar en ese objetivo, muy posiblemente sea contraproducente priorizar ese objetivo porque todavía no hemos hecho ese trabajo. Quizás sea más adecuado priorizar un problema o una solución que queremos validar.
El anterior reto suele suceder cuando nos fijamos objetivos de muy alto nivel. Por ello, a veces es más útil elegir objetivos intermedios que consideremos buenos proxies para incrementar las ventas, aumentar la retención, o reducir el churn. No siempre es fácil conectar todas las métricas. Por ejemplo, podríamos trabajar en objetivos de activación del producto o de aumento de frecuencia de uso.
Priorizar objetivos también requiere que el equipo tenga experiencia en la empresa y sector, y tenga buen conocimiento de los objetivos de este área y de los problemas que suceden. También es muy necesario que sea un equipo analítico que pueda profundizar en descubrir los problemas que merecen ser solucionados antes y las soluciones que van a causar más impacto.
Cuando estamos trabajando de este modo, es imprescindible evitar la parálisis por análisis. Vuelvo a recomendar la doble vía que comentaba anteriormente.
Trabajar en modo problema u objetivo es mucho más complicado
Podemos decir, por tanto, que cuando estamos priorizando un objetivo, estamos dejando varias puertas abiertas y tenemos que tomar decisiones rápidas para ver qué problema resolvemos y qué solución implementamos. Cuando priorizamos una solución, están todas las cartas echadas y confiamos en que esa solución funcione. Tenemos menos flexibilidad.
Si tenemos 100% claro que debemos construir una cierta solución y que aportará valor, adelante. Sin embargo, si no tenemos claro qué solución o problema tiene más impacto, dejar al equipo que explore ese universo de opciones puede hacer que acaben impactando más porque acaban entendiendo mejor los problemas y encontrando las soluciones que realmente mueven la aguja.
Trabajar en modo solución es mucho más fácil, es realmente una gestión del proyecto. Terminas de definir los requisitos, haces el diseño de la solución, te aseguras que todo funcione y despliegas a producción. Si tiene impacto esa solución o no, no es tu problema. Posiblemente, ya tienes la siguiente solución a desarrollar sobre la mesa, así que ni tienes tiempo para pensar. Desgraciadamente, todos sabemos que esta forma de trabajar acaba en funcionalidades que no aportan el valor que esperábamos.
Trabajar en modo problema o en modo objetivo es mucho más complicado. Requiere que rápidamente seas capaz de entender qué está pasando, que te alinees con stakeholders, que hables con usuarios, que analices datos, y que tomes decisiones en múltiples aspectos a la vez. Sin duda alguna, es mucho más retador. Si conseguís impactar es una sensación fantástica, porque toda la empresa os va a aplaudir. Sin embargo, si no hay impactáis, el peso recae sobre el equipo.
¿Eres Senior si solo trabajas sobre soluciones?
La cultura de producto por la que yo apuesto es por profesionales y equipos que prioricen problemas y objetivos, que tengan ese acccountability, que se obsesionen por entender bien los problemas y por diseñar la mejor solución con un buen retorno y que sepan dar en el clavo en aportar el máximo valor al usuario, al negocio y a la empresa.
El seniority de un profesional está muy relacionado con este aspecto. Alguien que está comenzando su carrera o que no tiene mucha experiencia va a trabajar principalmente sobre soluciones. Un profesional que ya tiene cierta experiencia va a trabajar sobre problemas. Y solo aquellas personas que son más estratégicas y pueden aportar más a nivel global de la empresa van a trabajar más sobre objetivos.
Por tanto, si no trabajas sobre objetivos ni sobre problemas, sino que principalmente haces soluciones, posiblemente no deberías ponerte la etiqueta de "Senior". Mi consejo es que te empieces a mover hacia los problemas y objetivos para adquirir esa accountability e impactar en el negocio de forma clara.
Un mensaje para fundadores y directivos
Si eres el CPO o CTO y vuestro equipo trabaja sobre lo que decidís en el equipo de liderazgo, estáis creando una alta dependencia en vosotros. La empresa sufrirá según escale. Ya no podréis invertir ese tiempo o empezaréis a perder contexto de lo que realmente sucede porque no llegaréis a ese nivel de detalle o la empresa sufrirá cuando os vayáis o cambiéis de puesto.
Hay fundadores que tienen muy claro lo que quieren y dicen a su equipo las soluciones que tienen que construir. Hay unos cuantos que tienen muy buen conocimiento e intuición y aciertan en lo que hay que hacer. Mientras crezca la startup seguirán con esa cultura. Al final, el objetivo de muchos fundadores es vender la empresa. La transición cuando ellos se van no es su preocupación. Lo que acaba pasando es que la empresa sufre en ese momento. Falta conocimiento y accountability en el equipo y muy probablemente la plataforma está llena de deuda técnica.
Yo soy de la opinión que como fundador y directivo se puede y se debe formar y empoderar el equipo para que sean independientes y tomen muy buenas decisiones, a la vez que estás controlando la ejecución y diciendo claramente cuándo apuestas por una cierta forma de solucionar un problema. Este liderazgo requiere más trabajo inicial porque debes invertir más tiempo en explicar, escuchar y en tomar una decisión en vez de simplemente decir lo que tienen que hacer. Ahora bien, en mi experiencia es una inversión que acaba dando mejores resultados.
¿Cuál es tu experiencia priorizando soluciones, problemas u objetivos? ¿Qué te resulta fácil y qué te resulta más complicado?