Bart Krawczyk Learning how to build beautiful products without burning myself out (again). Writing about what I discovered along the way.

How to meet product deadlines

5 min read 1597

How To Meet Product Deadlines

As much as we dislike deadlines, they’re often necessary for proper business planning. Healthy deadlines:

  • Allow us to plan cross-team dependencies
  • Provide input for other teams’ planning (e.g., marketing or sales teams)
  • Enable us to capture external opportunities (e.g., major events)
  • Keep us focused and create a sense of urgency

But, how do we balance hitting deadlines without burning out the team along the way?

Good product companies minimize these commitments. But there are always some real commitments that need to be made in order to effectively run a company.

Marty Cagan


After spending a few years in consulting/outsourcing model littered with tough deadlines, I’ve learned to recognize three common scenarios:

Let’s dig into each scenario in more detail.


Scenario 1: Co-creation

This is an ideal scenario. The team either sets its own deadlines or collaborates with the deadline requester to set the most appropriate date.

The latter consists of four steps:

  1. Engage key players
  2. Provide context
  3. Estimate and negotiate
  4. Set ground rules (leading indicators)

1. Engage key players

You want to make sure key stakeholders participate. There’s no point in negotiating a deadline if some director will just come in after two weeks and challenge the agreement.

And I hope it’s self-explanatory, but team members working toward the deadline are key players here.

Don’t waste time negotiating a deadline if all crucial voices are not represented.

2. Provide context

What’s the reason for the deadline? Why is such a high degree of predictability necessary in this case? What will happen if you meet the deadline? What will happen if you miss it?

This context will be critical for the negotiation part. Without a set context, we would be just playing a guessing game. Maybe descope this, maybe that — and so on.

Context gives us a decision-making framework and allows us to compare competitive paths.

3. Estimate and negotiate

With key stakeholders and context, we can start our estimation/negotiation process.

First, the team should be given ample time to properly estimate the scope of work; don’t expect anyone to provide a realistic estimation within seconds. It’s a give and take: the more predictability you expect, the more time the team should have.

From there, it’s all about negotiation. Should we cut something out to deliver faster? What would be the impact of adding one more feature? Include the team in negotiations  —  there’s a high chance the team will find creative alternatives and solutions that you haven’t thought of.

I’d recommend you try negotiating even if you are comfortable with the estimate. There’s almost always something you can cut or adjust to optimize the speed vs. scope ratio. And wouldn’t it be nice to get that shiny, new feature done a week ahead of schedule?

4. Set ground rules (leading indicators)

With a goal defined and a date set, the last step is to set rules and call out assumptions.

The question is, what must happen for the deadline to remain achievable? An example of ground rules include:

  • “We need the full focus of our architect; he cannot be distracted by any other team”
  • “We need unrestricted access to SMEs, and we need them to answer us within one day”

Core assumptions might include things like:

  • “We assume a total loss of 100 man-hours due to sick leave and unexpected absences”

Calling out rules and assumptions serves three purposes:

  1. A contract between parties regarding what must happen for the deadline to remain realistic
  2. A sanity check — for example, are those requirements even possible? What if the architect is split between two projects? Perhaps we need to renegotiate the deadline or make other tradeoffs. Is the assumption that people will take ~100 hours of unexpected leave supported by data?
  3. Leading indicators If you notice the architect isn’t 100 percent there, you can flag that the deadline is at risk  before your burndown charts indicate as much

Scenario 2: Total ownership

Sometimes, the deadline is fixed upfront and there’s no room for negotiation. In such a case, if you really want the team to strive for the deadline, give it as much ownership and freedom as possible.

I once worked on a product designed to help students prepare for exams. Even though we started late and encountered plenty of technical challenges, we couldn’t move the exam season.

What saved the launch is that  we had a clear goal and full ownership to make decisions that helped us meet the deadline. The ownership included:

Process

