Pruning, or the selective removal of specific branches or stems, is an important maintenance practice that helps to keep your trees healthy for many years to come. Important reasons to prune mature trees include controlling size, providing clearance for foot traffic or vehicles, removing potentially hazardous branches, and improving appearance.
I’ve noticed a concerning trait among product teams I’ve been a part of. That is, there’s a goal to “grow a tree” (i.e., create or improve a product) without taking the time to systematically re-evaluate the heath of the product and prune unhealthy or unhelpful capabilities. These teams continuously build upon a minimal viable product (MVP) so that the product meets the broader needs and goals of its customers (or the business).
To use another metaphor, we might start by building a rowboat, and that gets our customers from point A to point B, but it’s not good enough. Perhaps it’s too slow, so we build a speedboat. But that cannot carry enough customers at one time. So bit by bit we grow our boat until it becomes a cruise liner. This cruise liner has every amenity known to humankind. Music. Food. Activities. Wifi. Window views. But have you checked to see how long it takes for a rowboat or speedboat to change course compared to a cruise liner? We learned just how nimble a container ship can be.
I have a colleague who works in the real estate investing space. He purchases distressed homes at a discount, often from homeowners who have neglected to care for them and upkeep them. Some homes were filled from floor to ceiling by hoarders who refused to purge. Other homes were a Frankenstein-assembly of antiquated and garish upgrades and adornments, fitted on top of previous design decisions. Although my colleague wisely buys homes at a deep discount, he knows the secret sauce for making a profit on his fix and flips: Strip the home of anything unnecessary, start with a good set of bones (and foundation), simplify the design, and modernize the fixtures.
Reasons Businesses Do Not Prune
As professionals who deploy products and services for our customers, how often do we stop and make decisions to prune or simplify? Is the deck stacked against this behavior? A few observations may shed some light on this phenomenon:
- It’s not how we’re wired — According to a recent Nature article, the authors observed that “people are more likely to consider solutions that add features than solutions that remove them, even when removing features is more efficient.”
- It discourages job security — Removing features and capabilities means more people will be upset, and upset customers could threaten my ability to work, right?
- It’s not how we’re accustomed to working — Developers develop. The creativity is in building code, not destroying it. Removing features might increase technical debt, and technical debt is seen as detrimental to the success of a product development initiative. Further, what would product demos look like when pruning means teams have less to show?
- It’s not incentivized — When was the last time you read product release notes that reflected reduction instead of expansion? When do you hear the Steve Jobs of the world host an annual conference boasting of removing or simplifying capabilities? We reward progress. We reward creation.
How Might We Become Pruners?
So, how do we change business behavior to value pruning? I offer a few suggestions, including:
- Measure the Customer Experience — Create recurring customer feedback loops that map to customer experience touch points. It might mean tracking the number of subscribers and looking for changes after features are released. It may mean collecting satisfaction data about a recently released feature. It could mean tracking usability data such as task completion rates or time to complete a task. You cannot prune your tree if you are not actively monitoring its health.
- Build it into Project Plans — Whether you follow agile or waterfall approaches to development, there should be triggers or milestones where teams can pause, review, and make decisions about what aspects of the product should be simplified. For those who follow agile approaches to development, this reflection activity could occur during the innovation and planning sprint. Or maybe Product Owners could create “simplification” as its own feature, giving teams planned focus on reviewing the product for opportunities to simplify.
- Potential Future Enhancements — Did you know that the act of reduction could be considered an enhancement? Many teams add specific types of stories to their backlog, including targeted work for testing or technical debt. Why not add an “enhancements” story type in the backlog that consistently provides focus for teams to simplify so they can begin to see reduction as its own type of development activity?
A simplification mindset is hard to adopt. As indicated in the Nature article, perhaps it’s not our first instinct. Perhaps it’s not behaviorally reinforced. But I remember a time when I was really young being invited to a home that was planned to be bulldozed in order to build a new home. We were given all sorts of tools to choose from for destroying the home, including hammers and pickaxes and told to “have at it” — destroy anything you want. What freedom there was when simply being given permission to destroy, to simplify!
Washington Seattle GIF - Find & Share on GIPHY
Discover & share this Washington GIF with everyone you know. GIPHY is how you search, share, discover, and create GIFs.
Have you ever seen those videos where a building is loaded with TNT and after a moment, the building falls to the ground? It is fun and satisfying to watch, isn’t it? So how can product teams channel that same feeling, not as a destructive tendency, but as a way to elevate the value that subtraction is just as valuable as addition? I encourage you to add Subtract: The Untapped Science of Less to your reading list, as will I.