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.