Cuando comenzamos una posición como Product Manager es difícil saber por dónde empezar. Sabemos que hay algunas iniciativas que aún no han sido desarrolladas, así como algunos problemas que no han sido solucionados, pero no tenemos mucha claridad sobre cómo atacarlos, documentarlos, solucionarlos o comunicarlos. Por eso, necesitamos de alguna herramienta que nos ayude a responder a esos cuestionamientos y nos permita ir, paso a paso, consolidando toda la información que tenemos sobre el producto que pretendemos construir.
No te preocupes, todos hemos estado ahí, todos hemos sentido que tenemos tanta tela que cortar que no sabemos cómo empezar a usar las tijeras. Con esto en mente, este blog post pretende guiarte en la construcción de un documento que no sólo te ayude a ti a entender el problema al que te enfrentas, las oportunidades que hay a su alrededor, y las soluciones que podrían ser implementadas, sino también ayude a entender el problema a tus stakeholders y tu equipo de desarrollo.
Comúnmente en la industria este documento es conocido como un Product Requirements Document o PRD. Para muchos, este documento es una compilación de información sobre las funcionalidades que un producto debe tener para solucionar un problema dado, sin embargo, a medida que ha ido evolucionando se ha convertido en una oportunidad para consolidar todo nuestro conocimiento sobre el problema y su impacto, tanto para los usuarios, como para el negocio.
Fuente: https://co.pinterest.com/pin/380132024792507622/
Déjame llevarte en un viaje de construcción de este documento. La estructura que te presento aquí es una adaptación de la propuesta de Reforge, sin embargo, no temas modificarla, la idea es que cada PM pueda hacer los cambios que más hagan sentido en su ambiente de trabajo.
Valor para el Usuario
En la mayoría de los casos, las motivaciones de un proyecto están fundamentadas en las necesidades de los usuarios. Digo “en la mayoría de los casos” porque no siempre es así, a veces, como PMs debemos desarrollar proyectos porque la capa de liderazgo de la empresa los considera relevantes, aunque no estén 100% justificados dentro de las necesidades del usuario o los objetivos estratégicos de la empresa. Si esta es tu situación, te sugiero hacer una investigación profunda para encontrar las razones que están detrás de ciertos requerimientos y socializar estos descubrimientos con los líderes para disipar dudas y supuestos.
En el caso en el que estemos partiendo de un problema real del usuario, nuestro PRD debe incluir información sobre quién es el usuario, cuáles son sus características demográficas y cuál es su rol en el uso del producto. Esto último puede ser confuso, pero se refiere a que el cliente puede ser quien usa el producto o puede ser quien paga por el producto para que alguien más lo use (ejemplo: una persona de finanzas aprueba la decisión de pagar una herramienta, pero no necesariamente la usa).
Luego de documentar quién es nuestro usuario, debemos identificar y describir, dentro de nuestro PRD, cuál es el problema al que él se enfrenta. Desde que empezamos a aproximarnos al problema del usuario tenemos una idea sobre cuál es este, sin embargo, debemos confirmar que dicho problema tiene, en efecto, una alta severidad. Podemos identificar esa severidad a través del desarrollo de entrevistas de usuario que se enfoquen en entender si el cliente realmente tiene el problema, qué tan grave es para él o ella, y cuáles son las alternativas que usa o ha usado para darle solución.
Es fácil pensar que un problema es más severo de lo que realmente es. Por eso, es importante comprometernos a ser honestos con las investigaciones y, entre más severo creamos que es el problema, brindar más evidencia que nos permita demostrar su nivel de gravedad a los ojos del usuario.
Finalmente, nuestro PRD debe ser una fuente que nos ayude a entender cuáles son los objetivos que tiene el usuario. Por ejemplo, aprender sobre una tecnología o declarar impuestos rápidamente. Por esta razón, debemos incluir dentro del documento una sección que explique con claridad qué es eso que el usuario quiere lograr.
Conocimiento en práctica:
Imaginemos que estamos trabajando para un restaurante y nuestro equipo nos ha mencionado que los clientes quieren un menú que incluya opciones vegetarianas. Actualmente, no tenemos ninguna en el menú y aparentemente los clientes esperan que las tengamos.
El siguiente cuadro te muestra cómo documentar la información sobre el usuario:
El Problema y la Compañía
Al comenzar un proyecto que ha sido asignado a nosotros, debemos entender muy bien cómo eso que queremos lograr resuena con los propósitos estratégicos de la compañía. Por eso, debemos comprender muy bien cuál es la misión y la visión. De la misma forma debemos entender cuál es la estrategia de la empresa, ¿cómo se van a lograr tanto la misión como la visión?. Estos tres componentes nos darán una idea de cómo el problema que queremos resolver se alinea con lo que la empresa quiere alcanzar.
Si eres nueva en tu rol, puedes pedirle ayuda a tu equipo de liderazgo para tener mayor claridad sobre este contexto. Usualmente, aunque no pase en todos los contextos, las empresas tienen documentación sobre los planes que están creando hacia el futuro. Comúnmente, estos están expresados en la misión, la visión y los OKRs de la compañía.
En niveles un poco más profundos, tenemos la estrategia de producto, la cual es establecida por el equipo de liderazgo de la organización de producto. Entendemos la visión de producto como la forma en la que un cliente específico se va a ver beneficiado por nuestro producto una vez sea construido. Sin embargo, muchas de las start-ups nacientes no cuentan con una definición clara de esta visión, lo que puede dificultar su definición dentro de tu Product Requirements Document. En cualquier caso, puedes incluirla o no dependiendo de las definiciones de tu compañía.
Por último, es importante que el problema que estás resolviendo se alinee con los objetivos de tu equipo. Tener esta alineación clara, te ayudará a que tu equipo comprenda por qué está involucrado en este proyecto, en otras palabras, les dará un sentido de propósito.
Conocimiento en práctica:
Continuemos con el ejemplo del restaurante. En esta ocasión vamos a enfocarnos en entender cómo el proyecto de agregar más opciones vegetarianas resuena con los objetivos de la compañía:
El Valor para el Negocio
Si hemos encontrado un problema para el usuario y además sabemos que solucionarlo se alinea con lo que nuestra compañía quiere alcanzar, es hora de documentar cuál es el valor que este proyecto traerá para el negocio. El valor puede estar expresado de muchas formas, podemos encontrarlo en aumentos de retornos de inversión, crecimiento en usuarios, crecimiento en alcance, etc.
Si aún no te has familiarizado con las métricas de tu compañía, este es el momento de hacerlo. Asegúrate de entender qué se mide, cómo se mide y por qué. Apóyate de tu líder para identificar en dónde se enmarca tu proyecto y cuáles serían las métricas que el proyecto debería impactar. Una estrategia que puede resultar muy útil es analizar el embudo de conversión de tus usuarios y determinar en qué pasos pierdes más clientes, de manera que puedas usar esa información para estimar cómo la solución al problema podría tener un impacto positivo en dichos pasos.
Puede que estimar el impacto en las métricas sea una tarea compleja, dados todas las incertidumbres que tenemos. Para eso, es importante tomar otras experiencias que hayamos tenido o que el equipo haya tenido (como proyectos similares) y extrapolar su impacto en nuestro proyecto.
En este punto, como PM debes ser capaz de identificar a los stakeholders de tu proyecto. ¿Qué áreas del negocio se verán beneficiadas o afectadas por tu proyecto? ¿Quiénes son las personas que debes mantener informadas? Esta información ayudará a mantener una comunicación fluida y clara en todos los pasos del proceso con las personas interesadas en el proyecto y permitirá que la toma de decisiones sea más eficiente.
Conocimiento en práctica:
Para nuestro restaurante, nos enfocaremos en impactar una métrica en particular: la retención de los usuarios. De manera que nuestro PRD se vería así:
Dependencias y Restricciones
Las restricciones y las dependencias son un componente fundamental en la creación de un PRD. El propósito de identificarlas tiene que ver con nuestra capacidad de anticiparnos a lo que pueda representar un bloqueo o una dependencia para las posibles soluciones que definamos. Tener claridad sobre ellas le dará al equipo de diseño y de ingeniería herramientas para entender desde dónde partir a proporcionar ideas de solución.
Lo primero que deberíamos hacer es identificar qué áreas o procesos son dependientes de nuestro proyecto. Estas dependencias incluyen las técnicas, las de los recursos y las de terceros. Las primeras están relacionadas con todos los componentes que serán afectados por nuestro proyecto o qué necesitan de nuestro proyecto para funcionar. Las de los recursos tienen que ver con el equipo que ha sido designado para el proyecto. Finalmente, las de terceros se refieren a las dependencias que se crean cuando trabajamos con proveedores. Puede que en los proyectos que realicemos existan otro tipo de dependencias y será tu trabajo identificarlas.
En segundo lugar, tenemos que encontrar cuáles pueden ser las restricciones que afectan a nuestro proyecto. Las restricciones tienen que ver con la idoneidad de la solución, factibilidad y viabilidad de las soluciones. Primero, debemos encontrar soluciones que de verdad resuelvan el problema del usuario. Luego, debemos determinar qué podría afectar la viabilidad de una solución, por ejemplo, tecnologías específicas. Finalmente, debemos saber qué podría afectar la factibilidad del proyecto, como por ejemplo, fechas de entrega, cantidad de recursos, etc.
Con esto en mente, podemos trabajar con el equipo en idear soluciones que contemplen todas las restricciones y dependencias que podamos enfrentar.
Conocimiento en práctica:
Este es un ejemplo de algunas dependencias y restricciones que hemos identificado en para el problema del restaurante:
Propuesta de Soluciones
Hasta aquí hemos consolidado información que nos ayuda a situarnos en el momento de la compañía, la problemática del usuario, la pertinencia para el negocio y las dependencias y restricciones que podemos enfrentar al buscar una solución para el problema que hemos identificado. Con esta información, deberíamos ser capaces de idear algunas soluciones que respondan a la necesidad del usuario, se enmarquen dentro de la infraestructura de nuestro producto y puedan ser desarrolladas con los recursos y tiempos con los que contamos.
Cuando tengamos estas soluciones a la mano, deberemos incluirlas dentro de nuestro documento de requisitos de producto o PRD. En algunos casos, los PMs, de la mano del equipo de diseño e ingeniería agregan esta información para mostrar cuál fue el proceso que los llevó a escoger la solución más adecuada, dadas las circunstancias. Sin embargo, si esta información no parece relevante para tu equipo, puedes simplemente optar por incluir la solución “definitiva” o más tentativa a ser desarrollada.
Los siguientes componentes permiten una mayor claridad sobre lo que se espera de la solución:
Funcionalidades que serán incluidas en la solución.
Interacciones con otras áreas del producto.
Interacciones con agentes externos.
Links a los prototipos que hayan sido probados con usuarios.
Riesgos identificados en usabilidad y utilidad.
La presentación de las soluciones dependerá en gran medida de las propuestas que hayan surgido. Sin embargo, es fundamental que seamos explícitos en lo que esperamos que la funcionalidad pueda hacer y de qué manera esperamos que esta solucione el problema del usuario. De la misma forma, el equipo de desarrollo y los stakeholders deben estar informados sobre cómo la propuesta que tenemos va a interactuar con las demás áreas y con agentes externos, de manera que ellos también puedan prepararse para una integración menos traumática. Finalmente, los links a los prototipos y el mapa de riesgos de usabilidad y de utilidad debe ser presentado, de manera que todos los involucrados sean conscientes de que estos estarán presentes cuando se entregue la solución.
Conocimiento en práctica:
El siguiente es un ejemplo de la propuesta de soluciones para el problema que enfrentamos en nuestro restaurante:
Nota: Algunas empresas incluyen historias de usuario y criterios de aceptación. Sin embargo, ese tipo de detalles pueden generar confusiones y generar discusiones innecesarias con los stakeholders.
Recuerda que este documento busca brindar claridad sobre las motivaciones y las expectativas detrás del desarrollo de un producto. Nuestro objetivo es mostrar con la mayor transparencia posible lo que se espera alcanzar y cómo se verá el éxito de eso que construyamos. Cuéntame tu experiencia creando PRDs, qué componentes usas y cómo los has implementado en tu día a día.
Sencillamente claro y de altísimo valor para los que buscamos impactar positivamente en la creación de soluciones usando tecnología, personas y procesos. Gracias Paula por estos regalos de conocimiento en cada artículo. Está genial!!! Ya espero por más jejej!!