With plenty of assumptions and no time to run proper discovery, we decided to start delivery from day one. It required us to replace our research phase with a different discovery method :  a group of reference users that worked with us closely. That allowed us to speed things up without completely neglecting the discovery phase.

Scope

Whatever didn’t seem valuable or necessary enough for v1, we simply descoped, no questions asked. The client knew they had to trust our gut instinct if they wanted the release on time.

Quality

We aimed for ~60-percent accuracy in implementing designs (we skipped all the fancy shadows and UI details) and took on a decent amount of tech debt. We recorded all the shortcuts we took knowing we would need to pay it back later. That was a tradeoff worth making.

Resources

We knew we needed an extra engineer to make our deadline, so we got one within a week of requesting it.

In the end, even though the deadline seemed out of reach, with the empowerment to make any changes we deemed necessary, we managed to meet it. In fact, with every new change and adjustment we made to meet the deadline, we felt more responsible for hitting it.

In short, if you can’t engage the team in setting the deadline, at least give it all the tools and resources it needs to reach it.

Scenario #3: Crunch

Here’s an unpopular opinion: crunches are OK  —  under certain conditions.

Crunches usually happen due to:

  1. Planning failureIt happens to the best of us; things could always be planned better, and when plans fall short, you must play catch-up to stay afloat
  2. Unexpected, short-lived opportunity Sometimes opportunities appear out of nowhere. I’m not talking about a chance to win one new customer or slightly nudge metrics — I’m talking about the kinds of opportunities that have the potential to 10x your business

Ground rules for crunching

Let me be clear: no crunch is entirely healthy. But sometimes , on rare occasions,  it can be worth it.

To make the most of a limited timespan without burning out your team along the way, you should follow a few basic principles:

Is a crunch justifiable?

What’s the impact of meeting/missing the deadline? If it’s close to 10x growth versus bankruptcy, then it’s somewhat justifiable.

However, if it’s all about one director promising a specific deadline to the CEO  —  sorry, the team shouldn’t have to pay for that. The deadline itself isn’t the problem in this case, anyway.

Extenuating circumstances

Life happens. Sometimes we fail to plan. Sometimes a brand new opportunity appears out of nowhere.

However, you can’t justify a planning failure every month, and those unexpected opportunities don’t appear every day. If they do, then focus on your planning process first.

Extra hours are not a long-term solution.

Give and take

The team should be rewarded at least 2–3x its effort. This serves two purposes:

  1. An incentive that stresses the importance of the deadline
  2. A guardrail to check against arbitrary deadlines

It’s too easy to get used to paying a little bit extra to get stuff faster  —  which, in the long run, could have disastrous consequences. However, if you pay 300–400 percent for every overtime hour, you’d think twice about whether or not that deadline is really critical. If it is, then you’ll accept the cost. If not, then don’t crunch at all.

Crunching is voluntary

You can try to get the team’s buy-in, but if you forcibly break the team’s boundaries, you’ll pay interest on that in the long term.

On the bright side ,  if the deadline is genuinely important, the incentive is strong, and you don’t abuse crunches, then most people on your team will lend a hand.

Wrapping up

There’s no avoiding deadlines. I don’t even think we should try.Deadlines bring focus, predictability and alignment.

The problem isn’t with deadlines themselves but with how people abuse them. You can’t just throw dates at the team and expect it to deliver.

The healthiest scenario is when a deadline results from negotiations between key players. Unfortunately, this is rarely the case.

More often than not, deadlines come unexpectedly and are hard to move. If that happens, ensure you give your team as much ownership as needed to deliver the deadline.

If you end up in a situation when both scope and time are fixed, then crunch is a last resort. Keep in mind, there’s a thin line between extraordinary, well-rewarded crunch times and using overtime to cover up more fundamental problems. Be careful not to cross it.

LogRocket generates product insights that lead to meaningful action

LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.

With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.

Get your teams on the same page — try today.

Bart Krawczyk Learning how to build beautiful products without burning myself out (again). Writing about what I discovered along the way.

Leave a Reply