Maarten's Guide to Shipping With Impossible Deadlines V0.8

How to Beat Crazy Timelines When the Clock's Ticking

As a Product Manager, insane deadlines aren’t a matter of if, but when.

I’ve been personally involved more than 6 product rebuilds, and I’ve launched countless features under incredible pressure. I’ve got the scar tissue from missing many deadlines. I’ve also received the praise (and raises!) that come from delivering early under incredible pressure.

Through this gruelling experience, I’ve learned that it’s inevitable someone will toss an impossible deadline over the fence towards you.

Here are some real-world examples I’ve faced over the years:

• Somebody from sales sneaks a new feature in with a fixed timeline for a gargantuan feature that’s never been discussed with anyone who is supposed to deliver it.

• Marketing decides to not extend the contract of a crucial tool they’re using that’s integrated with our product.You suddenly have one month to connect to the new tool before the contract expires.

• A full rebuild has been promised to be completed in 6 months by someone on the C-level to the board.

Let’s be clear: the reason for the impossible deadline you’re facing doesn’t really matter. There can be many reasons, some of them perfectly valid and others incredibly foolish.

What matters is that from one moment to the next you’ll suddenly become the lucky fella who they expect to swing for the fences to make it happen.

Yes, you should try to have a conversation to ensure that it doesn’t happen again. And yes, in all likelihood it will happen again. Maybe not for the same reason, but happen it will.

If you currently have a deadline breathing down your neck, don’t worry I’ve got your back. Relax, breathe in and out.

We’re going to crush this deadline together. Welcome to Maarten’s Guide to Shipping With Impossible deadlines.

How do you ensure you deliver an impossible timeline on time? Let’s get cracking!

The First Rule of Delivering Under Extreme Pressure: Don’t Panic

The first rule of delivering under crazy pressure is: don’t panic. Don’t let the stress and the pressure get to you. Stay calm and focus on what you can control. I like to call this: don’t add stress to the stress. You’ve already got enough stress, so don’t add more.

Easier said than done, but it definitely is something you can learn. It’s your job to make the best of a hopeless situation, but it’s not your fault we’re in this bad situation. You may even be set up to fail from the start.

Let’s put the stress aside for now. Your first job is to figure out: how screwed are we exactly?

What Was Promised? By Who? And Why?

Let’s preface this by talking about promises. In general, people should not make promises without involving who’ll be responsible for delivering said promises. As this means you are set up for failure from the start.

As the 3rd Law of Software Estimation for Complex Work forebodes:

“Imposing estimates on others is a recipe for disaster.” – 11 Laws of Software Estimation for Complex Work

Few things are more frustrating than crazily optimistic estimates the team has to execute on. Because those estimates often will turn out to be incorrect, the team that tries to deliver on them will develop feelings of resentment towards those who put them in their miserable position. Plus, they will be far less motivated than if they were involved in producing the estimates.

When faced with an impossible deadline, the first step is identifying what promises were made, by whom, and how. In short: why is the deadline a deadline?

The promise matters, because not all promises are the same. You’ve got at least two types of promises:

1. Hard promises. If you don’t meet them, something is guaranteed to go wrong. Like a payment service provider that is deprecating an endpoint you’re using, which means your shopping cart will stop working if you don’t release your new integration on time.

2. Soft promises. If you don’t meet them, something may or might not happen. Sales wants us to deliver a new feature because they believe it will help us to close a deal. Missing the timeline may make us lose money.

A verbal promise to internal stakeholders is a completely different scenario from a contractual obligation with penalties for wrong or late delivery. A written contract may limit your flexibility in delivering the solution, so your first priority is understanding exactly what was promised by whom by when, as this defines how much wiggle room you may have in your solution.

Is it a hard promise, like a signed contract with a customer with penalties for delays, or is it the CEO who is trying to move pressure from shareholders to the teams.

The harder the promise, the less flexibility and wiggle room, and the harder it will be to deliver on time. When you figure out the promise that was made, here are some important questions to take into account:

