Product and Pricing Strategies

By Daniel Shefer
August 09, 2007

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.

Pricing Models

Before delving into details, here are some common pricing strategies. Note that combinations of these models are possible.

  • Per Unit
    Also known as the 'per seat' model in software. This is the way most people buy their material objects: home, car, software licenses, etc.
  • Concurrent Users
    Cost is determined by the number of users that can access the service, application, etc. at the same time. The concurrent user model is common with server based applications such as databases.
  • Per Usage
    In the per usage model, the cost is proportional to the extent of usage. The most common example is long distance calls and home utilities such as electricity and gas. Depending on the product, an initializing or installation fee might be tied in.
  • Per Unit of Infrastructure
    The product, such as a database, is licensed per the number of CPUs on the machine that runs the application.
  • Revenue Share
    The customer pays a percentage of the additional revenue achieved when utilizing the product. The revenue share model works best when the vendor manages the collection of the revenue.
  • Costs Savings
    The customer pays a percentage of the savings achieved when utilizing the product. This can cause customer antagonism because the need to open books and share financial information will be seen as an intrusion.
  • Site License
    The customer pays a flat fee. Site Licenses are used mostly when usage is wide-spread in large companies. A site license saves customers the trouble of managing licenses when the number of users fluctuates.

Price Baseline

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.

Testing the Validity of the Pricing Model

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.

The Vendor's Side

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.

Divide and Conquer Approach to Productizing

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.

Page 1 / 6

About the Authors

Categories:  Pricing Strategy

Post a Comment


Allowed HTML: <b>, <i>, <u>