Hey Saeed,
Thanks for spending your time reading, considering, and writing such a detailed response! Building products is a nuanced beast and it’s always fun to dig into the details — I appreciate you giving me an excuse to elaborate!
I’ll try to talk through your points one a time.
1.
Your observation about using a situation-appropriate release cadence is a good one and in many ways, I agree. Amazon’s users may be able to absorb a few dozen releases per second but that pace of change might crush an enterprise Salesforce org. Delaying a release for business reasons can make sense but only if it doesn’t delay validation too.
Even though Salesforce and Intuit may accrue changes and bundle them under a “2018 Release” banner, I guarantee they’re “releasing” early adopter and beta builds constantly. Those releases give them the “in the wild” feedback they need to ensure they’re on the right track. That feedback is what resets the risk counter, not the release itself. If a company decides to delay an official release for business reasons while still collecting release-quality feedback then no problem.
2.
Shipping regularly doesn’t prevent bugs, that’s very true. Only good dev practices can do that. What it does do is keep the bugs that slip through small and manageable. Bugs are much easier to track down and fix when the release that introduced them only changed one thing vs. one hundred things.
3.
Priority changes aren’t something to solve or avoid. In fact, they’re usually great news! After all, they usually signal that you’ve learned something new and are moving to a path with better odds of success.
The part of that sentence to focus on isn’t the priorities changing bit, it’s the part about the waste that happens as a result. Teams (correctly) shelve partially finished work when priorities shift. By shipping often you keep the amount of work in progress small. By keeping WIP small you limit waste.
Tossing out work you’ve spent a day on is a lot more palatable than tossing out work you started last year.
4.
I think every product manager has worked on a feature that looked great in testing but fell flat in production. Of course it’s better to learn that in discovery and validation but sometimes the data can be deceptive. If you have to learn your idea is a dud the hard way, shipping (and abandoning ship) quickly is a much better option than investing a bunch of time on a feature bet that won’t pay off.
Thanks again for your comments!
Michael
