What's wrong (or right) with this pricing model?


I bought a small personal laser printer last year. It was on sale at the local electronics chain and cost me all of $79. It is small, less than 1 cubic foot in size, weighs less than 10 lbs, has a 1200×600 dpi print resolution, and is rated at about 22 ppm print speed. This is less than 5% of the price I paid for a far less functional laser printer 15 years ago. Then, I paid over $2000 for a 6ppm, 300×300 dpi printer, that must have weighed 30 pounds.

My little printer came with a toner cartridge that has only now begun to run out, over a year later. I went online to purchase a new toner cartridge. I was surprised (should I have been?) to find that a new toner cartridge cost $99. Now this cartridge will print for about twice as long as the original, but it’s hard for me to get over the fact that the toner cartridge costs more than the printer. How can I purchase a printer and toner for $79, but a replacement toner cartridge costs $99. BTW this is about the same price I paid for toner for my original $2000 laser printer 15 years ago.

Now, I’m used to this scheme with ink-jet cartridges — it’s the old razor blade model. The idea is that you’re not buying a shaver, but in fact, a subscription of sorts, to blades. It’s a recurring revenue model and seems to work for razors. In the context of shaving, it is the blade that has the value — consider the 5 bladed, Fusion razor as an example. If I want a close shave, I focus on the blade. The handle has little value except to enable the blade to do it’s job, but if I like the blade, I will buy and use more.

But in the printer world, it doesn’t apply that easily. At least it did apply 15 years ago, but doesn’t apply today. Why not? If we look at the printer as the handle, and the ink/toner as the blade (recurring revenue stream), it is the handle (printer) that has the real value. The toner/ink only enables the printer to do it’s job.
Also, the “handles” get better and better every year. My little laser printer from last year has been replaced by a better model that is faster and has a couple of additional features as compared to mine and costs about… you guessed it…$79.

But even more important, there are many other printers on the market that I can choose from. Aside from basic laser printers such as the one I purchased, there are colour printers, printer/scanner/copier combos, networkable printers, etc. etc.

The cost of these printers is, in my opinion, incredibly cheap, far below what I believe it costs to make them. I saw an Epson color ink-jet printer/scanner/copier on sale for $29 recently. Think about that. What other technology can I get for $29? Not much. A router. 2GB of RAM. Some flash memory. A video game. A full single colour ink jet cartridge!

So what did I do given this dynamic? Instead of buying a new toner cartridge for $99, I decided to spend $10 dollars more and bought this baby. It prints at 2400×600 dpi, scans, copies, OCRs text and much more. And yes, it comes with a toner cartridge.

So, here’s the question. How viable is this pricing model? Granted, I’m a light user of printers at home. And if I run through 1 or even 2 printer cartridges a year, I’m going to benefit every year from better printers at cheaper prices. I fully expect that a year or two from now, I will be able to get fully networkable, colour laser printer for about what I paid for my monochrome printer this year. How is this sustainable? Or am I in the minority of users who don’t print very much and thus can benefit from such low prices?



Measuring the selling cycle

When I talk to Product Managers about Win/Loss Analysis, one of the first steps I suggest is to analyze the sales funnel to find out where we are losing traction. (Normally I’m focused on places we’re losing traction, but the same thinking applies to figure out what’s working.) From there, we design the win/loss analysis to focus on the stage in the selling cycle where we are having the biggest problem.

The trouble is that funnel ratings are all over the map. There are so many problems … where to start? Some of the most common problems I’ve seen are:

  • sales people don’t use the CRM system reliably, so it can be very time consuming to determing where we are losing, or getting, traction
  •  the ratings systems measure activity by the sales person, but don’t measure activities that the customer performs. Customer activity is a meaningful indicator and should be the primary thing we measure.
  • the resolution of the ratings systems are too high or too low. If there is no rating between “we know their name” and “onsite presentation”, then we really don’t know where we’re at with the top of the funnel. Similarly, if we have too many ratings, the sales people will stop using the ratings, or they will be used unreliably.

As I have said before, I like the CustomerCentric approach to selling. They outline a good way to measure activity throughout the funnel; to advance to a higher rating, the customer needs to agree to something or take action on something, and the CCS approach holds back valuable resources, information, and expertise from the prospect until they perform those actions.

The truth is though, it’s more important that your company trains, uses, and enforces some kind of sales process. Just using one is more important than which one you use. And even if your sales people don’t use a disciplined approach, you can use a framework like CCS to do your own querying for specific opportunities.

Later this week I’ll describe a high-level framework that I like to rank progress through the selling and buying cycles.


Product Manager vs. Product Management (part 3)

How important a role does Product Management play in your company?

Is it truly a strategic role, or is that just what is written in the job descriptions when hiring PMs?

Who sits at the table?
Does Product Management report directly up to the CEO, or does it report through Marketing or Engineering, or heaven forbid, up through Sales. Not that I have anything against the Sales orgs in companies, but if Product Management is reporting up through Sales, the company doesn’t understand the role or the benefits Product Management can provide.

I view Product Management as a key function in a company that should have VP representation at the Sr. Management level. i.e. Product Management should be on par with Sales, Marketing, Engineering, Finance etc. and should not report up through any of them. If that is not the case, then that means that the company views Product Management as subordinate to these other groups and not worthy of “a seat at the table”.

It means that the influence Product Management will have will be subordinate to the influence these other groups have. For example, if Product Management is part of Marketing, and Marketing consists of Corporate Marketing, Product Marketing, Field Marketing and Product Management, guess how much focus and attention Product Management will have from the VP of Marketing, let alone the Sr. Management team?

