Project roadmap
This page is about how I'd run a content program for a NimbusWiz-shaped product, and the framework I'd use.
This is a method demo, not an actual operating plan.
Treat documentation as a product
Documentation has users with jobs to be done. My first step is to define these segments precisely enough that content decisions can be argued for or against.
For NimbusWiz, three segments use the docs differently:
| Segment | Job to be done | Primary concern | How they read |
|---|---|---|---|
| DevOps Engineer | Get a system through the pipeline without it failing in production | Risk: what can go wrong, what the rollback options are | Skips to the relevant stage; uses the API reference as a working document |
| System Administrator | Keep the fleet healthy and catch problems before they escalate | Visibility: what the metrics mean, when to act | Returns to the same pages repeatedly; uses the KB during incidents |
| Technical Manager | Make and defend the upgrade-vs-replace decision | Decision support: confidence scores, tradeoffs | Reads overviews; arrives via the Dashboard |
Each segment implies different content investments. By naming these segments, I aim to avoid over-investing in whichever audience my writer-avatar most resembles.
Prioritize on effort and impact
Score every backlog item on two axes:
- Effort is relative to the existing baseline: low (one page or a section rewrite), medium (a new multi-page section or structural change), or high (a new doc suite or major IA change).
- Impact is estimated from the analytics signal driving the action: ticket volume, search failure rate, drop-off rate, or feature-usage-vs-doc-views gap.
The scoring isn't precise, but names what each item is for. See Content Analytics Insights for worked examples of the items with impact signals.
Instrument what to measure against
The NimbusWiz program is organized around outcomes, so three things are planned or in place before the first content investment:
- Page-level analytics on every doc page (Plausible, GA4, PostHog, take your pick).
- Search analytics on the doc-site search bar, including zero-result queries.
- A funnel metric that ties docs to product outcomes. For NimbusWiz, that would be Time-to-First-Success: time between first docs visit and the first system completing the full Register-to-Monitor pipeline.
The point of the funnel metric is how the number moves when content investments ship, not the absolute number.
Phases, not features
The docs program for NimbusWiz runs in phases, each defined by what the prior phase made possible.
| Phase | Goal | Defining work |
|---|---|---|
| Baseline | Know the numbers before optimizing for them | Implement analytics, set search baselines, publish the dashboards |
| Critical gaps | Fix the content with the loudest signals | Address the top unresolved searches and the highest drop-offs |
| Persona optimization | Tailor by segment | Split entry points by audience; add contextual links from product to docs |
| Retrieval-augmented | Let users ask questions instead of searching for pages | Restructure the corpus for AI consumption; ship a RAG chatbot with an evaluation framework |
Each phase produces a measurable change in the funnel metric. A phase that doesn't move the metric is a signal to recalibrate the plan.
What I'd do first in a real engagement
Spend a few weeks in instrumentation and observation before a single content change ships. It is crucial to know what you're optimizing for before you start optimizing.