1. Did we promise to deliver a specific solution, or to solve a specific problem?

2. Is it clear what outcome we’re trying to achieve with our solution, together with sufficient context to make decisions?

3. How did we come to the conclusion to deliver on this promise? Did we do research? Did we do discovery? Or did we simply take a customer request and turn it into a solution?

4. What happens if we don’t deliver on the promised timeline? Do we lose money? Reputation? Or will something break from a technical perspective?

These four questions are super important because they play a key role in determining how much wiggle room you have in delivering your solution. Depending on the answers you will receive to these four questions, you may have less degrees of freedom because many choices are already set in stone.

Ok, this all sounds pretty abstract, let’s talk through a real-world example where we walk through these four questions.

Solution Promised In a Contract With 12-Week Timeline

The worst-case scenario that you can have is that a solution has been promised with a fixed-scope timeline, without any understanding of why they want that solution. Let’s talk through a real-world example I was facing.

In a contract, a list of 7 bullet-points was promised with a timeline of 12 weeks. Let’s answer the four questions I posed above for this situation:

1. We promised to deliver a specific solution.

2. The outcome is unclear, and we have zero context to make decisions.

3. Someone decided to promise something because it felt right to them.

4. If we don’t deliver, we’re screwed big time, as there were huge financial penalties explicitly mentioned in the contract.

If you would ask our lawyers, a contract is a contract, so we must deliver. But what I did instead was talk to the customer and have an open conversation and ask them explorative questions:

• What problem are you trying to solve or what is the outcome you’re looking to achieve?

• Why is delivering it on time important?

• Is everything equally important, or are some things more important?

• How will this functionality be used?

After talking to the customer, I discovered a few things:

1. Only a tiny part of all those bullet points was urgent and important. They would be at risk for receiving fines if we’d deliver it late.

2. I reframed the conversation, if we only focus on delivering this crucial part first, you will get it sooner and with a higher quality. We will also work together on it.

3. I also promised that I would update the timelines after delivering the first part. And to take into account feedback from delivering the first parts in future parts.

What happened? The customer got what they really wanted sooner, and everything else was delivered far later (and in breach of contract). But since they were super happy with us, the legal mumbo jumbo didn’t matter.

They were unhappy with the timelines and a bit frustrated it took longer than expected, but they were only paying us for 12 weeks, so I told them bluntly: “If our estimates would have been accurate, you would have paid for 36 weeks and you still would have gotten it all after 36 weeks. Now you have paid for 12 weeks and you got it in 36 weeks.

There are two ways of looking at it and it’s up to you to choose which way you want to look at it: 1. You were screwed on the timeline, or 2. you secured an incredible deal. I think you got an incredible deal, despite us failing to manage expectations.”

The key thing in all your conversations with the customer is: don’t be fooled by requirements.

Just because it’s written down, doesn’t make it true or important. It doesn’t even mean the customer really needs what they have asked for. The big assumption is that someone did a good job at eliciting those requirements and to be frank: most people do a shoddy job.

If you have better information, it’s okay to revisit any requirement, because the alternative, to ignore the latest and best information at your disposal, is silly.

Okay, so let’s say you've figured the exact details of your miserable situation, where do you take it from here?

Understand the Problem You’re Solving For With the Relevant Context

One of the biggest reasons delivering on tight timelines gets butchered is because we don’t understand what problem we’re trying to solve, or we don’t know the relevant context for solving the problem in the right way.

The moment you have a good understanding of the problem you’re trying to solve, together with the relevant context, then you can figure out a solution that works for the customer in a way that also works for the business.

If you don’t have this information or understanding, then you’ll get stuck in a self-referential loop: the goal of the project is to deliver the project. That’s the worst possible place to be in when trying to deliver on an impossible deadline, as you will have extremely little flexibility on scope.

The goal of the project is never to deliver the project, but to achieve something else. And it’s your job to figure out “that something” else. If you are unable to figure out “that something” else, then your scope will become inflexible and limited in your options to deliver on the crazy timeline.

