Start with uncertainty.
A content plan often starts with a list of things a company wants to say. We prefer to begin one step earlier: what is a buyer still trying to understand? That question changes the shape of the work. It gives an article, a comparison or a video a clear reason to exist.
For a software product, the uncertainty might be about accuracy, team adoption, implementation or the effort of switching. A useful plan makes room for those specific concerns instead of treating every reader as if they are ready for a demo.
Keep a question log.
Collect the language people actually use in sales conversations, support requests, public discussions and research sessions. Record the question, the context and what the person was trying to decide. A phrase without its context can easily become the wrong brief.
Then group the questions by the decision they support. “Can it do this?” is different from “Will it work for our team?” and different again from “How do we get started?” Those distinctions help you choose the format and the level of detail.
Give each answer a job.
Before making an asset, write down the question it answers, the evidence it needs and what the reader should understand afterwards. An expert interview may supply the missing context. A walkthrough may show a workflow more clearly than another paragraph. A comparison may need a visible evaluation method.
The aim is not to fit every question into the same template. It is to make the next decision easier. If a piece cannot explain its job in a sentence, the brief probably needs more work.
Let the next question shape the next cycle.
After publishing, return to the question log. Look at the follow-up questions, the points people still misunderstand and the subjects your team keeps explaining. Use that context alongside your visibility observations to decide what comes next.
A strong content plan is a working record of what buyers need to know. It becomes more useful as your understanding improves.
A note on our approach, from the Nakama team.