Planning a blog that supports a product

A blog supports a product when each post answers a search a buyer already has, then points back at the product or the service that does the job. A pile of unrelated essays can be well written and still leave the product to explain itself alone.

Blog strategy for saas, and for a studio that sells a specific kind of site, is a list of those searches. You publish into the list. You do not publish beside it and hope the association is obvious.

One search, one post

Start with the questions a founder types while deciding, or while trying to do the thing themselves. "What should a seed-stage homepage include?" is a search. "Our thoughts on the future of design" is a mood. The first can be a post with a point of view and a next step. The second can be a note in a founder’s journal. It does not need a URL on the company site until it answers someone who is not you.

Give each post one primary query and one job. The title names the decision. The opening two sentences give the answer a stranger could quote. The rest of the piece explains the conditions. When a second topic shows up, it becomes the next post, linked from a sentence, not bolted into this one.

Google's helpful-content guidance asks whether you are producing lots of pages on many topics in the hope that some of them rank. That is the failure mode of a disconnected magazine. The same guidance asks whether the site has a primary purpose. A product blog's purpose is to help the buyer of that product understand a decision, then find the product. If a post would be equally at home on any agency's domain, it is not supporting yours.

Write less, and finish the pages. A complete answer a buyer can use beats a thin post that exists to hold a keyword. You can always add the next question after this one is actually good.

Point at the product or the service

Every post needs a path back to the offer. The path should match the post. A piece about homepage structure points at the service that builds homepages. A piece about reading a portfolio points at the work. A piece about hiring points at a conversation. The link sits in a sentence that says what the reader will get. It is one link, not a banner repeated after every heading.

Mention the product in the places it is the honest example. If you are explaining empty states, and your product has a careful empty state, show that. If you are explaining a general decision, do not drag the product name into every paragraph. Repetition is not relevance.

The Princeton GEO paper, published at KDD 2024, is a useful warning here. The authors tested ways of rewriting pages so generative engines would cite them. On Perplexity.ai, keyword stuffing performed about 10 percent worse than the unmodified baseline. Methods that added real citations, quotations, and statistics improved visibility in their tests. The lesson for a product blog is practical. Answer clearly, cite a source when you use a number, and name the product when it belongs in the answer. Do not salt every paragraph with the product name and call that a strategy.

A generative engine quotes a passage that can stand alone. Your opening and your FAQ answers are those passages. Write them as if they might be lifted. Then make sure the lift is still true.

A cluster, not a shelf

Group posts around the buyer's job. For a SaaS product, a cluster might be "understanding the problem," "setting the product up," and "judging whether it worked." For a studio, a cluster might be websites, the engineering under them, and how an engagement runs. Inside a cluster, each post links to one neighbor that should be read next. The cluster has a hub, even if the hub is a service section on the homepage until a dedicated page exists.

Publish in an order that makes the links true. A spoke that points at a hub which is still a draft sends people into a hole. Write the hub, then the two or three posts that answer the questions the hub cannot hold. Two or three pieces a week is a human pace. A hundred posts in a day looks like the magazine you were trying not to build.

Keep a list of searches you refused. That list stops the next brainstorm from dragging in a topic you already decided was someone else's. It also shows you where the product's story has a gap. A gap you can fill with a real answer is the next post. A gap you cannot fill is a sign to stay quiet.

What the writing has to include

A post that supports a product still has to be a good post. Use a definition in the first paragraph when the subject is a term. Use a list when the reader is choosing. Use three questions at the end whose answers stand alone. Name an author and a date. Give the hero image a description of what is in the picture.

Use an outside number only when it changes the advice, and name the publisher. Invented metrics about your own product will be quoted later, by you or by someone else, and you will have to live with them. If you do not have a figure, write the qualitative truth. "Teams of five need a handful of components, not a second product" is advice. A fake percentage attached to it is not.

Edit for the buyer who will never buy. They should still leave with the decision made. Trust is the byproduct. A post that withholds the answer until a sales call is a landing page in disguise, and it teaches people to stop reading you.

Review a post when the product changes. If the screenshots are from a flow you removed, the post is now teaching the wrong product. Update it or retire it. Leaving it up because it once had traffic is how a library starts to argue with the app.

Keep the site and the journal in step

The blog is not a separate brand. The sentences should sound like the product and the homepage. If the product is calm and the posts are breathless, readers believe the posts, and the product feels like a different company. Pick the voice in one place and apply it to the button, the error, and the article.

Plan the next piece from the last sales conversation and the last support thread. Those sources are less flattering than a content calendar, and they are more accurate. A question that came up twice is a post. A topic that came up in a competitor's newsletter is a maybe.

When the map runs from the name, to the site, to the interface people use, the writing has a place in that sequence. That map is a founder's path from brand to site to product. The blog is the part that answers the questions those three surfaces should not have to answer at full length.

If you want that kind of site built with the writing in mind, start from Hanabi's services. The studio designs and builds the pages, and the editorial structure should be part of the same scope, not a stack of posts added after the launch out of nerves.