Measure at Great Cost
Apple is notorious for being a “measure twice, cut once” kind of company. It works for them.
On the other hand, Google is more “launch and iterate” in their approach, which works for them.
When you implement Subscription-based software, you have a choice about which approach works for you. Therefore, it’s worth a moment to think about which style best represents your organization.
You can implement the software as Apple would. You can do a comprehensive discovery, modify, test, modify, and release.
Or you can implement it like Google. You can do enough discovery, test, and release. And then do it all over again.
There are reasons for either approach and some constraints.
When it comes to the quickest time to receive value for your Subscription-based software, it’s hard to find fault with Google’s approach.
When it comes to Apple’s historically strong quality-centric delivery, it’s hard to argue against the “measure twice, cut once” approach. This scenario works well for product releases or even some custom code creation projects.
However, when you buy a Subscription software, your default state should be: I want value now because I’m paying for the subscription now. Therefore, you should always lean towards the Google Approach of “launch and iterate,” as that is more in line with the product you purchased.
Also, advocating for the “measure twice, cut once” approach tends to obscure the real issue. When customers advocate for this approach with a Subscription software purchase, this indicates two issues: 1) The last time they implemented Software – Agile wasn’t a thing, or 2) Fear. The use of Apple to support this method is deceiving. The difference here is that deadlines for Apple are real. If they weren’t, Apple would not exist. There is pressure for Apple to complete. In contrast, customers that “require” the Apple method usually do not have an absolute deadline. With no deadline, “measure twice, cut once” is an active decision to give into the fear and let that take the lead.
As the model for software delivery has changed over time – so too has the best way of implementing it. So embrace an Iterative approach and Overcome your fear – it’s what SAAS was built for.
Supporting Music
Originally published February 4, 2018