Curating Your Roadmap: Turning These 900 Topics into a Content Calendar

Nine hundred topics is not a plan; it is a quarry. Left alone, a backlog that size produces two failure modes: the team publishes in file-name order and buries the three pieces that actually matter, or the backlog becomes so intimidating that nobody starts. The difference between a pile and a roadmap is a small amount of structure applied ruthlessly — scoring to decide what deserves to exist, clustering to decide what belongs together, sequencing to decide what comes first, and pruning to keep the whole thing honest. The reference model for this discipline is not a marketing department; it is the Kubernetes documentation, which organizes a decade of material into a shape readers can navigate without a guide.

Borrow the documentation mindset

Open the Kubernetes docs home page and you will find the entire information architecture in four words: Getting started, Concepts, Tasks, Tutorials, Reference. Every page has exactly one job:

Intent	Reader’s question	Shape of the piece
Concept	”What is this and why does it exist?”	Explains, argues, situates
Task	”How do I do this one thing?”	Goal-oriented steps, minimal prose
Tutorial	”Teach me this from zero”	Learning-oriented, complete journey
Reference	”What are the exact fields/values?”	Exhaustive, neutral, look-up

That split does more than tidy a sidebar — it prevents the most common technical-content defect, which is a page trying to be two things at once (a tutorial that digresses into reference tables, a concept post that stops halfway into a how-to). Tag every one of the 900 topics with an intent before you score it; you will find that a surprising number are duplicates of an existing page in a different costume, and those merge instantly.

The Kubernetes docs make a second useful distinction: the versioned documentation (v1.33 through v1.37 live side by side) versus the evergreen material that carries the concepts. That is your evergreen-vs-timely split made explicit. A task page describing a flag that changed in 1.31 is versioned and dated; the concept behind resource requests is not. Know which kind of page you are writing before you write it.

Score before you schedule

Intent gives you a type; scoring gives you an order. Keep it deliberately coarse — a 1–5 scale on four axes, computed once per quarter:

• Audience — how many of your actual readers need this? (Practitioners beating adjacent-tool tinkerers.)
• Search — is anyone looking for it? Query volume, existing SERP gaps, and whether you can plausibly win.
• Strategy — does it support something the business cares about: a product, a hire, a partnership, a reputation?
• Effort — research + writing + technical review + editing + assets. Be honest; “quick post” is usually a lie.

priority = (audience × search × strategy × confidence) / effort

A worked example of how differently three plausible topics land:

Topic	Aud	Search	Strat	Effort	Priority
”Kubernetes resource requests, explained”	5	5	3	2	37.5
”Comparison: three niche ingress controllers”	2	2	2	3	2.7
”Migrating our internal CLI to WASI”	1	1	4	5	0.8

The third row is the trap: high strategy, real interest to the author, almost nobody searching. It may still be worth publishing — but as a strategic slot in the calendar, not a demand-generation one, and you should say so out loud when you schedule it. Confidence (your odds that the search and audience estimates are right) multiplies in; a speculative bet should visibly score lower than a proven one.

Cluster into series, sequence prerequisites

Individual scores are necessary and insufficient, because topics have edges: a post about the referrers API assumes the reader knows what a registry manifest is. Treat the scored backlog as a graph and cut it into series where each cluster shares a prerequisite chain:

1. Identify prerequisites mechanically — for each topic, ask “what must a reader already understand?”
2. Order within a cluster foundations-first: concept posts before task posts before advanced opinion pieces.
3. Publish clusters close together (weekly or biweekly) so the internal links between them are live and mutually reinforcing, rather than scattered across a quarter where nobody reads them in order.
4. Let hub posts anchor clusters: one strong concept piece per series, with the rest orbiting it and linking back.

The six-part series this article closes is an example of the pattern applied to a working backlog: a supply-chain cluster (OCI artifacts), a runtime cluster (crun and containerd), an architecture cluster (Wasm components), an operations cluster (green computing), a forward-looking capstone (predictions), and this meta-piece. Each assumes only what the earlier parts established, and each earns its place by adding a dimension the others do not cover.

Sequencing also settles the “should we cover the news first?” question: newsjacking slots go where they land naturally in the calendar, never at the cost of displacing a prerequisite in a cluster mid-series.

Evergreen versus newsjacking

News is a traffic strategy; evergreen is an asset strategy. A workable default split for a technical blog:

• ~60% evergreen — concept explainers, task guides, reference-style deep dives. Compound interest: they keep earning for years and are refreshable.
• ~30% reactive — releases, deprecations, incident post-mortems, “X is now stable.” Fast to produce, fast to decay.
• ~10% bets — predictions, prototypes, strong opinions. Low volume, high differentiation.

The discipline that makes this work: reactive pieces must point at an evergreen hub. A launch post about a new Kubernetes API is worthless in six months unless it links to the concept page that will still be ranking in three years. Conversely, never write the evergreen piece twice — when the news lands, update the hub and let the news piece be the doorway.

Tag every topic with a shelf life (evergreen, refresh-annual, dated) and a review date at authoring time. Content without a review date is content you have already decided to let rot.

Cadence, batching, and the calendar itself

Sustainable cadence beats heroic bursts. Two or three pieces per week, written in batches (research three, draft three, review three), produces a quarter’s calendar in an afternoon once the scoring and clustering are done:

Month	Week 1	Week 2	Week 3	Week 4
Q1 M1	Concept: OCI artifacts	Task: ORAS workflows	Reactive: release notes	Concept: runtime stack
Q1 M2	Task: switch to crun	Concept: Wasm components	Evergreen hub refresh	Prediction capstone
Q1 M3	Green computing concept	Task: right-sizing	Reactive: deprecation	Quarterly prune + retro

Rules that keep the grid stable: one concept post per cluster ships before its tasks; reactive pieces may swap with any week but never displace a cluster’s first post; every quarter reserves one slot for updating the highest-traffic existing page rather than publishing new material.

Repurpose deliberately, not lazily

One deep post should leave the building several times: a task walkthrough becomes docs; the core diagram becomes a talk slide; the argument becomes a thread; the code becomes a gist with its own README. The failure mode is repurposing into filler — the same 800 words chopped into five shallow posts reads as spam and trains readers to skip you. Test for it: does the derived asset give someone a reason to click the original? If not, it is cannibalization, not distribution.

Measure, then prune

You cannot curate 900 topics without a removal policy. Review quarterly with four numbers per post: search impressions, engagement (scroll depth or time), conversions/assists, and internal-link equity (how many other posts link to it). Then act on every post in one of four ways:

• Keep — performing, or strategically load-bearing.
• Refresh — right topic, stale details: update, bump the review date, and note the revision.
• Merge — two posts chasing the same intent: combine into the stronger URL, 301 the loser, and fix inbound links.
• Prune — no impressions two quarters running and no strategic role: delete with a redirect, or demote to an archive.

Pruning is the part teams skip, and it is the part that compounds. A blog of 120 deliberately maintained posts outperforms 900 decaying ones in search, in reader trust and in the team’s own morale — and every deletion makes the remaining backlog’s average score go up, which makes the next quarter’s decisions easier.

Wrapping up

The loop is short: tag intent, score, cluster, sequence, schedule, publish, repurpose, measure, prune — then run it again next quarter. Nothing in it requires a new tool; it requires deciding that a backlog is a queue to be processed rather than a monument to be preserved. Kubernetes’ docs survived a decade of growth because every page had one job and someone was willing to reorganize. Your 900 topics deserve the same treatment.

References

• Kubernetes Documentation
• Kubernetes: Documentation style overview
• Diátaxis — a systematic approach to technical documentation