Their Problems Should Be Our Problems

By Tamara Wilhite
An IE in IT

The book “How to Become a Rainmaker” is geared toward salespeople but applies to businesspeople and businesses as a whole. The book says that customers buy for only two reasons: to feel good or to solve a problem.  IT teams too often forget that fact.

Software rarely helps people feel good, unless it is a game. In that regard, games like Candy Crush manage to make a lot of money and many people happy. For everyone else in IT, software changes must solve a problem to be worthwhile. The problem many IT managers, programmers and developers face is aligning their solutions with the customers problems.

Before planning any software changes, upgrades, updates or whatever term you’d like to apply to the process of altering your application, ensure that the answer to at least one of these questions is a resounding “Yes!” before you go forward.

1. Does this change solve a user problem?

While reviewing the facts, verify that the problem it fixes applies to enough people that making one customer happy doesn’t annoy many others with the downtime or lost productivity of installing a new version.

2. Does it fix something we ourselves broke?

These software changes should take priority, in order to restore the company’s reputation.

3. Have we verified that this update or change is what the customers want?

Too many software changes are implemented because someone in engineering or IT considers it cool, cutting edge or the next big thing. However, it may not be what the customers want.

4. Does this change or improve an attribute customers consider critical?

A software change to improve IT security doesn’t need customer approval – we already know that no one wants to lose their credit card information or have personal information leaked.
Software changes that improve system uptime can be assumed to meet customer needs if reliability and uptime are critical to the customer base.
Software changes to stay in compliance with ISO, CMMI or another standards organization standard that customers want or need to achieve are worthwhile.

5. Have we verified that our change isn’t going to create problems?

There is a joke that all that matters in real estate is: location, location, location. In IT, we need to have the adage “test it, test it, test it”. All software changes need to be thoroughly tested for all environments and operating conditions, user types and transactions. Verify that the new functionality works – and that it doesn’t break anything else. And never remove functionality in order to add new features without verifying with the customers that they don’t need the old functions. After all, it was there for a reason.


In IT, it is essential that the problems we choose to solve are the ones that matter most to our customers, not the system administrators or techies that dominate the software development group. Focus on what matters to the end users, not the performance metrics or high tech projects that look best on someone’s resume.