Share this Post
Jim Geisman: I think there’s a great temptation to load every feature you can into either a single addition (one size fits all) or to load a whole bunch of features into the various additions and overwhelm the customer. But this is a case where more is less. There’s nothing wrong with having a feature-rich product. But sometimes you reach the point of diminishing returns where the customer really doesn’t understand how the product fits into what they’re doing or they see it as a lot of features that are extraneous.
It’s typical most customers will push back on the price or if this is a product that you take down over the web they’ll just move on, so be careful of that. Now when you’re putting together an offering what you want to do is think in terms of packages, small medium and large. These packages consist of some amount of functionality.
There are a range of prices that are acceptable and what you’re trying to do is is make sure that these packages scale with value so that you have the option when a customer says I don’t want to pay this much, you say well that’s okay, you have the option to pay less but you also get less. That cone [in the graphic] by the way is the “what’s fair line”. You pay for value delivered and if you deliver more value then you get paid more.
Now in determining what features to include in an offering, those discussions are a lot more fruitful when you have a framework behind it.
The framework that we developed has to do with usage and value and what you’re seeing here is when you have high usage and high value those are probably features. That’s probably a good way to implement it in the various tiers.
“There’s nothing wrong with having a feature-rich product. But sometimes you reach the point of diminishing returns where you know the customer really doesn’t understand how the product fits into what they’re doing…”Jim Geisman, Software Pricing Partners
The next quadrant are probably candidates for options because they have special appeal, but they have high value to a smaller number of customers that are interested. In the upper left where things are used frequently but not valued at all, those are our must-haves (i.e. table stakes) for playing the game but nobody will pay extra for font treatments in a word processing program, for example. But they wouldn’t buy one that didn’t have those font treatment so that’s what the must-haves are.
If there are features that are not used very frequently and have low value you might want to reconsider whether these features are worth continuing development on. Or whether you should even implement them at all.
I think one of the the major focuses to have when you use this framework is you really need to define who the target customers are for the various products and options you’re coming up with. What we tend to start with to define three different types of customers who when they look at the list of features will say “oh you know that that kind of describes me”.
Now if you take those features and you plot them, you begin to get some clues as to what features ought to go where. Here there are some pretty basic features and then the mid-range product includes the basic features but has some additional features ditto for the premium and then the lower right you can see a series of options. Now it might be a good idea to survey customers, but you can also have that discussion in-house. This was a photo one of our clients supply this with showing us how they had their internal discussions and where they settled out on a bunch of features.
“Packaging which results in a tiered offering at the offering model is one of the under-exploited strategic weapons you have.”Jim Geisman, Software Pricing Partners
As you can see this by the way is Salesforce.com you know they’re they’re talking about a group professional enterprise performance and you want to think about how you describe the people for whom each Edition would be used. I think that that’s very useful it’s always useful to have a customer in mind when you’re doing development or slotting features into into products. Now it’s not just having the features but it’s also how you implement them. This this comes from Logi Analytics, state of an embedded analytics report from last year they have a new one out which we’ll talk about in a moment.
But you know they’re really three ways of taking technology like embedded analytics and embedding it in your products. One way is just have a link to an external program where the user experience is going to be different. The user interface is going to be different and that’s okay, that’s an okay feature. But it doesn’t add an awful lot of value relative to not doing the feature at all when you start integrating these embedded technologies analytics.
You wind up getting a higher value premium because it’s a better user experience, it’s more convenient and you can probably do more things you know within the context of an application as opposed to just being called externally by the application. Then finally if you decide to go all the way and embed it, you’re probably in new product land. You certainly can embed it and use that in your tiered offerings.
But if you do that as a new product you can certainly isolate the value that you’re creating there and that’s where people think they get the greatest boost in value. from the 2014 state of embedded analytics what you’re seeing here is if you’re going to embed analytics what do you do and you see about half of the people will give every customer access to all the analytics capabilities and to which I might add whether they want it or need it or not. So you may want to think about that now. Add-on options may be a reasonably viable approach if the analyst you’re doing are only valuable to a small audience and finally the tiered offering which is about a quarter of the people who responded to this a tiered offering.
It offers you much more flexibility and I might also say that packaging which results in a tiered offering at the offering model is one of the under-exploited strategic weapons you have. Another one is of course price, so be careful of how you implement your features now there are really two approaches regardless of how you implement the features you can have a tiered offering where you have small, medium and large and that’s pretty good for fairly simple products that have narrow ranges of use.
But when it comes to the more complex stuff, often an ala carte offering makes a lot of sense, but having said that it’s not bad to take that ala carte offering and actually show a series of bundles. As you would in a tiered offering with a you know some description of the use cases that would result in that bundle and that the benefit of that of course is the customer when they look at this they can decide whether that bundle is just for them. Or whether gee can you take this out and add this other thing and it just helps configure a deal much faster than if you just gave people a menu of ingredients and told them what sort of a meal do you want us to make.
Share this Post