The Midior MailboxMidior
Volume 4 Issue 3
A Product Manager's Playbook
border image
The Plays
border image
The Midior Team
Team MIDIOR
Led by Founding Partners  Susan Loconto Penta and Michael Goldberger, the MIDIOR team is focused on  the discipline of product development and management, helping clients seize new opportunities and respond to changing markets.  
 
MIDIOR.
Changing the way you think about products

HIT THE MARK FOR REQUIREMENTS
Using the Data: Themes and Patterns to Define Requirements

Background
Since so many of the questions we get from clients relate to the challenge of defining requirements, the current series of MIDIOR Mailbox newsletters is focused on this very important topic. As a reminder, over the course of the series we are addressing the following core question:

How can we get better at defining requirements so that our products and services consistently delight our customers? We often get stuck on debating features that, in the long run, don't make a material difference to the product's success.

The previous issue of the MIDIOR Mailbox focused on how to get into your customer's world and drive the discussion to elicit requirements. Next we'll look at how to use the customer insights you have gathered in a meaningful way to define product requirements.

MIDIOR's Answer
Now that you have detailed transcripts in hand from your conversations with customers (or prospects), you need a way to organize this free-form data so that you can easily identify themes and patterns that may be important in defining the critical requirements. This is not a simple exercise, as a good discussion with a customer will follow a path that does not fall neatly into a list of check-off boxes that can be quickly sifted and sorted. This is in contrast to an online survey where answer choices are restricted and the questions are presented in the same order every time. An in-depth dialogue with a customer gives you an abundance of facts, encoded in prose, which may or may not be significant so even after you have transcripts, you may still not know what you don't know. One way to decode the free-form data is to create a spreadsheet out of the transcript (yes, this is possible). This is an iterative process which starts with breaking apart the dialogue into high level discussion topic areas and with each successive pass, parses it into more granular categories and subcategories. And this last point is important - there is no detail that surfaces in a dialogue that is too small to document at a granular level. More often than not, it's the small details that a customer may think unimportant that provide the clues on how to develop a stellar product. If you take the time to do this, you will ultimately have digested the transcripts AND will have created a way to communicate the free form information in a structured, quantified and actionable way.

In addition to parsing the details into a tabular format, we make sure to capture direct quotes from each discussion. The quotes may highlight expressions of interest or disinterest, likes and dislikes, perceived opportunities and pain points. We read these quotes carefully to catalog things that seem alike or different from customer to customer, since it's often the outliers that point to a need for further discussion. Analyzing quotes provides a great filter to assess if you and your customer are on the same page and really talking about the same thing during the course of the initial interview. Hopefully, at the end of each interview, your customer also agreed to a follow-up call if certain points need clarification. We never assume that one conversation gives us all of the information we need or even the right information.

Go beyond the buyer: You can be sure that all of the answers you are looking for cannot be sourced exclusively from customer or prospect interviews. As part of the process of capturing product requirements, you should talk to other internal and external stakeholders that will touch the product as it goes from the lab to the customer. For example, if we are capturing requirements for a software product, perspectives gained from developers, salespeople, technical support representatives and anyone that is part of the delivery channel may uncover reasons that the product is hard to buy, sell or use. We've seen product managers do a great job of appearing to "nail the requirements" yet down the road, the product fails to meet expectations because a piece of the puzzle that the product fits into was not considered. Be sure you have the complete picture.

Profile on multiple dimensions: Go beyond the interview and get creative about how to segment your customer or prospect base. Size of company, geography, specific behaviors of the buyer or user are good places to start, however, take the next step and push beyond the conventional. Take an example of two company profiles from the financial services industry: the product requirements for a financial services firm, $300 million in revenue, located in Greenwich with the employee base made up of traders with Ivy League degrees, will be different from those for an investment management firm, headquartered in Boston, that tops a billion dollars in revenue and employs a mix of traders and back office people. What we do know is that you can never assume that you know what the data is telling you until you triangulate on multiple dimensions.

Read between the lines: Know that the data does not always say what it appears to be saying on the surface. Now that you have granular information about the customer on multiple dimensions, take different cuts at the data, cross-hatching on multiple axes. This will help you categorize customers by their differences and similarities while themes and patterns should emerge as you look at the data in different ways. We view requirements definition much like the iterative process of work in the lab; we stake a hypothesis, create a "lab environment" to test it, use the data to validate or invalidate the hypothesis, source additional information, refine the hypothesis and then start the process again until we are confident we have a consistent conclusion that we can prove with facts.

In the next issue of the MIDIOR Mailbox we'll discuss how to decide what makes the final cut for your product requirements from the list that has been generated from this detailed look at the data.

For more information about defining product requirements, contact MIDIOR.

A New MIDIOR Workshop
Bring your product initiative to this one-day requirements workshop and build your team's knowledge and skills to generate accurate requirements, the first time and every time...get agenda.
Visit The Product Line Blog
Have you ever answered your phone with your nose? You no longer have to.
Find out why...
In the Next Issue

So you think you have the correct product requirements? How do you know what's important and what not to do?

border image
Ask a Question
If you have a product development or product management question for the MIDIOR team,
send it to us.
border image
Share a Copy

If you would like to share this newsletter with a colleague, click here

Follow us on Twitter

©2011 MIDIOR Consulting / All rights reserved

MIDIOR Consulting | 22 Putnam Avenue | Cambridge | MA | 02139