A bulk export option got requested often enough that I built it, then pulled it two weeks after launch
The feature worked exactly as designed and still made the product worse for almost everyone who touched it
Request volume measures wanting, not using, and I mixed the two up for a full release cycle
Now I ask what a request replaces before I ask how many people made it
The Request That Wouldn't Stop
The pattern started small. A customer wanted to pull every saved config out of one of my tools in one go instead of one at a time. I filed it as a nice-to-have and moved on. Then it came back. A different customer, same ask, slightly different wording: give me everything at once. Then a third. None of them were rude about it, none of them threatened to leave, they just kept mentioning it in support replies and the occasional review.
I do this alone, so every repeated request gets weight it might not deserve. There is no product team to argue the other side, no second opinion in the room before I open the editor. When three people ask for the same thing inside a month, it starts to feel like a signal instead of three isolated preferences, and I started treating it that way.
That is one of the harder parts of running a one-person studio. Every voice that reaches me is a real customer, not a sample, so it is tempting to treat each one as representative of everyone who did not write in. Most customers never email at all. They either get what they need from the product or they quietly leave, and neither group shows up in my inbox to balance out the handful who do. So when the same request lands three separate times, I have almost no way to know if that is three out of ten people who feel that way, or three out of a thousand. The inbox only shows me the numerator, never the denominator, and I forgot to account for that.
I went back through the support inbox and pulled every mention I could find of exporting more than one item at once. It was not a huge number of people, but it was consistent, spread across a few weeks, and always phrased the same way: I want everything, not one at a time. That consistency is what convinced me. A single loud request is noise. A quiet, repeated one from unrelated people who never talked to each other is closer to a pattern, and patterns are what a solo studio should actually build for.
So I scoped it. Not a redesign, not a new section of the product, just a button: export all, one file, done. It looked like exactly the kind of small, contained addition that a one-person shop can ship without breaking anything else. I linked it from the check I run on every tool before I call it shipped in my own head before I ever opened the editor, because I already knew this was going in front of real customers within days, not weeks.
What I Built
The build itself was straightforward, which should have been my first warning. Straightforward features are the ones I trust too quickly, because there is no hard technical problem forcing me to slow down and think about the edges. I added the button, wired it to pull every saved item into a single downloadable file, tested it against my own account with a dozen items in it, and it worked cleanly on the first real attempt.
Because it was easy, I skipped a step I usually do not skip: I did not sit with the feature for a day before shipping it. Most changes get at least one night where I use the product the way a stranger would, cold, without the context of having just built the thing. This one felt too small to need that. A button that zips up your saved items and hands them back to you is not a redesign, it is a convenience, and convenience features get less scrutiny than anything that touches the core workflow. In hindsight that is exactly backwards. A convenience feature that quietly changes the shape of what customers download is not a small change to the people receiving it, even if it is a small change in the codebase.
I shipped it in the next release, wrote it up in the changelog the way I write up everything, and mentioned it to the handful of customers who had asked. The initial reaction was good. People who wanted it used it, said thanks, moved on. For about a week it looked like a clean win, the kind of small feature that costs little and earns a bit of goodwill.
Then the second kind of message started arriving. Not complaints about the export itself, but confusion about what came after it. The bulk file mixed several items into one, and using any single item out of that file required more steps than exporting it individually would have. I had solved the problem of getting everything out, and in doing so created a smaller problem for everyone who only ever wanted one thing out at a time. Before this, that was the entire customer base. The export-everything crowd was real, but it was also small next to the export-one crowd I had built the whole product around in the first place.
What It Cost Everyone Else
Nothing broke. That is the part that made it hard to see at first. No error logs lit up, no crash reports, nothing that would show up in the error log I read every morning before anything else. The feature did precisely what its spec said it would do. The cost was not a bug, it was friction, and friction does not announce itself the way a crash does.
What I noticed instead was a shift in support tone. Questions that used to be answered by the interface itself started needing a reply from me: which one is my file, why does this look different from before, how do I get just the one I need. None of these were angry messages. They were confused ones, and confused customers are quieter than angry ones, which meant I nearly missed the shift entirely. It took a deliberate read back through two weeks of tickets, not a real time alert, to notice that a feature I had added to make things easier was making the common case slightly worse.
The people who wanted bulk export got what they asked for. The much larger group who never asked for it, and had never needed to think about export logic before, now had one more decision to make every time they touched that part of the product. I had optimized for a request instead of for the product's actual center of gravity, and the two were not the same thing.
What made it worse is that the new button sat right next to the old single item export, in the same row, at the same visual weight. Someone opening the product for the first time now had two ways to do a thing that used to only have one, and no obvious reason to know which one applied to them. I had not just added an option, I had added a decision point to a screen that used to require none. Every extra decision point is a small tax on attention, and I had spent that tax on behalf of everyone without asking whether the trade was worth it for people who were not the ones requesting the feature in the first place.
How I Decided to Pull It
Pulling a shipped feature is a strange kind of decision, because nothing forces it. There was no deadline, no outage, no single customer email demanding a rollback. It would have been easy to leave it in, call the confusion a rounding error, and move on to the next thing on the list. I sat with that option for a few days before I decided against it.
What tipped it was going back to why I build anything in the first place, which is the same reason behind the feature request I say no to every time: every addition has to earn its place against the people who never asked for it, not just the people who did. A feature that makes a vocal minority happy while quietly taxing everyone else is not a win, even if the support tickets asking for it stop coming in. I had let request volume stand in for actual usefulness, and those are not the same measurement.
So I pulled the button, kept the single item export as the only path, and wrote a short note in the changelog about why. I answered the handful of people who had used the bulk export directly, explained the reasoning, and none of them pushed back. A couple even agreed once I laid out what had happened on their side too. Removing a feature after shipping it costs a little pride. Leaving in something that quietly makes the product worse for most people costs more, just more slowly, in ways a solo studio might not catch until it is a habit instead of a one time mistake.
Bottom Line
The lesson was not that customer requests are unreliable, they usually are not. It was that a request tells me someone wants a thing, not that the thing belongs in the product for everyone else who never asked. Three people wanting bulk export was real information. It was not, on its own, proof that bulk export made the product better on average, and I skipped the second question because the first one felt urgent.
Now, when a request repeats often enough to act on, I ask a second question before I open the editor: what does this replace for the people who never asked for it. Sometimes the answer is nothing, and the feature ships clean. Sometimes the answer is a small tax on every other customer, and I either find a version that avoids the tax or I let the request go unbuilt. Either way, I know the answer before I write a line of code instead of two weeks after I ship it.
Top comments (0)