Rest in peace, dea(r/d) feature!

The full story of why we removed this key feature from Mimo

Letting go is hard

When talking to my colleagues a while ago, I noticed that letting go of features is hard for some of us. In a company where we constantly develop and evaluate new features, a drastic change or removal of features is happening quite often. So, shouldn’t we be able to deal with that better?

We invest time in research, design, and development, make features complement other features. After days and weeks – sometimes even fighting with them – we are glad it’s over (temporarily). Meaning it’s published or released. Most of us love the variety in tasks so there is a point where we all want to move on, but we need to know if it was worth it. Where to better find this than in the acceptance of the feature by our users?

From investment to the decision of removal

We start our tests, dive into the analytics, and sometime after the release, the results slowly come back. In some cases, we trusted the feature, the change, to be permanent from the beginning. In most cases the A/B test results come back showing a variant has outperformed our original. We anticipated correctly! Or were we lucky?

Then there are those times where a non-performing variant or a strategic decision makes a feature (or beware: even a whole product line or platform!) obsolete. Yes, the one in parentheses has happened! Our data scientists summarize the results and write them down. When it’s a small feature or change, we post the results for everyone in the company to see and read whenever we have time. If it’s a bigger feature we present it to everyone.

The 5 phases of (feature) grief

There we make room for discussion – and the first phase of grief, denial:

• Was this analyzed correctly?
• Did you take into account the other change that has happened at the same time?

On to anger:

• It’s clear that users don’t use it. It’s so hidden / ugly / badly written / bad in combination with the previous screen / <insert complaint here>.
• I knew from the beginning this is preposterous!

On to bargaining:

• What if we keep it, but only remove part A?
• Let me get back to it and fix one more thing!
• Let us run the test one more week!

While the first three phases usually happen in (the company’s) public, the next phase – depression – comes within more private, smaller groups. Once a colleague told me:

• I took me 8 weeks to work on it and I did not know anything about that framework before and now I have to remove it. I feel resistance and sadness, and a bit ridiculous, cause in the end it’s only a feature, right?

Yes, it is only a feature of the coding app. There is always someone considering something more important (probably a colleague who has not designed or developed that feature). It’s also clear that investment leads to expectations. We have a need for the celebration and appreciation of our ideas, our endurance and perfection, flexibility, workflow and quality. So if we can’t celebrate a successful feature, can we celebrate the (short) lifespan or even the death of a feature and continue on the road to the last stage of grief – acceptance?

Thread of eulogies

Here’s what we do: When we remove a feature we start a company wide public thread of eulogies in Slack. Everyone who feels like it can contribute and send a message to the feature. Although it started without specific rules a pattern arose immediately. 

Colleagues open up and get personal with the feature. Literally, they address the feature as if it was a person that just died. In the eulogy they include what they have learned when writing, designing, marketing, coding, testing and last but not less important how and when they were using it. The statements are certainly funny but carry some truth. The colleagues repeat the reasons why it’s not the right time (yet) to go along with it and wish it to rise from the dead later, when we have fixed other stuff that might allow for another try. Which leads to gifs of terminator or zombies. Most in the company read through it and add their emoticons, including hearts, urns or coffins and skulls.

In showing that we care about this feature, the ones who have worked on it are appreciated. Here it comes, wait for it … acceptance!

Only later did I notice that this idea was unconsciously inspired by the Austrian chocolate maker Josef Zotter who has a cemetery of ideas.

Zotter sets a physical gravestone outside his company buildings in the edible zoo for every past chocolate variety and idea. Its motto: 

It all ends here or starts again. 

R.I.P., dea(d/r) feature!

A lot of things are changing at Mimo. Recently we moved 6 Million Users from Auth0 to Firebase. Here’s how we did it.