Start with the end (date)

This might be a controversial take, but I firmly believe that for larger projects and features, tech and product teams should start by agreeing on a delivery date and then work backward to define the requirements. This approach contrasts with the more traditional method of first defining the scope and then setting a delivery date. Hold on—before you rush to the comments, hear me out.

Now firstly, I appreciate there is no universal road mapping solution for every scenario and team.  Let us focus on larger, more complex, probably multi-disciplinary and ultimately large impact on business projects.  Projects like rebuilding or migrating a platform, launching a new product line or completing a brand restructure.

My advice is for stakeholders to align on a realistic project end date, this does not mean cutting corners and risking the project.  But it does mean setting a date that does not hamstring the business, stuck in a project for too long.   Business priorities should ultimately drive this date, as right now, tech and product are not clear on the requirements.

Once a date is agreed then start filling that time with must have, non negotiable tasks and features. Force the “what is good enough” decision early, have the arguments with stakeholders from day one, not at the deadline when it’s too late.  Your absolutely must have tasks should be completable before the deadline with at least a 30% buffer.  Promise yourselves to try to add in those nice to haves, but also be clear that everyone agrees launching without them is good enough.

Now let me justify why…

It helps reduce scope creep

When a product or business team is tasked with spec’ing up front, they will almost never provide you with the minimum viable product.  They may try to, but the temptation to just add one more thing while you are there is way too big.   Remember at this stage tech has provided no estimates, so everything seems doable and reasonable.  When a then unacceptable timeline is proposed it is much harder to scale back requirements, because once someone has gone through the effort of recording and spec’ing, they are much more invested in the solution, and it appears much more important.  Rather avoid even engaging in the conversation about nice to haves until you know there is plenty of spare capacity, and I guarantee there isn’t.

It forces priorities to be put in context

When you start speccing with a blank sheet, everyone throws out many wonderful ideas.  Each on its own is a critical priority… who would say no to a feature an important client requested, or something the competition is doing.  But only when you start putting tasks in context of others do you actually see how important they really are.  

I like business stakeholders to rank tasks and features from most to least important.  Don’t use Critical, High, Low priorities, otherwise everything ends up Critical.  When you rank, it forces people to engage in the conversation of is this really more important than that.  Suddenly you will see a critical priority task is actually priority seventy two, and has fallen out of the scope of the initial project, because you know what… you don’t actually NEED it for a successful launch.  Having that realization is almost impossible when speccing up front and collecting all stakeholder input and ideas.

It is what teams already do, almost every day

This may seem counterintuitive and many tech teams will tell you they must work from the full spec up front.  But this isn’t how we run sprints, this isn’t how we run OKRs and isn’t how we run initiatives like innovation projects or hackathons.   In all those cases we have a set amount of time, be it 48 hours, 2 weeks, or 3 months and then we plan what is most important to fit into that time slot.  With practice a team can get really good at accurately estimating these time bound units of work.  So then why when it comes to big projects do we try to reverse the process?

Going live is not the end

I think the difference there is everyone knows there is another sprint after this one, or something can be scheduled for the next quarter.  But when it comes to big projects, we feel it must be “done” when we go live.  But this is the furthest from the truth, going live is where a project should begin, if you do not continue to work and iterate on it, then you are doomed to fail in the medium term.

It is not a comprise for less

It may seem like a good idea to only go live when everything is done.  But I would argue that that goes against the entire product development cycle.  Are we not supposed to release, learn and iterate?  In large projects, with huge scopes upfront we make a lot of assumptions because we have the opportunity to do so much.   Whereas focusing on the bare minimum, launching and iterating means that a year down the line you at worst have built the full spec anyway, but much more likely you have built something significantly better and learnt from the platform being live.

Estimates are always wrong

Let’s be generous and assume estimates are always out by 50%.   If you are wrong by 50% on a six month MVP the delay is manageable in months.  However when you are wrong by 50% on a two year full scope build, the resulting delay can be disastrous for the entire project if not the business.   Being stuck mid project means nothing else can move and much time and money is wasted from marketing, sales and operations preparing and delaying a launch.  The business ends in paralysis.  Sales cant increase prices but are also scared to bring on new customers when there is no project end in sight.  I would argue it is easier to deal with a limited feature set and continuous improvement cycle than try to promise customers something great is coming… eventually.

Clearer heads prevail

When arguing up front about how important a feature is, everyone is less stressed and still invested in the project’s success.  Smarter decisions will be made versus crunch time.  The project is already months late and business has had enough.  Now you have probably built a whole bunch of nice to haves but been avoiding that critical must have that was really tough or uninteresting.  Short cuts or justifications to avoid critical work will come to the table.

It’s not about going live earlier

It is about going live with the right things done.  When the bare minimum is clear and a deadline locked in, the team prioritizes better.  When conversations of delays or changes come up, at least you know you have been spending the time on the most important aspects already.   It is much better to have a conversation about “is what we have now good enough” rather than a case where vital tasks were not done while other parts of the spec were worked on first.  In the second scenario the answer is obviously no and the whole cycle of speccing starts again.  Versus a much more constructive conversation of, what do we need to do from here to get live and is that possible if we push out the deadline X amount.   While the project may end up taking the same amount of time in the end, the road to getting there is less stressful and progress reviews more meaningful. 

So why wouldn’t we

No solution is perfect for every team, and this approach introduces the real risk of prioritizing the deadline over the scope, that after all is the point.  If your deadline is too tight, inflexible to changing conditions and your teams do not understand what is truly required for launch.  Then you run the risk of crashing and burning at go live, something almost impossible to recover from.   Which is why teams prefer to play it safe, they spec the must haves, but also the need to haves, and even the nice to haves.   It feels good to know you haven’t missed anything.

The problem is that the opportunity cost of having everything up front is never appreciated until you are six months late on delivery.  So for your next big project, try to set a date and work out what would be possible by then.  Either you don’t know what is actually vital for launch, in which case you probably need to understand your business levers better.  Or everything will be vital and the date gets pushed out to accommodate the spec, but at least we understand everything in that spec is actually important and can revert to a more traditional road mapping methodology.