The Midior Mailbox Midior
Volume 2 Issue 3
A Product Manager's Playbook
border image
The Plays
border image
The Midior Team
Team MIDIOR
With 20 years of experience and leadership from 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

Design-in Rapid Market Adoption - Part Two 
Background: As the product manager for an industrial products manufacturer, Gina is responsible for the introduction of an important new product.  Now six months into the selling cycle, the process for closing new accounts is slow.  Certainly, poor economic conditions have been a contributing factor but the beta test for the product went smoothly and feedback from early customers has been overwhelmingly positive.
Gina1
Question
Are there key obstacles to market adoption that can be addressed by the product team in the development of a product or service?  Is there a way to design-in aspects of the customer environment that will influence sales success? What role should the product manager play in bringing the engineering team closer to the customer?
Example Photo
Dear Gina,
 In the last issue, we talked about the need for product teams to put themselves in the customer's frame of reference in order to understand the obstacles that will face their product once in the market. We identified four barriers to market adoption that, if recognized and addressed in the early stages of the product development cycle, can pave the way to success for your product.  

This is a critical subject. Long sales cycles are a tremendous source of risk for new products and anything you and your team can do to accelerate adoption contributes to the likelihood of success. The launch of a new product marks the beginning of the sales process and is often the time of greatest excitement as well as highest expectations.   And, since there is so much visibility, disappointments are often magnified and can be tough to recover from.  The most important piece of advice we can give, is to get your team and your customers ready in advance by addressing barriers to the sales process early in the development cycle.

integrateTo recap, we noted that integration with the customer's systems and processes is critically important so that the benefits of a new technology are easy to get to.  Ignore what platforms and software are in play where your product will be used, and your product's functionality and quality may be called into question. In many cases, a test drive of the product is not possible and information about the product has to substitute for hands-on time with the product during the sales cycle.  This barrier highlights the critical role that a product manager must play to help the design team recognize the importance of accurate product information and sales tools. Creating demos, beta test documentation, online installation guides and other sales tools are as important as developing the product itself.

Equally critical to consider in the design phase of a new product are the other two barriers which at MIDIOR we call the organization and change-in-behavior barriers.

organizationThe organization barrier: When the sales and implementation process cuts across organizational boundaries, the sales cycle becomes more complicated.  Different functional areas will look for different benefits from a product and will often require different justification and even returns on their investments.  By extension then, different buying criteria will be used by each of the parties involved when evaluating your product.  So the first step, and one that is often overlooked, is to help the entire product development team truly understand the various constituencies by mapping out names, titles and specific buying criteria.  Think through the buyer(s) (whose budget will be tapped to purchase your product), user(s) (who will use the product), influencer(s) (who will influence the sale), implementer(s) (who will be responsible for installing and maintaining your product) and any others that comprise this community of stakeholders. Once you've mapped this out (and sometimes this can go beyond the customer's organization and into their customers), you can begin to identify the priorities and evaluation criteria for each area. It's your job to help the product team digest this information and connect it to real attributes of how the product is designed, how it is delivered, how it is priced/serviced, etc. You need to be the expert on customers and how they purchase and use products like yours. Too often, we see product managers rely exclusively on charts and graphs of markets and market segments as their input to the development team when it is much more valuable to run through the various scenarios that might be encountered in client companies, even down to role playing discussions with the various characters in your stakeholder community. Great teams are able to absorb that knowledge so that it becomes embedded in the product plan and ultimately in the product.

behaviorThe change-in-behavior barrier:  Is your product so innovative that customers need to change something about the way they do business in order to take advantage of what you have to offer?  We know that this sounds like a good thing, but in fact, more often than not, it is an obstacle to sales. Most people find change difficult, and there are often very good reasons why their current behavior works for them. It is easy to underestimate the cost and disruption that can occur from your new product or even your idea of a beneficial enhancement. In addition to being a significant barrier to the initial sale, this can also limit the widespread (and successful) adoption of your great product.

Take for example, an innovative content management system that offers significant benefits and cost savings in the writing and compilation of the thousands of documents required for a drug regulatory submission.  If the product templates are not presented to users in the "word-processing" authoring environment they are familiar with, using the new software may actually result in more errors, lower quality and increase the time required to prepare a submission.  Or you might end up with users sticking with their old process, and creating a new step to manually convert their legacy formats into the new tool. No question that the new technology offers a better approach but, if it demands significant changes in user behavior, the benefits may never be realized.

Remember to get these considerations on the table as early as possible in the development cycle. Product teams often ask themselves, "what problem is being solved?" but they don't always follow through with, "how are customers solving this problem today?" Not because they aren't interested, but more likely because they see their product as the answer. However, while the customer's current method for addressing the problem may be a primitive, manual solution, it is serving its purpose and users are accustomed to it. So the critical question your team needs to address is, what will change when our product gets installed?

Gina2
Do you have any recommendations about how I can get the development engineers thinking like a customer?
Changing the mindset of developers so that they think of themselves within the larger context of how a product will be used is not a project-specific exercise.  It represents a true cultural shift for the organization.   Developers need to feel a responsibility for understanding the customer's environment, what the implementation and integration barriers may be and how to enable the delivery organizations to overcome those barriers.  Fundamentally, the focus needs to be on what it will take to get the product into customer's hands, rather than just on how to meet the target release date.
 
The first step to changing the mindset of developers is for you to be an expert. This is not an abstract concept.  If you have stories to share - do it. If you don't have stories to share then that points to a different problem.
Go to The Product Line Blog
What is a product? Sounds simple enough, but getting a tight definition on what is a product seems to be getting more and more difficult, especially when services are involved ...  click here to read this post
In the Next Issue
Where do great product managers come from?
Learn what to look for when you interview and know how to manage your champions to keep them on board.
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

2009 MIDIOR Consulting, Inc. Re-printing, re-distribution, re-publication, including to news groups without the prior permission of MIDIOR Consulting, Inc. is expressly prohibited.

2009 MIDIOR Consulting / All rights reserved
MIDIOR Consulting | 22 Putnam Avenue | Cambridge | MA | 02139