Affinero

Blog

Publish the post about what went wrong. Nobody can copy it.

GENERATED · 800 words · EN→FI ✓

Editorial illustration: a cracked ceramic bowl mended along one bright seam, resting on a worn workbench beside the left

Every company blog has a post it is never going to publish. Not the confidential one — the one about the project that quietly failed, the campaign that lost money, the launch that landed on nobody. It is usually the most useful thing that company could write. The reason it stays unwritten has almost nothing to do with writing.

A competitor can copy your guide. They cannot copy your wreckage.

Most business writing is assembled from other business writing. Anyone can produce a competent explainer on a subject they have researched rather than lived, which is exactly why the results for most commercial search terms read as though one person wrote all of them.

Google's guidance on helpful content asks publishers to self-assess against a set of questions, and two of them are unusually hard to fake. Does the content provide original information, reporting, research or analysis? Does it demonstrate first-hand expertise — the kind that comes, in Google's own phrasing, from having actually used a product or service? An account of something you attempted and got wrong satisfies both by construction. You are the only holder of the material.

This is also the cleanest answer to the question we field most often. As we have argued before, Google's objection was never machine authorship — it is pages that exist without containing anything. A failure post is the hardest page in the world to write emptily.

Engineering solved this. The commercial side never adopted it.

Infrastructure teams publish post-mortems as routine. Cloudflare's account of the outage on 2 July 2019 walks through the change that took its network down. GitLab published a post-mortem of its January 2017 database outage, in which data was removed from the wrong server and several of the backup procedures turned out not to work.

Neither company reads as weaker for it. They read as organisations that know what happens inside them, which is a rarer and more valuable signal than a page of uptime claims.

The habit stopped at the edge of engineering. Marketing, sales and product publish wins. The result is an archive that reads like a highlight reel, and it gets believed exactly as much as a highlight reel deserves.

The bottleneck is permission, not prose

A failure post does not stall because it is hard to write. It stalls because someone has to decide the company will say it out loud, and that decision sits above whoever owns the content calendar. You cannot schedule an admission the way you schedule a product update.

This is the sharpest limit on what we do. We can write the post the day someone tells us what happened and what may be said about it. We cannot originate either. It belongs in the same category as everything else in what an automated blog cannot do — the engine was not in the meeting where the thing went wrong, and no amount of reading your website will put it there.

So treat it as a decision rather than a task. Someone senior decides once, in advance, that the company publishes its own post-mortems, and draws the boundary: no customer named without agreeing to it, nothing with live legal exposure, no unpatched security issue. Inside that boundary, the writing is the easy part.

A post-mortem is not an apology

Done badly, this is worse than silence. "We learned so much from this journey" is a press release wearing a hair shirt, and readers detect it on sight.

The test is mechanical. Can a reader in your position avoid your outcome? That takes the sequence of events, the decision that looked reasonable at the time, and the exact point where it stopped being reasonable. Vagueness is the tell. A write-up that never says what was actually done is protecting someone, and the reader can feel the shape of what is missing.

One more restraint. A public failure post should never be a performance review with a URL. Both Cloudflare and GitLab describe systems that permitted a mistake rather than the people who made one. That is not politeness. It is the part that makes the post useful to anyone outside the company.

Publish one and listen to your next sales call

You do not need a policy of radical transparency, and we would not recommend one. A single honest write-up a quarter is enough to change what your archive is.

Two things move. Prospects arrive having already read the least flattering thing you have published, which makes everything next to it more credible. And you own the one page in your category a competitor cannot answer, because answering it would have required living it.

The post you are least comfortable publishing is usually the one carrying the most information. That is not a coincidence. That is the definition.