This my friends, is where the action happens. Not a big fan of military metaphors since I don’t have any idea what I’m talking about, but there’s one called no plan survives engagement with the enemy, or thereabouts. Writing this post caused me to look it up and evidently it’s a prussian quote, so it’s been around awhile, seen any prussians lately?
I digress. Bottom line though, whatever you thought you were going to launch with, this is not it. It may share a little or a lot with what you planned. The size of the drift is lessened or heightened by the skill of your implementation team, crossed with the clarity of everyone involved, and the feasibility of the timeline.
Short timeline, you’re cutting scope if you’re smart, nothing else to do.
Team not performing, if you realize it early enough maybe you can change something about the implementation team, otherwise cut scope or wait. And maybe wait forever, perhaps it’s was never possible.
Built the wrong thing, oops. That is on you, leader. This is potentially the worst of the three, you basically lose morale no matter what from here on. You need to now get clarity and explain to the team where it went wrong and what you were really looking for. Hopefully you’re not in this place.
Assuming you’re getting close to launch, and you’re committed to cutting some scope, the question is what. It’s pretty simple, anything that would cause the product to not work, that’s gotta stay. Every other feature, nice to have, design consideration, thing that causes support issues, all are in play.
When is it done? I always say done is a state of mind. More precisely done is when you’re ready to allow somebody outside to the development team to use it. Perhaps there is an executive demo, a group of beta testers, a “bug bash”, and a wide release. This should be encapsulated in an artifact known as a “Launch Plan” which should have dates, actions, and owners on it.
Each of those aforementioned stages could take some amount of time, you might find breaking bugs that simply cause the product to “not work”. Maybe you’ll find some you think, I could live with. Maybe there’s something that will schedule a bug in the future. Monthlong subscriptions looking at you. It’s probably controversial, but I’d make a tradeoff to get the product in the hands of users fully knowing you have a hard deadline to fix some behavior. It’s a known issue and these tend to be easier to fix because once you ship.
Shipping fixes all! Ok that’s an overstatement, but shipping fixes a lot, I compare shipping to an overinflated balloon which represents pressure. Shipping pops that balloon or at least unties the knot which held the fill tube closed allowing for the pressure to release gradually. Let’s explore that in the next section. – Post MVP