averting revenue cannibalization

Product Overview

Salesforce Shield, a bundle of 4 security products, brings in billions of dollars annually. However, the forthcoming release of a new product threatens to destabilize this revenue stream. Product Management asked for research into 1) pricing and packaging the new product and 2) how to provide additional value within the Shield bundle to avoid cannibalization.

As a result of my study…

1. Updated product roadmap: A new security product was locked in on the basis of my recommendation.

2. New help documentation: Technical Writing planned updated enablement docs to map customer needs to Salesforce products

3. Increased customer empathy: A forthcoming decision could damage customers’ trust in Salesforce—I emphasized this danger to senior management.

4. Propelled demand for research: By making this project a team sport, I built trust and received multiple new research requests.

“This was one of the best, if not the best, research presentations I’ve seen at Salesforce.”

- Senior Director of Product Management

Selected Challenges & Adaptations

Challenge 1: Highly technical product space

This project required me to interview subject matter experts (SMEs) on encryption, cybersecurity law, and data monitoring practices. Suffice it to say, there were a lot of details to digest. Realistically, I couldn’t become an expert in time for in-depth interviews.

Adaptation: I prioritized reading customer-facing help documentation and help forums to learn the customer’s point of view. This helped me talk the talk. I back-burnered studying the back-end functionality or product strategy until the analysis phase, as they aren’t relevant to the customer.

Challenge 2: Recruitment (Isn’t it always?)

Many companies use these products, but each company has few SMEs that inform purchasing decisions and create and implement policies. I could not recruit as many customers as planned.

Adaptation: I interviewed third-party implementation partners and internal sales employees in addition to customers themselves. Their collective experience with hundreds of Salesforce security customers acted as a proxy for a large sample size.

Challenge 3: Urgent need for insights

Adaptation: I invited all my stakeholders to listen in on my interviews, instead of making them wait until the end of the project to learn anything. This expedited their takeaways, and also increased the visibility of the research process and practice. One PM told me that he better appreciated the art of interviewing and follow-up questions.

Challenge 4: Different cohorts of data

The 3-cohort approach unfortunately meant that my data was not cleanly attributable to one customer or another. A qualitative coding approach would normally work for semi-structured interviews, but I needed something more creative.

Adaptation: First, I performed a rough affinity mapping to get a sense for high-level groups of takeaways. Then, I sorted these by which type of interviewee had responded, and eliminated takeaways that were only supported by one group of interviewees. Often, translation was required between data from different cohorts, as sales folks would describe a situation differently than the customer perspective. As much as possible, I looked for underlying causes and commonalities.

Deep Dive

Problem Area

Salesforce offers some security products out-of-the-box with a Salesforce subscription, while the Shield bundle of products carries an additional price tag. Shield brings in significant revenue, but the rollout of a new product — I’ll call it Product A to avoid sensitive information — may cannibalize the Shield bundle, and the company hadn’t decided whether to release it for free or not. Therefore, the Product A PM approached us with this over-arching research question: “how can we provide additional value with the Shield bundle?”

Methodology

With that as a starting point, I planned and executed the study. I interviewed customers to get deep into their expectations, needs, and jobs-to-be-done. And as a proxy for a larger sample size, interviewed Salesforce implementation partners and internal sales employees — people whose job is helping customers buy and use Salesforce security.

Findings & Recommendations

“None of the documentation is written to talk to security people. A bunch of types of people come to this [purchasing] decision, and [with] no singular document, it becomes really hard to reach consensus.” - Customer 1

Without divulging sensitive information, I found two overall segments of Shield customers. The first segment has specific unmet needs that presented an attrition risk, so I recommended the development of Product B to shore up this gap in the product space.

Secondly, I found widespread confusion about options, use cases, and trade-offs within products. Even selling these products requires deep technical knowledge. As a result, I recommended the creation of publicly available and low barrier to entry guidance to map customer needs to Salesforce products. This would smooth out the selling experience and improve customer satisfaction.

Impact

1. Product B was locked into the product roadmap on the basis of my recommendation.

2. Documentation to map customer needs to Salesforce products was added to the Technical Writing team’s roadmap.

3. I raised the alert that Product A would cannibalize the Shield bundle for a large segment of customers. The final decision is above my pay grade, but this changed how the product organization thought about the why of customer demand for these products.

4. I built relationships and spurred desire for more research — I received multiple project requests. Throughout the project, I invited stakeholders to interview sessions and provided rolling updates. This established trust, and the team saw the added benefits of more research.