---
title: Failing on Day One
teaser: Make projects successful by treating them like failures.
tags: playbook
author: Chad Pytel
published_on: 2016-05-27
---

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][podcast]. This episode introduced me to
the book [Seeing What Others Don’t: The Remarkable Ways We Gain Insights][book]
and the concept of a "pre-mortem". You may also be interested in this article
about [defensive pessimism][article].

[podcast]:http://freakonomics.com/2014/06/05/failure-is-your-friend-a-new-freakonomics-radio-podcast/
[book]:http://www.amazon.com/gp/product/1610392515
[article]:http://www.theatlantic.com/health/archive/2014/09/dont-think-positively/379993/