Muscle memory leads to software failure
I have a premise that software development often fails due to Muscle Memory.
- Late to market
- Over budget
- Poor communication and collaboration
- Scope kept chaining throughout development
- Doesn’t solve the right problem
- Doesn’t solve any problem at all
- Negative customer sentiment
- Sloppy code
- Or, like last year’s Healthcare.gov launch, it doesn’t work at all
Believing that the digital explosion we are living in globally is driving business transformation at unprecedented levels, I do think that muscle memory should be in the list of reasons why software product development fails. Hang with me for a few minutes here as I draw the corollary.
Through learning how to do something (anything) and repeatedly doing what we’ve learned, we create muscle memory. Repetition has long been used in athletics to hone skill and technique to the point that the muscle memory becomes so strong the technique is near automatic. Take golf for example, I took lessons to learn a swing. I then did what my instructor insisted I do to get the most out of my lessons investment and hit bucket after bucket of balls – doing the reps – to train my muscles. And, finally just when I thought my arms would fall off my shoulders, the pro deemed me ready for the golf course and I have been playing with that automatic swing ever since.
What does golf and muscle memory have to do with software development failure? Read on….
Now, nearly three decades later I’d like to improve my game beyond where it has plateaued and be able to at least hang closer to my two sons who play for their high school. I struggle to want to make the investment and commitment to learning a new way, because the new pro says that he will have to “reconstruct my swing.” I will have to commit to unlearning everything I thought I knew about golf, learn a whole new technique that will feel completely uncomfortable and unnatural and then I’ll have to put in months of hitting more buckets of balls than I did when I first learned to play the game. And, if I don’t commit to the full transformation and only get partially there, I won’t be able to remotely play again at the level I am currently at. WOW, what a commitment and huge risk to a mere hobby! However, if I want to shave 6-7 strokes off my game, I have to make the commitment to change my mindset, swing technique and put in the reps to get back to an automatic level that supports my achieving a better outcome in my golf game.
Whether it be golf, basketball, leadership or technology, we learn to do and improve through repetition. That repetition starts to become a strength. That strength becomes a conduit for success. Success lasts, for a while. And then —— the game changes. The tools, techniques and mindset become dated. The muscle memory that drove our prior success begins to become our biggest inhibitor to regaining or sustaining success. The muscle memory that once made us great turns on us!
The same principles of muscle memory apply in software product development. However, unlike my ailing golf game where only my ego suffers when I fail to play well, the stakes are much higher in software. In software, if we let our muscle memory drive our future, we could lead ourselves into software failures of epic proportion. In software development, its not about getting better at a hobby, it is about delivering business outcomes.
You see the digital explosion necessitates that we not only serve our clients in new innovative and digital ways to drive customer loyalty and deliver revenue growth in our businesses, but we also have to do it yesterday. Software products don’t fail because we didn’t have well defined solution requirements. They fail because of our Mindset. We have learned over the three decades that I have been playing golf how to define and deliver technology based solutions. Out of IT has emerged great muscle memory on how to “do” technology. That Mindset, simply is a bad swing in the digital era. I believe we have to learn a new swing, a new mindset to avoid failures in software product development. That mindset is a Product Mindset. We have to think Product, not Project!
A Product Mindset prioritizes:
Success Metrics vs Scope
User Adoption vs Stress Testing
Revenue Generation vs Budget
Continuous Innovation vs Done
Note that the left side of the above table are business outputs and the right side are process inputs. hmmm!
A Product Mindset embraces the reality that innovation is never done. Innovation is indeed continuous and never ending in this digital explosion we live in. Software will never again be “done.”
With a Product Mindset you avoid failure altogether by releasing software early and often. A Product vs. Project approach allows for 1) optimized user feedback, and 2) immediate and continued adoption, which should ultimately lead to self funding the ongoing product development. A Product Mindset assures you hit the business outcomes needed to propel your business forward.
In my next posts, I will explore the Product Mindset, Outputs vs. Inputs and the notion of Continuous Innovation.
I’d love to hear your thoughts on software development failures? Do you have any experiences that align to my belief in Product not Project? What has driven your software success or failures?