Does and don’ts
Objectives tend to focus on what should be done rather than what should be avoided. On a day to day basis, this is clearly advantageous, focusing team members and plans in the direction that progress should be made. This, however, creates an environment where the value of what not to do is often lost. It seems so easy to create an endless list of what not to do that there can’t be any real value in creating one.
The way that people think, however, isn’t that straight forward.
When undertaking a new project and looking for feedback on what could go wrong, simply asking team members isn’t sufficient. If you ask them what could go wrong, they will create a list of reasonable points that could contribute to failure. A lack of marketing presence, a compressed timeframe, understaffing, etc. The standard answers.
If however, you ask them to imagine they are x months in the future, that the new undertaking has already been carried out, and that it has already failed, you will get very different answers. Now when asked what caused the project to fail, problems that are far more likely to actually cause the project to fail will surface.
The product didn’t fit in the shipping containers we had, no one was assigned to look for problems in our customer funnel, I didn’t understand why I had to do this step, etc. When confronted with the ‘fact’ that the project has failed, people draw upon direct experience and reasoning. When asked to predict what could go wrong, they base their thoughts on the plan.
Simply telling people a project has failed allows you to get a real list of don’ts. A list with a value likely greater than the list of does. (This is called the premortem technique).
The mistakes of others
Another very valuable approach is to learn from the mistakes of others. Given the cost of these insights took to generate and how cheaply they can be obtained, they are often an underused resource.
For example, I came across a paper “Involvement of “Ostensible Customers” in really new innovation: Failure of a start-up”. In it, the authors list the most common external and internal factors for startup’s failure and links to the initial research. Using this to simply signpost an avoidance list of what not to do could prove very valuable as it seems unlikely that any startup aimed to be a part of the paper, and all probably had healthy to-do lists.
Another paper lists the reasons for high failure rates in terms of trust and adoption for digital-only startups.
And the list goes on.
Researching failure, not in passing or because there is some time free, but as an infrequent but actual activity can be incredibly useful. I’ve certainly learnt a lot and quite possibly avoided mistakes thanks to those who went before me.