alexe-ev Build Product Wiki
Purpose
Help teams design a product knowledge base that is actually used — organized around how teams work, not how information is created, and maintained through team habits rather than individual effort.
Skill type
Conceptual skill
Use this skill when
- New team members take too long to ramp up due to missing documentation
- Decisions get relitigated because the rationale was never recorded
- The same questions keep getting answered in Slack rather than documented
- Tooling has changed but process documentation hasn't caught up
Do not use this skill when
- The goal is tooling selection alone (tooling is a means — structure comes first)
- The goal is sprint or delivery documentation (use plan-delivery-collaboration)
Required inputs
- Team type and size
- Primary use cases for documentation (onboarding, decisions, process, templates)
Optional inputs
- Current documentation state and tools
- Onboarding pain points
- Most common repeated questions
- Documentation owners or maintainers
Upstream context
Works best when:
- Operating cadence and key processes are defined
- Team norms are established
Downstream handoff
Output can feed:
- align-cross-team-communication (wiki is a shared context artifact)
- design-planning-process (planning templates go in the wiki)
Instructions
- Define the purpose of the wiki: what decisions or work does it support?
- Design the top-level structure around how teams navigate, not how information is created.
- Define the core content types: process guides, decision logs, templates, onboarding tracks, reference material.
- Define content ownership and update responsibilities per section.
- Design a "freshness" system: how do team members know if content is current?
- Define what goes in the wiki vs. in tickets, Slack, or other tools.
- Plan for maintenance: what happens at each planning cycle to review and update?
Output
Provide:
- Wiki purpose and primary use cases
- Top-level structure (navigation design)
- Content types and their locations
- Content ownership map
- Freshness system (review dates, owner tags)
- Tool boundary definition (wiki vs. tickets vs. Slack vs. docs)
- Maintenance plan
Risks / caveats
- A wiki that isn't navigable will be ignored — structure for findability, not completeness
- Content without clear owners goes stale — assign every section
- Don't document everything — document what is repeatedly needed and not in people's heads