Meera runs a small online shop selling handmade home goods, and last spring she launched a new line with a big announcement. Within a week she knew something was wrong. Orders arrived, but the shipping estimate on the checkout page was off, two popular items were already out of stock, and the person who packed parcels was ill. When she told the story later, she said the same thing most owners say: “I could see every one of those problems coming, after they happened.” This post is about that odd gap between hindsight and foresight, and a habit called the pre-mortem that closes it a little.
The problem: failures look obvious only in hindsight
Why do we find the causes so easily afterwards and so rarely before? Part of it is how planning works. When we plan, we follow the path we want. Each step flows into the next, and the story feels complete. We are not looking for what could interrupt it, because nothing in the exercise asks us to.
Part of it is social. Mentioning a risk in a planning meeting can sound like doubt, and doubt can sound like disloyalty. So the concerns that people feel privately stay private. By launch day, a dozen small worries sit in a dozen separate heads, and the plan has never heard any of them.
Diagnosis, then, comes down to two missing ingredients: nobody was assigned to think about failure, and nobody felt safe to speak about it.
The fix: a pre-mortem, or pretending it already happened
A pre-mortem supplies both ingredients at once. You tell the team: “Imagine it is three months from now and the project went badly. Write down why.” The instruction turns pessimism into the task. It is not that anyone doubts the plan; they are doing the homework.
Meera tried it with her next launch. She invited the two people who help her, plus her cousin who handles the website, and set a timer for five minutes. Everyone wrote on sticky notes. What came out surprised her.
- “Customers abandoned the cart because shipping costs appeared only at the last step.”
- “We sold more than we had in stock and had to cancel orders.”
- “The website was slow during the announcement because many people arrived at once.”
- “Nobody checked how the payment page looked on a cheap phone.”
- “The cousin updated the site on launch night and broke the product page.”
The last note stayed with her. It was not a large technical failure. It was simply that changes were made at the worst possible moment, by one person, without anyone looking over them.
How the diagnosis works step by step
The same process is easy to repeat for any project, whether it is a shop opening, a new service or a website rebuild.
- Name the date and the failure. Be concrete. “The launch week went badly” is vague; “customers complained and returned items” is better.
- Write alone first. Silent writing lets quieter people contribute before any discussion shapes opinions.
- Cluster the notes. Stack similar ones. Repeated themes tell you where the real exposure sits.
- Pick the cheap fixes. Some risks can be reduced with a phone call or a checklist. Do those first.
- Give each fix an owner and a date. Otherwise the notes just become wallpaper.
What the pre-mortem found in the bigger picture
Meera’s list pointed to categories that apply well beyond her shop. Planning the order of work matters, and a clear digital roadmap helps; a piece on sketching a blueprint for steady digital growth shows how to lay out stages so the riskiest step is not also the last one. Money matters too. Many of her imagined failures would have forced emergency spending, so she revisited an article on finding spending leaks and extending runway to see how much cushion she had before a rough week could hurt.
Her cousin’s note also led to a wider question about how changes reach the live site. Software teams think about this routinely, and a DevSecOps resource like DevSecOps Now, whose blog focuses on securing CI/CD pipelines, shows how seriously they treat the path between a finished change and a live product. A tiny shop does not need the full machinery, but it can borrow the idea that someone other than the author should look before a change goes live.
Turning notes into small, real changes
Meera converted her sticky notes into a short list of actions. She added shipping costs earlier in checkout, set a stock buffer so she never sold her last few units, and scheduled a quiet “no edits” window the day before announcements. She also arranged a second pair of eyes for any change to the product page. None of these took more than an afternoon.
She also asked a harder question: which of the notes could she not fix? Some risks, like illness or a late courier, cannot be removed. For those she chose a response in advance, such as a backup packer on call or a polite delay message ready to send. Naming a response ahead of time lowers the stress when the thing finally happens.
Keeping the habit light
A few cautions help the exercise stay useful instead of heavy.
- Keep it short. Thirty minutes is enough for most small projects.
- Do not argue about likelihood while collecting notes. Rank them later.
- Avoid blame. The question is “what went wrong in the plan,” never “who made the mistake.”
- Look at the list again after launch. Which notes proved true? That feedback sharpens the next round.
It also helps to read the planning side alongside the risk side. A write-up on how a new client might approach a digital services roadmap pairs naturally with a pre-mortem, because roadmaps describe the hoped-for path and the exercise tests it.
What changed for Meera
Her next launch was not perfect. A courier delay still happened, and one product photo turned out to be misleading. But the checkout worked, the stock held, and the site stayed up. When customers wrote in, the replies were already drafted. The difference was not luck. It was that the worst ideas had been spoken aloud a few weeks earlier, when fixing them was only a matter of time and attention.
If you are about to start something, borrow her method. Gather the few people involved, imagine the project has gone badly, and ask each person to write the reasons. Then choose three fixes and put names beside them. The exercise is short, it feels slightly uncomfortable, and it quietly removes surprises. That discomfort is the cheapest price you will pay for finding problems before your customers do.