This brings me to one of the other crucial mistakes: breaking down all the work to arrive at an estimate.

Don’t Break Down All the Work to Arrive at an Estimate

How most teams approach delivering something big, is roughly the following approach:

1. Figure out the complete scope.

2. Break down all the work into small chunks.

3. Estimate all the small chunks.

4. De-scope as much as possible.

5. Produce a forecast that reasonably fits with the impossible timeline. Go back to step 4 if necessary.

If you follow this approach, you will achieve two things:

1. You will deliver the whole project later than if you hadn’t broken down the complete scope in small pieces. All the wrong assumptions and premature decisions will become baked into your project and slow you down.

2. You’re placing trust in an unreliable narrator at a point in time when you understand the least about the project you’re undertaking - before starting the project.

You should work the other way around. Don’t start with a functional scope, but start with the outcome. Reflect on the smallest possible outcome that will satisfy the needs of the customer and the business. Prevent premature optimization, and discover the real problems you’re facing by delivering something early.

The reason for this is pretty simple: by focusing on the outcome, your solution will remain anchored in the real-world of what you’re trying to achieve. By remaining anchored in reality you will have far greater flexibility than if you purely focus on the scope of the solution.

Use Propelling Questions to Explore Alternative Solutions

An excellent technique to explore alternative solutions is to use Propelling Questions. In the book ‘A Beautiful Constraint’, Adam Morgan and Mark Barden define a beautiful constraint as:

“A limitation that initially appears to block progress, but when embraced and reframed, becomes a catalyst for breakthrough innovation, creativity, or transformation.” - Adam Morgan and Mark Barden in a Beautiful Constraint

What is your constraint for delivering on the timeline? What’s blocking your progress? Write down all of your biggest constraints and figure out where most of the problems come from.

A good example is when Audi competed in the 24 Hours of Le Mans in 2006. During the 24 hours of Le Mans, there was a rule limiting how much fuel each car could use. Instead of seeing this as a handicap, they reframed the question as:

“How could we win because we use less fuel?”

They were the only team that used more fuel-efficient Diesel engines. They didn’t have the fastest car, but they made far fewer fuel pit stops than other cars. As a result, they won in 2006, 2007 and 2008.

Some examples of propelling questions:

“How would we deliver this solution if we had only one developer?”

“Imagine we only had one month, how could we achieve this outcome?”

“How could we deliver this solution without depending on other teams?”

I want to stress, these are all hypothetical questions;, the most important thing about propelling questions is that you begin by identifying your real-world constraints. You can also achieve something similar by using the Min Specs Liberating Structure.

Produce a Forecast For the First Milestone

The smallest possible first outcome you can achieve, should be your first milestone. Projects that show quick progress, are finished quickly. If you’re working on something for 3 months, before you show something working end-to-end, then you’re putting yourself at a high risk of delivering late.

It’s extremely crucial to have a quick first milestone that produces better information about the project you’re undertaking. As that first milestone will provide more and much better information than breaking down the work in small chunks and estimating all of them before starting.

If you finish something, it works, and it reduces risk, and you can use it to produce a much more reliable forecast that even takes into account the things you didn’t know before starting. But of course, you may still discover yet even more things you didn’t know.

Now you have information, and once you have information, you can descope aggressively.

Perform Aggressive Descoping Based on Outcomes

I see the same mistake happening over and over:

“No, we can't go live without Feature X.” Then, once we’re realize the shittiness of our predicament that same stakeholder says: “Yeah, we can live without Feature X.”

Be as aggressive as possible in keeping the scope as small as possible. Remember, you can always add things later. But you will never get the time back from all the stuff you’ve already added that you could’ve added later.

I’ve literally seen projects delayed by many months because they didn’t keep the scope as small as possible and they sucked at descoping. And then when the deadline neared, must-haves were suddenly no longer important. What a big waste of everyone’s time. The key thing here as well: make sure you descope in relation to the outcomes you’re trying to achieve, as the outcomes are leading, not the scope.

