giphy.com

Deadlines

For as long as I’ve been working in tech I’ve heard this oscillating debate about the use of deadlines in projects, with particularly strong opinions from those against them:

“I don’t believe in deadlines. They are bullshit created by (predominantly business) people who don’t understand how hard it is to design and build great products. You cannot rush great [design, software, etc.]”

I disagree, I believe in deadlines. Not because the date matters, but because they’re a powerful way to influence the behaviour of a team.

At the time of this writing, our team at Shopify is busy preparing for Unite, our annual partner & developer conference. It’s the final stretch of six months of work that started when we (internally) committed to launch a bunch of products at the conference.

It really is a great conference. See why so many developers build on Shopify.

Unite brings together thousands of people from our ecosystem, and on top of building the products themselves, our teams spend hundreds of hours preparing for presentations and workshops. It’s very hard to pull off, and a big investment of company energy. The pace is frantic, the months are stressful, and the chaos is draining.

Yet, no one forced us to have it. We happily impose this deadline on ourselves because it makes us better, and in turn, makes our product better.

Why deadlines work

Deadlines work because they force critical thinking by adding a constraint. When a deadline is set on a project, magical things happen.

1. Teams are forced to work backwards from launch — A deadline forces your team to confront what must exist at launch, and the by-product of that is a realistic list of all the work to be done.
2. Teams must prioritize ruthlessly — Since you have a list of what needs to get done and a fixed time to do it, teams are forced to decide how much time they’re willing to allocate to each item.
3. Teams know if they’re on pace — open ended projects mean you can never know if you’re progressing too slow or fast. A deadline creates a benchmark.
4. Teams combat human nature — People aren’t lazy but they don’t default to urgency either. Parkinson’s law explains this best, “work expands so as to fill the time available for its completion.”
5. Teams are compelled to ship faster than they otherwise would have — most teams dream of their product in a perfect end-state, and sometimes that dream can create an inertia to ship. Deadlines combat this by providing an externality to help teams justify shipping an imperfect product.

How to use Deadlines effectively

There are two types of deadlines: those that matter, and those that don’t really matter at all.

The ones that matter tend to relate to either a short-lived opportunity, or a company’s survival. The day your startup runs out of cash is a deadline you don’t want to miss. You don’t even need to think about using these types o deadlines, they will use you.

More interesting (and common), are deadlines that don’t actually matter.

Missed an arbitrary launch date by 3 weeks? Stakeholders may moan, but does it really matter? Just delay the blog post, and save that tweet for later. You’ll get roughly the same impact.

Even Shopify’s Unite conference doesn’t really matter. Would Shopify’s outcome materially change if a team missed the conference launch date? Unlikely. (jk team, jk 🙏)

Which brings us to the interesting part about using deadlines effectively. The meaning of the date is often irrelevant to it’s usefulness. You will get the behavioural benefits by just having a deadline for the sake of it.

Using deadlines when the date doesn’t (really) matter

As a leader of a team, using deadlines when the date is irrelevant is tricky, because in order to get the behavioural effects to work for your team, you have to genuinely care about the date or they will see right through you.

Am I suggesting you fake it? No, and I don’t think you need to.

When runners are training, is there some universal force compelling them to care that today’s time was better than yesterday’s? No, runners aspire to hit the time for the sake of achieving it and for the pleasure in knowing they’re growing.

This should be your mentality when you rally your team around a deadline. Make it a point of team pride to achieve it. Make everyone want to meet the deadline, if not for the impact it will have to customers, than for the sake of the challenge and for what it says about them.

How to avoid using deadlines disastrously

Be wary of deadlines negatively influencing your decision making as you approach the ship-date.

If you don’t think it could happen to you, imagine leading a team and beating the “we can do it!” drum everyday for seven months. In that situation, don’t kid yourself — you are very emotionally vested in meeting the date. And that’s exactly when you will act irrationally.

Here are a few reminders I give myself of as a deadline approaches:

1. Do not ship a shitty product for the sake of the deadline. The dumbest thing you can do with a deadline that had very few consequences if missed, is to create real consequences by shipping a half-baked product that hurts your company.
2. Never punish missed deadlines. If your team is working hard, there’s nothing more you should ask of them. Remember, you already got the behavioural benefit by having the deadline at all. If you’re a PM, stand up and accept 100% of the blame for missing the date to all stakeholders, publicly. It’s the least you can do for a team that’s been hauling ass, and it’s the right thing to do.
3. Celebrate met deadlines. The deadline may have been artificial, but the focus and drive of the team to hit it was very real. It needs to be acknowledged, celebrated, and observed by other teams.

No more debate

Deadlines work because constraints foster creativity and resourcefulness. There are countless examples of how deadlines pushed teams to do more than they thought they could. Think moon landing, think Tesla even though they miss every one.

Deadlines work even when dates are arbitrary, because they give a team a challenge and something to prove.

Deadlines work, but they must be used with care and in service of good products, not in priority to them.

Deadlines make product teams better, and that’s why I believe in them.

Bonus — how to pick a date when there isn’t an obvious one:

1. Register to present the new project at a public event
2. Pick a meaningful date that’s relevant to your customer base. For example if you make education software, aim to launch the week students go back to school in September.
3. Schedule a demo to the CEO or board
4. Publicly promise customers a day it will launch (okay don’t do this one)

Before you go, some things to consider:

1. Recommend or share this if you found it useful. It gives me 🔋 to write knowing people find value in it.
2. Subscribe to The Black Box of Product Management if you want more reads like this, or if you consider submitting to it so we can share your story.