Why I Killed My Most Popular Feature
Shashank Manjunath
On the 14th of May I looked at the Frictionwell analytics dashboard, saw that the "quick reset" button had been tapped 340,000 times that month — by a wide margin the single most-used interaction in the entire app — and by the 16th I had deleted it. Not throttled it, not redesigned it, not A/B tested a softer version. Deleted. I want to walk through why, because it's the clearest example I have of a rule that took me two years of running this app to actually believe: the number everyone tells you to chase is not the number that tells you whether your product is good.
What quick reset actually did
Frictionwell is a small habit-tracking app — I built it originally for myself, to break a specific bad pattern, and it grew, slowly, into something with about 4,800 paying users. One of its core mechanics is a daily streak: you log a habit, the streak counts up, and the whole design is built around making that streak feel worth protecting. Early users kept asking for a way to "reset gently" when they broke a streak — instead of the counter snapping back to zero and feeling punishing, quick reset let you tap once and restart at a slightly softer number, with an encouraging message instead of a blunt zero.
I built it in an evening, shipped it, and watched engagement do something I'd never seen in this app before. Daily active use went up nine percent in two weeks. Session count per user climbed. Every dashboard I looked at said, unambiguously, that this was a hit.
"Every number I had access to told me quick reset was the best thing I'd shipped all year. It took me three months to notice it was also the thing quietly emptying the app out."
Building it was, in retrospect, the easy part — the kind of feature that feels obviously good the whole time you're building it, because every piece of feedback while you're building it is positive. Users had been asking for exactly this for months, in almost these exact words, in the small community I run alongside the app. I remember feeling, the week I shipped it, like I'd finally listened properly to what people wanted instead of guessing. That feeling turned out to be part of the trap: the feature request itself was completely sincere, and completely correct about what would make people feel better in the moment, and almost entirely wrong about what would make the product work over a longer horizon than any individual user was thinking about when they asked for it.
The number I wasn't looking at
I don't check thirty-day retention as often as I check daily engagement, because engagement updates every day and feels like progress, and retention takes a month to tell you anything and mostly just makes you anxious. That's a bad habit and I know it's a bad habit, and it's exactly why quick reset got three months to do damage before I noticed.
When I finally pulled the cohort data — comparing users who joined before quick reset shipped against users who joined after — the retention curve for the "after" cohort was visibly, uncomfortably worse. Not catastrophically. About six percentage points worse at the thirty-day mark, which in a small app with thin margins is not a rounding error, it's the difference between a sustainable product and one that's slowly leaking.
Why the popular feature was the problem
Once I went looking for the mechanism, it wasn't subtle. The entire design of a streak mechanic is that breaking it should cost something — not punitively, but enough that the small discomfort of almost breaking it is what makes protecting it feel meaningful. Quick reset removed that cost entirely. You could break your streak, tap once, and be back to something that still felt almost as good as an unbroken one, with a friendly little message on top. It felt kind. It was, mechanically, the thing that made the whole point of having a streak evaporate.
Users loved it in the way you love a snooze button — genuinely, in the moment, every single time — and the cumulative effect of loving it every single time was a slow erosion of the one thing the app was actually for. The engagement number was measuring how often people used the escape hatch. It was never measuring whether the app was still doing its job.
The afternoon it took to kill it
- Pull the cohort split before you trust the aggregate number — daily engagement told a happy, misleading story; splitting by signup date against the feature's ship date told the true one, and it took ten minutes once I actually ran it.
- A single-person team can act on a bad finding immediately — no roadmap committee, no quarter of "let's monitor it," no sunk-cost meeting about the nine-percent engagement bump. I found the problem on a Tuesday and shipped the fix by Thursday.
- Kill the mechanism, not just the UI — I didn't hide the button behind a flag and call it done. I removed the soft-reset logic entirely and rewrote the break-streak message to be honest but not punishing, which took longer than deleting the button but was the actual fix.
- Tell the users who'll notice, before they ask — I emailed the roughly 1,200 users who'd used quick reset more than five times, explained exactly what I'd found and why, and got eleven replies. Nine were supportive. Two were annoyed. I'll take that trade every time.
The fix itself, once I understood the mechanism, was almost boring: remove the soft reset, keep the honest message, but make the honest message genuinely kind instead of blunt — "your streak reset to zero, and that's fine, most people who come back the next day end up stronger for it" rather than a cold number with nothing around it. Painful in the way the mechanic needed to be. Kind in the way the tone didn't have to sacrifice.
The two replies that stuck with me
Of the eleven users who wrote back, the two annoyed ones taught me more than the nine supportive ones did, and I want to be honest about that instead of only telling the flattering half of the story. One had a forty-one-day streak going, had leaned on quick reset twice during a genuinely rough month, and told me, not unkindly, that removing it felt like I'd taken away a tool that had kept her using the app at all during a period when a blunt zero would probably have made her quit outright. I didn't have a clean rebuttal for that. It's entirely possible the mechanic I killed was, for a specific subset of users going through something specific, actually load-bearing in a way my aggregate cohort numbers couldn't see.
What I did instead of ignoring that reply was add a much narrower, much less frictionless version of the same idea a few weeks later — one soft reset available per calendar quarter, framed explicitly as a "life happens" allowance rather than an always-available escape hatch. Retention on the new cohorts held. The handful of users who'd genuinely needed the safety valve during a hard stretch still had one. What disappeared was the version that had turned an occasional mercy into a habit's daily background assumption, and that distinction — mercy as an exception versus mercy as the default — turned out to be the entire difference between the mechanic that helped and the mechanic that quietly hollowed the product out.
"The annoyed users weren't wrong that something real had been taken away. They were right about a smaller, truer version of the feature than the one I'd originally shipped, and it took their pushback for me to find it."
What happened after
Thirty-day retention for new cohorts climbed back to within a point of the pre-quick-reset baseline within six weeks. Daily engagement, predictably, dropped — the easy tap that used to inflate session counts was gone, and I lost a genuine, if shallow, form of usage I'll never get back on that specific metric. I'd make the trade again in a heartbeat, and I think that trade is the entire argument for building small. A team big enough to have a growth function optimising for engagement dashboards would have had a very hard time killing the number that made the dashboard look good. I didn't have that problem, because I don't have a growth function. I have a spreadsheet, a Tuesday afternoon, and the freedom to be honest with myself about what the numbers actually meant before anyone with a quarterly target had a chance to talk me out of it.
"The advantage of building alone isn't speed of shipping. It's speed of un-shipping the thing that was quietly wrong, before you've built a whole team's incentives around defending it."
That's the version of "small and deliberate" I actually believe in. Not small because it's cute, not deliberate because it sounds virtuous on a landing page — small because small is the only size at which you can afford to notice your best number was lying to you, and act on it before the lie compounds into something you can no longer afford to fix in an afternoon.
I still check daily engagement — it's a useful number, and pretending otherwise would be its own kind of dishonesty. But it no longer gets to sit alone on the dashboard I look at first every morning. Retention sits next to it now, pulled by cohort, every single week, whether or not I feel like being told the truth that day. The one lesson from quick reset I never want to unlearn is that the number that makes you feel best about your product and the number that tells you whether your product is actually good are, distressingly often, two completely different numbers — and the only way to catch the gap between them is to keep looking at both, even after you've been burned once.
Shashank Manjunath
Small & Deliberate · Editor & sole writer
An Indian builder-operator writing about AI, teams, and the cross-cultural patterns shaping tech — read from Asia outward, with the West as the contrast class. This is a one-person publication; reply to any email and it reaches me directly.