Te reto a enviar retroalimentación a tu producto favorito

Reto | Challenge – Solicitar un feature de tu producto favorito, nivel: Product Manager

Intro

Para documentar este reto no profundizaré a detalles sobre ciertos conceptos, en cambio, te dejaré referencias las cuales te podrán servir de consulta.

Una US -User Story-, es la manera en como se organizan y solicitan los requerimientos de nuevas características de un producto o sistema de software a través de utilizar scrum o alguna otra manera ágil de organizar equipos de trabajos**.
** Nota: consultar como funciona scrum

El PM -Product Manager- suele estar a un nivel más estratégico, es el principal responsable de responder por el desempeño y las métricas del producto. También tiene que asegurar que el producto construido esté alineado con la misión, visión & “job to be” done de la compañía.

Irónicamente, las historias de usuario “US” no las redactan los usuarios y es una actividad que cubre el Product Owner o el Product Manager en su defecto.
Idealmente, el PO o PM del producto deberían de conocer muy bien las necesidades y dolores de sus usuarios. Pero nunca está de más echarles una mano…

Uno de los principales propósitos de este reto es justamente esto: violar la narrativa
Proponer nosotros como usuarios de un producto, una US a los PM’s -Product Manager- de una startup que admiremos.
Esto ayudará a fomentar una cultura de retroalimentación, además que si estás buscando una entrada al mundo del producto este reto te ayudará a saber cómo se redacta una US al nivel que un PM experimentado lo haría.

Si aún no estás convencido del todo para hacer este reto:

Piensa, ¿Qué es lo peor que puede pasar? ¿Qué te ignoren?
El “NO” ya lo tienes, con este ejercicio/reto te harás notar. Pondrás sobre la mesa tus habilidades y el profundo conocimiento del producto que has adquirido como usuario.

Piensa, ¿Qué es lo mejor que puede pasar?
Posiblemente, contribuirás genuinamente al mejoramiento del producto. Ese tu producto favorito.
Posiblemente, llames la atención de alguien con poder de decisión en la compañía y quiera conocerte.

Indudablemente: Desarrollarás habilidades que te ayudarán a entender mejor que es esto del “producto” y de como funcionan las “startups”.

¿Listo para el reto? 👀

Como estructurar una user story para tu producto favorito, nivel Product Manager

Estructura de una user story:

  1. User story
    • Title & Description
  2. Acceptance criteria or DoD
    • Gherkin language
  3. Hypothesis
  4. Success criteria
    • Define a SMART product Indicator to perform
  5. Risks & Mitigation plan
    • Identify risks
    • Propose a mitigation plan for each identified risks

Estructurar una User Story, nivel product manager

Title & Description

El título y la descripción deben de estar escrito desde una perspectiva del usuario. El título tiene que ser breve y resuma puntualmente de qué tratará la descripción.

A user story is an informal, general explanation of a software feature written from the perspective of the end user. Its purpose is to articulate how a software feature will provide value to the customer.

MAX REHKOPF – Atlassian

Acá te comparto un enlace donde podrás consultar una documentación detallada de como se redacta una US, en este artículo solo resaltaré los pasos principales

La principal estructura es:

  • Yo como usuario…
    • Acá describes bajo qué usuario o persona está escrita la US, la idea es ir contextualizando.
  • Quiero o necesito…
    • En este punto se describe la necesidad o el porqué se necesita lo que se está solicitando, la idea es que al ser una historia. Cuidado con meter demasiados tecnicismos en esta parte, justo lo que queremos es resolver la necesidad y dejar espacio para que el equipo de desarrollo u otras personas puedan proponer soluciones alternativas o bien pivotar con un MVP es importante.
  • Ya que…
    • Después de redactar la necesidad, es en este punto donde se explica el usuario el porqué es importante para el resolver ese dolor. Cuando son desarrollos de productos internos, es aquí cuando el usuario de negocio nos indica el porqué el tener este requerimiento completado le agregaría valor a su operación, es decir, la importancia a nivel negocio

