The best technical content topics are already sitting in your support tickets, your sales calls, and your search console. You do not have to invent them. Teams run dry because they gather in a room and try to brainstorm themes, when the questions their buyers are actually asking have been piling up in five places the whole time. Harvest those and you will have more good topics than you can write, each one attached to a person who already wants the answer.
This matters more for devtools than for most categories, because your buyers search in precise, technical language and they can tell instantly when a post was written to chase a keyword rather than to answer their real question. A topic with genuine intent behind it clears that bar on its own. Here is where to go looking.
Start with the queries engineers actually type
The richest source is how developers search when they are mid-problem. They paste an error string into Google. They look up how to connect your tool to the one they already run. They type “X vs Y” when they are choosing between two options and getting close to a decision.
Pull those from search console, keyword research, and the autocomplete suggestions on your own category terms. Each one tells you both the topic and the exact phrasing to lead with. The mechanics of turning these into pages that rank are what I cover in SEO for devtools, and the comparison queries specifically deserve their own treatment, which I get into in comparison and alternative pages. The point for now is that this is a bottomless well. Developers generate new specific queries faster than you can ever write them up.
Your support queue is a content calendar in disguise
Every question that lands in support is a question some larger number of people had and did not ask. When the same one shows up three times, you have found a post. The exact confusion, in the user’s own words, is sitting right there in the ticket.
This is some of the highest-converting content you can write, because a person searching that same error or setup problem is blocked right now and will try whatever unblocks them. A page that explains the thing, with your product as part of the fix, catches them at the moment they most want help. Ask your support person or whoever answers in your community to flag the repeat questions. That flag is a content brief.
Sales calls tell you what the buyer is stuck on
If you have any kind of sales motion, the calls are full of topics. Every objection, every “but can it handle,” every “how is this different from” is a question your market is asking out loud. The ones that come up on call after call are the ones worth a page, because the page then does that part of the convincing before the next prospect ever books time.
Sit in on a few calls, or read the notes, and write down the questions that repeat. A founder doing their own selling already has this in their head. The job is just getting it out of the calls and onto the blog, where it works for everyone who never calls.
Your product and changelog are their own supply
When you ship something that changes what a user can do, that is a topic. Not a version bump or a dependency update, but a real new capability or a limit that no longer blocks people. Those earn a post that shows the thing working, and your changelog is the running list of candidates, which is part of why I treat the changelog as a marketing surface rather than a dry log.
The same goes for the hard-won internal knowledge your engineers have. The reason you built a feature a certain way, the tradeoff you chose and why, the benchmark you ran to settle an argument. That thinking is interesting to exactly the people you want reading, and most of it never leaves a Slack thread.
Mine the gaps, not just the volume
High search volume is not the only signal. Sometimes the better opportunity is a question that gets asked a lot but answered badly everywhere, or a comparison where the existing pages are all thin, outdated, or obviously biased. If you can write the honest, genuinely useful version of a page that currently only has bad versions, you can win it even against bigger sites.
Look for where the top results are weak, where a popular answer is wrong, or where the whole topic has shifted and nobody updated their post. Those gaps are easier to rank for than fighting a crowded head term, and they tend to be the ones your technical buyers quietly appreciate you for filling.
Keep the list alive
All of this works only if you capture ideas as they surface instead of trying to remember them later. Keep one running doc. When a support question repeats, a sales call throws an objection, or you notice a weak page in search, it goes in the doc that day, with a note on which query or ticket it came from.
Tag each one lightly by intent, so you know whether a topic is someone mid-problem, someone comparing options, or someone just learning the space. That tagging shapes how you write it later and keeps your calendar balanced across the different reasons people show up. Do this for a few weeks and the problem flips from “what do we write about” to “which of these do we write first,” which is a much better problem to have. If you want someone to run that sourcing and the writing that follows, that is what I do, and you can tell me what your buyers keep asking.
