How SaaS Founders Can Write a Thought Leadership Book (Without Writing a 200-Page Brochure)

You already have most of a book. It is spread across the narrative deck your sales team opens every first call, the conference talk that got you three warm intros, the investor memo that explained why the old way of buying this kind of software is broken, and two hundred customer calls in which people said some version of “we didn’t realise this was the problem”.

The pull, when you sit down to write, is toward the product: how it works, why the architecture is different, what the roadmap will do. That book gets written a lot. Almost nobody outside your pipeline finishes it.

This guide covers the decisions specific to software founders. For the general method of building a point of view and an evidence base, see our guide to writing a thought leadership book; we won’t repeat it here.

Two books a founder can write, and which one travels

Most founder books fall into one of two shapes. The first teaches the reader how to see a problem. The second explains a product. The second is easier to write, because the material is already in your docs, and it is far less useful to anyone who has not bought.

Question	Category-design book	Product-manual book
What it answers	“What is changing in how this work gets done, and what should I do about it?”	“How does this software solve the problem?”
Who finishes it	Buyers, their bosses, analysts, people in adjacent roles, future hires	Existing customers and late-stage prospects
What the product’s name does	Appears in the bio and perhaps an afterword	Appears on most pages
What sales can do with it	Send a chapter to a champion who has to explain the problem to a CFO	Send it as a long product sheet
What happens after a major release	Mostly still true	Wrong in places within a year
Most likely failure	Too abstract, with no decision the reader can make	A brochure nobody asked for

We would write the first kind almost every time, even for a developer tool: teach the method, not your implementation of it.

The main-site guide on writing a category authority book as a SaaS founder walks through the category argument itself: the market change, the stakes, the old model and the new one. This article is about everything around that argument.

Don’t write a 200-page brochure: the swap test

Here is the rule we would hold every chapter to. Take the chapter, replace your product’s name with a competitor’s, or delete it. If the chapter still helps the reader, it belongs in the book. If it collapses, it is marketing, and it should go to your website instead.

The reason is commercial, not moral. Readers can tell when a book is a sales asset, and they read it the way they read sales assets: quickly and sceptically. LinkedIn’s write-up of the 2024 Edelman–LinkedIn B2B thought leadership study reports that only 15% of those surveyed described the overall quality of the thought leadership they read as very good, and that 75% of decision-makers and C-suite executives said a piece of thought leadership had led them to research a product or service they were not previously considering. The teaching came first; the product research followed. LinkedIn sells B2B advertising, so treat the numbers as a direction, not a law.

A founder book that passes the swap test usually contains:

• The old assumption, stated fairly, including why sensible people still hold it.
• The cost of that assumption, shown with evidence a sceptic would accept.
• The new way of thinking, as principles a reader can apply with any tool.
• How to evaluate solutions, including criteria your product does not win. This is the chapter that buys you trust, and the one founders most want to cut.
• Where the new model fails, so the reader knows you are not selling.

Some founders will dislike this: if the honest argument makes your product look less necessary for some buyers, publish it anyway. Those buyers were going to churn.

Product data and customer research: what you may use, and how

Your advantage is data no outside author has: how teams actually use software in your category, and what customers told you in interviews. It is also what most often gets founders into trouble.

Start with your customer contracts

Before anyone pulls a number, ask counsel what your agreements allow. Common Paper’s openly licensed Cloud Service Agreement (version 2.1), a standard B2B SaaS template, is a useful example: the provider may use usage data to improve and promote its products, but “may only disclose Usage Data to others if the Usage Data is aggregated and does not identify Customer or Users.” It treats non-public customer content as confidential; a logo-rights clause lets the provider name customers in marketing. Naming a customer is not the same as describing their problems and internal politics in chapter four. Your paper may differ; this is not legal advice.

Aggregate until nobody can work out who is who

“Anonymised” is a claim, not a label. The UK Information Commissioner’s Office guidance on whether anonymisation is effective uses a “motivated intruder” test: someone “who wishes to identify a person from the anonymous information”, and whether they would succeed. The guidance covers personal data and is under review, but the test suits company data too. In a niche market, “a 400-person logistics company in the Midlands that cut approval time by half” is not anonymous; its competitors and former employees will know.

Our working rules, which are stricter than many data teams would set:

Material	Can it go in the book?	Conditions
Aggregate usage figures across many accounts	Usually	Check contracts; no cut with fewer than about 20 accounts behind it; state sample, period and definitions
A single customer’s metrics	Only with written permission	Approved text, not just a verbal yes from your champion
Customer interview quotes	Only with permission for publication	Interviews done for product research were not consented for a book
Support tickets, call recordings, CRM notes	No	Paraphrase recurring themes instead
Your own experiments and public data	Yes	Cite them like any other source

