Start with problems rather than broad labels
Labels such as 'education,' 'inspiration,' and 'promotion' describe types of posts, but they do not identify what your audience needs help with. Collect actual questions from conversations, support requests, comments, and your own work. Keep the original wording and context when you have permission to use it. A question about fixing a failed upload is more actionable than a general intention to publish educational content.
Separate observed questions from ideas you suspect people might ask. Both can be useful starting points, but they carry different evidence. Do not call a brainstorm a proven high-volume keyword. Group questions by the task or decision they share, then ask whether you can supply a clear answer, an original example, or a useful demonstration. A theme without credible material is a research assignment, not yet a publishing pillar.
Give each pillar a distinct reader promise
Imagine a creator who teaches practical bicycle maintenance. 'Fix a specific problem,' 'choose the right tool for the job,' and 'recognize when to seek professional help' could be useful themes if the creator has the appropriate expertise. These are illustrative categories, not a recommended template for every niche. Each should tell a reader why another piece from the same creator could be worth their time.
For Ferryman's audience, useful themes include choosing a publishing workflow, adapting content accurately, and resolving destination-specific failures. The boundaries matter: a general scheduling guide should not be rewritten repeatedly with slightly different titles. Put closely related questions into one strong explanation, and create a separate article only when the reader's task and useful answer are genuinely different.
| Pillar worksheet | Question to answer | Evidence to collect |
|---|---|---|
| Reader problem | What recurring task are we helping with? | Real questions and context |
| Credible contribution | What can we demonstrate or explain firsthand? | Example, test, or reviewed expertise |
| Boundary | What belongs in another guide? | Nearby topics and merge decisions |
| Continuation | What useful question comes next? | Reader follow-ups, not a forced series |
Vary formats without losing the theme
One pillar can produce a short answer, a detailed tutorial, an annotated example, or a response to a follow-up question. The format should suit the task. A visual process may need a demonstration; a decision may work better as a table. Repurposing should preserve the underlying facts while changing how the audience encounters them, not create several nearly identical pieces just to fill a calendar.
YouTube's audience guidance recommends consistency in topic or format and developing series from topics viewers already find useful. It also notes that how-to viewers may leave after getting their answer. That is not automatically failure: a solved problem can be valuable even without immediate repeat viewing. Use the guidance as a planning input, not a promise that choosing three pillars guarantees algorithmic distribution.
Review usefulness and capacity together
After publishing a small set, look for relevant questions, reader understanding, completed tasks, and appropriate business outcomes alongside reach. Identify whether the audience wants depth, a missing prerequisite, or a different topic. Keep a record of what changed your decision. Avoid abandoning a useful support theme because one broad entertainment post earned more impressions; the pieces may serve entirely different purposes.
Reduce or merge pillars when you cannot maintain accurate material or when they repeatedly produce the same answer. Add a new theme only when you can explain the reader need and provide evidence beyond generic advice. Ferryman can help distribute supported content, but editorial focus remains a separate decision. The goal is a recognizable body of useful work that people have a reason to return to and recommend.
Sources & further reading
Written by Ferryman. Sources checked Oct 16, 2026. Platform rules can change; consult the linked documentation for current requirements.