I was in Las Vegas last week at Shorecliff's ISP Exchange Internet Services Conference. This turned out to be an excellent show. I might be biased because I'm on the advisory committee, but I sincerely think that this was one of the best ISP-centric shows that I've been to in the last five years.
What it lacked in quantity, it more than made up for in quality. For instance, the number of providers making presentations exceeded the number of vendors making presentations. Also, the attendee's were invariably senior decision makers that were there to do business, not juniors' out on a boondoggle in Sin City.
I did a presentation on Tuesday @ 8 o'clock in the morning. I was quite surprised (and definitely pleased) with the number of people that showed up at what I thought was a completely ungodly hour for a conference to start.
My session was actually a team effort - Paul Engels from Hostopia and I shared honors. His portion of the presentation focused on leveraging customer support services as a revenue center and mine focused on streamlining service offerings to ensure maximum customer experience.
My message was simple - customers are willing to pay for services that meet their requirements, therefore services need to be designed and marketed based on customer requirements and not solely by analysing the features and pricing offered by the competition. My null hypothesis is that an increased focus on customer requirements during the service development cycle tends to decrease overall service development costs whereas an increased focus on competitive services during this same period will tend to increase service development costs.
The driver behind this dynamic can be expressed pretty simply. If the feature set of series of competitive product is expressed as cfA, cfB, cfC, cfD and so on, the aggregate feature set of these products can simply be expressed as;

cfA+(cfA-cfB)+(cfB-cfC)+(cfC-cfD)+(...)

(in other words, the net feature set is simply the sum of the features contained in the basic service plus the sum of the delta's of the features found in all of the other services in the series. I'm sure that there is a more elegant and accurate algebraic way to express this, but I wasn't paying attention when I needed to.)

The problem with using this sum of delta's as the starting point for a new service is that the net feature set will always exceed customer requirements. The problem lies with the fact that features cost money to development. A corollary is that developing features that lie outside of customer requirements is essentially a poor investment because your customers won't appreciate the value of these features and therefore be unwilling to pay for them.
This approach becomes especially powerful when one considers the implications of a reduced feature set as it relates to the functional complexity of the service. Less features = less complexity which implies greater ease of use and therefore, (probable) higher utility.