“Therefore, the best criterion for choosing what to keep and what to discard is whether keeping it will make you happy, whether it will bring you joy.”
― Marie Kondo
Marie Kondo changed my life. Her approach to purging my home of things that didn’t make me happy proved to be the most effective means of simplifying my life I’ve encountered. By focusing on feelings, she took all the doubt, stress, and guilt out of culling the contents of my closet, kitchen, electronics, and toiletries.
Minimalism or simplicity is not a new idea, but her contribution is to suggest that we use our feelings as the primary deciding factor, which in practice worked much better for me than other methods. The result is that I decluttered far more efficiently and effectively than ever before, eliminating over 75% of my possessions without worrying that I was making a mistake. It worked because the purpose of my things is to give me comfort and security and my feelings about a thing are an excellent reflection of its ability to provide those two things.
I wonder if the same principle could be applied to product design?
The Kanbanery ideas backlog contains hundreds of items, collected over years of brainstorming, competitive intelligence gathering (once we had competitors), and customer feedback. I wrote last week about how my attitudes toward customer feature requests have changed over the years. Some of the ideas come from competitors and are things that we won’t do on principle (see last week’s post on principle-driven design ). Requests from clients that have sat on the list for over five years have been passed over in hundreds of queue replenishment sessions for a reason. They serve the same function as that ugly sweater your mom bought you does in your closet, guilt. It’s time to admit to ourselves that we’ll never do it because we don’t want to.
“By facing your things, you’re facing yourself,” Marie Kondo says. “It will make you happy and everyone around you happy.” That’s an idea that fits wonderfully with my ideas about Principle-Driven Design. A team that culls a backlog together, faces their demons together and grows together. Together they can learn what makes them happy to come to work.
“The process of assessing how you feel about the things you own, identifying those that have fulfilled their purpose, expressing your gratitude, and bidding them farewell, is really about examining your inner self, a rite of passage to a new life.”
― Marie Kondo
Just as taking stock of our personal possessions and what they mean to us can help us to understand who we are now and how we see our future, applying those same techniques to a backlog as a team helps the team to better understand who they are now and where they see the product going in the future. The product vision they had in the past was valid, and useful. Even deciding not to do something teaches us something about ourselves and our values. It inspired us once, but parts of it no longer do. Let them go.
“But when we really delve into the reasons for why we can’t let something go, there are only two: an attachment to the past or a fear for the future.”
― Marie Kondo
Isn’t this so true of an old backlog? “It seemed like a good idea at the time, so it must have been.” or “But we might need this some day!” are two of the most common excuses for keeping old ideas in a bloated backlog.
“The space in which we live should be for the person we are becoming now, not for the person we were in the past.”
― Marie Kondo
We had a clear vision of where we wanted the product to go, but we’ve pivoted or we’ve learned through iterative releases and user feedback and research. Our vision has changed. Shouldn’t our backlog?
A scrum team might say that this is solely the prominence of the Product Owner. In Scrum terms, that’s true. But an old backlog suggests an experienced team. One of the great things about the tech world is that it’s largely inhabited by intelligent, enthusiastic people. After months or years of working on a product, the team becomes heavily invested in it, and they have very valid ideas of their own. If those ideas differ from the Product Owner’s, there’s no better time to find out and talk about it than now. In the process, the team can learn what inspires them and forge a shared vision.
Just go through that old backlog as you would a pile of clothes from the deepest depths of your closet. Sort them by type, however, makes sense. For example, bugs, UI enhancements, administrative features, reporting features, onboarding improvements, core features, etc. The go through each group of features, looking at each one carefully and asking if it inspires the team. How do they feel about it? Maybe make a deck of cards for each member with feelings like “excited”, “ambivalent”, “scared”, “guilty”, and “amused” and use them like planning poker. Discuss outliers. And most importantly, discard all those ideas that don’t inspire positive feelings.
As you’re doing it, think about each idea from different points of view. How do you feel about it in general? What’s the first feeling that comes to you? How would you feel if that feature were already done? If you could implement it as easily as flicking a switch, would that make you feel good, or not? If a feature scares you and having it done would scare you, too, discard it. But if it scares you but having it done excites you, that’s a challenge worth doing.
If your backlog is in Kanbanery, you can export it as a CSV file and work with it in a spreadsheet. If it’s in your first column, you can move everything that doesn’t inspire positive feelings to the icebox if you’re worried about making a mistake. I suspect you’ll soon feel relieved to have those little nuggets of negativity out of sight and will happily go back later and delete them.
Just be sure as you do to thank them for the inspiration they once provided. Gratitude lies at the core of happiness, and taking a moment to acknowledge the lessons those ideas have provided before consigning them to eternal nullness makes that process cathartic rather than agonizing.
If you try this, please let me know how it goes. If you think I’m nuts, you can tell me that, too.