How to approach changes in software

Arguably one of the most difficult things we do as software developers at my company, Hannon Hill, is to change existing functionality in our products. You’ve got an awesome customer base to whom you’ve pledged your undying loyalty. Every once in a while, you’re going to pull the rug out from under them by changing some piece of functionality that they rely on. It’s remarkable how much of our time we spend debating, making and ultimately supporting these kinds of changes in our products. But you should spend a lot of time wrestling with these decisions.

Here are a few guidelines and reminders when changing existing functionality in software (though this could probably apply to any type of business that sells a product or service):

  • Will the changes make life better for at least one of your internal stakeholders — support, engineering, sales, marketing, services? Will it reduce the number of support requests? Will it make the product easier to maintain? Easier to sell?
  • Will they help 80% of your current customer base? Of course, it should also make things better for future customers (that’s presumably why you’re changing it), but don’t forget the people that got you to where you are.
  • Will they negatively impact less than 5% of your current customers? SaaS makes this much easier to assess and conversely, installed software makes it very difficult. Have a rough plan of action of how you intend to address any problems that arise as a result of the change.
  • Communicate. Make sure you let people know what you change — in your product release notes, in personal emails to customers, on Twitter, wherever you can! Be prepared to justify your decision. We usually have good reasons for changing things. Our customers are smart and it’s up to us to convince them that a change is for the better.
  • Not everyone will be happy. This is a fact of life and a fact of software too. Despite your best intentions and efforts to accommodate your customers, there will always be vocal detractors whenever anything changes. This is one of the toughest aspects of product management especially when you know many of your customers by name. Remember that very few changes to software can truly benefit all of your users. Be willing to talk openly about your decision, try not to lose too much sleep, and stay positive!

Software developers: how does your organization approach changes to its software? Software users: what could do better when making changes to software that you use?