How to market your SaaS with the work you already do

A repeated support question can become a public answer you send to the next buyer. You don't need a fresh opinion every morning to have something useful to publish.

If you've shipped a SaaS product, start with the work you're already doing. Capture the question, the decision, and the evidence. Then use AI to help explain it clearly. Your job is to supply what actually happened, check the draft, and talk to the people who respond.

What is founder led marketing?

Founder led marketing uses your first-hand knowledge of the product and its buyers to help people understand their problem. You publish under your own name, but the useful part is what you know, not how often you appear.

Ampere describes it as marketing built around the founder's knowledge, opinions, and experience. Its examples include LinkedIn posts, newsletters, and guest appearances. Those are places to publish. They aren't the reason someone should listen.

The reason is your access to the work. You heard the customer explain why their current process failed. You chose which feature to delay. You know which workaround still needs a spreadsheet.

A useful post makes some of that knowledge available to a buyer. It might explain how to evaluate a tool, why an approach failed, or where your product doesn't fit. A reader should leave better able to make a decision, even if they never buy.

Vlad Sedenko draws a helpful distinction: the founder supplies evidence, judgment, and relationships rather than becoming the entire channel. That gives you a better goal than becoming an internet personality.

You need to contribute facts and judgment. You don't need to perform a personality every day.

You can ask someone else to edit. You can let AI turn rough notes into a draft. You can reuse an explanation across a post and a help article. But you still need to provide the part a writer can't invent: what you learned from building and selling this particular product.

Start with one buyer question you can answer from experience. That's enough to begin without turning your week into a posting schedule.

Keep the evidence beside the idea

A useful founder post starts with a record of something you actually saw, tried, or decided. Keep that record beside the idea so you can check it when you write.

HubSpot's founder-led content guide points to work founders already produce, including investor updates, product decisions, and customer descriptions of their problems. You don't have to publish those documents. You can use them to find something worth explaining.

Create one private note for possible posts. Use whatever tool you already open while working. A complicated setup adds another task before you've written anything useful.

For each entry, capture:

• The question or problem, in plain words.
• What you tried, changed, or decided.
• What happened, including what you still don't know.
• A link to the original call note, ticket, document, or result.
• Anything you must remove or get permission to share.

The source link matters. “We changed onboarding and customers liked it” gives a writer too much room to guess. A linked note lets you check what changed and what the customer actually said.

Treat failed experiments the same way. Record your expectation before explaining the outcome. If you don't know why something failed, keep that uncertainty in the note. An honest account of an unresolved problem can still help someone avoid repeating your approach blindly.

You don't need to record every passing thought. Save the moments when a customer asks something hard, a result surprises you, or a product decision needs a real explanation. Those notes give you somewhere to start when it's time to write.

How do you turn a support question into a useful post?

Answer one support question completely enough that you could send the published page to the next person who asks it. That gives the post a clear job before you start drafting.

Ampere describes a loop between founder posts and sales conversations: questions from calls become posts, and posts become material for follow-ups. Support questions offer another place to apply that approach.

Pick a question about something you can explain from direct experience. Avoid stretching a narrow question into a broad guide just because a broad title sounds more impressive.

For example, suppose a customer asks whether your product can replace a step they currently do by hand. Treat that as a hypothetical starting point, then write from your actual product notes:

1. Explain when someone needs that step.
2. Show what your product handles today.
3. Name what still needs a person or another tool.
4. Explain how a buyer can check whether the approach fits.

Don't stop at “yes, we support that.” A useful answer explains the conditions. If the answer depends on a particular setup, say so. If your product only handles part of the job, make the remaining work visible.

Keep private customer details out of the draft. You can explain a question without identifying who asked it. If a quote or result needs permission, get it before publishing or leave it out.

Then put the finished answer where you can find it during the next conversation. Send it when it answers the question, rather than dropping it into every reply. You now have something useful for a reader and something you can reuse while helping a customer.

Give AI a source before you ask for a draft

An AI draft should begin with your notes and a specific buyer question. Asking for general content ideas leaves the most important part of the work unspecified: what you have evidence to say.

Sedenko's guide puts first-hand market evidence at the start of founder-led marketing. Apply that standard to the writing process. Let the model help explain the evidence rather than decide what happened.

Start with one source note. Include the original link for your own checks, but paste the relevant text into the drafting tool unless you know it can read the linked document. Don't assume a link alone gives it the facts.

