As much as we dislike deadlines, they’re often necessary for proper business planning. Healthy deadlines:
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
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:
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.
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.
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?
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:
Core assumptions might include things like:
Calling out rules and assumptions serves three purposes:
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:
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.
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.
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.
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.
Here’s an unpopular opinion: crunches are OK  —  under certain conditions.
Crunches usually happen due to:
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:
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.
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.
The team should be rewarded at least 2–3x its effort. This serves two purposes:
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.
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.
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.
Featured image source: IconScout
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, Product, UX, 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 LogRocket today.
A fractional product manager (FPM) is a part-time, contract-based product manager who works with organizations on a flexible basis.
As a product manager, you express customer needs to your development teams so that you can work together to build the best possible solution.
Karen Letendre talks about how she helps her team advance in their careers via mentorship, upskilling programs, and more.
An IPT isn’t just another team; it’s a strategic approach that breaks down unnecessary communication blockades for open communication.