Deadlines are always a sensitive topic at startups: if managed properly, deadlines can be a real asset, rallying everyone around a common goal and force the teams to focus, but if they are not carefully handled and they are just somewhat random dates, then they become this thing that everybody has on their mind but nobody really takes seriously until it is too late.
The following caricature might ring a bell:
Executives identify a business objective, setup a date in three month for a release and then ask the product development team what they think about it. The team comes back by saying that they might be able to do it but it is a bit early to say because there are many unknowns. The executives hear "oh yeah we can do it" while the team was actually saying "we have no clear idea about the scope so there is no way we can commit to anything". The project starts on a misunderstanding and these deadlines are completely forgotten until someone from Marketing starts working on how they should talk about the new release.
This is when people discover that there are different opinions about what should be out and when: Executives expect most of the value to be there from day 1 while the product team tries to think about what an MVP should be knowing that the engineering team is not even sure that they can release anything on the date previously mentioned. Add on top of this that some of the things that are already built are either nice to have or badly done and you start getting in the deadline shit-show. This usually ends up with a first MVP delivered a couple of weeks after the original planned date and the next few months spent on finishing the original scope (or the original scope being totally abandoned so that the team can focus on the next big thing).
That does not sound ideal. The good news is that it does not have to be like this. Here are some of the things that I have learned by shipping releases late for many years. From product to engineering and marketing leadership, hopefully, these few pieces of advice can help to get better alignments around deadlines.
Setting up deadlines that make sense for everyone
First thing first, it is key that everyone working on the project understands why a specific deadline matters. If executives want something to be done by a certain date, they need to pitch the whole team and explain them why it is key to stick to that date. The reason can be external or internal but there needs to be a crisp answer to the question: "what happens if we don't meet the deadline". Once everybody has a common understanding about the deadline, then you can start having the tough conversation about how to make it happen.
Having a scope as clear as possible
There are three components that you can play with when thinking about product development: Quality, scope, and date. Since here we are trying to work with a fixed date, then you need to start setting up expectations about the release and make sure that everybody is onboard with it. This includes going into details about what should be there, what should not be, what should work 99% of the time and what can be a little bit less robust. Don't forget that the world does not end after the release and that you can optimise things later. It can sometimes be ok to go with an educated guess to start with if you don't have time for proper testing. After this is done, you should not have anyone come back and say "oh but I thought there was X included in the release".
Focusing on what's important right from scratch
In an ideal world, your scope would be split in two different prioritized buckets : "Must have" and "Nice to have". There is a big redline separating the two buckets and nobody should start working on anything below the redline before every above is completed. Reality never being that easy, you might end up in situations when teams are blocked on must have and then "nice to have" are used as fillers in sprints. This might be fine but it is key to never forget that "nice to have" come after and that when there is a blocker on a must have, the priority is to remove it, not switching to something less important.
By the way, scope and prioritisation discussion should not be limited to features, the engineering team also needs to have the hard talk about how "clean" things will be done and what refactor can be afforded. Same on the product front, if you want to take this opportunity to improve small UX things, you need to make sure that they appear on the "nice to have" list somewhere.
Thinking about it as a company effort
One of common mistakes I have seen is taking only product development time into account when thinking about a deadlines. Messaging, marketings assets, website contents, operations (including user support training) are key to a good release and are not small pieces of work that can be added at the end of the project. They usually require the involvement of the product development team too so they need to be accounted for as soon as possible.
Having clearly identified whips and project leaders
Project managers are usually not the most famous functions in the company but having someone in charge of making sure that everybody stays on top of everything is key to the success of a project. A good whip can be anyone as long as they are well organised and are ok asking 100 times "hey, what's the status update on this". Depending on the size of the release, I would recommend having one person managing the overall project and focal points for each functions. If anybody has a product question, they should not have to ask three different persons. Of course these roles don't have to be full time. The most important is that it is clear for everyone who these people are.
Creating intermediary milestones
Nothing new here, but for any big project, it is key to have different milestones identified, whether this is a feature finalised first or an internal/beta release, the commitment to these dates are as important as the final one and everybody needs to understand that. This is very rare to see people "catching up" at the end so if things are already shifting on intermediary milestone, this is a good indicator that something needs to change. These milestones are also very important because being mini-deadlines themselves, they are a great way for teams to run the extra mile when necessary. It is probably better to have to work harder a couple of times a months rather having to be in rush mode for the whole last months (knowing that this will probably happen anyway).
Keeping some slack
Something bad is going to come up at some point so to release on a firm date, it is good to plan on having everything finished a couple of weeks before D day. When working with Apple, this is a good practice to submit apps three weeks in advance to get a chance of being featured and if it's not possible, this might be the time used to still be able to release on time. If everything goes according to plan (this never happens but let's assume it does), the remaining time can still be used to work on quality (I would not recommend rushing down the nice to have list during the last few days because this can introduce instabilities on the rest).
I guess that's it. Deadlines are not the end goal, but they can force teams to get better organised and take a step back to think about what matters. I would not recommend any team to work without deadlines.
One last thing, all this organisation requires a lot of preparatory work so it is good to save some time in order to build that plan. Dedicating a sprint after a release to plan for the next thing while finishing some polishing is generally good for team morale and efficiency. Anyway, have fun and feel free to share other tips if you have some.
