A feature you were sure nobody would use, and were completely wrong about
by•
we built something as an afterthought, basically a debug tool we left exposed because we were lazy about hiding it, and it turned into one of the most used parts of the product. meanwhile a couple of things we spent weeks polishing barely get touched.
curious if this is universal. what's a feature that you almost didn't ship, or built half-heartedly, that ended up mattering way more than the stuff you were actually proud of building?
31 views
Replies
Cool story. I'd bet it's user-base dependent too — different crowd here, technical folks lean into raw/debug tools more than a general audience would.
@omri_ben_shoham1 Mine is a feature that refuses to do the thing the product is sold on.
We turn a customer interview into a written case study. Somewhere in there I added a check that judges whether the conversation actually produced a story, and if it didn't, it writes nothing at all. I nearly cut it. A tool you pay for that sometimes hands back nothing is a horrible thing to put on a pricing page.
It's now the part people react to. Someone read past everything else on my launch and said the refusing bit was the detail that made him trust the output, then immediately found the hole in it, which was that the customer who gave up five minutes never got told. The hole was worth more than the compliment.
My theory on why this happens: the safeguards are the only claims a stranger can actually check. Everything else is a capability, and capabilities all sound the same.
the reply about the refusal feature being the thing people trust is the one that stuck with me. it maps to what Evelyn said too - a capability claim is marketing, a safeguard is falsifiable, you can go check whether it actually refuses when it should. survivorship bias is a fair worry, but I think it's less that lazy features randomly win and more that the ones people ship reluctantly tend to be the ones that expose the product's actual judgment instead of just its output