A simple instruction is enough:

Draft an answer to this buyer question using only the supplied note. Separate what we observed from what we think it means. Don't add results, quotes, customer details, or product features. Flag missing facts as questions for me. Keep the product's limits in the answer.

Then read the questions before polishing the prose. If the draft needs a result you never recorded, look for it in the source. If you can't find it, narrow the claim or remove it.

Use follow-up requests for bounded edits. Ask for a shorter opening, a clearer explanation, or a less technical version. Avoid asking the model to “make it more convincing” without explaining what evidence it can use.

Automate turning your evidence into a readable draft. Keep responsibility for every claim.

The finished post should sound like something you could explain on a customer call. If a sentence sounds impressive but you couldn't defend it when questioned, it isn't ready to publish.

Show the limits before you ask for trust

A founder can say where the product doesn't fit without waiting for someone else to approve the message. Vlad Sedenko calls that willingness a useful part of the founder's contribution.

Use it while checking a draft. Look for places where a precise fact has turned into a broad promise. “We added an export” doesn't mean “you can move your entire workflow.” A customer's positive reply doesn't establish that every customer gets the same result.

Check each claim about results against the original record:

• Does the source contain the number, and does the draft preserve what it measures?
• Is a quotation exact, and do you have permission to publish it?
• Does the product do what the sentence says it does today?
• Have you kept the conditions and limits attached to the result?

If you don't have a measured result, describe the work without pretending you do. You can explain why you changed a screen or removed a step. You don't need to claim that the change improved retention unless you have evidence for that claim.

Ampere also recommends a written policy for protecting customers, employees, and confidential details when building in public. For a solo founder, that can start as a short private checklist. Being small doesn't make a customer conversation yours to publish without care.

Be equally careful with failures. Explain what you tried and what you observed. Don't turn one unsuccessful test into a universal rule.

A buyer should be able to read your post and understand both the promise and the boundary. That makes the post useful even when the right decision is to choose something else.

How much time should you spend each week?

Choose a weekly routine you can keep while running the product, then cut the output to fit. A schedule that depends on an uninterrupted afternoon isn't a useful starting point if you don't have one.

The sources offer different time budgets. In HubSpot's guide, Eric Lay describes posting twice a week with a process that takes about 90 minutes. Ampere describes about three hours a week, including capture, writing, replies, and a weekly log. Neither is a promise about how long your process will take.

Borrow the routine rather than treating either number as a target:

1. Capture useful moments during the work you're already doing.
2. Pick one question and its supporting note when you sit down to write.
3. Draft, check the claims, and remove private details.
4. Publish somewhere your buyers actually spend time.
5. Leave time to answer relevant replies and record new questions.

Start with one place to publish. You can add another after the routine works. A blog answer and a short social post can share the same evidence without requiring two separate research projects.

Keep a small queue of checked drafts for weeks when the product needs your attention. Don't fill that queue with generic advice just to maintain a streak. A shorter, useful answer is a better fit for this process than an ambitious post you can't verify.

If writing keeps taking too long, inspect where the time goes. Missing notes need better capture. Repeated fact-checking may mean the drafting instructions need tighter limits. More output won't fix either problem.

How do you know founder led marketing is working?

Judge founder led marketing by whether relevant buyers start better conversations with you. Follower growth can be interesting, but it doesn't tell you whether the right person understood the product or moved closer to a decision.

Ampere recommends watching who engages, which conversations start, and what buyers say about how they found you. That gives a small SaaS founder something concrete to record without building an elaborate reporting system.

Keep a short log beside your published posts:

• Which question the post answered.
• Whether someone with that problem replied or got in touch.
• Whether you used the post in a support or sales conversation.
• What the next conversation revealed that the post didn't answer.

Ask new prospects how they found you. Record their answer in their words. If they mention a post, note which one. Don't claim that a post caused a sale simply because the buyer saw it somewhere along the way.

Read any success story with the same care. In HubSpot's guide, Eric Lay says more than 90% of Virio's leads come from LinkedIn. That's his account of one company's results. It isn't a forecast for your SaaS or a reason to ignore where your buyers already talk.

A post with a modest audience can still earn its place if it answers a buyer's question or gives you a useful follow-up. Keep those wins separate from the reach numbers so you can see both clearly.

Open your recent support notes. Pick one question you can answer with evidence, write the answer, and save the source beside it. Publish only after you've checked every claim. Then keep the link ready for the next person who asks.