A minimum viable content strategy

At most content marketing agencies, you will be sold a content strategy.

You will need it. Just as you need a product strategy, a go-to-market strategy, and a marketing strategy, a content strategy helps you align your content with your goals, choose the right topics and distribution channels, and measure what matters.

But do you need it right now? Like, your site is bare, and you just want words on the page?

Probably not. Right now, you need minimum viable content, or MVC. No, not that one. It's a content strategy for before you have content.

The MVC framework

MVC is four pieces: docs, a thesis, a guide, and a how-to or two. Each answers a different question a prospect has, and each has a natural home on the internet.

You need docs

For technical teams, this is the easiest piece. Reference docs answer "how does this actually work?" They're what earns you the right to be taken seriously by a developer who's already evaluating you.

The main reader of your docs is now an agent. When a developer tries your product, they hand the integration to Claude Code or Cursor, and the agent goes and reads your docs to work out what to call and in what order. If it can't find them, or the page only renders in a browser, it guesses at the API and the integration doesn't work. So make the docs easy for an agent to find and read. Publish the OpenAPI spec, keep a plain Markdown version of every page, and add an llms.txt that points to them.

Don't write the reference by hand. Generate it from the spec or the code with Mintlify, Fern, Scalar, or whatever fits your stack, so it stays in sync with the API. Quickstarts and guides then go on top of that.

Distribution-wise, docs live in search and inside the product. You don't really publish them, you just make sure they show up when someone searches "how to [thing] with [your category]," and when an agent asks for them.

You need a thesis

This is the piece founders find hardest to write and the one that matters most. You built your product because you saw something wrong in the world. Write about that wrongness.

The thesis answers "why should I care?" Think Linear’s Readme, Ink & Switch’s Local First essay, or the 37Signals manifesto. Probably steer clear of Marx's, though.

This is a single post. No more. It is enough to vomit down the thoughts that have been swimming around your head since you came up with the core idea of your product.

This is the HN and X piece. A sharp argument earns a front-page spot or a quote-tweet from someone with a real audience.

You need a guide

This is the 0 → 1 walkthrough of your product. If someone with no experience with your tool, and only a little experience in your domain, had to implement it, how would they do it?

The guide answers "what does using this actually look like?" It's the piece that turns intrigue into a working integration.

Guides are search and developer-community pieces. Dev.to, Hashnode, Medium republication, and a canonical version on your own blog all pull their weight. They also compound. A good guide from two years ago is still sending you signups today.

You need a how-to or three

If the guide covers the happy path, how-tos cover the long and winding road your customers actually take. "How to do X with our product." "How to integrate with Y." "How to handle Z edge case."

How-tos answer "can this solve my specific problem?" Start with one or two, ideally the ones that match the top support questions you're already getting.

These are pure search plays, and they're increasingly what LLMs cite when someone asks ChatGPT or Claude how to do something in your category.

What MVC leaves out

MVC is deliberately small. It leaves out:

• A blog with a regular cadence
• A newsletter
• Case studies and customer stories
• Podcasts, video series, or social content
• Thought leadership on topics adjacent to your product

All of these are fine. Add them when you have traction, not before.

When you need more than MVC

You're ready to move past MVC when:

• Search and community posts are sending you qualified traffic, and customers are asking the same questions often enough to fill a content calendar.
• You have a repeatable way to turn customer work into publishable material.

If you want the four pieces written, that's what we do. If you're past MVC, we also work with customers to define the exact content they need to achieve their growth goals.

All the articles screenshotted in this piece were written or edited by Argot. If you want this kind of technical content marketing for your product, see how we work or email us at work@argot.dev.