Pricing has far reaching effects beyond the cost of the product.
'The price point defines the sales model. It has to be simple, and you have to know how to make money with it.' -- industry pricing consultant
Pricing has far reaching effects beyond the cost of the product. Pricing is just as much a positioning statement as a definition of the cost to buy. Pricing defines the entry threshold: who your buyers are and their sensitivities, which competitors you will encounter, who you will be negotiating with and what the customers' expectations will be.
The most important thing in developing any marketing strategy, including pricing strategy, is to understand as much as possible about current and potential customers. The more you know about their motivations, sensitivities, needs, and their own customers, the more likely you will be to maximize both the effectiveness of your product as well as your own revenue stream.
The purpose of this article is to explore the interrelation between product and pricing.
Before delving into details, here are some common pricing strategies. Note that combinations of these models are possible.
The pricing model sets the framework in which the final product price is calculated. Think of the pricing model as an equation. To get to the price ('Y') the value for 'X' in the equation needs to be inserted. This 'X' is the Price Baseline. An example is the price of a user license for a software program. After entering the Price Baseline into the pricing model and relevant discounts such as for volume, the product's price point is calculated.
The pricing model should always be tested against sales scenarios. The best fit should be within the target market. Most models will not be optimized for some segments. In some cases, it may cause money to be left on the table or deals to be lost due to too high of a price. One way to test the fit is to list various sales scenarios and compare the effect on revenue caused by changes of the pricing model and the price points that feed into it. This exercise should be repeated at least twice a year. The assumptions used in the comparison should be validated and the model should be tested on the previous quarters' sales.
Another test for the fit of the pricing model and price point within a market segment is that a comparison with the competitors' pricing must be made. Take into account the pricing differential based upon positioning and functional differences. If the differences between your price and that of your competitors? cannot be justified, you will either have to change the model or the pricing factors in it.
The last test is the market. Make sure that your prospects and customers 'get it.' The pricing model should be simple to explain. If you need more than a couple of sentences to explain the pricing model, it is too complex.
This section covers vendor approaches to products and pricing. The vendor's pricing approach may determine the appropriate product packaging or vice versa. Consider a 'one size fits all' approach versus a specialized product approach, the logic of adding ever-more features and the impact of product development approaches on the customer's perception of value.
The 'Divide and Conquer' approach refers to breaking a whole product into parts and selling these individual pieces separately.
For example, a PC software application originally cost $8,000 for full functionality. A consultant investigated the way people used the toolkit and determined that there were five standard implementations. The R&D department created compile flags that would only include the features necessary for each specific implementation. As a result, the company was able to split the product into five specialized offerings using the same code base and sell them for $8,000 each. The difference was that each version of the new products worked out of the box. People will certainly pay for that!
The tool was originally marketed with a 'you can do it all with this toolkit' approach, and afterwards, the approach was changed to a 'we have done it for you' approach with the five main uses of the toolkit. In other words, the 'tool' was reconfigured and made into five separate 'solutions.'
In another twist to this approach, a network fault management company decided to charge for the rules that managed individual network element types and not only for the tool itself. The developers didn't understand why this was done. Non-developers created the rules so, of course, they should be free. Their point of view was that the customer only wants to pay for things created by developers. Contrary to this pretentious view, it was 'the rules' that made the real code valuable.