Te comparto un ejemplo:

  • Yo como usuario de mi tarjeta de crédito “TDC Product Name” emitida por “SAVI” del segmento “Acero” de su banco “Bank Name” la cual me da 4.5% de cashback topado a 100 USD mensuales
  • Quiero poder visualizar de una manera fácil e intuitiva en la aplicación “Bank App” cuanto cashback tengo acumulado
  • Ya que la única manera que tengo es llamando a la línea telefónica y eso me consume tiempo o bien utilizando los ATM’s de su banco.

Acceptance criteria or DoD

“Definicion of Done” o bién “Acceptance criteria”, son dos términos equivalentes que escucharás en la industria y dependerá de la jerga que se use en la organización si usar una u otra.

Acá se busca dejar por escrito bajo qué condiciones se considera que la historia de usuario o requerimiento ha sido resuelta.
Es decir: qué tiene que suceder en el producto para llevar al usuario a resolver su dolor.

Lenguaje Gherkin es un lenguaje que se usa para hacer casos de pruebas el cual es de facil lectura a nivel negocio. A continuación te dejo un artículo donde podrás leer sobre él y ver algunos ejemplos

Los PO o PM’s no-técnicos no suelen llegan a esta profundidad técnica. Sin embargo, créeme que si haces un esfuerzo de aprender a redactar esto les ahorrarás mucho trabajo y te amarán. Además de demostrar que conoces de tecnología y de procesos de testing.

La estructura básica es la siguiente:

Scenario: “Acá le pones título al escenario o caso a probar”

  • GIVEN “Acá das todo el contexto, declaras las precondiciones que se tienen que tener y describes el ambiente”
  • WHEN “Describes cuál es el -trigger- o detonante para el caso”
  • AND “Esto es opcional, pero si requieres de tener varias condicionantes puedes usar esta clausula como estratégica”
  • THEN “Escribes el desenlace para el contexto dado bajo las condicionantes “When & And”, lo que tienes que resolver acá es: describir en términos funcionales, ¿Qué debería de pasar?”

De nueva cuenta, te invito a leer el artículo y te dejo un ejemplo:

Scenario: Consultar cashback acumulado

  • GIVEN Que soy un usuario el cual tiene la tarjeta de crédito “TDC Product Name” emitida por “SAVI” del segmento “Acero“
  • WHEN Yo entre a la sección de saldos a través de “Bank App” y haga tab/clic a mi TDC.
  • THEN Mi saldo de cashback al último corte se debería de desplegar junto con los otros montos mostrándolo en una etiqueta “Total Cashback: ” seguido por el monto que tenga en formato flotante a dos dígitos.

Success criteria

Antes de explicarte como redactar el success criteria como todo un pro, te quiero compartir un meme:

¿Oye, tu perro muerde? No, pero te puede lastimar de otras maneras…

Para que a ti como futuro profesionista trabajando en producto no te pase esto tienes que tener muy en mente las siguientes preguntas:

  • ¿Cuál es el indicador de negocio que quiero impactar?
  • ¿Por qué es importante esto para mi usuario/cliente?
  • ¿Cómo puedo cuantificar el beneficio que obtendremos al completar este requerimiento/US?

Acá un artículo de Wikipedia que te puede servir de base para definir un indicador SMART:

Seguimos con nuestro ejemplo:

  • De las llamadas que recibimos en nuestro callcenter para solamente consultar el saldo de cashback, se busca que con esta US resuelta, nuestras llamadas para consultar saldo de cashback se reduzcan en un 50% en los próximos 3 meses. Así optimizamos el tiempo de nuestros ejecutivos y reducimos los tiempos de espera.

Acá incluso se podría sacar un indicador económico (Costos/Ahorros) de cuál es el costo de tener ejecutivos de servicio a cliente al ya no gastar tiempo en responder llamadas que se hacen para consultar el saldo.

Hypothesis

