The natural reaction to tight deadlines
Almost every product being built has a deadline, or a set of deadlines, for the phases that it has ahead.
Deadlines have a purpose: they exist to achieve business goals (eg: launch ticketing system for a music event), and to guarantee that the various stakeholders — Marketing, Sales, Finances, etc — can plan their work accordingly.
Nonetheless, it’s a well known problem — due to the complexity of building software, or any other type of engineering work actually — the big challenge that is to meet deadlines.
Overwork
And, even though this is a challenge that confronts product teams in almost every single project/product/phase, the first solution is, almost always to… overwork. It’s almost a natural reaction, either from the Product Managers, CEOs, Board and the developers and designers themselves: over and over again, pressure will be created towards work harder, faster, (stronger?).
The first solution is, almost always to… overwork.
Even though many companies were built under these conditions, and in some cases this is necessary even if just for a short period, it’s not a sustainable solution: people will get stressed, burned out, and unhappy, making bad decisions and delivering bad work. After a while, the product will get bad and your churn will get high.
To overwork may be a solution in some cases or during certain short periods, but it’s one that’s clearly overused.
Add more people
After overworking, the second most overused reaction when confronted to tight deadlines is: adding more people. Again, this can in certain situations be a good solution, but more often than not, and as it’s mentioned over and over on the “Mythical Man Month”:
“Adding human resources to a late software project makes it later” — Fred Brooke, Mythical Man Month
There are alternatives though. Alternatives which are often forgotten, and that should be on top of the list instead: Cutting Scope and the use of Soft Deadlines for experimentation and discovery work.
I believe these are not our natural reactions when confronted to tight deadlines because they require making hard decisions and require hard long discussions to achieve. But in the long term, they are often better.
Cut Scope
If you can’t do it all inside your timeline, you need to pick what’s actually important. Yes, you and every stakeholder will think that what’s important it’s already on the list: “we already have the minimum set of features defined — we can’t go lower”.
This happens to me every single time. But I’m also always surprised that, when faced with the right constraints, we can be very creative in figuring out what features to cut, or finding alternative ways to achieve the same goal.
A simple example is that, in one project, instead of creating an automated system to export User Data (to comply with GDPR), we changed the scope to create a button that simply triggered a pre-filled email that the User could send to ask for their data. A Developer would then export manually and send it back. A much simpler and smaller task that achieved the same business goal.
Soft Deadlines for experimentation and discovery work
This is my new favorite trick in the book.
Hard deadlines make sense when, we not only know the problems that we are trying to solve, but we also have a validated solution.
Hard deadlines make sense when, we not only know the problems that we are trying to solve, but we also have a validated solution: we went through some sort of Discovery to evaluate its value, feasibility, usability, etc, and also have a good idea of the time it will take to implement. We are more confident of our solution and estimate.
But in that list of hard deadlines we frequently include work that, even though it’s important to be materialised sooner or later, we are not sure exactly how it will be built, if it’s worth it, if it’s possible, and are not confident of much time it may take to implement. This is work that hasn’t passed yet through a Discovery of some kind.
Or, we set hard deadlines for work that needs exploration and experimentation: depending on your business goals, that may be a design revamp of the app, or the improvement of conversion rates for example.
When we do this we are putting the team under an unnecessary stressful deadline, while committing ourselves to deliver some sort of solution, regardless of its results.
For these cases, we should aim towards soft deadlines instead — deadlines where we evaluate our research and proposed solution so far, and decide if: it’s worth pursuing, if needs more discovery or experimentation, or if it should be stopped.
This gives freedom, empowerment and time to teams to explore the best and most creative solutions that actually solve the problem at hand, while having the guidance to achieve our goals inside a rough timeframe.
—
If you enjoyed the read, please click the clap button to show your appreciation!
