The maintenance factor, Entropy
Understanding the Theory of entropy is crucial in Product Management. Each feature we introduce carries a maintenance factor; the more intricate the feature, the higher the maintenance factor.
A couple of years ago, I wrote about the challenges of maintaining things over time and how having more stuff means having more to keep track of and care for. This maintenance factor, as I call it, applies not only to our personal lives but especially to the products and companies we build. I've since learned this is also known as the Theory of Entropy.
The Theory of Entropy
I'm no Bill Nye, but science guys smarter than me say that the Theory of Entropy concludes that every system in the universe will naturally be found either in the state of maximum disorder or moving toward it.
This concept is not just a scientific theory but a practical reality. Have you ever managed a product that was in maintenance mode with no active development? It's like a never-ending game of whack-a-mole. Something always seems to break, and you're constantly working to keep it running, even if it's just because the environment around it keeps changing.
As Peter Drucker (author and management consultant) says, "Entropy is a measure of disorder, and it is based on probabilities and possible combinations in a given system. It also states that to return a system to its original state, it takes more energy than that which was required for disorder to happen."
How this applies to Product Management
Understanding the Theory of entropy is crucial in Product Management. Each feature we introduce carries a maintenance factor; the more intricate the feature, the higher the maintenance factor.
As part of our prioritization and planning process, we can also examine future work through the lens of Entropy. Sometimes, we capture this as complexity, but it can go beyond that. It's hard to consider all the possible angles and think far into the future, but considering possible conflicts now is extremely useful.
Avoid adding unnecessary complexities to what you're building. Keep it simple.
An analog comparison
Early last year, I bought a new car. Well, it's not a new car; it's a 1968 MGB GT (for those interested), but it's new to me. Compared to modern vehicles, it's straightforward and easy to work on. There's very little to go wrong with it. The engine is so simple; look at all that room under the hood! You could store your luggage between the radiator and the front grill.
Compare that to a new vehicle, a modern machine with many amenities. A failing sensor on a newer car can render the thing useless. I can carry a small toolbox with me in my classic and fix all but a few things on the side of the road.
Things you can do to fight Entropy
The science is clear: it takes a lot of energy to stay organized and avoid the decay that is Entropy. There are a lot of things you can do to help maintain that order; here are a few things to look at:
Automated testing
Keep things modular
Remove features no longer being used
Simplify price plans
Regular process reviews
Avoid customizations
Address technical debt
Refactor of legacy code
Maintain good documentation
Clear product direction and purpose
Have a good understanding of who your customers are (and aren't)
Don't hardwire 3rd party integrations into your product
Develop iteratively
Avoiding Entropy is an uphill battle. In Product Management, this can manifest as increasing code complexity, accumulating technical debt, feature bloat, no longer effective processes, or diminishing returns on new features. Constant effort and vigilance are required to maintain order, improve systems, and ensure that products effectively meet user needs.
How do you maintain order as a Product Manager?
For a different and more personal angle on maintaining things, read one of my first posts from a couple of years ago, which I mentioned in the intro.
