El arte y la ciencia de escribir documentos de definición de producto
Estos son los principios y pasos que sigo cuando quiero definir un nuevo producto desde cero
Mi nombre es Alex Swiec y cada semana os comparto ideas y aprendizajes que me han ayudado en mi carrera profesional construyendo producto digital.
Si quieres seguir aprendiendo conmigo, suscríbete y cada Sábado a las 7am recibirás una nueva píldora de aprendizaje que espero te permita ser mejor product manager.
TL;DR
Escribir un documento de producto es principalmente un ejercicio para aclarar tu pensamiento y poder compartir tu visión con el resto de la organización.
Este ejercicio, además de aclarar tus ideas, te permitirá obtener feedback de los departamentos y personas que necesitarán colaborar contigo para que la propuesta de producto sea un éxito.
El documento de producto también debería de tener una definición clara de porqué se está desarrollando el producto, qué significa éxito, y cómo se mediría dicho éxito.
Y no te equivoques, lo más importante del documento no es el documento en sí, sino todas las conversaciones que se generarán para poder iterar tu propuesta de valor para que tenga más posibilidades de éxito.
En este post compartiré a alto nivel las diferentes secciones del documento que yo recomiendo,así como una reflexión sobre cómo puedes ir mejorando tanto el documento como el de creación del mismo proceso a lo largo del tiempo.
¡Empezamos!
Tener contexto del ciclo de producto
Es importante tener en cuenta en qué momento se escribe el documento de producto dentro del ciclo de creación de producto digital.
Aquí te dejo un diagrama, y antes de seguir leyendo, pregúntate a tí mismo…
…¿En qué momento de la fase de creación de producto escribiría un documento de producto?
La respuesta es que el documento de producto se escribe entre la fase de “Brainstorming” y “Definición”.
De hecho, el documento de producto no deja de ser un “brainstorming” personal que luego abres al resto de stakeholders para hacerlo un “brainstorming” grupal de las personas que tienen que contribuir al documento.
Usa el documento para clarificar tus ideas
Si bien el documento de producto es para ser presentado y compartido con otras personas, también es importante darte cuenta de que este documento es para tí.
Este documento es la forma de darte espacio para poder pensar de forma enfocada y profunda sobre qué es lo que crees que hay que construir, entender porqué hay que construirlo, y entender cuál es el impacto que tendrá tu producto en el negocio y en tus clientes.
Lo más importante es poder comunicar tus ideas de forma clara para que los stakeholders de turno puedan entender qué es lo que quieres construir, porqué lo quieres construir y por qué crees que tu producto será un éxito.
Secciones que debería tener tu documento de definición de producto
Las secciones más importantes de un documento de definición de producto suelen ser:
Define el Problema: ¿Qué problema está resolviendo?
Define el problema específico que se intenta solucionar
Describe cómo este problema afecta a los usuarios o clientes actuales.
Explica por qué es importante abordar este problema en este momento.
Describe el producto: ¿Qué quiero construir?
Explica brevemente el propósito del producto, definiendo el concepto general y cómo suolucionará el problema
Resume en una o dos frases el objetivo final del producto para facilitar su comprensión.
El por qué: ¿Cómo sabemos que este es un problema real y que vale la pena resolverlo?
Expón evidencias y datos que demuestran que el problema es relevante.
Si puedes, incluye comentarios de usuarios, investigaciones de mercado u observaciones que respalden la necesidad de una solución.
Justifica el valor y el impacto potencial de resolver este problema para la organización y los usuarios.
Si puedes, usa números financieros que justifiquen el valor potencial a generar
Stakeholders: ¿Quién en tu empresa necesita apoyarte?
Define a los stakeholders del producto usando la metodología RACI:
R (Responsible) - Responsable:: Define quiénes son las personas encargadas de ejecutar el trabajo y llevar a cabo las tareas específicas.
A (Accountable) - Aprobador: La persona que tiene la responsabilidad última del resultado de la tarea y toma decisiones importantes. Es la persona que debe rendir cuentas y usualmente son los que dan presupuesto para que el producto se desarrolle.
C (Consulted) - Consultado: Son aquellas personas que son consultadas. Se les involucra activamente y se les pide su opinión, ya que su conocimiento necesita integrarse en la definición del producto .
I (Informed) - Informados: Define a aquellas personas que deben mantenerse al tanto del progreso y de los resultados del producto, pero que no participan en la toma de decisiones
Éxito: ¿Cómo sabemos si hemos resuelto este problema?
Define los criterios de éxito para medir el impacto del proyecto.
Detalla los indicadores clave de rendimiento (KPIs) que se utilizarán para evaluar si la solución ha sido efectiva.
Especifica las métricas de satisfacción del usuario y los resultados deseados que definirán el éxito.
Audiencia: ¿Para quién estamos construyendo esto?
Describe el perfil de los usuarios o clientes principales para los que se está desarrollando la solución.
Explica sus necesidades, motivaciones y cualquier desafío específico que enfrentan actualmente.
Asegura que el proyecto esté alineado con los intereses y expectativas de la audiencia objetivo.
Cómo: ¿Cuál es el plan del discovery?
Especifica las hipótesis a validar y los métodos de recogida de datos
Establece el plan para probar y validar la solución propuesta a través de discovery de producto
Describe las fases del discovery, desde el diseño hasta la implementación y la evaluación de los resultados.
Flujos: ¿Cuáles son los flujos principales del producto?
Especifica los flujos más importantes que tendrán que tenerse en cuenta para que el producto pueda ser usado
Se suelen definir los tipos de usuarios para cada flujo (usuario final, usuario de gestión de back office, usuario administrador, etc.)
También en caso de productos que pueden usarse sin cuenta, se definirán los flujos cuando el usuario está logado vs. cuando no está logado.
Cuándo: ¿Cuándo se lanza y cuáles son los hitos?
Define la línea de tiempo para el desarrollo y lanzamiento del producto
Establece los hitos clave y las fechas objetivo para cada fase.
Describe cualquier dependencia o recurso necesario para cumplir con los plazos establecidos.
Inspírate con las plantillas Lenny Rachitsky
Uno de los recursos que te invito a revisar para que te inspires y puedas crear tu propia plantilla son los documentos de definición de producto recomendados por de Lenny Rachitsky en su blog Lenny Newsletter.
Revisar estas plantillas ha sido algo que me ha ayudado mucho mientras escribía este post para repasar mis propio
Dicho esto, quiero insistir en que lo realmente importante es tu capacidad de comunicar de forma clara qué quieres construir, porqué lo quieres construir y cómo medimos el éxito.
Una vez aclarado esto, te dejo con la lista que es oro en polvo.
La plantilla personal de 1 página de Lenny: Esta es la plantilla con la que Lenny empieza cada proyecto. Es bastante básica, con puntos describiendo que es lo que se quiere construir, el problema a solutionar, porqué se quiere sonstruir, métricas de éxito, etc.
Es una plantilla muy básica, pero sirve para construir una propuesta de producto sólida.
La plantilla de definición de producto de Kevin Yien (PM en Square): Esta plantilla me encanta.
En el primer párrafo define equipo, contribuidores, recursos así como el status del ciclo de vida del producto
Además añade secciones como los “no objetivos” para aclarar qué no resolver porque está fuera del alcance del producto
La sección de de narrativa me encanta porque explica de forma clara cómo se siente el cliente actualmente sin este producto
También define las funcionalidades y flujos clave, que es algo extremadamente importante para cualquier definición de producto
Añade hitos en la creación de producto, que en algunas empresas cae en la parte del gestor de proyecto
Por último, me encanta que pone un checklist operacional, con todos los departamentos que tienen que ayudar para que el proyecto sea un éxito
La parte negativa es que este template es muy complejo, por lo que puede llevar mucho más tiempo del necesario rellenarlo
Plantilla de resumen de proyecto de Asana: De esta plantilla rescataría la parte de gestión de riesgos, que muchas veces es el gran olvidado a la hora de definir producto y también una sección de preguntas abiertas, que siempre es algo que debemos tener en el radar
Plantilla de historias de Intercom: Me gusta la simplicidad, aunque incluye todo lo necesario para comenzar.
Plantilla PRD de Product Hunt: El inicio es bueno porque responde a lo básico y más importante (Quién, Por qué, Qué), aunque es un poco larga.
Plantilla PRD de Adam Waxman (Diseño en SeatGeek): A Lenny le encanta la primera página de resumen, y yo estoy de acuerdo con él.
A veces hay que poner de forma clara qué es lo que queremos comunicar y luego ir profundizando en lo que necesitamos hacer.
Plantilla de 1 página de Steve Morin (EM en Asana): Me gusta el enfoque en los criterios de éxito y los riesgos.
Plantilla PRD de Figma: Una plantilla súper completa y de fácil uso.
Plantilla de iniciativas de Adam Thomas: Un recordatorio de lo valioso que es limitar estas a una página, al menos para empezar.
Lo más importante es obtener feedback
Por muy bueno que sea tu documento de producto, si nadie en tu empresa te compra la idea, ya que si alguien tiene algún problema con lo que estás proponiendo, necesitas escucharlo lo antes posible.
Y digo lo antes posible, porque cuanto más tarde encuentres ese cisne negro que rompe tu producto, más coste y más probabilidad tienes de que tu producto sea un fracaso.
Por eso tener tus ideas claras, saber quienes son las personas que necesitas consultar, e ir iterando el documento de definición de producto con cada feedback que te den y tenga sentido, más posibilidades tendrás para que tu producto sea un éxito.
Pero esa no es la única consecuencia de obtener feedback.
Además, cuantas más personas vean tu propuesta de producto y compren tu idea, más apoyo interno tendrás para que tu producto pueda ser desarrollado y sea un éxito.
Si tienes la oportunidad, comparte este documento en alguna herramienta que permita el feedback asíncrono, ya que si la gente tiene tiempo de bajar a tierra su feedback y puede plasmarlo con palabras, seguramente sea más claro y también a ti te dará el espacio para entender el feedback recibido y poder profundizar con ese stakeholder más sobre su feedback.
Conclusión
Redactar un documento de producto es esencial para organizar y comunicar la visión de un producto o funcionalidad de manera efectiva.
Más allá del contenido, el verdadero valor del documento radica en las conversaciones que genera y el feedback que recibirás y que te ayudará a definir mejor el producto antes de empezar el proceso de discovery y delivery.
Incluir secciones clave como la definición del problema, la descripción del producto, la justificación con datos y el plan de discovery te permite profundizar mucho en el problema y solución y perfeccionar tu propuesta de valor.
Personalmente otra herramienta fundamental es la gestión de stakeholders usando la metodología RACI ya que ayuda a aclarar roles y responsabilidades, lo cual mejora en el alineamiento de los equipos que tendrán que trabajar o se verán impactados por este producto en el futuro.
Si te gustó este contenido, por favor dale al corazoncito y compártelo con las personas que creas que podrían encontrar este contenido útil en su día a día.