Ask what your north star metric would have to show before it told you to delete a feature. For most teams the answer is nothing, because the metric only points one way. Sessions, active users, engagement, tokens spent: each can say more, and none can say stop.
A product built to be deleted
Ben Celebicic, Hinge’s Chief Product and Technology Officer, writes: build a product that increasingly helps people form meaningful connections and then delete the app. Product School’s write-up of his podcast interview puts it more bluntly: most apps optimise for time on screen, and Hinge optimises for you leaving.
It is a strange thing to build a business on, and it changes what the metric can say. A metric defined by people leaving happy can tell you a feature is wrong. A feature that keeps someone scrolling for another twenty minutes but does nothing to help them meet a person would fail the test, however good its engagement chart looks. The metric has a direction, and it is not only up.
Metrics that only point up
Most metrics teams rely on were chosen because they were easy to count and easy to celebrate. A number that rises when the team ships more, and never falls when the team ships something unhelpful, works as a scoreboard. It cannot work as a filter.
Engineering organisations swap one measure of effort for another, story points for tokens, and each replacement can only report more. Goodhart’s Law does the rest, and token spend is the current example.
A metric that can say remove has a different property. It is anchored to an outcome the product is supposed to produce for the user. Activity can always grow. An outcome can be reached, and once it has been, the correct reading of the number is that the product has less to do.
What cheap building does to the backlog
This matters more now than it did two years ago. When a prototype takes an afternoon, the backlog stops being a list of things you can afford to build and becomes a list of everything anyone can imagine. Output outruns absorption: the team ships faster than users, support and the codebase can take it in.
Every feature you add carries a cost that never appears on the roadmap: something to maintain, explain, test and defend. When building was slow, the price of building did the filtering for you. It no longer does. The scarce skill is deciding what not to keep, and that decision needs a metric that is willing to argue for it.
A CPTO sits in an unusually good position to make it. Celebicic describes the tension between the product instinct to ship and the engineering instinct to protect quality as one that plays out inside his own head. A CPTO holds both sides in one role: the person who wants the feature and the person who pays to maintain it are the same person, which makes it harder to pretend that cost is free.
I have made this call once. A learning product I have worked on let operators configure what each student could use: whether classes could be booked directly or only through a coach, how many classes a student could attend in a month, the minimum gap between one class and the next. The settings were meant to give flexibility. Each one also handed an operator a value to set arbitrarily, and the values that appealed were the ones that saved cost, not the ones that helped students succeed. Measured against student success, none of them earned its place. They had to go.
Flexibility rarely loses an argument on the day it is proposed. Every option has a champion, and its cost arrives later and somewhere else: an operator’s temptation, a student’s worse outcome. A metric anchored to the outcome is the one voice that can argue against an option nobody has proposed removing.
Limits of the Hinge idea
Hinge’s model has a favourable structure. Its users succeed by leaving, and a company can build a metric around that. A workplace tool, a payments product or a learning platform cannot be deleted by a happy customer in the same way, and pretending otherwise would be cargo cult.
What transfers is narrower and more useful: the metric has to be able to reach a conclusion you don’t want. Ask of any north star what result would make you take something away. If no result could, the metric is measuring your convenience.
Three questions to run today
- What would this metric have to show for you to remove a feature you shipped last quarter?
- When did it last tell you to remove something, and what happened when it did?
- Which options or settings exist only because someone might want them, and what outcome would tell you to take them out?
Most teams can answer the first question in theory. Few can answer the second.
What was the last feature your north star told you to delete?
Leave a Reply