It’s the first week of a brand new project. You and the whole team are excited and optimistic about its success.
In the second week, one of the features you are working on takes two days longer than expected. “No problem,” you think, “I can make it up next week”.
The next day you have a debate with another developer about using a library that is part of your standard tool set. You compromise because, “I can’t argue about everything. I can make it work”.
Today, the designer on the project has just been informed that the client will be working with an outside “usability expert” who will do all wire-framing.
With each subsequent challenge, your confidence level is eroded. Your satisfaction level is cut down one notch. Yet, you still try to remain optimistic. Talking about how the project will be successful in spite of these problems, as long as we push through and stay positive.
As you near the end of the project, what started as excitement and optimism has steadily descended into disappointment. You are running out of time, you and your team are dissatisfied with what you’ve built, and each other.
Is there another way to approach your work that can avoid this downward slide over the course of a project?
Here’s another perspective for the start of a new project:
- No one is using your software today because you haven’t designed, coded, shipped, and told them about it.
- Most software projects go over schedule and over budget.
- Most software startups are out of money and out of business within two years.
In short, from day one your project is already a failure. You can make it successful by calmly, but urgently:
- shipping small beautiful things to users frequently.
- testing with users whether the software solves a job to be done for them.
- testing with users whether the software delights and elicits an emotional response.
- testing customer acquisition cost and techniques.
In this mindset, each day your task is to fight from failure to success. You no longer are so willing to compromise, or to sweep seemingly small challenges under the rug.
Instead, you aggressively seek out challenges and problems, and attempt to eliminate them in order to salvage the already failing project.
When a feature takes longer than expected, you don’t assume you will be able to make up the time, because the project is already failing. Instead, you reprioritize or cut scope on other upcoming features, and work harder to ensure you’re working in the smallest shippable chunks possible.
You will use the library in your standard tool set because doing otherwise will slow you down and introduce unnecessary risk into the already failing project.
You don’t simply compromise on the design process, but rather address the challenge immediately and come to successful resolution.
This approach can be seen as overly pessimistic. However, I’ve found that this feeling is strongest when you first try out this mindset, and at the start of a new project.
That pessimistic feeling will fade when you are building positive momentum as the project goes on and ending on a high note, rather than ending the project defeated after months of compromise and numerous disappointments.
If you’re interested in exploring this concept more, there is a good episode of the Freakonimics podcast on this topic. This episode introduced me to the book Seeing What Others Don’t: The Remarkable Ways We Gain Insights and the concept of a “pre-mortem”. You may also be interested in this article about defensive pessimism.
