Comparing Products – Compare Products Not Specs (Part 1)

Recently, the gadget-reviewer crowd has caught on to something we’ve known for a long time.  Comparing products is not about comparing specs, it is about comparing how well the products solve problems that customers will pay to solve.  That begs the question – how should you compare products?  Read on to see the product comparison technique I recommend.

Inspiration

Writing about how to compare products has been on my backlog for about two years, as a key component of how to perform competitive analysis.  This topic is easily a chapter-length discussion, perhaps that’s what delayed writing an article-length discussion.  A flurry of recent articles, The Death of the Spec, Do Device Specs Really Matter Anymore, and Device Specs all discussed how the Amazon Kindle Fire will likely succeed, in spite of not having particularly good specs (specifications).  The first article also opines that Consumer Reports, because of its fixation on specs, has made itself irrelevant as a company providing advice to consumers.

John Gruber hits closest to the mark in his article where he says:

Combine this with a conversation I had last night after recording the latest Start With the Customer Podcast, about writing more frequent articles on my blog.

Product Management and Specs

The discussions are mostly centered on the utility of specifications, speeds and feeds, in informing a customer’s buying decision.  As Pragmatic Marketing espouses, we should be market-driven, with a focus on solving the problems that customers will pay to solve.  A screen resolution does not solve a problem, but an easy-to-read screen does – it prevents eye-strain and makes a long-session reading experience (like you would have when reading a book, versus reading this article) better.  Avoiding eye-strain is a problem people are willing to pay to solve – we’ve seen that with the success of products that use e-Ink technology.

Let’s look at how this example impacts what you do as a product manager.

You want your team to create a product that avoids eye-strain.  But you also know that you need to write requirements that are unambiguous and measurable.  We know from research that higher resolution displays (to a point) delay eye fatigue.  We also know, from Apple’s successful marketing, that promotion of a retina display (326 dpi, for a phone) is effective, at least with buyer personas, at addressing the perceived problem as well.

A “normal” consumer is not going to be able to make an informed comparison of the likely difference in eye strain over time – the problem the consumer actually cares about – when looking at the specs for a 225 dpi device and a 250 dpi device.  The authors of the articles are exactly right about that – but we, as product managers, already know this.

The problem comes when writing the requirements for your product team – do you just say “create a low eye-strain screen” and trust the team to pick a resolution that is effective? In an ideal world, yes, you would.  Someone (that someone may have to be you) on your team would do the research and come back and tell you that a 225 dpi interface will cause moderate eye-strain in 80% of people after 12 hours of continuous reading (but only 20% of people after 4 hours), and that that number drops to 20% of people experiencing eye strain after 12 hours when using a 250 dpi screen*.  You have an understanding of the value of a 250 dpi resolution over a 225 dpi resolution – an additional 8 hours of reading time for the majority of your customers.  Your customers will not know this (unless you tell them).  But you know it, and that’s enough.

Now you have to understand the incremental cost of creating a product with a 250 dpi resolution versus one with a 225 dpi resolution.  In this example, the incremental device cost is $25 per device for the next 12 months (given projected manufacturing levels).  At your target margins, this would reflect in an increase of $40 in device pricing to your customers.