You can have a date or a scope, but you can't have both!

I was recently talking product with a PM at a local startup, and casually mentioned something I've said a LOT over the years.

"When it comes to product development, you can have a date or you can have a scope, but you can't have both!"

Ok great, but what does that really mean? Since I hadn't said it in a while, it got me thinking about why I've had to say it so many times in my career and what it really means. If you've lead product development teams before, you've almost certainly had this fight with stakeholders. We want this ridiculously large and complex scope, and need it by (pick your unrealistic date). Oh, and we're gonna add a ton of scope creep along the way.

Apologies for the PTSD ;)

This is so anti-Agile and against all good product management principles that every time I experienced it over the years I wanted to quit and become a beet farmer!

But as you can see, I'm still fighting the good fight, with no fresh beets in sight...

Look, I get it. You can't run a business by saying "you'll get it when you get it." But if you want a 100 page MRD, PRD, TRD, or anything ending in RD with that many pages, I will tell you its a waste of time, you'll still miss your date, and you should probably go back to 1995 and do waterfall.

Agile doesn't require big requirements docs for a reason. They're a waste of time and always wrong. Keep it lightweight and iterative, and you'll outdo the bloated overdone process every time.

BUT, (of course there's a but) you can't ask for everything and have it in an unrealistic timeline. It doesn't work that way, no matter how good the team or process.

You can have a date or you can have a scope, you can't have both! I'm not saying there aren't crappy teams out there that don't know what they're doing and miss dates or scope out of incompetence. Of course there are! But even the best teams can't deliver both, unless you have a mature process, the right people, the right expectations, and a reasonable timeline.

One of the things the best teams I've lead over the years have done REALLY well is estimating. Estimation is critically important in Agile, and when you do it right/well, you can get much closer to delivering both date and scope. Another important tenet of Agile is iterative development. Not only will your some of your estimates be wrong throughout the development phase, but so will your assumptions about users, the problems your solving, the solution, etc. The right thing to do in these cases is to refine and improve your requirements. This may push the delivery date out, but for the right reasons! Agile + Continuous Discovery and great product management lead to products that solve customer problems and reach product-market fit.

So I ask, do you want the date at all costs, or do you want a great outcome? The right process will provide incrementally deliveries, leading to the right outcome.

Because you can have a date or you can have a scope, but you can't have both! :)