Una vez que tu producto esté disponible en el mercado, todo se revolucionará un poco. Acabarás recibiendo peticiones de:
- Tus usuarios y equipos de atención al cliente, que te informarán de errores que siempre tendrán que solucionarse inmediatamente.
- Tus usuarios, que no volverán a utilizar tu producto si no construyes cierta feature para la semana que viene.
- Tu CEO, que quiere que construyas algo porque un amigo suyo le dijo en una cena que estaría muy bien.
- Tu equipo de ventas (para software orientado a empresas), pidiéndote que incorpores una feature para lograr su objetivo trimestral de ventas.
Suma todo lo anterior a las features que crees que son importantes para estar a la altura de tu competencia o construir algo nuevo e interesante; compaginar lo que tú quieres con lo que tus usuarios buscan te parecerá una tarea imposible.
En ese momento tendrás que dar un paso atrás, recordar tu visión de producto e intentar definir qué es lo más importante para el futuro de tu producto. Lógicamente, es mucho más fácil decirlo que hacerlo.
Parte de tu lucha interna (y esencial) de ser Product Owner es dar prioridad al desarrollo de nuevas features, al trabajo de optimización y al desarrollo de mantenimiento.
Fórmate con profesionales top en el Curso de Product Manager de Thiga Academy
El resto de este capítulo recoge una serie de consejos y estrategias que esperamos que puedan ayudarte a tomar estas decisiones tan complejas.
No permitas que tus usuarios tomen el control
La era del desarrollo de producto orientado al cliente ha llegado. Tanto empresas grandes como pequeñas (desde conocidas marcas de zapatillas o de patatas fritas) están ahora sacando partido de lo que aportan sus clientes para desarrollar nuevos productos.
El concepto de desarrollo de producto orientado al cliente es muy bueno; al fin y a cabo, se trata de un producto que se crea para cubrir las necesidades de sus usuarios. Sin embargo, no es lo mismo el desarrollo orientado al usuario que el centrado en el usuario.
A medida que sigues desarrollando tu producto tras el lanzamiento, los usuarios:
- Pedirán que se incluya una nueva feature, asegurando que están dispuestos a pagar lo que haga falta para que se incluya en el producto, aunque su petición no tenga fundamento.
- Se quejarán incesantemente sobre un problema que tienen con tu producto, pero seguirán pagando por él y utilizándolo.
- Expresan su frustración y exigencias a pesar de que éstas no tengan nada que ver con el producto y su uso.
Como Product Owner, escuchar a tus usuarios es muy beneficioso, y una parte importante de tu trabajo, pero no dejes que las exigencias y peticiones de tus usuarios te afecten más de lo necesario, pues podrían desviarte del camino.
En su libro «Rework», Jason Fried de Basecamp nos explica cómo evitan ellos que los usuarios dirijan el desarrollo del producto. Llega incluso a decir que no hay que prestar tanta atención a los comentarios de los usuarios, y que permitir que los usuarios dirijan el trabajo de tu equipo acaba llevando a crea una colección de features sin ton ni son en lugar de un producto. A modo de ejemplo, veamos esta cita de un capítulo que precisamente se llama «Di que no por defecto».
No te creas aquello de que «El cliente siempre tiene la razón». Imagínate que eres cocinero. Si muchos de tus clientes dicen que tu comida está muy salada o picante, la cambias. Pero si unos pocos clientes quisquillosos te piden que pongas plátano en tu lasaña, descartas la idea… y eso es lo que hay que hacer. Contentar a unos pocos clientes alborotadores no merece la pena si eso acaba estropeando el producto para el resto.»
Esta puede parecer una mentalidad un tanto extrema, pero Basecamp ha demostrado que esta forma de trabajar puede ser muy eficaz. Centrarse en los usuarios no significa que haya que atender sus peticiones más excéntricas, sino escuchar sus problemas y encontrar soluciones con la ayuda de tu equipo. Los comentarios de los usuarios deben considerarse única y exclusivamente como una gran fuente de conocimiento.
Entiende el impacto de una feature antes de construir otra
Lo normal es que cuando lanzas una nueva feature, no suele ser la solución perfecta a los problemas de tus usuarios, incluso a pesar de haberla probado lo suficiente previamente.
Seguro que has escuchado a tus usuarios y que has dedicado el tiempo necesario a comprender el impacto de una feature, tanto de forma cualitativa (mediante entrevistas a los usuarios) como cuantitativa (mediante analítica web).
Empezar a trabajar en una feature antes de que se haya confirmado que la anterior ha funcionado significa que no estás aprendiendo de cada iteración de tu producto, por lo que te recomendamos que incluyas en tu flujo de trabajo una fase de comentarios sobre cada feature.
Si trabajas con Kanban, una manera de evitar que te olvides seguir la evolución de una feature tras su lanzamiento satisfactorio es incluir una columna de «impacto conseguido». Si estás trabajando con Scrum, ten siempre a mano una lista de features lanzadas recientemente en una pizarra de software dedicada o de gestión visual.
Guíate por los objetivos cuantitativos para optimizar tu producto
¿Aún te cuesta decidir si concentrarte en optimizar o construir nuevas features? Déjate guiar por los KPI cuantitativos; cada decisión que tomes deberá estar orientada a mejorarlos.
Para guiar tus decisiones, puedes comenzar por utilizar métricas de negocio tradicionales, como los ingresos y beneficios. Sin embargo, para dar un paso más en tu análisis cuantitativo, te aconsejamos que prestes mucha atención al marco de métricas pirata conocido como AARRR.
AARRR gira en torno a la medición de cinco indicadores que utilizan diferentes métricas:
- Adquisición: cantidad de nuevos usuarios que adquieres.
- Activación: cantidad de usuarios que ya están a bordo y que comienzan a utilizar el producto.
- Retención: porcentaje o cantidad de usuarios que vuelven y utilizan tu producto repetidamente.
- Ingresos (Revenue): cantidad de ingresos generados por una cantidad X de clientes de pago.
- Referencia: cuántos usuarios nuevos atraen tus usuarios actuales.
Analizaremos las AARRR en el duodécimo mandamiento. Por ahora, ten en cuenta que cada vez que decides optimizar una feature existente o bien añadir una nueva, esa feature necesita tener impacto suficiente y moverse en uno de esos indicadores.
También te recomendamos que intentes darle una visión cualitativa a la satisfacción de tus usuarios. Hay muchas formas de conseguirlo (por ej., utilizando Net Promoter Score), pero la idea es saber si los usuarios aprecian tu producto y de qué features disfrutan más.
Si te das cuenta de que algunas features no le gustan a la mayoría de tus usuarios, puede que haya que plantearse eliminarlas. Si tu producto tiene features que poca gente utiliza o disfruta, puede verse afectado y perder atractivo y facilidad de uso.
Para saber más: Descarga nuestro libro Las Claves del Product Management
Foto de David Travis en Unsplash
