From target market to product definition using VOC
/
VOC Decision Model Sequence
The following example outlines a voice-of-the-customer (VOC) process we applied with a client developing a GreenTech product. The product had the potential to serve many market segments and perform many functions. The question for the development team was; "which segment would drive 80% of the functionality requirements and where could they get the fastest and biggest bang for their investment?" The goal was to accelerate time-to-revenue. They essentially had one bullet in their gun and needed to hit the target with the first shot.
We developed three decision models to focus the limited development resources and ensure we were right the first time with the first product. Further, the idea was to find the most valued features from a customer's perspective in order to optimize the very short target development cycle time. Following, is a series of vignettes that give some insight into the process.
Market Selection
We brought together a group of 15 industry experts, developers, and investors in a workshop to determine where to focus. After much discussion we agreed that the goal was to find a beach-head segment on which we could define the first product.
Like the beach-head at Normandy, it provided the foothold to land more troops (i.e. the second and third wave of product introductions) in the future. But without a beach-head we couldn't "launch the invasion." And without the first successful product launched into the market, we would have no going forward venture/funding. The challenge was to resist putting everything into this first product and delay its introduction until "we got it all right."
Market Segment Requirements (prioritized based on project goal)
We then described the characteristics of the desired segment. For example, we wanted one where the customers valued the most important aspect of our design; energy savings. Further we wanted a segment that would accept our current design and also have a short sales cycle. Both of these characteristics would shorten the time-to-revenue time which was the investor's primary driver. We prioritized (i.e. weighted) the segment characteristics using pairwise analysis. This generated a lot of rich discussion among the panel of experts and debates with the development team. The development team learned a great deal about the markets and what drove customer buying decisions in each segment.
Doing pairwise analysis of the market segments (above), then ranking market segment alternatives
This process gave us our ranked list of segment characteristics with "energy savings" weighing three times more than its closest driver. Not news, but an interesting discussion. The point was that the model focused discussion and removed position, personal, and expert power from the decision process and focused on a data-based discussion.
We brainstormed the possible market segments for the product. We ended up with more than 30 possible segments. We asked, "if you only had time and money to go after one, what would that one be?" To answer this we ranked each segment against each of the weighted market characteristics. For example, "Industrial: Heavy" segment saw "medium value" in "dimming," subsequently "medium value" had an associated numeric value on a QFD scale (9-high, 3-medium, 1-low).
Prioritized market segments
The decision model calculated these values to determine the "winning" market segments. Clearly the "Warehouse" segment was the winner. We did a series of dynamic modeling with the group to explore the impact of changing the weights of the segment characteristics. For example, what if "florescents are weakest" where the most important criteria for selecting a segment? How would this change the priorities of the segment alternatives? No matter how we "played with" the criteria, warehousewas always a clear winner.
Customer Requirements
With the warehouse segment selected we defined four potential customers in this segment with whom we could do VOC to determine the driving customer requirements and eventual product requirements. These four target customers later became beta sites to validate the new technology. This was effectively a co-development partnership between the customers and the supplier. We added a "light manufacturing" segment customer to the VOC mix to see if/how much their needs differed.
Key potential customers by market segment
Customer Requirements are specific NEEDS a customer has in order to solve some kind of problem. Product Requirementsand laterProduct Featuresare the MEANS to the END, in other words they are the way in which we will solve the customer's requirements. in Quality Function Deployment (QFD)terms... Customer Requirements are also called WANTS and Product Requirements/Features are called HOWS.
We decided to weight all four customers equally. Then we made visits to the customers to asked them what where the ten most important needs they had. In other words, what were the problems they were trying to solve that they could not solve today with current technology? We did not lead with product features and asked them to tell us what they "liked the most" about our solution, as we did not want to confuse the focus which was on their problems -- not out potential solution. Often this "feature-based-VOC"is a waste of time. You end up validating what you already know rather than finding out what customers really need.
Ranking customer requirements vs the prioritize key customers, which requirements appeal to each customer?
We then plugged in their rankings (1-10) for each requirement in order to determine the priority of their requirements. Once again, Energy Savingswere top of the list followed by Increased Foot Candles and Creating a Stable and Safe Working Environmentfor workers. Most importantly, it told us the proportional relationship between requirements, i.e. Energy Savings was twice as important to them than Controllability. This was not clearly understood by the team prior to this study. We went back to the customers with the finished ranking model and tweaked it with them further. This lead to more discussion and the continued uncovering of more nuances that helped during the refinement of the product definition (later).
Product Requirements
The final step in the modeling process was to determine the product features that would satisfy the customer requirements. We used the weighted/prioritized customer requirements from model 2 (above) as the customer input to the feature prioritization model. These customer drivers would influence the prioritization of the product features -- i.e. what features most contribute to meeting customer needs?
The bottom of the previous customer model (customer requirements) becomes the top of the product features model
The team already had a working prototype product and had already done their own assessment of what was needed in the market generally, but not specifically for the target segment and the driving customers they selected. Further, their assessment of need was from the technologies perspective, not necessarily from the customer's special viewpoint.
Ranking product features against customer requirements
We knew that the requirements for a product that would satisfy the needs of 30 segments was different than one that would meet a single segment's specific needs, but could that single segment drive 80% of the requirements in the other 29 segments? If we could solve this puzzle using a single representative (or driving) segment, we could focus the product and shorten development time. The resulting product would then be unburdened with trying to do everything for everyone on day-one. We know from experience that this is the primary reason for schedule delays as teams try and do it all instead of doing it incrementally, based on a time-phased product roadmap.
For example, there were a series of sophisticated features involving software and wireless functions that turned out to be of little value to the customers, at least initially. Not doing this would save the team a lot of time and R&D investment, so this "non-need" was good news! There were almost 100 product features that we considered variable, meaning they could be in or out of the product.
Prioritized customer requirements
There was a set of MUST HAVE features that were not included in the ranking model since these had to be in the product to make it "sellable."Each feature was ranked against each customer requirement. The model calculated the prioritization values for each feature.
The process confirmed the general belief of the team that they had guessed right, the 15 top features they thought should be in the product were confirmed by the customers through this process. They took the results back to the customers to confirm their interpretations and refine the model together. This dialog with customers further produced more learnings and insights for the team. The other interesting outcome was that the prioritized list of features provided a product roadmap of sorts for the successive product generations. The ~100 features were segmented into three groups, these represented the second and third generations of the product. The prioritized features provided an incremental roadmap for future product innovations.
The process quickly targeted the limited development resources on creating the right-product based on specific VOC. Stay tuned, the product successfully exited the beta phase and is in the final stages of manufacturing ramp-up. It has exceeded all performance expectations. Customers are estatic.