There is no one product that best fits every customer’s requirements, yet the goal of product management is to develop requirements that address the greatest portion of the market possible. Of course, it is neigh impossible to create a solution that is optimal for every customer. This raises a couple interesting questions. For any given project, how much of the addressable market’s requirements can be met? How are such trade-offs made, and what is the role of sales in all this?
Security As a Requirements Trade-off Example
A good frame of reference for requirements trade-offs is wireless security for medical devices. There is a plethora of security standards, and the target is always moving; new standards are implemented, some of which have varying degrees of reverse compatibility with previous generations of hardware, and some require upgrades or replacements to work. Likewise, different markets have different requirements. For example health care has HIPAA, the credit card industry has the PCI data security standard, and other industries have their own requirements. Next, individual customers make security choices based on the infrastructure installed, how current their infrastructure is (is it currently sold by the vendor, is no longer sold but still supported, or is it discontinued), and what security standards they chose to adopt and enforce (sometimes chosen capriciously, often enforced vociferously) in their enterprise.
Like the workflow automation that wireless connectivity enables and the necessary security required to support it, there is a finite degree of requirements variability that can be practically implemented -- systems can't be everything to everyone. Creating a product that address 100 percent of the target market is virtually impossible. Trade-offs must be made so that a product can also reach cost of goods, design budget and time to market objectives.
The flip side of this is the fact that a product must offer a certain threshold of features if it is to meet the sales forecast associated with the R&D project. Much of the eventual success of a new product is dependent on the quality of trade-off decisions that are made. Following a certain process can increase the likelihood of good trade-off decisions that maximize your addressable market. First, a solid understanding of market requirements is needed. For workflow, use cases is frequently the best method for requirements gathering. Features like security can be gathered by straightforward research, customer surveys and interviews.
Requirements Variability: Trade-offs Done Right
In any requirements gathering effort, the majority of requirements will be found to apply to virtually the entire market. Also a subset of requirements will vary noticeably from site to site. This variability must be quantified if you hope to determine the percentage of addressable market available to your resulting product, i.e., the financial impact of your trade-off decisions. Many of these variable requirements can be realistically supported in the resulting product if they are properly identified (by designing in multiple ways to do things). Sometimes though, you have to draw the line and exclude certain options or features due to practical considerations - you know, like meeting budget and release dates.
These variable feature trade-offs are easier to make when you can show an association to the trade-off and the portion of the market that is impacted. A variable that affects 40 percent of your target market is probably hard to justify as a trade-off. But without the data -- design and time to market impact on one hand, and how much of the addressable market is effected on the other -- a rational trade-off decision becomes a guess. All too often, these decisions are poorly informed and the resulting product fails to meet forecast.
Sales Impact of Trade-offs
Sometimes these trade-offs become account qualification issues. In this case the prospect that requires a feature you traded-off becomes disqualified as a sales prospect. In other cases, the trade-off creates sales objections that must be overcome to win the sale. This is an important distinction that’s rarely identified and built in to launch plans, marketing and sales training. In the case with some connectivity features, overcoming the objection raised by the feature trade-off requires knowledge and expertise frequently not held by the sales rep. These situations require a sales support specialist.
Let’s look at wireless networking security for an example. A couple weeks ago I did a security workshop for a group that included several folks from the same medical device company’s R&D group. They had a released product with security features that was acceptable to 80 percent of their addressable market. The remaining 20 percent were hospitals that had quirky or outdated security requirements that were traded-off by the vendor during the design process. At least some of these outlier requirements were traded-off, not because they were difficult to implement but because they were deemed insufficient to meet HIPAA security requirements by the industry in general (hint: here's an example of leverage to overcome some unmet requirements as sales objections).
This R&D group is under pressure from sales and marketing to “fix” their product’s security so that it can also meet the requirements of this 20 percent of the market. After some discussion to dig into the details, it turns out that there are many different security features that made up 20 percent of outliers, and the cost to meet those requirements exceeded the budget available (not to mention opportunity costs).
More discussion revealed that security issues were a common sales issue across all the companies and industries represented in my workshop group. Best practices discussed for overcoming security sales objections were early qualification and addressing the objection quickly in the sales process -- often before a competitor can get in and muddy the water. Another best practice was using a resource to over come security objections that is knowledgeable enough to “speak the language” of IT security.
We determined that this medical device vendor didn’t so much have a feature shortfall, as their sales force lacked the resources with the appropriate knowledge to successfully overcome the objection. This company had a couple European based security experts in their R&D group that were frequently pulled to the field to overcome these objections worldwide. Needless to say, this was both expensive and often deprived R&D of this important resource.
Trade-offs and the Necessity of Sales Support
Lots of medical device vendors use application specialists to support the sales process. These are often clinicians who’ve gone to “the dark side” to do product demos and training. Health care IT vendors also make frequent use of application specialists, due to workflow complexity and specialization. Adding connectivity to a product creates similar needs for expertise that falls outside the sales rep’s sphere of knowledge. Networking, systems integration and security are three common technical areas where sales reps need support. Insufficient levels of support will negatively affect sales, specifically the percentages of deals won.
So, here are the take-aways:
- When gathering requirements, identify those requirements that are variable across your market. Work those variables until you know just how variable they are, and have a handle on the major permutations.
- Associate your variable requirements with addressable market. Like a lot of product management this is as much art as science -- few have the budget or time to market to invest in developing statistically relevant data on each element of every variable requirement. Guessing or winging it is not art, just poor practice.
- Now make informed trade-off decisions. Apply R&D and time to market estimates to the addressable market impact of specific variables. You rarely have the chance to recast your projects forecast numbers, so choose wisely.
- Document the consequences of all trade-off decisions, especially those that impact how the product is best marketed and sold.
- Be sure your marketing and sales training tackles both kinds of trade-offs, those that disqualify a prospect and those that need to be treated as sales objections.
This is another installment of a series on selling connectivity. You can read the first installment, with links to subsequent posts, here.
Tim:
Your point about sales support cannot be overstated. When the traditional “device” sale starts to become dependent on connectivity and integration - vendors would be well advised to plan and budget for one or more classic “sales engineer” roles. This role has been overlooked by many device vendors. And even when considered, the sales engineer role is often deemed a luxury that the sales budget cannot afford. This is a short sighted view and I argue that device vendor can’t afford NOT to have one or more sales engineers supporting the sales process. As devices become commoditized, the sales differentiators are often directly related to connectivity and integration.
I’m fond of saying, “you don’t know what you don’t know.” And most vendors adopting connectivity don’t come to grips with many of the ways connectivity changes their business until after their budgets are locked in for the year. Sales support is a great example.
The need for sales support is often not identified until staffing decisions and budgets are already approved. When the need comes up, the executive has 3 choices: go back to his boss (usually the CEO) for more money and head count, get another exec to provide the needed resources, or try to get by with the resources they already have. Typically these types of resources come from either Sales, Marketing, or Service. As noted in the post above, sometimes these issues get pushed off to R&D.
The downside of asking for more money is easy to imagine. The risks of not properly supporting connectivity are largely unknown - at least by the exec looking to minimize their downside.
In short, insufficient operational support for connectivity results in a reduced sales and higher operating costs (often in both sales and service). A few secondary effects include longer sales cycles, sales rep turnover due to frustration, growing customer dissatisfaction, and disrupted R&D projects (esp. if they end up fielding technical sales issues).
Tim,
Reading your latest on MDDS and noting you like recent HIMSS Analytics Report talk about automatic device data flow from medical devices to EHRs without noting an RN validation step. I had just resolved this with Marc Holland at HIMSS before his untimely death.
What is your position on this. Do you not see this as a critical step or just silent on it?
Thanks!