Ditch the spreadsheet for content analysis.

You're willing to pay for the feature? So what?

Key Points

  • Don't implement something solely because a group is willing to "pay" for it.
  • Remember that costs are more subtle than they may initially appear.
  • Any change should consider the breadth of change it makes, and making one-off changes has a cost.
Related resource
Change Request Flowchart | Use this flowchart when you get a change request

Once you are dealing with a big website with a large number of stakeholders, you have a challenge: how do you decide what functionality gets implemented on the site? If you run a small site, this question may seem completely ridiculous (and, if the question does seem silly then this blog post probably isn't for you). You can read about digital presence product management elsewhere (book and intro article), but here I'll concentrate on one thing: why it doesn't matter if a group is willing to pay for the feature they want. This is always tough to deal with. Your internal clients will say things like "I don't understand. I have the money to pay for it, so of course you should implement this." Hopefully this blog post will help firm up you response.

So why doesn't it matter if a group is willing to pay for a feature? 

1. They aren't really paying the full cost

Sure, you might estimate the total development cost correctly, but are they even paying for simple maintenance of the feature? Upgrades? More subtly, are they paying for the extra regression testing now needed for features that aren't even directly related? Or the extra troubleshooting required for even what turns out to be unrelated issues?

2. Consistency of web experience for, you know, the site visitor

Not that this always seems to matter much in internal discussions, but is this better for the site visitor? Sure, it might be a gee-whiz and exciting feature. But is it going to confuse the experience of the rest of the site? Even if conceptually you could make it consistent, will you have the time to implement it in a way that's consistent?

3. Not implemented in an extensible way

If a particular group is commissioning a new feature, chances are they are thinking about how it needs to work for their site. The cost they are willing to pay will reflect that. So then you implement something (perhaps partially under the guise that this could be a "pilot" of a new feature), and other teams want it. Well, now the cost has actually gone up since not only does the feature need to be implemented anew for the rest of the site, but the feature needs to be retrofitted into the site that initially got that feature.

4. Not implemented in a technically consistent way

If only a particular group is getting a new feature, then even the technical team will be tempted to take shortcuts to get it in as directly as possible. This may seem innocent since, hey, only this group cares about it. But actually adding any complexity to your system just adds to the Frankenstein nature of your implementation. This means that as you are adding features you are just adding heft that may eventually grind your ability to add new features to a halt.

5. Limited resources anyway

Alas, you are only dealing with limited resources anyway. Maybe you can throw an external development team at the problem. But even if you are able to do that, what about the core team's coordination cost? This just means they won't be able to spend time on items that all groups want.

Obviously, sometimes special functionality needs to legitimately be developed. But consider the factors above before providing a new feature, and never just because a group is willing to "pay for it".

Change Request Flowchart Use this flowchart when you get a change request