Say plainly what your data cannot show. Your customers are a self-selected group that already agreed with part of your argument, so “teams using our approach saw X” describes your customer base, not the market. For permission emails and composite stories, see our guide to client stories and case studies in a book.

Your team does the research. You own the argument

You have less writing time than a solo author and far more help. Use the help for everything except the thinking.

Task	Who does it	What the founder does
The thesis and each chapter’s claim	Founder	Writes them, in a page or less each
Data pulls and charts	Data or analytics team	Agrees the questions; legal reviews the outputs
Customer interviews for the book	Product marketing or research	Joins three or four; reads every summary
First drafts	Writer, ghostwriter, AI tool or founder	Reviews against the chapter claim
Fact and source checks	An editor or analyst	Signs off the evidence ledger
Final read	Founder	Reads every chapter aloud, in full

The common failure is delegating the argument by accident: a product marketer drafts chapter three from the messaging framework, the founder is busy, and the chapter turns into positioning copy. Protect a few fixed hours each week for the thesis and the reviews; our guide to writing a book when you have no time has a schedule for that.

Voice matters too. Technical buyers have read plenty of ghostwritten founder books and AI prose, and discount both. The draft has to sound like the person who gave the conference talk.

A guided tool can take a share of the drafting. WritebookAI is one option: you upload talks, essays and decks as PDF, Word or text files, or paste notes, and its source analysis shows what your material covers and where it is thin. It builds a Writing DNA voice profile from your own writing samples, which you test and approve, then drafts chapters from your material and leaves out what it cannot support, such as an unsourced statistic, asking you instead of inventing it. It does not know what your customer contracts allow and should not receive confidential customer data; that judgement stays with you and your lawyer. The free start is described on the WritebookAI homepage, and our guide to writing a book with AI from your documents compares the other routes.

Align the book with go-to-market, without letting marketing write it

If the book names the problem well, your reps will start using its words, and so will buyers explaining the purchase internally. That is the main return, so the book’s terms must match your narrative deck, or you will run two vocabularies for a year.

• Sales enablement. Pick the one chapter a champion would forward to their CFO or head of IT, and make sure it stands alone. The general tactics for using a book in sales are in how to use a book to attract clients.
• Events. Each keynote should carry one chapter’s argument. Your user conference is the obvious launch room.
• Community. The evaluation chapter suits a customer community or analyst briefing because it does not flatter you.
• The market that is not buying yet. The same LinkedIn article cites the “95-5 rule”: only 5% of potential customers in a category are actively in-market at any one time. A book works on the other 95%.

Legal should review the book. Marketing should not approve every sentence; a book that has been through brand review reads like one.

Write principles that outlast the roadmap

Software changes quarterly; books are printed once. Product specifics, platform tactics and prices date fastest.

Inbound Marketing, by HubSpot’s co-founders Brian Halligan and Dharmesh Shah, shows both halves of this. Wiley’s product page describes an argument rather than a product: “Stop pushing your message out and start pulling your customers in”, because cold calls, email blasts, advertising and direct mail are “increasingly less effective.” But Wiley’s page for the revised and updated edition, dated August 2014, lists “New sections on visual content, tools as content, and Google+”. Google shut down consumer Google+ on 2 April 2019. The principle held; the platform advice dated. We have no data on what the book did for HubSpot’s pipeline, and we would not guess.

A worked example (hypothetical)

Imagine the founder of a B2B tool that manages purchase requests for finance teams at mid-sized companies. Her first outline has chapters called “Smart Intake Forms”, “Approval Workflows” and “Our Integration Layer”. Every chapter fails the swap test.

The rewrite starts from what customers kept telling her: finance teams treat approvals as a control problem, when most delay and unapproved spend come from requesters who cannot tell what the process wants. That is a claim about the work, not the software. The new outline:

1. Why “more approvals” increases unapproved spending (the old assumption and its cost).
2. The requester is the customer of the finance process (the new model).
3. Designing a request process people follow, with or without software.
4. How to evaluate any intake tool, including the case for keeping your current ERP and a good form.
5. Where this model fails: heavily regulated spend, and very small teams.
6. An appendix, online and updated each release, showing how her own product implements chapters 2 and 3.

Her data team supplies two aggregate figures from several hundred accounts, cleared against the contracts. Product marketing runs twelve interviews with publication consent. She writes each chapter’s claim and reads every draft.

Where to start this month

Write a one-page version of your argument without your product’s name, your company’s name or any feature. If you cannot, you are not ready to outline; listen to how customers describe the problem for another month. For ordering the chapters once you can, see how to structure a business book.

Then send your head of legal one email: which customer agreements would govern usage data and customer stories in a published book, and what would need permission. The answer decides which chapters can use your own evidence. Do both before anyone opens a draft.