Drawing the line on feature requests

It’s the classic pattern.

You build an app, website, or tool. It’s nice, small, and simple. You launch, and (if things go well) the feature requests come pouring in.

You add more features and expose more options, expanding it again and again. You give them a “light” and “dark” theme. You allow them to fiddle with the variables. The process could go on like this forever.

So when do you say “no, I’m not going to add that feature”? Or, better question, why would you say that?

You say it because if you don’t draw a line somewhere, you’ll end up turning Dr. Jekyll into Mr. Hyde. You’ll sacrifice an app that does one thing well for an app that could do many things well if you could only figure out how to set it up properly. Attention is scarce these days, so you don’t have a lot of time before your users will run out of patience.

Back to the when. You won’t know when to draw that line if you don’t have a vision for what you’re making. There’s so much gray area when it comes down to each individual feature request. “Oh, that’s a simple fix, it’ll only take 20 minutes.” “Oh, that’s the third time I got that request in a single day. It must be really important. I’ll do it right now.” If you have no principles to fall back on for evaluating each little case, then it’s easy to drift away from your ultimate goal.

Comments