El equipo de producto que no tiene una wiki centralizada pierde tiempo buscando decisiones pasadas y onboarding nuevos PMs desde cero. Construye la product wiki que todo el equipo usa y mantiene.
Cuándo usarlo: Construir una product wiki que centraliza el conocimiento del equipo de producto y acelera el onboarding y la toma de decisiones.
Herramienta recomendada: Claude
Actúa como un director de producto con experiencia construyendo y manteniendo sistemas de conocimiento de producto en organizaciones que van desde startups con un solo PM hasta empresas con veinte PMs trabajando en distintas áreas del mismo producto. Entiendes que la product wiki no es solo documentación: es la memoria colectiva del equipo de producto. Necesito construir o mejorar la product wiki de mi equipo. Para asesorarte bien, primero pregúntame: 1. ¿Cuántos PMs hay en el equipo y cuántos ingenieros, diseñadores y otros stakeholders acceden regularmente a la documentación de producto? 2. ¿Cuál es el mayor problema de conocimiento que tienes: no se recuerdan las decisiones pasadas y el razonamiento detrás, el onboarding de nuevos PMs es muy lento, los stakeholders no tienen visibilidad del estado del producto, u otro? 3. ¿Qué herramientas usa ya el equipo para documentar: Notion, Confluence, Google Docs, Linear, Jira u otras? 4. ¿Cuántos productos o áreas de producto distintas necesitan estar representadas en la wiki? 5. ¿Cuál es la disciplina del equipo con la documentación actual: hay algo documentado aunque de forma caótica, o se parte prácticamente desde cero? Con esas respuestas, diseña el sistema completo de product wiki: **1. La arquitectura de la product wiki: lo que el equipo busca y encuentra** Una wiki sin arquitectura es una colección de documentos que nadie puede navegar. Define la estructura óptima para la product wiki: las secciones de primer nivel (el producto en su conjunto con visión y estrategia, las áreas o squads con sus respectivos roadmaps y decisiones, los procesos del equipo de producto, el conocimiento de usuarios y mercado, la historia del producto con decisiones pasadas y sus justificaciones), la profundidad de cada sección según la complejidad del producto, el sistema de navegación que permite llegar al documento correcto en menos de tres clics, y la distinción entre los documentos de referencia que son estables y los documentos de trabajo que cambian frecuentemente. **2. Los Product Requirements Documents y los documentos de decisión** El PRD y sus equivalentes modernos son el conocimiento más valioso del PM porque capturan el porqué de las decisiones de producto. Define el sistema de documentación de decisiones: la plantilla del PRD o spec que incluye el problema a resolver y la evidencia que lo valida, las opciones consideradas con sus trade-offs, la decisión tomada y su justificación, los criterios de éxito que se van a medir, y las hipótesis que la decisión pretende validar, el proceso de revisión y aprobación del PRD que garantiza el alineamiento antes de que el equipo empiece a construir, y el sistema de versioning que preserva el histórico de cambios en el documento cuando la spec evoluciona. **3. El roadmap como conocimiento compartido** El roadmap no es solo un plan: es la comunicación de las prioridades y el razonamiento estratégico del equipo de producto a todos los stakeholders. Define el sistema de roadmap en la wiki: los diferentes niveles de granularidad del roadmap (el roadmap estratégico de doce a dieciocho meses para la dirección, el roadmap táctico de seis meses para los equipos de desarrollo, el now-next-later para la comunicación general), el proceso de actualización del roadmap y la comunicación de los cambios, la documentación de las decisiones de priorización que explica por qué X está en el roadmap y Y no (la pregunta más frecuente que recibe el PM de los stakeholders), y la distinción entre el roadmap de compromisos y el roadmap de intenciones. **4. El conocimiento de usuarios: centralizar lo que el equipo sabe sobre el cliente** El conocimiento de usuarios es el activo más valioso del equipo de producto y el más disperso. Define el repositorio de conocimiento de usuario: el sistema de insights de investigación que recoge los hallazgos de cada estudio de usuario, test de usabilidad, entrevista y encuesta en un lugar accesible y buscable, las buyer personas actualizadas con la evidencia en la que se basan, el mapa de jobs-to-be-done del usuario que captura las necesidades más profundas detrás de las peticiones de funcionalidades, y el proceso de actualización del conocimiento de usuario cuando la investigación produce nuevos hallazgos que contradicen o matizan lo que se creía antes. **5. El onboarding del PM: la wiki como acelerador de productividad** Un nuevo PM que puede encontrar en la wiki todo el contexto que necesita llega a ser productivo mucho más rápido que uno que tiene que preguntar a todo el mundo. Define el programa de onboarding basado en la wiki: la ruta de lectura recomendada para los primeros catorce días (los documentos en el orden correcto para construir el modelo mental del producto, el equipo y la empresa), los documentos must-read que todo PM debe conocer independientemente de su área (la visión del producto, los principios de diseño, la estrategia de la empresa, el proceso de desarrollo del equipo), y el buddy de onboarding que guía al nuevo PM por la wiki y responde las preguntas que no están respondidas. **6. La cultura de documentación del equipo de producto** La wiki más bien diseñada no funciona si el equipo no la alimenta. Define la estrategia de adopción y mantenimiento: la norma de que toda decisión de producto relevante va a la wiki antes de comunicarse por Slack o en reunión (lo que se decide en Slack se pierde; lo que va a la wiki se preserva), la revisión trimestral de la wiki que audita los documentos obsoletos y los elimina o actualiza, la asignación de ownership de las secciones de la wiki a los PMs correspondientes, y la integración de la actualización de la wiki en el proceso de desarrollo (la feature que se lanza actualiza la spec correspondiente; la decisión que se toma en la sprint planning va al decision log). Termina con el plan de noventa días para construir la product wiki mínima viable: los documentos prioritarios para crear primero, el proceso de migración del conocimiento existente disperso, y los hitos de adopción que indican que el sistema está funcionando.