La hipótesis idealmente se debe de formular desde un profundo conocimiento de los usuarios o de la industria.
Las entrevistas con usuarios, creación de hipótesis, iteración, validación de MVP’s y procesos de product discovery deberían ser procesos constantes en cualquier startup la cual busque crear un producto innovador de talla mundial. En todo este proceso se van recolectando notas, identificando patrones e insights, los cuales nos ayudarán a formular hipótesis y validarlas a través de la redacción de las US.

Acá para redactar la hipótesis es importante preguntarse:
¿Cuál es la idea que quiero validar? ¿Qué busco obtener?

Hipótesis – Seguimos con el ejemplo:

  • Todas las semanas recibimos correos a nuestro email de contacto solicitando conocer el saldo del cashback acumulado, de las llamadas del callcenter 10% de ellas son solamente para consultar el mismo tema. Si nosotros implementamos el poder consultar el cashback desde la app de una forma fácil e intuitiva, mejoraremos los tiempos de respuesta vía telefónica, optimizando el tiempo de nuestros ejecutivos y reduciendo los costos.


Risks & Mitigation plan

Para redactar los riesgos identificados y proponer un plan de mitigación te recomiendo el siguiente artículo:

Al momento de redactar los riesgos identificados yo te recomendaría tener en cuenta los siguientes puntos:

  • Conocer del sector: podría parecer algo que damos por hecho, pero el ser usuario del producto nos da un conocimiento sobre qué hace la organización. Tener conocimiento sobre la industria o bien identificar empresas las cuales son competencia en algún sentido es importante.
  • Proponer cosas que demuestren tus capacidades, sin dejar de ser realista: evita proponer cosas descabelladas, si tienes conocimiento sobre tecnología o identificas las principales retos del sector, es acá donde te harás brillar.
  • Presentar las ideas en grupos de tres: es algo que las grandes consultorías utilizan para presentar sus ideas, de una u otra manera funciona, fluye con el agua y has tu propuesta identificando 3 riesgos principales.

Pregunta clave: ¿Qué podría salir mal?

Seguimos con nuestro ejemplo:

Riesgos

  1. El consumo promedio de los clientes baja después de sobrepasar al monto máximo de cashback
  2. La información del cashback se encuentra en una base de datos aislada y desactualizada, la cual se ocupará resolver deuda técnica estimada en un mes para tener una integración
  3. Si nuestra “MVUS” -Minimum Viable User Story- es solo mostrar un número con una etiqueta “cashback”, el usar la palabra “cashback” puede ser un término no tan claro para nuestros clientes

Plan de mitigación

  1. -MONITOREAR- Monitorear las tendencias y el consumo promedio de los clientes, en caso de ser necesario formular un plan de respuesta
  2. -ACEPTACIÓN- Si la prioridad de la User Story es suficientemente alta y el costo beneficio sale a favor, el equipo de desarrollo puede estimar con mayor certeza cuanto tiempo requerirá resolver la actual deuda técnica
  3. -MITIGAR- Revisar con expertos en UX/UI de qué otras maneras podemos transmitir la idea del “cashback”

Te reto a hacerlo y escribir esa user story para tu producto favorito

Quiero agradecerte por haber llegado a este punto del artículo. Te comprendo totalmente y sé que hay varios puntos en los cuales se puede indagar.

Pero ahora te toca a ti poner en práctica todo este conocimiento. Te reto a identificar alguna startup de la cual seas un “heavy user”, hacerle saber a los PM’s de ahí que cosa te gustaría que agregaran y que harían que amaras más su producto.

Te pongo el ejemplo de una product US que he escrito para platzi:

Acá te dejo un post que he hecho en LinkedIn donde les solicito a los PM’s de Platzi dos historias de usuario siguiendo este formato.

IVAN CHAVEZ

Hi there! If you’re into the data world like me, then you’re in the right place.

In this website, we’re going to dive into the exciting world of DataOps & Analytics. From the latest trends and innovations to practical tips and tricks, I got everything you need to stay on top of the game.
So grab a cup of coffee (or your beverage of choice), get comfortable, and let’s get started!

-IC