If It Ain’t Broke…
Building software requires a delicate balance
Stephen Balzac, President, 7 Steps Ahead
There are a great many ways to complete the phrase, “If it ain’t broke…” The classic, of course, is “don’t fix it,” but I’ve found that “then it doesn’t have enough features,” is also pretty popular. While some other popular endings include “then you haven’t hit it hard enough,” “clearly it’s unbreakable,” and “don’t upgrade it,” for the most part, they’re variations of the first two.
The original phrase, and several of the alternatives, conveys the wisdom that once a piece of software is working correctly, you shouldn’t mess with it. That’s a nice, but surprisingly dangerous, sentiment. Just because something works today doesn’t mean that it will work tomorrow. Conditions change, what people want to do with the software changes, new and better ways of doing things are developed, and so forth. Even under the best of conditions, just because it “ain’t broke” today, doesn’t mean it won’t be broken tomorrow.
Paradoxically, the other extreme of “then it doesn’t have enough features,” is also a pretty risky proposition. Constantly building upon and expanding a product until it collapses under its own weight is not a particularly useful strategy either. Bloatware is an experience shared by all users of certain PC operating systems. Whereas the first scenario represents a refusal to innovate, the second can easily become innovation for the sake of innovation. As Mike Csikszentmihalyi points out in his book, Creativity, an idea is not creative if people don’t see it as creative. By extension, a feature is an innovation only if enough people think it is one. Otherwise, it’s an irritation.
So if not changing a working system is bad, and too much change is bad, what’s the alternative? It takes no great brilliance to realize that the answer lies somewhere in the middle. That’s the easy, and obvious, part. Figuring out where that middle ground is, now that’s the hard part! The bad news is that the middle ground isn’t a very precise location. Finding that exact, perfect spot in the middle is incredibly expensive in terms of time and energy. The good news is that the middle ground isn’t a very precise location. A relatively minor investment of time and energy to land somewhere in the general area of the middle can yield some very outsized rewards. The goal is not perfection but improvement. Far too many companies become stuck on the former when they should be focusing on the latter.
The first step toward improving software is to ask the customer what they want. Unfortunately, what I’ve observed is that most people also make this the last step. Seems logical, right? Who else would know what they want other than the customer? Unfortunately, as more than one company has discovered to their sorrow, what the customer says they want and what they really want are often two very different things.
When the customer says they want something, what they are really doing is telling you about a problem they are facing and giving you the solution they imagine will solve that problem. What you do not know is the actual problem, nor do you know if the customer’s solution will actually solve that problem in the context of your product. Some years ago, I worked with one bioinformatics company that was building software to help bench scientists. Based on a couple of comments made by one researcher, the engineering team became enamored of building a “protocol editor,” a tool to edit experiment protocols. Design was well under way when I finally prevailed on the head of engineering to let me take a day and visit a nearby biology lab. It did not take very long to discover that a “protocol” was the equivalent of a cake recipe, only with considerably less pleasant smelling results. The scientists didn’t need a fancy editor. Any text editor was sufficient. What they really needed was a way to manage the protocols and keep track of which ones were built on top of others, and so forth. In other words, they needed a database.
The oft overlooked step, in the words of MIT’s Ed Schein, is to assess your ignorance. Take the time to identify what you do not know and then figure out how to obtain that information. There are several questions you might ask your customer to help you here:
• What problems are you trying to solve right now?
• What problems do you imagine this feature would allow you to solve?
• How do you envision using this feature?
• Please tell us more about what you’re trying to accomplish?
Be patient and explore the problems with your customers. Once you better understand their problems, then you can set up brainstorming meetings with them. Very few things make a customer feel important and build loyalty to your company like inviting them to contribute to brainstorming sessions about the next release of a product. When you’re done, the odds are far greater that you’ll actually have something that your customers see as providing value as opposed to just being some expensive bells and whistles. So long as you can continue innovating and providing value, your product will continue to not be “broke.”
If it ain’t broke, what are you doing to keep it that way?
Stephen Balzac is a consultant and professional speaker. He is president of 7 Steps Ahead (http://www.7stepsahead.com), an organizational development firm focused on helping businesses to increase revenue and build their client base. Contact him at 978-298-5189 or .