Imagine that you get an e-mail from your CEO saying, "We've got to fix this user issue on the Web site as soon as possible. People are complaining and it's a real problem." Fixing this issue is not a simple bug. It will require several person days of developer time, which may disrupt your project. You know that you have a major release of your Website coming in two months that will fix a whole host of problems, including the one that your CEO identified. So, the question is: do you work on this feature and endanger the release of the larger project or convince your CEO to hold off. Here are some (internal) decision criteria that I've found useful in deciding whether to Band-Aid now or wait for the cure.
The first question always to ask in any product management situation is: what is the goal? This isn't a about the importance of the feature, since you know it needs to be done eventually. The question here is more immediate and contextual within the project: why should it be singled out as a potentially disruptive sidebar to the larger project? Once you've established a goal, metrics will tell you the effect of the feature, giving you a qualitative measure of importance.
What's unique about this scenario is that you know the feature is going to come out eventually. Therefore, statements like, "Users keep asking for it" are not sufficient to justify changing the project. Even a financially sound goal like "Increase CTR by x%" isn't ideal, because you'll get the financial gain at the end of the larger project anyway. An ideal goal is one that justifies the feature in the context of the project, e.g., "Reduce the number of complaints to tech support so that they can focus on gearing up for the launch." In this case, the very reasons for disruption are to prevent further disruption.
The feature's relation to the larger project is the next thing to consider. If the feature is separate from the project, then the feature must be coded twice, once for the current version and once for your upcoming project. If the feature is a subset of your project, then you can reuse the code and minimize disruption. However, the scope of the feature comes into play here. Releasing anything to the outside world incurs a maintenance cost. Developers will fix bugs and make tweaks, which can be extremely time consuming. Any resources spent on maintaining the current product aren't developing the new, better product.
Of course, you still have the CEO gauntlet to run, but hopefully with some numbers, a clear model for decision making, and a few Powerpoint slides, you can do what's right!
