Kobo hosted the November 5th, ProductTO MeetUp. I facilitated a session on “When and how to kill a product / feature?”
The sessions went well. It was nice to participate in the larger community for once–it’s something that Kobo has never been good at, but I’m going to make a priority for 2014 to host these type of events in the future or at least participate at a personal level.
I often approach feature pruning from the sense of operational expense. Old features that are not used, or no longer relevant have a cost associated to them:
- They take up space in the UI. Make the UI more confusing because you have to move it around or add hierarchy.
- Code quality is reduced. Often times, old features use old programming paradigms.
- They add weight to the code that you need to carry forward with each release. You feel that as SDKs update or through regression testing.
It makes the code in the product more brittle.
The same can be said at a macro-level with the company’s product portfolio.
I kind of want to write my own “Spring Cleaning” blog for Kobo; similar to how Google announces it.
However, it takes effort to gracefully remove and prune items. Effort that could be used to add new and innovative features. There is also a downside for some of our customers, most likely a minority, who rely on that specific feature that deprecate. How do you handle the collateral damage when everyone has a twitter or facebook account?
The response that I get internally at Kobo is about 50%. Now, 100% of the people understand what I am saying, but only 50% respond positively with outright support. The other 50% are reluctant to accept my approach.
One of the learnings from the session that I facilitated is that I should change my approach. Rather than a subtractive discussion, make it about “additive value”. Spin it up in a positive light by saying that removing this feature or product will allow us to focus on this specific functionality that we know is extremely valuable.
I’m going to give that try.