Cómo crear una base de conocimientos sobre productos que la gente realmente use

Los equipos de producto son de los creadores de conocimiento más prolíficos en cualquier organización. Investigaciones de usuarios, análisis de competidores, especificaciones de funciones, PRD, registros de decisiones, síntesis de feedback de clientes, justificaciones de mapas de ruta, resultados de experimentos, análisis post-mortem. El volumen de pensamiento que se dedica al trabajo de producto es enorme, y casi todo es valioso más allá del momento en que se creó.

Casi nada de esto se puede encontrar seis meses después.

La investigación de usuarios de la fase de descubrimiento del año pasado vive en un Google Doc cuyo investigador creador ya ha dejado la empresa. El análisis de competidores está en una página de Notion que nadie ha actualizado desde el segundo trimestre (Q2). El PRD de una función que se descartó está en Confluence, titulado con un nombre en clave interno que nadie recuerda. La decisión sobre por qué el equipo eligió el enfoque A sobre el enfoque B se tomó en un hilo de Slack que ya no existe.

El conocimiento fue creado. La inversión fue realizada. El proceso de recuperación falla porque el conocimiento está disperso en varias herramientas, nombrado bajo las convenciones del creador en lugar de las necesidades de quien busca, y sin mantenimiento tras la conclusión del proyecto inmediato.

Qué contiene una base de conocimiento de producto que funciona

Registros de decisiones. Por qué el equipo eligió este enfoque, qué alternativas se consideraron, qué limitaciones impulsaron la decisión. Esto evita volver a debatir decisiones tomadas y proporciona a los nuevos miembros del equipo el contexto que necesitan sin reabrir preguntas ya resueltas.

Repositorio de investigación de usuarios. Cada entrevista, encuesta, prueba de usabilidad e información de valor, búscable por tema y pregunta en lugar de por nombre de proyecto y fecha. La información sobre la fricción en la incorporación de usuarios corporativos del descubrimiento del año pasado es relevante para el trabajo de funciones de este año.

Inteligencia competitiva. Continuamente actualizada a partir de inteligencia de campo, informes de analistas y lanzamientos de productos, en lugar de ser recopilada trimestralmente y quedar obsoleta en cuestión de semanas.

Contexto de las funciones. Para cada función significativa: por qué se construyó, qué problema de usuario aborda, cuáles son las métricas de éxito, qué se excluyó deliberadamente. Este contexto es importante mucho tiempo después del lanzamiento de la función, porque fundamenta las decisiones futuras sobre iteración, extensión y desuso.

Justificación del mapa de ruta (roadmap). Por qué los elementos se priorizan de la manera en que se hace. El mapa de ruta en sí suele ser visible. El razonamiento detrás de la priorización suele estar bloqueado en la cabeza del líder de producto, lo que significa que cada conversación sobre "¿por qué estamos trabajando en X en lugar de Y?" requiere que el líder de producto vuelva a explicar la justificación en lugar de remitir a un documento.

Por qué fallan las bases de conocimiento de producto

Fallan por las mismas razones estructurales por las que fallan todas las wikis: la contribución requiere un trabajo adicional, nadie mantiene el contenido después del proyecto inicial, las búsquedas se basan en palabras clave y pasan por alto resultados conceptualmente relevantes, y la organización refleja el modelo mental del colaborador en lugar de las necesidades del buscador.

Los equipos de producto tienen un modo de fallo adicional: el conocimiento se crea durante una fase específica del proyecto (descubrimiento, planificación, ejecución) y es relevante para esa fase. Una vez que la fase termina, el conocimiento pierde su urgencia inmediata y el documento se hunde en el archivo, imposible de encontrar y sin mantenimiento.

La alternativa de autoescritura

La documentación autoescrita captura el conocimiento del producto desde los canales donde se crea de forma natural:

Debates en Slack donde se discuten y resuelven las decisiones de producto. El hilo en el que el equipo decidió posponer la función X se convierte en un registro de decisión que se puede buscar.

Reuniones donde se discuten las prioridades del mapa de ruta, se presenta la investigación de usuarios y se comparte el contexto estratégico. El resultado de la reunión de planificación del sprint pasa a formar parte de la base de conocimiento de producto automáticamente.

Canales de producto donde el contexto de las funciones, los comentarios de los clientes y la inteligencia competitiva se acumulan diariamente.

La base de conocimiento crece continuamente a partir de la actividad existente del equipo. No se requieren periodos intensivos de documentación. Sin pasos de contribución separados. El trabajo habitual de un gestor de producto de discutir decisiones, compartir contexto y debatir prioridades genera la documentación como un subproducto.

Preguntas frecuentes

Usamos Notion ampliamente para documentos de producto. ¿En qué se diferencia esto? Notion requiere creación y mantenimiento manuales. Cuando el proceso del equipo cambia o se actualiza una decisión, alguien tiene que acordarse de actualizar la página de Notion. Los documentos autoescritos se actualizan a partir de las fuentes donde ocurren los debates reales, lo que significa que la base de conocimiento refleja la realidad actual en lugar de la realidad del momento en que alguien editó la página por última vez.

¿Qué pasa con la estrategia de producto confidencial? Los controles de acceso garantizan que los documentos estratégicos solo sean visibles para las personas que deben verlos. La base de conocimiento respeta los mismos límites de acceso que las herramientas subyacentes.

¿Cómo se integra esto con nuestras herramientas de gestión de productos? Las conexiones con Linear, Asana, ClickUp y otras herramientas de producto permiten que el conocimiento en esos sistemas se pueda buscar junto con la documentación de Slack, Google Drive y reuniones.

Lecturas relacionadas: Por qué las decisiones de producto se vuelven a debatir, Tu investigación de usuarios vale millones, Nadie lee la wiki. Páginas relacionadas: Documentación autoescrita, Para gestores de producto, Para equipos de producto.