The Midior MailboxMidior
Volume 4 Issue 2
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

Part Two: Get Into Your Customers World

Background: 

Since so many of the questions we get from clients relate to the challenge of defining requirements, this year's series of MIDIOR Mailbox newsletters is focused on this very important topic. Over the course of the year, 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.

 

Studies suggest that the overall success rate for new products and services is well below 50%. Since we know that getting the requirements right improves your product or service success rate, it also makes a ton of difference in the return on your investment.  This year, we are offering a step-by-step approach that is actionable for both products and services and are sharing some key tips from our former lives as product managers and developers as well as lessons learned from our day-to-day work with clients.

 
Our last issue focused on the importance of starting with CONTEXT in order to establish the "whys" of the product or service initiative in play. 

MIDIOR's Answer, Part Two

After CONTEXT, the next most important thing is to UNDERSTAND YOUR CUSTOMER'S WORLD.  Sometimes this is called "eliciting requirements." While there are many useful methods that have been put forward as best practice, from Voice of the Customer (VOC), to focus groups, from surveys to software, none, on their own, can be counted on to complete the job.

 

We think about requirements elicitation in a manner that aligns closely with the basis for Agile development methodologies, valuing conversations and communications over tools and processes and accounting for iteration in each step along the way. In fact, this approach can also be found in the construction industry whose underlying premise is that it is impossible to "elicit your customer's needs" in a single step or without actually showing them something that they can react to.  Rather, it is a conversation and an iterative process filled with dialogue, visuals and models and lots and lots of questions.  If you are building a house, you would expect lots of questions from the architect about its intended uses and what your family looks like.  You would be shown pictures and drawings that are refined and tuned until you can picture yourself standing in the kitchen or walking through the halls.  You would NOT provide your requirements through a survey or a single conversation and expect to come back in a year ready to move in to your dream home.  Rather, you would expect to walk around the structure as it is being built, so that adjustments can made and design flaws resolved along the way. Keep in mind that customers may not be able to describe for you what they want and it helps to show them something to react to.  If Henry Ford had asked his prospective customers what they wanted him to build next, they would have likely said a better horse!  Eliciting the true VOC is hard and few people have the patience and aptitude to do it well.  With these considerations, here is our recipe for engaging in a meaningful dialogue that will help you understand your customer's world.

Never assume that you know anything and park your belief system at the door. The key here is curiosity.  Consider this a path of discovery - a learning exercise, not a formula. We like to think of ourselves as investigative journalists who are given a piece of information and then we go chase down the evidence. Start by getting comfortable with knowing that you don't know what you don't know yet and accept that you will never know everything. This is the moment to stop thinking about "product" or "service" and to instead think about the customer's problem. By taking a random walk in the park with the customer through dialogue you should get a close enough look at the problem to validate the answer. 

Watch your customer: Watch the buyer and the user of your product or service. A common approach is to start by following a customer around for a "day in the life study" and document the process. This is a good first step but remember that on its own is not sufficient. You will certainly come to understand the customer's to-do list and their habits, which is a very important input but you will not know what they are thinking. 

Talk to your customer: Start a conversation. It's a good practice to put a stake in the ground with a visual or a shell of a hypothesis and go from there. But first you will have to select a set of people to converse with. Typically we do this by creating a visual map of the customer's food chain to define the various constituencies (their customers, partners, competitors, vendors and employees). Then we have at least one, and preferably more, conversations that provide a data point for each one. We look at who touches the customer in the distribution or sales of the product as well as in support and development of the product. Building your knowledge about the customer happens when you engage in a dialogue that gives you insight into their business process. That's why structured surveys can't help you on their own; they don't give you the opportunity to ask the next question nor do they allow you to anticipate what that question should be before you ask it. We have found that there is simply no substitute for the in-depth discussion (aka interview) and asking the right questions. Let the dialogue move along without too much structure and listen, listen, listen. We prefer discussion guides over a long list of questions, transcripts over a list of answers.

Ask enough questions to walk in your customers' shoes and look through their eyes. At this stage there are no "should's," just what is. Sometimes it's tempting to latch onto the first piece of evidence and form a conclusion when there is still much to know.   Accomplished investigators have the confidence to take their time and know that asking all of the questions will uncover the real truth. Don't limit your questions to the perceived problem but ask what they do during the day; what's hard, what's easy, where are the challenges? Sometimes customers have something they wish they could do but have already accepted that this is not possible.  If you uncover the need and it's a significant one you have hit the sweet spot of requirements.  Very often, it does not look like what you expected going in.

Recognize that it's harder for the winners: Once a company or product is successful, we find there is a tendency to file beliefs in a particular box and never return to untie the wrapping around the box to see what's really inside. Understanding your customer's point of view is not a task to be checked off along the path of new product development. Sometimes, early product success correlates with a growing distance from the customer. As the installed base grows, direct customer interactions for open-minded inquiry occur less frequently and it's easy to focus on other priorities. Keep in mind that it's an ongoing discovery process. And the same wide-eyed curiosity must apply even when you think you know your customers well. Their world is always changing and there is no steady state.

Once you have a picture of your customer's world, all you have to do is solve a set of problems in a way that the customer values and finds easy to consume and buy.  Sound easy?  In the next issue we'll look into how to use the customer insights you have gathered in a meaningful way to define product requirements.

 
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.

Share your insights about the product management discipline in your organization and get a free copy of the research study. See how your team ranks against the top performers.  Take the survey.

Go to The Product Line Blog
What does Johnny Carson have to do with product development?  It turns out, he's still an innovator.  Find out why...
In the Next Issue

So you think you have the customer's point of view? We'll cover what else is important, how to use the data and translate what you know into product requirements.

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

©2011 MIDIOR Consulting / All rights reserved

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