Pain-Driven Features

Often we find that there is not one problem in something, but a cluster of problems. This doesn't necessarily point to a problem in the code specifically, but often to a design weakness, or a process issue. In this case, it can be difficult to really define the boundaries of the problem and therefore the change required to fix the underlying issue.

Basically, a cluster of problems needs to be resolved, and that often means adding a new feature (to the product or to the process). So we treat it like a feature, and brainstorm what we really want it to do. After all, brainstorming is a fairly common requirements development technique.

Where it gets hard is that this feature isn't just a future problem. This is a feature you're creating because you're hurting today. So brainstorming is great, but keep in mind that you're feeling the pain right now, so speed matters. Dreams more than an hour or two long are dangerous - after a few hours you're not solving your pain point, you're designing something that's going to take you a while to build, and that means your pain isn't going away any time soon.

So when you're brainstorming how to handle a feature, keep in mind that your most important priority is not the feature itself. Your most important priority is alleviating the pain it's causing today. 

Think quick hits. Think doing it right. And most importantly, don't overthink. Just make the pain go away.