If you understand the important market problems, you can make a good product. If you understand how important each problem is, for each group of customers, you can make a great product. If you’re new to this series, go back and start at the first article, we’ll wait for you right here.
Overall Product Comparison Process
This is a relatively long series. Each article will start with a recap of the overall process.
Getting useful information from comparing products requires you to:
- Introduction & Overview (so that the step-numbers align with the article numbers)
- Identify your customers.
- Articulate the problems they care about solving.
- Determine how important solving each problem is, relative to the other problems, for your customers. (This article)
- Characterize how important it is for you to solve the problems of each group of customers.
- Discover which (competitive) products your customers consider to be your competition.
- Assess how effectively each competitive product solves each important problem, for each important group of customers.
With this information, you can create a point of view about how your product compares to the others.
Important Problems
In the previous article on defining market problems, we identified 6 personas / contexts by which we would compare the kindle fire with other products.
- Tina - A hi-tech prosumer who is using the device to get smarter about the latest trends in her industry
- Tim - A hi-tech prosumer who is using the device to enjoy niche fiction content, particularly comics, e-zines and self-published works
- Kenny - A typical kindle user who is using the device for his work in the finance space, studying proposals and business plans, etc
- Karla - A typical kindle user and voracious reader who is using the device to eliminate the large pile of books on her nightstand
- Chris - A basic consumer who would is studying business in college
- Christina - A basic consumer who is in a book club, and who is always reading the latest best seller
The reason it was important to identify contexts is that the important aspect of personas is to identify groups of users with homogeneous perspectives on the relative value of solutions to particular problems – and the three personas previously identified would place different values on the solutions, depending on the context in which they were using the device.
Revisiting the Market Problems
We also identified a set of problems that these personas would want to solve.
- Read Anywhere – Be able to read content in multiple physical environments / on multiple devices, and not lose my place in the book.
- Annotate – Be able to annotate / highlight what I'm reading for future review.
- Talk About It – Be able to have conversations with other people who are reading what I'm reading.
- Find More to Read – Make it easier for me to find other content that I would like to read.
- Subscribe – Be able to subscribe to magazines / newspapers / blogs / serial publications.
- More From My Network - Be able to read what people I trust are reading.
This process is iterative, and in reviewing the 6 problems above, a valid question is – are problems (4) and (6) different versions of the same problem? When writing requirements, it is important to specify the problems and not the design. This is a tricky one, as it blurs the line between requirements and design. Reasonable people can make either of the following interpretations:
- The market requirement is to “find more to read” by any means necessary – it could be through receiving recommendations from the user’s network, or it could be based on some not-specified “black box” heuristic and scoring algorithm. These two requirements are duplicates.
- Yes, ultimately the user is trying to find more to read, but this is actually too abstract – consider the goal of “enjoy using the device,” which is also the ultimate goal, and too abstract to be useful in guiding the product creation. Asking people you trust for recommendations is a well established practice for finding reading material, and people make the distinction that it is inherently different from, and provides unique value relative to other approaches (like finding similar products, or “people who bought this also bought this other thing“).
Based on research I’ve done for previous clients (primarily on findability and recommendations in an eCommerce context), my personal perspective is that these problems are distinct, and should be treated differently. This is one of those Art of Product Management situations, where different product managers can, will, and should reach different conclusions. For this analysis, the problems will be treated distinctly, and the data that I invent will reflect that I believe these problems would manifest with different importance for different personas in different contexts.
In contrast to the above analysis, problem (1) conflates the two notions of “multiple devices” and “multiple environments.” People familiar with eInk technologies and Amazon’s Whispersync technology may see these as independent solutions to reading in direct sunlight, and moving from device to device respectively.
I’ve combined these two ideas, primarily because of the influence of this presentation about multi-screen strategies from Precious , a design and strategy consultancy.
[image from Precious article]
My interpretation is that the notion of device shifting is something that is intentional – use the right device for the right environment – and not arbitrary. Based on that, and the technologies that enable reading in different physical environments – like direct sunlight or a dimly lit room – should be evaluated as part of implementing a device-shifting strategy, and not independently.
Combining these two (in this example) is an opinion-based decision, just as keeping problems (4) & (6) distinct is an opinion based decision. If the data you gather in identifying problems leads you to combine or separate those problems, do so.
Gathering the Data
In the previous article on identifying market problems, I indicated that you are using a mix of qualitative and quantitative data-collection techniques to identify the problems. It is during those activities that you also quantify the relative importance of solving these problems.
Innovation Games are a particularly engaging way to gather this type of information [disclosure: while I haven't formally done work for the company, I have worked with and know and respect the founder Luke Hohmann , and likely will work with him again in the future]. I’m including them here because they have worked for me. A couple examples:
- 20/20 Vision – get customers to put solutions to the problems into relative order (for them). Effectively, a card-sorting exercise.
- Speedboat – the relative priority insight you get from this game comes when people put anchors at different depths, indicating the severity of a particular problem.
- Whole Product – this brainstorming game can also be used to identify what people perceive to be Must Be (table-stakes) capabilities of your product.
Surveys can also be used to gather data when you need to get feedback from larger numbers of people, or are operating in an environment that is less collaborative. A simple approach – ask the question “How important is it to you to solve problem X?” Read up on Likert scales to understand the dangers of asking this type of question, and determine if you need to bring in someone who is an expert at survey design to minimize the impact of bad survey design in your results.
Quantifying the Results
Using the word, quantifying, may not be wholly accurate here – it implies something scientific, when really you are synthesizing the data you have received, in order to eventually determine the relative importance of solving (or improving your solution of) specific market problems. A made-up word like numberifying might be better. If quantifying, used in this context, causes your head to explode, please comment below – I suspect this might be a hot-button for folks, but I’m not really sure if it is.
[larger image]
The above table shows hypothetical data representing the “quantified” relative importance of having a solution for each problem, to each persona / context.
For example, Kenny wants to use a device to review and annotate proposals and business plans – internal company documents. He can do this on any of a number of devices, but the ability to do it “anywhere,” as long as he can annotate, is what really matters to him. He’s not at all interested in capabilities to find more to read, discuss what he’s reviewing, or subscribe to new content.
For Christina, however, the act of reading is more social than private. She is not worried about making notes in what she reads or subscribing to new content – she’s reading books and talking about them with her friends.
Gaining Insights
We’re not to the point in the series where we can actually compare competing products effectively yet, but you can already start to get insights. Imagine you are designing a product for Christina. Your business case is about going after the “Oprah book club” audience, and Christina is your target user. You already know which problems are important to her, and more importantly, which problems are not important to her. You can completely eliminate the subscription and annotation capabilities from your product and create something that Christina would love.
This step alone allows you to avoid the elastic user problem.
Usually, you aren’t able to design a product for just one user. You can’t be all things to all people. This is part of the analysis you have to do to determine what to build first – identifying the relative importance of problems to each persona. The next step is to figure out the relative importance of each persona. Combining the two allows you to understand the overall relative importance of each problem.
Summary
Creating a great product for your customers means not only knowing who your customers are, but also knowing which problems they want to solve, and among those problems, which ones it is most important to solve or solve first. When comparing your product to competitive products, the best measure is one that compares the products based on the most important problems for each group of customers.
Recapping the overall flow of this series of articles on product comparison
Getting useful information from comparing products requires you to:
- Introduction and Overview (so that the step-numbers align with the article numbers)
- Identify your customers.
- Articulate the problems your customers care about solving.
- Determine how important solving each problem is, relative to the other problems, for your customers. (This article)
- Characterize how important it is for you to solve the problems of each group of customers.
- Discover which (competitive) products your customers consider to be your competition.
- Assess how effectively each competitive product solves each important problem, for each important group of customers.
With this information, you can create a point of view about how your product compares to other products.