Are PM roles defined clearly?
Second, it’s very important to clearly define the duties and responsibilities of Product Management and demarcate them from analogous duties that other team may have.

For example, when talking about Competitive Analysis, one must distinguish between the types of competitive analysis that, for example, Product Managers need to help define future releases of products, and the type sales teams need to compete on competitive deals. The end audience for those analyses is important in deciding who will create the particular outputs.

Sales teams need competitive information so they can position products clearly and respond to prospect questions or objections. Sales people may need high level “kill sheets” that list the key benefits and strengths of their offerings, and the key weaknesses and threats of the competition. Sales Engineers working with Sales Managers may need more detailed technical feature/functionality information. This is typically the job of Product Marketing.

Product Managers need very specific information about competitor’s strategic direction (and roadmap if possible), product functionality, limits or shortcomings, as well as key differentiators. i.e. the gaps between what the competitors does (or will do) and what the PMs own product(s) do and will do.

It is based on this type of detailed information that PMs can make the appropriate decisions on how to invest the time and efforts of the development teams to produce future releases of product. But, this kind of information is, in itself, not useful for sales teams.

Now, who can provide this kind of information for Product Management? Likely only other members of the Product Management team — perhaps Technical Product Managers, or Solution Architects or Technical Competitive Analysts — because other groups, such as Product Marketing, or Sales Engineering don’t have a vested interest in doing this work. They have other goals and objectives to focus on.

How to define the roles well?
The question then is how can the roles of the Product Management function be defined for maximum efficiency and benefit? Take a look at the following two diagrams. The first is a relatively well-known Pragmatic Framework diagram from the people at Pragmatic Marketing.

pragmaticmarketing.jpg (click to enlarge)

This diagram defines a number of possible activities ranging from Strategic to Tactical, in various categories such as Market Analysis, Qualitative Analysis, Product Planning, Sales Readiness that various people must complete during the product definition, development and launch cycles. Notice that it does not explicitly define the time frames in which these activities must be enacted, nor does it provide any specific order in which these activities must be completed. It is a generic framework diagram that can be used as a basis for defining the Product Management function in a company.

The second is a not so well-known diagram by yours truly.

pmdeliverables2.jpg (click to enlarge)

This diagram is almost orthogonal to the Pragmatic diagram. It lists specific deliverables that the Product Management function must deliver on during the product definition, development and launch cycles. It is categorized by stages in the development process and not by functional area ranging from strategic to tactical. It is, in fact, a specific implementation of the above Pragmatic framework diagram, tailored to a particular company’s need. Your company may have different needs and thus a somewhat different diagram.

This diagram, backed up by a roughly 20 page document describing each of the deliverables in the grid, down to who participates in completing them and who accepts the deliverables that are generated at each cell in the grid, describes very precisely what Product Management does, and equally importantly, what Product Management doesn’t do. Left out of this diagram are specific activities such as working with sales to help close deals or even, for that matter, visiting customers/prospects. Those are fundamental things that must be done as part of the job and feed into the deliverables listed in the diagram.

So, why go through the exercise of creating the diagrams and supporting definition documents? Well, if you truly want to build a Product Management function in your company then the first thing you need to do is clearly define what that function is responsible for. By defining it this way — what needs to be delivered when, to whom and by whom — the focus is placed on the outputs and those dependent on the outputs (the what) as opposed to the specific tasks that need to be completed (the how). Put another way — the people who depend on Product Management to do their jobs know well in advance, what to expect and when to expect it, without placing specific restrictions on how those deliverables must be completed. That is left to Product Management to decide.

Sounds like a model of efficiency to me. And isn’t that what you’d expect from anyone who has a seat at the Sr. Management table?


The rest of the series
Product Manager vs. Product Management (part 1)
Product Manager vs. Product Management (part 2)
Product Manager vs. Product Management (part 3)
Product Manager vs. Product Management (part 4)
Product Manager vs. Product Management (part 5)
Product Manager vs. Product Management (part 6)

Why Choose This Feature?

Recently I finsihed reading Why Choose This Book?: How We Make Decisions, by Read Montague, a fascinating book about how the brain makes decisions. It brings neuroscience, biology and computer science together to explore some of the latest ideas in how the brains actually makes decisions.

Montague spends a lot of time going over the notion of value and how measuring value is implicit and essential to every decision the brain makes. For example, when you train a dog using rewards the dog eventually obeys because it transfers the value measurement from the act of getting food to the command itself – the dog’s brain actually reprograms itself to see the command as being as good as getting food. (The cynical among you can go and check out What Shamu Taught Me About a Happy Marriage and how to apply these techniques more broadly.)

The book got me thinking – bringing in a value measurement is exactly what Product Managers do in product-oriented decision making. Why choose feature X over feature Y? Because we have some way of measuring the value of each feature. Too often we use an implicit value (“We added for support for AIX at my previous job and it never got us any sales”) but we often manage to do better (“35% of prospects said they would use the product on AIX”). But either way, Product Management is about making decisions by measuring value.

The End of Infrastructure

Yesterday Amazon announced Amazon SimpleDB, an on-demand database service similar to their EC2 and S3 services. With this final piece of the puzzle, Amazon has put an end to the need to own server infrastructure.

Now, don’t get me wrong, Dell, HP and IBM are hardly about to go out of business. But until now one of the biggest barriers to entry in some types of enterprise software was the capital cost of servers (which was already at a historic low). With this on-demand database service, any web-based product you can think of can be deployed without spending a cent on infrastructure. Regardless of what kind of software you sell, today your competitive differentiation just got a little bit smaller.