Developer Lifecycle Portal Content Gap and Friction Matrix
Map user onboarding journeys against documentation assets to uncover documentation gaps, SDK code deficits, and onboarding friction.
Apply this template when conducting comprehensive content inventory audits across software developer documentation portals. It helps technical writing teams identify missing code samples, tutorial dead-ends, and unindexed API references.
Role: Staff Developer Experience (DevEx) Technical Content Strategist specializing in developer portal architecture and content audits.
Context
- User Archetypes: {{developer_personas}}
- Product Architecture: {{product_stack_components}}
- Developer Adoption Phases: {{portal_journey_stages}}
- Quantitative User Analytics: {{telemetry_dropoff_data}}
- Code Sample Coverage: {{sample_repo_languages}}
- Lifecycle Governance Rules: {{documentation_versioning_policy}}
Task
Deliver a comprehensive Developer Journey Content Gap and Friction Matrix that pinpoints informational deficits, broken conceptual bridges, and unmaintained reference materials across the developer portal.
Method
- Segment the developer lifecycle into discrete milestones based on {{portal_journey_stages}}.
- Cross-reference {{developer_personas}} against each milestone to isolate distinct documentation requirements (e.g., quickstarts, architecture guides, deep-dive reference).
- Analyze {{telemetry_dropoff_data}} to pinpoint specific pages and navigation paths exhibiting elevated bounce rates or search abandonment.
- Inventory technical documentation covering {{product_stack_components}} to verify technical accuracy and conceptual completeness.
- Audit code sample availability across all targeted languages defined in {{sample_repo_languages}}.
- Evaluate content lifecycle status and deprecation indicators against {{documentation_versioning_policy}}.
- Score each friction touchpoint using a standardized impact-versus-effort matrix rubric.
- Formulate prescriptive remediation requirements for every flagged documentation deficit.
Constraints
- MUST evaluate all combinations of {{developer_personas}} and {{portal_journey_stages}}.
- MUST NOT recommend vague fixes like "improve writing"; every remediation item must specify technical edits or missing code artifacts.
- Matrix columns MUST maintain standardized Markdown formatting without broken pipes or unescaped characters.
- Severity scores MUST be directly justified using signals from {{telemetry_dropoff_data}}.
- Technical scope MUST remain confined to {{product_stack_components}}.
Output format
1. Developer Journey Coverage Summary
A concise 3-paragraph synthesis highlighting systemic content deficits across the portal lifecycle.
2. Journey Phase Content Audit Matrix
A Markdown matrix structured as follows: | Journey Stage | Persona | Documented Asset | Telemetry Finding | Friction Severity | Required Content Remediation | (Provide at least 8 evaluated rows spanning all journey stages).
3. Language & Sample Matrix
A multi-language code asset matrix: | Component / Feature | Language Target | Current Sample State | Missing Code Artifacts | Maintenance Priority |
4. Governance & Versioning Remediation Matrix
A documentation lifecycle matrix: | Asset Path | Version Status | Policy Compliance Delta | Deprecation Action |
Self-review
- Verify every persona in {{developer_personas}} appears in at least two audit matrix evaluations.
- Confirm every identified friction point references quantitative patterns from {{telemetry_dropoff_data}}.
- Ensure code sample deficiencies span all languages listed in {{sample_repo_languages}}.
- Check that all matrices contain specific actionable technical writing deliverables.
Explicit role, a named task, and discrete steps the model can follow.
Background, inputs and variables the model needs before it starts.
Hard boundaries — what the model must and must not do.
A named, field-level shape for the response.
Ordered work items that force analysis before an answer.
Length and structure that travel across frontier models.
Signal density — instruction weight without padding.
Documented variables so the scaffold adapts to new inputs.
Quality bar, assumptions and behaviour when inputs are thin.
How much real usage the template has behind it.