This time, the update is what I removed

After a few months spent mostly on other projects, I went back to Crew, my app for people who share a home, and reworked most of it: the home, the tasks, the expenses. It is a deep change. This is the point where a founder lists what’s new. There are new things, and they are not the news. The news is what I took out. Mechanisms that had been in the product for a long time, that I designed and paid for, are gone.

I had done something like this once before, on a smaller scale. This time it went through the whole app.

The old app was close to perfect, and that was the problem

From an engineering point of view, the old version covered almost everything. There was a mechanism for nearly every way a home can organise its chores and its money, and even the simplest thing took several steps. Each of these answered a real case. None of them was wrong.

The trouble is what happens when you answer every case, for everybody. I was speaking so precisely to so many different people that the product became complex, and a complex product is not for everybody. It is for the few who are willing to learn it.

Think of who opens a home app. Someone with a shopping bag in one hand, who wants to say: bins, tonight, me. That person does not want a system.

Then I looked at how people were using it. The results were not what we expected, and not what we wanted. The value was in there, and it was sitting behind its own completeness.

I wasn’t defending the idea

When people talk about removing features, they talk about ego. Kill your darlings. I don’t think that was ever my problem. I gave up the pride of having made something in my first months as a founder, and it never belonged to me much anyway. If something I made has to die so the product gets better, fine.

What I was defending was something else, and it took me a while to see it. I was defending myself from the work.

A change like this doesn’t move a button or two layouts. It changes how the product is used. Under that, it changes how the data is stored and how the pieces talk to each other. Rules the product had run on for a long time had to go, and other rules had to take their place. Whole parts came out, and what stayed had to fit together again without breaking anything for the people who use Crew today. On a product that has grown this much, that is hard. The thought of it made me want to cry. I mean that literally.

There is also the money. Early on I paid for a lot of that logic. Those were not wrong choices. They just weren’t the best road, and by now they were a legacy: every later choice sat on top of them.

So when I argued that the old version covered more cases, part of me meant it. Another part was simply afraid of the rewiring. Small changes to the interface don’t scare me. Touching the foundations does, and fear is very good at sounding like a product argument.

Fear is very good at sounding like a product argument.

What got me past it

Two things.

The first is the people around me. I didn’t get there alone. Someone had to tell me, one more time than I wanted to hear it, that the new direction was worth the headache. I think this is what the right team is for: they keep the value of a change in front of you on the days you can only see its cost.

The second is doing the design before deciding. We studied how each part should work, drew every state, and wrote down everything that would have to change underneath. When the design was done and I could see what the product becomes, the question was closed. Nothing of the new version existed yet. I already knew there was no better choice I could have made than to leave behind something I had built.

I think this is the practical part. The fear is about the work, so you can’t argue yourself out of it. You can look at the result first. Drawing the new version costs far less than building it, and it is enough to decide.

What I removed, and what I kept

I removed mechanisms: whole ways of doing things that asked people to learn the product before they could use it. Seeing your day, adding a task, finishing one, knowing where the money stands: each now takes far fewer steps.

I kept what people can do. My rule for this work was short: fewer steps, not fewer possibilities.

That said, some cases are no longer covered, and somebody will miss them. I accept that. I’d rather disappoint a few people than keep serving every possible case in the universe and miss the people I am building this for.

What I want from Crew now fits in one line: the most value, in the least time, for the people it is for. I can’t yet say how the new version performs. I can say what I saw when the design was finished, and it was a product whose value you can reach.

- Name what you are protecting: the idea, the money already spent, or yourself from the rewiring.
- Count who uses it. A case that is real but rare still costs every other user a step.
- Design the version without it before you decide. Look at the result, then judge.
- Remove steps before you remove abilities.
- Write down who will miss it, and accept that by name.
- Ask one person you trust to argue for the change, one more time than you want to hear it.