In keeping with my theme this week of blogging observations, this one ties together a basic tenet that I learned from science fiction in my pre-teen years, and applies it to product management.

The concept is borrowed from “The End of Eternity“, one of the classic science fiction novels from Isaac Asimov.  The book imagines a future with time travel, and the guidelines that govern its use:

There is a group of people (only males) who are called The Eternals. They live outside of ordinary time and space in a man-made construct called Eternity. The Eternals can move back and forth between Eternity and Earth, entering into any time period of Earth’s history. Their mission is to make Reality Changes, changes in the course of human history that will result in an improved Reality. They try to do this with the help of computers that can predict how even subtle changes will alter Reality. There is an art to finding the minimal intervention that will result in a desired Reality Change. There is a special change called “The Minimum Necessary Change“.

I’ve been surprised over the years how often I find myself using this concept, the “minimum necessary change”, to help frame potential solutions to problems.

In some ways, it’s a fairly obvious outcome of a scientific education.  Occam’s razor demands that, all things being equal, we bias towards the simplest explanation.  It’s not a far stretch to morph that concept into a bias towards the simplest solution to a given problem.

Seasoned product managers are also familiar with another, related concept, the “minimally viable product”.  The MVP, of course, is the minimal number of features necessary for a product to be successful at achieving it’s business & product goals.

Today, at LinkedIn, I was in a fairly intense meeting discussing potential solutions for a product that we’re trying to roll out in the next few weeks.  A fairly significant issue has arisen, and the team has been debating solutions.

It’s very easy for product managers and engineers to sometimes get caught up in “redesign fever”.  An unexpected issue or constraint arises that wasn’t expected.  Immediately, smart people will retrace their steps back to the beginning, and imagine a radical new design for their product that incorporates that new issue.  The problem is, there are always new issues.  There are always unexpected constraints.  Redesign fever can and will prevent products from converging, and prevent teams from shipping.

I’ve found that the best way to resolve these types of issues is to clearly define the problem, brainstorm potential solutions, and then way the pros/cons of each.  Not rocket science.

However, make sure as part of the exercise that the “Minimum Necessary Change” is one of the solutions that is part of the decision set.  It helps frame the costs (and benefits) of more elaborate solutions.  In fact, the intellectual pleasure of finding a simple, elegant solution to a complex problem can turn into a highlight for the entire project.

If you believe in fast iteration, in shipping product quickly and frequently to incorporate real user feedback into your designs, then more often than not you’ll find that the Minimum Necessary Change is your friend.