What to write about on a SaaS product blog: mostly the questions buyers ask right before they pick a tool like yours, each answered with a feature you can show. Those topics come from three inputs you already own: your product docs, your competitors, and the prompts buyers type into ChatGPT, Claude or Perplexity. The other posts need a different job, like a story worth sharing or an experiment.
I built this blog’s own 33-post plan in September 2026 from two of those inputs, the product’s features and 13 competitor profiles, plus 38 Google searches. I didn’t run the third, buyer prompts typed into AI assistants, so that step shows how you would. Below are the actual rows.
This post assumes you’ve already decided to blog. If you haven’t, start with whether a SaaS blog is still worth it.
This covers why idea lists fail, the four steps from inputs to a scored topic list, and the real plan with the rows that made it and one that didn’t.
What Should a SaaS Product Blog Write About?
A topic earns a slot when a real buyer question meets a feature you can show. Those make up the core of the plan. The rest need another job: a story people will share, or an experiment. A topic with neither is a guess about what might bring traffic.
Most advice on this answers a different question. I read six of the pages Google ranks for this query. They hand out formats (how-tos, case studies, listicles) or lists of generic ideas, and all six end by selling someone’s service to do the work for you. None of them uses the questions buyers ask AI assistants as a source.
Formats tell you how to write. They don’t tell you what.
Volume-first topics fail more quietly. @jakezward on X told the story of a SaaS company that spent six months of content budget on 60 posts like “what is email marketing”: “Their traffic skyrocketed, but their revenue flatlined.” That’s one practitioner’s anecdote about an unnamed company, not a study. The same trap sits under volume-first AI content.
A founder on r/scaleinpublic reported the other end. “Random ‘content’ never really worked directly for me,” they wrote, and “the only posts that brought real customers were all the same type: direct comparisons with competitors.” Again, one founder’s report.
So what does a topic that sells look like?
- A buyer asks it before choosing a tool.
- Your product answers part of it.
- You can show the feature that does.
Step 1: List What Each Feature Argues, From Your Product Docs
Start with the docs you already wrote. Feature pages, the changelog and onboarding emails are the cheapest topic source you have, because every feature exists to end a problem somebody had.
Write one line per feature, with four parts:
- The feature, in the words your docs use.
- The buyer problem it ends.
- What the buyer uses today instead.
- The question they’d ask about it, in their own words.
A made-up example for an invoicing tool:
- Feature: automatic payment reminders.
- Problem: chasing late invoices by hand.
- Today: a spreadsheet and a calendar alert.
- Question: “how do I stop chasing clients for late payments?”
The last two parts are the ones founders skip. They’re also the ones that matter. u/another_sleeve put it plainly on r/SaaS: “this doesn’t come from keyword research but actually interviewing prospects and customers.” The same comment lists what to find out: how your product solves the buyer’s problem, how they talk about it, and “what they are using now instead of your tool.”
Your docs give you the feature and the problem. Where do the buyer’s words come from? Sales calls, demos and support tickets. Copy the phrasing as it arrives, not your cleaned-up version of it.
Step 2: Read Your Competitors for What Buyers Compare
Your competitors tell you what buyers weigh you against. Write one profile per rival: pricing, what they do well, where they’re weak, and what buyers compare you on.
Each profile turns into topics at the decision end:
- alternatives pages (“[rival] alternatives for a small team”)
- “X vs Y” pages
- “is X worth it” questions
Why start there?
These sit closest to a purchase. They also hold up better when an AI assistant answers the query. Replying under jakezward’s thread, @alexvence_ wrote: “Awareness content gets summarized instead of mentioned.” A comparison names products by design.
This blog’s plan did exactly this. It split the competitors into tiers, with the closest tier marked “write comparison posts against these,” and the queue carries two alternatives posts and one “best AI blog writer” post built from those profiles. A separate table names which profiles each post may cite.
One rule matters more than the rest. A comparison is only as good as its date, and prices change. Date every competitor fact, and read the page again before you publish.
Pilcrino keeps these profiles on your machine; today you run them by hand, one competitor at a time.
Step 3: Collect the Questions Buyers Type Into AI Assistants
The third input is the prompts buyers type into AI assistants. Write them the way a buyer would type them into ChatGPT, Claude or Perplexity, then use them as working titles and section headings.
Why does the phrasing matter? Ahrefs studied 1.4 million ChatGPT prompts and found that the titles of pages ChatGPT cited had an average similarity to the prompt of 0.602, against 0.484 for pages it retrieved but didn’t cite. ChatGPT cited pages with natural-language URL slugs 89.78% of the time, against 81.11% for those without. A title that reads like the question has a better shot.
Question shapes worth collecting:
- “best [category] for [type of team]”
- “[rival] alternatives for a small team”
- “how do I [job] with [tool the buyer already uses]”
- “is [rival] worth it”
- “[your product] vs [rival]”
Then test a handful. Type each into two or three assistants, save the answers, and note who gets named. A question where rivals get named and you don’t is a topic. The longer routine, and why cited and named are different outcomes, is in getting ChatGPT to name your SaaS.
This is the step I haven’t run for this blog. The plan phrases its research as buyer questions and plans a monthly check where I type set questions into the assistants and log whether this blog shows up, but none of its topics came from typing prompts into an assistant. Treat this step as the method, not as my results.
Step 4: Score the List and Check Each Topic’s Feature
Put every candidate in one list, one row per topic. The feature column is a check, not a filter. Aim for 70 to 80 percent of topics arguing for a feature. A topic without one stays if it has another job: a story, result or opinion meant for sharing, or an experiment. Drop a topic with no feature and no other job, or park it until the product can answer it.
The columns:
- the buyer question
- the feature it argues for, if any
- its job: search, sharing or experiment
- the input it came from (docs, competitors or prompts)
- the nearest post you already have
- a score
Score what’s left. This blog weighs customer impact at 40%, product fit at 30%, search at 20% and ease at 10%. No keyword-volume tool sits behind the search score; it’s a judgment from what the results page looks like.
That answers a question @gunaa_dev left hanging under an agency’s post: “Keyword volume, competition, or customer demand?” Demand comes first, shown by your three inputs. Volume breaks ties.
Then dedupe. For each new candidate, name the nearest existing post and say why a searcher would land on a different page. No such clause, no post. This post passed against the one on whether to blog at all. That one asks whether to blog. This one assumes you do and asks what to write.
Isn’t this just a race to list more features? @yongfook argued on X in September 2026 that “Competing on features is dead.” Fair, if the post is a spec sheet. Naming a feature isn’t counting features. The topic argues for a job the buyer needs done, and the feature is the proof that your product does it.
A Worked Example: This Blog’s 33-Post Plan
Here’s the plan behind this blog. I built it across two research runs in September 2026:
- 38 Google searches through a logged-in browser
- a first sweep of 28 Reddit threads, 35 Hacker News stories and 23 X posts
- a second pass with 9 Reddit threads read in full and 6 primary studies
- 14 competitor homepages and pricing pages, and 13 full competitor profiles
That became five pillars, each with a column for its product tie:
- Get found by AI assistants (tie: the reason to blog at all)
- Blog with the plan you already pay for (no new subscription)
- AI posts that hold up (voice, Reddit and X research, the humanizing pass)
- Founder-led blog without the hours (topic research, approval, feedback that becomes rules)
- Choosing a tool (competitor profiles)
The queue has 34 numbered posts: one dropped, 33 active, split into 20 meant for search, 10 meant for sharing and 3 experiments. Four real rows:
| Post | Where the topic came from | What it argues for | Score |
|---|---|---|---|
| 2. How to write blog posts with Claude | Search finding: “Claude as a blog engine has no product owner” | No new subscription: the plan you already pay for | 8.9 |
| 3. How to get ChatGPT to recommend your SaaS | The commercial-intent cluster in the searches | Cited vs named vs recommended | 8.8 |
| 28. Feedback that becomes rules | A product feature, “Feedback becomes rules” | The feature itself | 6.8 |
| 7. What to write about on a SaaS product blog (this post) | The plan’s query log | The content plan step | 8.1 |
Post 2 shows the searches doing their job. The results for that query were YouTube walkthroughs, personal blogs and an open-source skill, with no product owning the answer, so the plan wrote it early. It’s live now as writing blog posts with Claude.
Post 28 came straight from the product docs. It scores lower, and the plan files it under sharing, not search.
And one that didn’t make it. A candidate on what to do when AI Overviews (the AI-written summary Google shows above the normal results) cut your blog traffic died at the dedupe step. The recorded reason: “same fix list; the searcher is a site with traffic to lose, not a founder starting a blog.”
Does any of this work? I don’t know yet. I’m scoring the plan’s results in public as part of this blog’s own 90-day bet.
How Pilcrino Builds This Plan for You
Everything above works by hand, with a spreadsheet and whichever AI assistant you already use. Pilcrino’s content plan does the proposing for you: it drafts topics from your product docs and competitors, covering what buyers search for, what AI assistants get asked, and which feature each post argues for. You edit the list and the order.
The research behind each post runs through your logged-in browser, so the post cites the Google results, Reddit threads and X posts it used. The competitor profiles from Step 2 feed the same plan.
Both screens show an example blog, not this one. Nothing publishes until you approve it, now or at a scheduled date.
If you’d rather have the plan proposed from your docs and competitors, with most posts arguing for a feature, join the Pilcrino waitlist. The plugin is free; the app is $199 once, $129 for the first 50, with 12 months of updates and support.
Researched and drafted with Pilcrino. Approved by Slav.
FAQ
How many blog topics does a SaaS startup need?
Fewer than you think. Start with the decision-stage topics your three inputs produce: the features buyers ask about, comparisons with your rivals, and the questions they type into AI assistants. This blog’s plan has 33 active posts, and none of them is a definition written to fill the calendar.
Should SaaS blog topics come from keyword research?
Use keyword tools as a tiebreaker, not the source. A volume list ranks topics by how many people search, not by whether your product can argue for them. In this blog’s scoring, search is 20% of a topic’s score, while customer impact and product fit make up 70%.
What if a topic can’t be tied to a feature?
Keep it if it has another job: a story or result meant for sharing, or an experiment. Most of the plan should still show a feature, around 70 to 80 percent of topics. Drop or park a topic with neither.
How do I find the questions buyers ask AI assistants?
Collect them from sales calls, demos and support tickets, in the buyer’s own words. Type a handful into two or three assistants, save the answers, and note which products get named. Any question where rivals get named and you don’t is a topic.
Should a SaaS blog write “what is” posts?
Rarely. AI Overviews and assistants summarize definitions instead of sending the click, and in one practitioner’s story on X, 60 “what is” posts sent traffic up while revenue stayed flat. Write one only when the definition leads straight to a feature you can show.