ISP Exchange Notes
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.
I've got some more notes, observations and adventures from this little jaunt that I will share at various points over the next few days...
See this post as it first appeared on Blogware.
4 comments
Comments are closed - these are kept exactly as they were left.
(name not saved), November 1, 2003
In a general sense are you saying:
Product concepts driven by business/customer needs?
(name not saved), November 3, 2003
> In a general sense are you saying: Product concepts driven by business/customer needs?
I suppose I am. Funny how little my act has changed over the years ;)
(name not saved), November 3, 2003
I agree with this advice 100% but want to highlight some of the difficulties inherent in putting it into practice and suggest an analytical framework for doing so.
1) It is difficult for someone to tell you what they want if it is something they never had before. For example when I say "until I had heated seats, I didn't know I couldn't live without them", I am describing a problem that confronts Innovation. If you asked me in 1990 what my key features in a new car would be heated seats would not have made the list. But the first time I felt the heat radiating so sensually up through my lower back as the wind whistled cold outside I knew this was a must.
2) On top of being unreliable for the reasons above (i mean they are a well-meaning bunch just sometimes they don't know), customer communication is costly.
To combat these deficiencies and for discussion purposes I suggest the following analytical framework (not necessarily a sequential thought process) :
1) Do not ask your customer what solutions they want, rather ask them what problems they have.
2) Use your creative genius to come up with solutions to those problems.
3) Look for indications that some of your competitors have done this type of analysis (the ones that most need to be worried about will have). Take a close look at their feature sets with a mind towards asking "why" they added that feature. If the 'why' is valid it should become part of your feature set as well.
(name not saved), November 3, 2003
Two things;
a) I only do theory. No framework needed! :)
b) Thanks for leaking part II of my presentation. Damn!
-rwr