Startup founder
How to Repurpose Content as a Startup Founder
Turn decision records, postmortems and support threads into a posting cadence that does not depend on finding time to write.
The problem
- The interesting material is already written down, in decision records, postmortems and support replies, where no one thinks to look.
- When you do post, it is an announcement, which is the least differentiated thing a founder can publish.
- Every post starts from a blank page, so it costs an hour you do not have.
- What you know — how you decide, what you would not repeat — is exactly what buyers and candidates want to read, and none of it is public.
Why the usual approaches fall short
Post announcements only
Reveals that you shipped, not how you think. Buyers follow judgement, not release notes.
Hire a ghostwriter
They can restate what you did; they cannot reconstruct why you chose it over the alternative, which is the part readers value.
Wait for a big milestone
Milestones are rare and every one of them arrives with more pressure to sound impressive. Cadence dies between them.
Write a "personal brand" plan
Plans produce topics. Topics produce generic posts. You need decisions, not topics.
The workflow
-
01
Treat decisions as the sourceOne file per decision: the options, the one chosen, the cost accepted, the thing that surprised you. This is the entire backlog.
-
02
Extract weekly, write neverFifteen minutes on Friday: pick three decisions, turn each into a post directly from the record, no new thinking required.
-
03
Always include the costThe trade-off you accepted is what separates a founder's post from a company post, because it is the part marketing would have removed.
-
04
Strip anything that identifies a customerKeep the mechanism, remove the name. Postmortems are among the most-forwarded genres in technical audiences and the most dangerous to publish carelessly.
-
05
Cap the cadence at what survives a bad monthTwo posts a week sustained beats five a week for three weeks, and the queue is what makes two a week possible.
01What went in
为什么我们下架了卖得最好的套餐
我们下架了卖得最好的套餐：它带来的客户，成本高于他们付的钱，而且每周都在工单里告诉我们。
An illustrative example, not a client case: a team removes the plan that generates the most revenue because it attracts the customers with the worst retention and the loudest roadmap demands. One decision record, five angles.
02Five angles out of one article
| Angle | What the post argues |
|---|---|
| Contrarian view | Our best-selling plan was the reason our churn was high. |
| Mechanism | The cheap plan attracted buyers who needed a different product, and they consumed support at four times the rate. |
| Founder experience | The week we told sales to stop selling the thing that paid their commissions. |
| Industry observation | Most pricing pages optimise for conversion at signup and ignore what the same buyer costs in year two. |
| Decision rule | If a plan's customers churn faster and file more tickets, its revenue is a loan, not income. |
03What came out
Post 1 — Contrarian view
We killed the plan that made us the most money.
Not because it was unprofitable. Because the customers it attracted cost more than they paid, and they told us so every week in support.
Post 2 — Mechanism
The cheap plan did not attract cheap customers.
It attracted customers whose problem was smaller than our product.
They bought the entry tier, hit the ceiling in six weeks, and left — after consuming support at roughly four times the rate of the tier above them.
Post 3 — Founder experience
Telling the sales team to stop selling our best-converting plan took one meeting and eleven months of consequences.
Their commissions were tied to it. Their pipeline was built on it.
The rule we adopted: nobody sells a plan that support cannot sustain.
Post 4 — Industry observation
Pricing pages optimise for conversion at signup.
Almost none of them optimise for what the same buyer costs in year two — support load, churn timing, roadmap pressure.
That gap is where "best-selling" and "best" stop being the same word.
Post 5 — Decision rule
A rule we now apply to every tier:
If a plan's customers churn faster and file more tickets than the tier above, its revenue is a loan.
You will pay it back, in support and in churn, one quarter later.
How AtomSlice helps
paste the decision record, the postmortem or the support thread. The cost line and the numbers stay attached to the claim they support.
one internal document usually holds several publishable angles: the contrarian call, the mechanism, the cost, the rule you now apply.
each angle becomes a separate post, so a single decision can carry a month without repeating itself.
output arrives written for the platform: a thread where the argument runs short and sharp, a LinkedIn post where the lesson leads.
Best practices
- Write the decision record before you need the post. Reconstructing a decision three months later always loses the detail that made it interesting.
- Keep the cost line. It is the one sentence readers quote back to you.
- Publish postmortems with the customer removed, not the mechanism removed.
- Let a post be unpolished. Founders who sound like their own product page get read like one.
- Track what readers repeat. The sentence they quote is the seed of next month's article.
FAQ
What if we have no decision records?
Start with this week. One paragraph per decision, three decisions per week. Within a month you will have more material than you can publish.
Should founders write every post themselves?
They should own the judgement. Voice can be edited, judgement cannot be delegated: a ghostwriter can restate what you did, but not why you rejected the alternative.
Is it safe to publish postmortems?
Yes, with two edits: remove anything that identifies a customer, and remove anything still under negotiation. What remains — the mechanism, the cost, the fix — is the part that travels.
How often should a founder post?
Twice a week, sustained. The number matters less than the queue behind it: a cadence you can keep for a year beats a burst you cannot repeat.
Does this work for non-technical founders?
It works better. Customer conversations, pricing calls and hiring decisions produce sharper material than most engineering notes, because the trade-offs are visible to anyone.
Keep reading
- Use case How to Turn Blog Posts into Social Media Content Turn one published blog post into a thread, a LinkedIn post and a carousel, each with a different angle instead of three copies of one summary.
- Article Why 90% of indie hackers die in three months Most micro-SaaS products fail on two invisible traps and a mistaken idea of distribution, not on bad code.