Los Product Managers NO escriben historias de usuario
Descubra más de Estrategia de Producto
Los Product Managers NO escriben historias de usuario
El foco del Product Manager está en la visión y la estrategia. El equipo se encarga de la ejecución. Así lo hacen en Facebook, y así lo debería hacer cualquier verdadera empresa de producto.
Esta semana hemos tenido una de esas raras ocasiones donde poder echar un vistazo a como trabaja un equipo de producto en Facebook. Todo vino a raíz de este tweet de Ben Erez, dónde comentaba como en un año trabajando allí no había escrito una sola historia de usuario. Su responsabilidad queda en la parte estratégica y de visión, el qué hacer, mientras es su equipo de ingeniería el que se ocupa de los detalles de ejecución, el cómo hacerlo.
Si habéis seguido los artículos de esta lista de correo, veréis que estoy muy alineado con el planteamiento de Ben. Hace unas semanas, en el post titulado “Un proceso de desarrollo de producto”, describía el proceso que mi equipo sigue en Voicemod. La responsabilidad del Product Manager quedaba en el espacio del problema, mientras que el equipo gestionaba el dominio de la solución, y por lo tanto, también la se responsabiliza de la ejecución.
Así pues, mi respuesta ante la pregunta de si los Product Managers deben escribir historias de usuario, sería un claro no. Esto no es más que un detalle de ejecución y organización interna del equipo. El equipo debe decidir como organizarse para cumplir los objetivos y al PM le debería dar igual cómo lo hacen.
Ahora, está muy bien ver cómo trabaja Facebook y ver qué opino yo, pero no tiene por qué coincidir con nuestra realidad. Veamos a continuación algunas situaciones comunes que he observado a lo largo de mi carrera y cómo podríamos tratar de solucionarlos.
En mi empresa el Product Manager escribe las historias de usuario
He pasado por empresas así. Creo que gran parte del problema es que, en países con poca cultura de producto, el término Product Manager se confunde o entremezcla con el de Product Owner.
El Product Owner es un rol dentro de Scrum cuya responsabilidad principal es optimizar la entrega. Es una figura que mira hacia adentro del equipo, en contraposición al de Product Manager que mira hacia fuera, a los problemas y oportunidades que pueden tener un impacto futuro en el negocio.
Siendo el de Product Owner un rol centrado en la ejecución, en mi opinión este debería quedar dentro de la responsabilidad del equipo. Puede haber un Product Owner dedicado, o puede no haberlo y ser el Engineering Manager quién se responsabiliza de que los objetivos se cumplan. El equipo es autónomo para decidir si necesita esa figura o no.
Tiendo a pensar que cuando una empresa contrata a un Product Manager para crear historias de usuario y gestionar la ejecución está confundiendo términos. En realidad quieren fichar a un Product Owner pero, quizás por desconocimiento o por simple moda, terminan abriendo posiciones de Product Managers.
Una buena heurística para saber si estás ejerciendo de uno o de otro es saber dónde estás enfocando tu día a día. Un Product Manager debería pasar un 70% de su tiempo buscando oportunidades y problemas a resolver. Un Product Owner, por su parte, no necesita mirar hacia fuera porque ya hay alguien, posiblemente ejerciendo la verdadera función de Product Manager, decidiendo qué se va a resolver a continuación.
Ahora bien, ¿qué podemos hacer si nos encontramos en esta situación?
En primer lugar, deberías entender quién está ejerciendo la función de Product Manager. Toda empresa tiene Product Managers aunque no los llame así. En empresas pequeñas el primer Product Manager suele ser el CEO. Cuando ya hay cierta estructura, son aquellas personas que están en contacto con los clientes y definen el roadmap del producto. Fíjate en quién está haciendo esa labor y entiende cómo puedes llegar a colocarte en esa posición.
Una buena forma de hacerlo es mirar más hacia afuera y empezar a plantear iniciativas que puedan tener impacto real en el negocio. El problema es que para hacerlo, necesitas delegar las tareas de gestión de ejecución en el equipo. Cuanto más sénior y más mentalidad de producto tenga tu equipo, más fácil será hacerlo. Los mejores ingenieros entienden que su impacto se mide por hacer las cosas correctas y no simplemente por ser eficientes moviendo historias de usuario entre columnas.
Por contraposición, cuanto más junior sea, más difícil será delegar la ejecución. Y ojo, porque ser junior o sénior es una actitud y no depende del número de años que lleves programando. Un ingeniero con 10 años de experiencia que no mueve un dedo si no hay una historia de usuario perfectamente definida a todos los efectos es un junior.
Si el Product Manager no escribe las historias de usuario, ¿cómo sabe el equipo qué hay que construir?
Esta es otra duda que podríamos tener. La respuesta es sencilla, el equipo sabe lo que hay que construir porque es el equipo quién plantea la solución al problema.
Recordemos que la principal responsabilidad del Product Manager es encontrar problemas y oportunidades que valgan la pena resolver. Nuestro trabajo consiste en trasladar adecuadamente estos al equipo, definir claramente los criterios que debe cumplir la solución, y facilitar que sea el mismo equipo quien proporcione las soluciones a los mismos.
Cuando es el propio equipo quién plantea la solución, las historias de usuario pierden importancia. El equipo sabe lo que hay que hacer porque es el equipo quién ha decidido qué y cómo hacerlo. Cuando un equipo llega a este grado de madurez, es posible que ni siquiera las necesite para organizarse.
Lo he probado todo y mi empresa no está preparada
En algún otro artículo pasado escribí que un Product Manager debía de hacer todo lo posible para que su producto saliera adelante. Si eso incluye escribir historias de usuario, tendrás que hacerlo.
Ahora bien, va a ser muy difícil que consigas hacer las dos cosas bien a la vez. O pones tu foco a los problemas y oportunidades o lo pones a la ejecución. Si de verdad aspiras a trabajar como Product Manager y no has conseguido hueco en tu empresa, no te limites y comienza a buscar oportunidades en verdaderas empresas de producto.
Conclusión
A modo de resumen, existe un mundo ideal ahí fuera donde:
Los Product Managers no escriben historias de usuario
Dedican su tiempo a detectar oportunidades y problemas que vale la pena resolver
Es el equipo quién asume la responsabilidad de gestionar la ejecución
Es el mundo de las verdaderas empresas de producto.
Si te ha gustado el post, lee la continuación: Product Ownership es un rol. Product Management es el trabajo.
📝 Referencias
Hilo de David Stanete, CTO de Voltz, en la misma línea desde su posición de líderazgo técnico y a partir del cual llegué al tweet de Erez.
Ben Erez también lanzó la misma discusión en LinkedIn. Las respuestas son bastante interesantes.
Un argumento más a favor de que las historias de usuario son un artefacto del equipo de ingeniería es el hecho de que fueron inventadas por ingenieros. Fuente Wikipedia.
Why we Need to Rethink Product Management in an Agile Practice.
What’s the difference between a Product Manager and a Product Owner.
📖 Contenidos recomendados
Algunos enlaces y podcast que me han resultado interesantes esta semana:
A Product Leader on How to Build Out a SaaS Platform: Interview with David Grabner
Mark in the Metaverse (Zuckerberg positioning FB as a Metaverse company)
Escalando unicornios con Tomás Pueyo [Podcast 🔊]
Outcomes Over Outputs – Josh Seiden on The Product Experience [Podcast 🔊]
🙌 ¡Comparte!
Cómo siempre, muchas gracias por estar ahí. Si te ha gustado el post y crees que le podría interesar a alguien de tu entorno sé libre de reenviarle este correo. También puedes utilizar estos enlaces para compartirlo directamente en Twitter o LinkedIn y así me ayudarás a que esta lista de correo llegue a más gente. Muchísimas gracias de antemano, Simón.
Los Product Managers NO escriben historias de usuario
Hola Simón, el artículo es muy interesante y toca un tema importante, pero no estoy de acuerdo con el planteo.
Coincido con Alex: escribir historias de usuario no es "redactar tickets" ni "gestionar proyecto" o "administrar tareas". Es parte de la definición del producto y, como tal, es una de las tareas principales del product manager. Entre otras cosas, porque es responsabilidad del PM priorizar el desarrollo del producto, y esto se hace fundamentalmente controlando el orden de las historias el la pila de producto.
El tuit que citas, de hecho, no dice que Ben Erez no escriba historias de usuario: dice que no escribe tareas ("tasks"), un concepto que en el vocabulario scrum es distinto de "user stories". Es verdad que dice que no está involucrado en los sprints, y se entiende por qué él está contento: la dinámica agile es muy exigente. Pero me parece una evidencia circunstancial, y no creo que algo esté necesariamente bien porque lo haga Facebook.
Como dice Álex, Marty Cagan, que es probablemente el mayor experto en product management, es bastante terminante en cuanto a que ser PO es una de las responsabilidades del PM. Además de tratar el tema en sus dos libros, también escribió un par de artículos en su blog, con muy buenos argumentos basados en la observación del mercado que trabaja:
https://svpg.com/product-manager-vs-product-owner/
https://svpg.com/product-manager-vs-product-owner-revisited/
Cito de este último artículo: "(...) more than a few companies were using the relatively new role of the product owner as an excuse to once again separate “the business person” from the “the person that talks with the developers. This causes serious problems (...) and I absolutely still believe it’s critical to be a single person rather than two".
Dicho esto, te felicito por el trabajo de divulgación que haces en tus artículos, ya que estos temas son cruciales para el desarrollo del product management en nuestro mercado.
Saludos,
Germán
Hola Simón,
quería felicitarte por el artículo, bien escrito y mejor documentado. He hecho me he suscrito a tu lista.
Hay varios puntos de éste con el que no coincido, principalmente por mi punto de partida, como trainer de Scrum.org y el enfoque "Professional Scrum" que defendemos.
En primer lugar, el foco del PO no es únicamente interno (delivery) sino que debería ser también la visión, estrategia y discovery (cuando le dejan). Coincidimos en que el PO es un rol y el PM un trabajo, pero desde Scrum.org defendemos que el PM adquiera el rol de PO. Así lo expliqué en este artículo, y allí apuntaba a otro de Ken Schwaber de hace 10 años donde insistía en el propósito original del rol de PO era que lo ejercieran los PM.
https://www.linkedin.com/posts/alexballarin_marty-cagan-released-the-article-the-cspo-activity-6809182749677649920-pwwK
En nuestra (Scrum.org) opinión y experiencia, un PM puede ejercer el rol de PO si delega al equipo la mayoría o todos los detalles de la solución. Pero si está cerca del equipo en el proceso de Discovery, junto con el diseñador y el tech lead, se trabaja mejor tanto en el espacio del problema como de la solución. Esto lo explicamos en el curso Professional Scrum with UX. En cualquier caso, pensamos que el Product Owner NO se limita únicamente al delivery.
Finalmente, las historias de usuario pueden entenderse como tácticas (como USER quiero una FEATURE) pero también como estratégicas (como USER tengo un problema o Job To Be Done). El origen de las historias de usuario son problemas o necesidades que el usuario explicaba directamente al ingeniero, y evitar que alguien (p.e. un analista) "traduzca" una necesidad a una especificació de solución.
De hecho, una historia puede comenzar como la descripción de una necesidad y evolucionar hacia la solución mediante el Discovery. Entedidas así, un PM sí podría/debería escribir historias (pero no su detalle).
No me alargo más, espero que el comentario sea útil.
Alex Ballarin / ITNOVE.com