If you’ve got extremely challenging stakeholders, they will resist aggressive descoping, even though it’s crucial for the project’s success. If that’s the case, create the flexibility you need by creating internal milestones as you would like to have them.

You have complete control over the internal milestone. And this will also mean you can still deliver based on a scope that’s more aggressively descoped than they feel comfortable with. You determine the milestones, not them, and you don’t need their blessing, as long as they ultimately will get the more expanded scope that they’d like to have.

Keep yourself in the driver’s seat, based on the information and understanding you have about the customers and the business.

Update Forecasts As You Learn More

Remember how we talked about delivering a first milestone quickly? That’s the moment you should provide a forecast for the other milestones based on real-world data. Don’t be seduced to provide a forecast too early, and if you must, make shit up, and revisit your shitty guesses later when you have more and better information at your disposal.

Late Integration = Late Project

I once worked on a project, that was only delivered to production close to the very end of the project. Everything was working perfectly on the test and acceptance environments, but, but NOTHING worked on the production environment. What happened?

The production environment used a different version of SharePoint, which used a Dutch API instead of an English API (yes, WTF… what kind of company has language-specific API endpoints). Nobody saw it coming, but it turned a project that was supposed to earn tens of thousands of Euros into a project that lost hundreds of thousands of Euros.

Deliver to production early, with feature flags, and make sure it really works. Shipping early to a real environment, means there is less room for surprises.

Handling Distractions

If you have lots of firefighting or technical debt that’s distracting you and keeping you from working on the important project with a deadline, it may make sense to have some team members work outside the project and purely focus on dealing with problems. It sucks, but at least it prevents every team member suffering from heavy context-switching.

Technical debt is like a joker that can make easy things extremely difficult. Carefully consider your strategy for the new project so you can minimize the impact of tech debt, or potentially even include some rework if it makes sense to do so.

If technical debt derails your delivery, you will see this in the forecasts. More technical debt, means more surprises. Adjust your forecast accordingly, and descope as necessary (which hopefully won’t be necessary as you already aggressively descoped from the start).

There is no recipe to provide here, but the only word of advice is: try to create an environment with as little distractions as possible, and be creative in your solutions.

Deal With Your Constraints

Progress isn’t delivering based on scope, it’s delivering something that really works and the customer has confirmed to work. It’s your job to make sure we don’t enter submarine mode, where we work for months, where everything works from a technical perspective, but nobody has worked with something on production.

I once worked on a full e-commerce platform rebuild that we had to deliver within 6 months. We had two big constraints:

• Timeline of 6 months.

• We only had one front-end developer, while we had two teams of back-end developers.

• Nobody knew how the old system worked we had to rebuild.

So, what did we do to mitigate these constraints?

• We would use the vanilla front-end that was supplied out of the box with the reference architecture. We would only make minor adjustments to make it on brand and where the reference architecture really sucked.

• We didn’t have feature teams, but component teams. Because of the vanilla front-end decision, the back-end teams could work independently from our front-end developer.

• The first milestone we set for the first month was to ship a real-world order to our office in one country. Return the order, process the refund, and make sure we received the money back. This milestone would reduce risk significantly, as we would have the most important part working for one country.

The project was a big success.

In short, I don’t believe there is one best way to deliver your project on time, but as long as you stay anchored in the reality of what you’re trying to achieve, you’ve got the best shot at evading any prickly problems you discover on your way.

The worst you can do, is to get stuck in extensive requirements documention that’s disconnected from reality, where you actually are destroying the degrees of freedom you need to make the project a success.

Projects that are delivered quickly, show quick progress. That’s the key thing you should be looking to achieve. And progress isn’t ticking boxes, it’s having something that really works.

Spend more time thinking about your strategy, than about all the operational steps. Because if you have a solid strategy, you’ll make all the steps you have to perform much easier and less murky.

Feel free to leave a comment, if you feel I covered any topic in adequately, and I’ll update accordingly.

Special thanks to Ben Richards, Maciej Sitko, Sky Chin and Diogo Silva for their feedback.