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.
Changing the way you think about products
|Design-in Rapid Market Adoption - Part One |
|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. |
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?
Rapid market adoption should be a priority for every product team, yet the critical components for achieving market success are rarely laid out in the specifications. Your question does not have a quick and easy answer. "Time to market" (when a product ships) gets a lot of attention these days and the importance of speed cannot be overlooked. Yet, an even greater source of risk for new products is time to revenue (time-to-market + sales cycle). In fact, for new, innovative products, delays in the sales cycle can be more catastrophic than delays in the development cycle. That's why we encourage product teams to pay attention to factors than can accelerate the sales cycle. In fact, we would like to respond to your question by highlighting four barriers to market adoption that must be recognized and expressly addressed in the early stages of the product development cycle for a product to succeed.
In this issue, we will address the first two barriers; integration with the customer's systems and processes and information about the product that substitutes for a product test drive. In the next issue, we'll take up your question again and discuss the organization and change-in-behavior barriers that are equally important for assuring product success down the road. Your role as a product manager is to help the team understand the implications of these barriers to adoption as they relate to the specifics of your product. Get it right and you'll speed time to revenue. Skip it, and you'll be in a scramble to support sales and justify missed projections.
The customer perspective:
Product teams need to put themselves in the customer's frame of reference in order to really understand the obstacles that will face their product once launched. That sounds simple enough, but the reality is that it takes a conscious effort to step out of a developer mindset and see the world from your customer's point of view. You, as a product manager, have a critical role in helping the engineers see the entire context of how a product will be sold, delivered, used, and supported, rather than allowing them to dwell in the narrow confines of the functional specification. In order to do that, you really need to know something about your customers. A simple exercise is to see if you can put names and faces on the hypothetical "market" identified in your business case. Product development is complex and there are many perspectives to keep in mind; company strategy, technology roadmap, competitive landscape, resource constraints, and so on.
The whole product:
Once you start thinking like a customer, you begin to get a different sense of "the whole product." From the customer's perspective, the product is "hired" to help them solve a problem. If solving the problem with your product demands too much change in how they do their jobs, their conclusion may be that it will be too much trouble to try, or worse, that your product doesn't work. Much as you would like to think that you are defining the product, a definition (and expectation) already exists in the mind of your customer. It helps if you and your team are in sync about the notion of "the whole product." Think of it as, the whole product is whatever is required for the customer to get the value out of the thing they have purchased. Until a customer takes delivery of the product, figures out how to use it, and incorporates it into their systems and process, you don't have a whole product.
There is actually a cultural shift that needs to occur that starts with acknowledging that a "panned out" perspective is critical. With a wide-angle view, developers get a better sense of the product's context, what implementation and integration barriers exist, and how the delivery organization can be enabled, through informed product development decisions, to overcome these inhibitors to product success.
When you talk about four barriers to market adoption, it sounds to me that you are going beyond features and functionality. What exactly should I be looking for?|
Let's focus on the first two barriers; integration with the customer's ecosystem and the information that may have to substitute for the product through certain parts of the sales cycle.
The integration barrier: New products are almost always purchased as a component of a broader solution and must therefore be integrated with existing systems and processes. If the benefits of a new product are hard to achieve because of difficulties in integration with a technology or platform at the customer site, the sales cycle will certainly be extended. At the same time, compatibility issues are likely to be verified and in the worst case, sales may be lost because change starts to feel risky. The product design team needs to construct a detailed understanding of where the product will be used and how to create a path to seamless integration into the broader solution.
A good way to think about this is to consider something we call the "installed base" challenge - where a previous version of a product has become so entrenched and customized that it is almost impossible to make any changes. Plug-electric vehicles provide a great example. First of all, the "plug-electric" component is just a variation in the power train of a conventional vehicle. Some obvious constraints are that the battery, wiring and engine interface need to fit into existing chassis and body designs. But beyond that, stepping outside of the car there is the tricky question of where to "plug-in?" Or put into technical terms - how to interface with the electrical supply? Is there an assumption that customers have garage parking with access to high-current electrical outlets? Are special plugs and cables required? Will those be included with the car or sold as a separate "charging package? Will the garage fuse box need to be upgraded to charge my car? These are all important questions to be asked in the design phase of the product.
The information barrier: Sometimes test-driving a product before it is launched presents a challenge, either because the product does not exist in a form that can easily be tried or because substantial investment is required to try it (installation in a production environment, as an example). During the sales cycle, information about the product often substitutes for hands-on time with the product. Yet, consider how little time and attention is paid to creation and presentation of this critical information. Most engineers do not recognize or sign on to this as a priority nor do they take responsibility for producing quality information as part of the development process. The assumption is that "marketing" will take care of it later. Product managers play a vital role in helping the design team recognize the importance of accurate product information and that this information will take many forms (e.g. demos, beta test documentation, online installation support). We think you'll agree that many a vendor has won the sale based on the quality of the information presented about the product, rather than the inherent quality or functionality of the product. Look at what's happening with those plug-electrics. None have been delivered yet - but our expectations (hence, our definition of the product) are being formed based on information about the products. With all the investment in battery technology - what are the car companies doing to get us ready to make decisions about these cars?
Can you address how these barriers translate into the technical specifications for a product? How do you make decisions about what to add to the product and won't this take the design process off track?|
On the contrary, a thorough understanding of the customer's perspective should help make the design process more accurate and more productive. Getting the requirements right is so much more efficient than building features that have no value to the customer. It's the product manager's job to understand the business implications of decisions in the development project, and to quantify and communicate those implications in a way that keeps things moving. |
Look for the second part of the answer to Gina's question in the next issue of the MIDIOR Mailbox. We'll consider the implications of a product crossing boundaries in the customer's organization and why changing the way users think about their jobs may be a bad idea.
|Get an Article|
To see whether your product management organization has the roles and functions covered, take MIDIOR's 41 question heath check ... |
click here to download the article
|Visit the Blog|
|The Product Line blog is all about great and not-so-great products, includes tips from the trenches about product management and occasional witty commentary from the MIDIOR team ... click here to read the latest posts |
|In the Next Issue|
|Part Two of Design-in Rapid Market Adoption considers how to address important issues that come up when the sales and implementation process crosses boundaries in the customer's organization and why changing the way users think about their jobs may be a bad idea.|
|Ask a Question|
If you have a product development or product management question for the MIDIOR team,
send it to us.
|Share a Copy
|If you would like to share this newsletter with a colleague, click here