Yesterday, stimulated by Kathy Sierra, I posted about bridging the gap between what your product can do and what your users want to do with it. 
I included this diagram along with an open-ended list of alternatives for what to do when your users hit the solid regions of discontent:
1. Add what the user wants to the feature list, and thank them for their suggestion.
2. Demonstrate how the same goal can be reached inside the green line.
3. Tell them “sorry, no can do”.
This morning I realized that I should have discussed some more creative options for doing #1, especially when it’s urgent.
First, you can develop what they need as an add-on (plugin, extension, whatever you want to call it). That way, you don’t have to touch the core product or weigh it down with features. If you charge for the product, the add-on could even mean additional revenue — allowing those who need the extended capabilities to bear the cost of providing them.
Second, there may be third-party solutions available that work in concert with your product to provide the desired functionality. Think creatively about how to stack the building blocks together to create sophistication out of simplicity. Randy Morin gave us a good example yesterday: take a simple RSS-to-email aggregator like Rmail, hook it up to a nice e-mail client like GMail, and you’ve created a pretty decent feed reader. No need to add a client UI to Rmail, or feed subscription support to GMail.
There may even be third-party providers who are willing to create add-ons specifically for your product. I post a lot of that kind of work over on Chip’s Tips. Of course, that does create its own set of issues. It can be difficult, if not impossible, to insure that future versions of your product don’t break the third-party add-ons. That’s where building in a good strategic design for extensions (like those provided by Firefox and WordPress, for example) from the start can pay huge dividends. The language you choose can help with this also. Ruby’s ability to add functionality to existing classes makes extensibility exceptionally easy. Still, unless the person writing the extension has an intimate understanding of not only how the application works but also the directions it is likely to take in the future, you can’t completely insure upward compatibility.
And sometimes it just can’t be done as well from the outside. Often the extension would like to be able to control internal behaviors of the product for which there are no published hooks. That creates pressure on you, the original product vendor, to incorporate the solution to some degree, or at least to provide the required interfaces. A good example of this would be the container support for Synergy/DE I originally posted on Chip’s Tips years ago. It has received wide adoption among Synergy/DE developers, but it’s only about a 90% solution. Some UI behaviors, like tabbing and window activation for example, can’t be smoothly controlled outside of the Synergy/DE runtime. Plus, my implementation created some unforeseen interactions that made their way to Synergex’s help desk. So now Synergex is incorporating support for containers in their next major version (and guess who gets to help).
It might seem like my add-on module bullied Synergex into adding this feature to their product, but there are lots of more charitable ways of looking at it. It provided an immediate solution for a very real user need, without forcing Synergex (or their users) to go through a release cycle to get it. Better yet, my version acted as a free prototype that identified the issues Synergex would face when implementing this kind of solution, as well as the ways in which their users would expect to be able to use it. It drew the red circles before they had to redraw the green one.
According to 
The web just 
But I have one problem: it seems like AOL is blocking my e-mails. Whenever I send to an address @aol.com, I get a message back about delivery being delayed, followed by a failure notice the next day or so later.
Update: e-mails sent to gmail addresses also fail. Fortunately, they fail quickly. Here’s the detail:
Subscribe by Email
