Sales Enablement

Full disclosure, I work for Highspot -- but as a customer prior to joining the company, the product capabilities blew my mind. I loved it so much that when an opportunity to join the company came up I took it because that is how much I believe in it. I'm happy to answer any questions you might have, feel free to reach out. 

Copying my answer from the following thread: https://sharebird.com/does-anyone-have-suggestions-for-hosting-content-assets-for-the-sales-team-to-referenceuse We are currently looking into tools like Highspot, Showpad and Docurated. It allows us to create a central respository of managed and tracked collateral/content. Most likely leaning towards Highspot. These can obviously be slightly pricy so the other option is to keep a very organized Box/Dropbox folder that makes all content and collateral available to the sales team. This will make it difficult to track how things are being used, but is definitely a good starting point.

We currently use Highspot — before this we've used a number of CMS systems including Drive & Google Docs, Dropbox Paper, Percolate, and Docurated. We also evluated Guru and some others. We also use Confluence for internal documentation. No tool has been perfect — but we've seen good traction with Highspot. The biggest challenge imho is on the usage side and getting solid adoption of the tool for all use cases (remixing, pitching, etc). I want good analytics and an understanding of how sales assets are used. The challenge is that there are still a lot of people keeping, storing, and creating presentations on their desktop. It makes measuring performance and impact harder — and also drives me a little crazy on marketing rights (logos/permissions/etc). Also, if anyone has tips for how you measure and evolve marketing assets, I would love to talk. There is a lot of "I like this" and "I don't like that" or "we need this" but I would like to get a little more regimented to creating and optimizing assets.

We evaluated a lot of sales enablement / CMS tools - Highspot, Showpad, Guru and Seismic included - but the one that has stood out is Highspot to be honest. For me they have the right blend of usability for both marketers and sales people, combined with intuitive reporting so I can actually see what collateral/messaging is working. What we had before with an enterprise DAM (Egnyte) mixed with an organized spreadsheet to post the latest docuement links worked fine as far as getting assets to the sales team. But it defiinetly didn't help me be more effective at my job - so the ability to provie ROI and metrics for continuous improvment was the key factor. When Highspot showed me their 'Revenue Attribution Report' my mouth dropped and I just told the AE - 'this is how I'm getting my next promotion'. So yeah.. sold me.

I've used both Showpad and Docsend in the past.  Showpad has some additional capabilities that Docsend doesn't have but Docsend could not be easier to get the sales team and SDR team to actually use. I also put all of our gated content on Docsend which allowed me to sync visit times and view rates to Salesforce as activities e.g. John Smith and Acme Corp spent 3:51 reading Ebook X 

I know that this is sometimes an incredible challenge. I think the challenge specifically is around balance. A balance between: What are metrics indicative of your business / GTM goals? AND What you can control? This requires leadership buy-in from multiple groups — ideally they would understand Marketing and Product Marketing (this is not always the case!) Based on Your Goals, I would then identify metrics. Some examples below: * GTM / Revenue Initiatives —> Before and After Analysis (ideally based on something specific) * Content —> Content Metrics  * Support —> NPS 

Hopefully I don't make this answer overly complex.  I think the more important question here is what are you actively working on? Because product marketing can cover such a wide variety of activities and tactics, we can't exactly tell you which metrics would be important.  Greg Hollander and Derek Pando both had great insights to share when they spoke on a panel about the topic of prioritization in product marketing. The key takeaway there is to know what the greater organizational goals are, and align yourself where it makes the most sense for the impact you can have.  Example: Your company has great awareness and lots of leads, but isn't closing enough deals. In this case, there are lots of different factors that could be contributing to the funnel leak (people entering but falling out). As a product marketer it may fall to you to understand why this is happening and address the problem.  For the sake of simplicity, let's say that you have great demo show rates but don't convert these into customers at the rate that you think you should be. Assuming that the prospect knows your pricing and terms ahead of time, this likely points to your demos being bad. Bad could mean a lot of things so it will require further analysis. Are your sales people doing enough discovery? Are they talking about things that actually matter to the prospect or are they just reciting from a script? In this fantasy scenario, with the information that you've been given, it's probably fair to assume that a good metric for you to track would be increase in conversion rate. 

Definitely echo the fact that Product marketing KPIs need to keep evolving with the focus that the organization currently has.  At Amplitude, we have come up with some strong *impact* metrics that the PMM function owns. Each metric is shared with a different team in the org: * Product Launches: # of deals closed where we had atleast 1 newly launched product add ons/packages purchased by customers. Our stretch goal for Q1 this year is 50% of all deals. Sidenote: this is a shared metric with the Product team and incentivizes them to work very closely with PMMs * Thought Leadership: # of opportunities influenced by original (often gated) content from the Product Marketing team. Shared metric with Marketing * Enablement: ACV and Win Rate - this is shared with the Sales & team and is a longer term, strategic metric. But in the near term, we track strategic deals with specific account-based interventions that the PMM function is making and their win rate  Would love to hear reactions to our frameworks from PMMs out there!

Agreed with the other answers about aligning impact with focus areas for the business as a whole. Though I also like to have some consistent metrics to be able to see some longer term trends. There's a separate thread here that dives into PMM metrics: https://sharebird.com/are-there-any-broad-metrics-you-guys-track-as-pmms Some good points there about the combination of quantitative and qualitative metrics, and even quantifying some of that qualitative feedback.

Full disclosure - I work for Highspot - but we do use our own platforrm and one of the benefits of it is that we can see usage and buyer enagement analytics for all of the content we create. It's a quick and easy way for us to determine what's working, what is being used (or valued) the most and also connect content performance with CRM data to understand how content is driving sales velocity, conversion, and quota performance.

Curious to know if there are any metrics that the Product Marketing function is accountable for any metrics? I know there is such a wide variety of jobs that Product Marketers do, but for example, if trial conversion or adoption purely owned by the Product Marketing function, or are all the metrics shared with other teams? 

That's a great question. It depends a lot on the product of course. There are some products that lend itself to a soft launch before we put any marketing effort behind it in which case quantifying marketing impact is pretty straightforward. More generally, I'm a fan of PMM and PM co-owning several metrics. You can't parse which side drove what share of the metric but if you have a good partnership that shouldn't matter. And having that lens means a PMM should care deeply about whether we're bringing the right product to market (or what could we do to make it more successful). And conversely that means the PM should care if we're positioning the product in a way they feel like can make the product long term successful. The end goal is the product generally speaking hits its OKR which should be the north star anyhow.

Recently PMM has been very involved with top-of-funnel marketing and campaigns, so a lot of the typical metrics you might suspect in a campaign are ways we measure success for these (Leads, MQLs, MQL>Opp conversion, Opportunities generated). For more middle & bottom of funnel content - we use a tool called Pathfactory (content tracks of content) that allow for visibility into what content is being sent out by sales, what is getting viewed, how much time spent on assets, and having this link in with opportunities influenced in Salesforce, which gives us a sense of revenue impact. Separately, this quarter, we're focused heavily on partnering with Sales Enablement to impact a very particular layer of the sales funnel where we were seeing the highest levels of drop-off (early discovery/pain). In focusing on this, we're working on additional tooling in SFDC to capture what is impactable vs non-impactable reasons (impactable by SE/PMM training). Once breaking out the impactable %, we're focusing our efforts this quarter on activities/trainings/content that supports for early "Why Change" opening perspective messaging (via slides or whiteboard), additional discovery training/questions refinement, and a revised First Call Deck that provides more wide-angle messaging beyond product features (cliche, but check out Andy Raskin on Medium). The goal here is to zoom in on an early-stage in the Sales cycle where we're experiencing dropoff and seeing opportunity and measure the imporvement we're able to have here through a quantifiable metric.  

While there is no "one size fits all" metric that works for product marketing, my recommendation is to try to align your goals with either sales, demand gen, or product depending on what you're working on. Ideally, you'll have explicitly shared goals with one or more of the cross-functional teams you're working with. This ensures everybody is optimizing for the same outcome. For a new product launch, I'll typically have a shared adoption goal with product and/or an attach rate goal (percentage of customers using the product/feature) with sales.  I'd also caution against only prioritizing work that can easily be attributed to ROI. Product marketing is responsible for driving a lot of initiatives (naming products, customer research, market research, etc.) that don't have an immediately measurable impact on leads or pipeline - but that work is still important. 

The question comes up a lot in product marketing. It is particularly challenging when you are in a product marketing role or on projects that lean heavy into influence or when your organization is stacked with channel owners. Simply put- there is no one metric that suits all product marketing.  That said, at the outset of any project, it is critical to discuss what the hypothesis or goal of the work is and how you intend to measure the success of the outcome. Since product marketing is cross functional, I'd look to align goals and outcomes around known or proxy metrics and I'd urge communication- consistently + often around them.  

1. Sales win rate, more specifically competitive win rate Make sure that you're reps are populating a "primary competitor" field in your CRM so you can track this effectively. You'll then be able to track win rates over time and show how your efforts to enable your team with competitive content is driving you win rates up.  2. Influenced deals Is your PMM team responsible for things like customer references, creating custom content (ie. decks or leave behinds), or generally brought in to help on strategic deals? If so, add a special field to Opportunities in your CRM so you can mark when you've "influenced" a deal. This will give you an additional way to show how your work, especially ad-hoc requests, are influencing revenue.  3. Sales confidence Distribute a quarterly survey to the sales team asking them to rank their confidence in the ways you support them. Some ideas are: 1) competitive enablement 2) collateral and 3) product positioning and messaging. 4. New product revenue If you're launching a new product or service offering, track revenue during the first 30-60-90 days since this is largely a result of your GTM launch.  A bonus tip that's less of a measurable metric: any time someone praises your team, like a sales rep, department leader, customer, etc. grab a screenshot of that shit and save it all somewhere. It can never hurt to have social proof that your team is killing it. 

This really requires a dedicated effort and should be owned by Product Marketing. Different industries change at different paces – in some cases, a quarterly review process is needed, in other case, it might be less frequent. It really depends. Product Marketing needs to keep a close pulse on customers, talk to sales and product management, and keep an eye on the competition. There are other factors to consider as well that may trigger an off-cycle review: major industry news, significant new competitive offerings or new entrants, win or loss of a key customer, an upcoming key tradeshow or perhaps a systemic shock such as COVID-19.

Your CMS (content management system) should have some sort of archiving parameters in place that should remind the PMM team when things get stale. With that said, all the reminders in the world won't matter if people ignore them, so I recommend you also have a "librarian" of sorts manage your content site - whether it's in a sales portal or in another tool, someone who is in charge of managing the site, tracking metrics, and also monitoring / organizing PMM when content needs to be refreshed/archived.  

Align on needs and get buy-in on the program from key stakeholders upfront, otherwise, you will just be reactive and the expectations will be that every request is handled and every asset is up to date. By setting a strategy upfront, defining the set of deliverables and the cadence at which they'll be updated, and creating rules of engagement and set venues / channels for to communicate with teams, you can create a scalable system. For larger orgs, you may have to create SLAs between your team and sales and product.  Specifically with competitive, I really believe you need to define ourselves based on problems you solve and value you provide, not your competition. But also equip teams to stand out from competition and win against them. Competitive can become a crutch for not having confidence in your own message and story. Some of the most impactful interactions I've seen between a vendor and buyer is when the vendor says, "I don't work for that company. I work here, I know we do this really well, and I think I understand your problem and how we solve it." That's refreshing to hear versus bashing the competition. 

In the "real world" this is a function of whose responsibility sales collateral is. If it's product marketing, the answer is simple: Supply new collateral when it's time for an update. However, if product marketing is responsible for informing, and letting sales create its own materials, then it becomes more complicated. For me, it all starts with the buyer personas (or, as I like to refer to them, stakeholder profiles). I have a particular way of approaching these, leveraging psychographic, rather than demographic, inputs and structuring outputs as stakeholder-specific business cases. They answer the question: "What does this person care about, and how can my product be related to that?" Whenever the relevant inputs change, so too does the output, and when that happens it's time to circulate to sales. These incorporate elements of competitive and market research, too, but in a way that is immediately actionable by sales (rather than a pile of information that a salesperson then has to figure out what to do with). 

There's two parts to keeping all the above content up to date, including content creation and content delivery: * Content Creation: This is all about capacity planning of the Product Marketing team on the capacity of the team to update content vs. the amount of content that needs to be updated. First, you need to define what content must be kept up-to-date and how frequently these updates need to happen. For example, some product marketing content needs to be updated frequently (e.g. information about new products and/or features that have come out in each release), whereas others can be updated less frequently (e.g. a broad assessment of the overall market or TAM). Once you've identified the cadence of updates and backed out the volume of work, then you can examine how much capacity the team has and align that capacity to tackle the highest priority updates. If there is not enough capacity, you can either reallocate the team to tackle only the higher priority updates or bring on additional team members if the priority content updates are not happening in a timely fashion. The key here is about prioritization -- not everything needs to be updated all the time. * Content Delivery: Once the required updates have been created by the team, then it's important to deliver this updated content as efficiently and quickly as possible. This is where having a good content management and delivery system is critical. Coupa uses a sales enablement system that we've internally named "The Vault", and this platform allows us to push out new content to the field in an organized way in real-time as product marketing content is updated in our internal file systems. What makes this system effective is its ability to manage versions, control access, and make it easy for the field to find the latest and greatest content at all times. Moreover, as a Product Marketer, I get to see real-time analytics on content usage to better target my efforts.

Make it jointly owned. Your team will (almost certainly) not grow as fast as sales, success, support, etc. Even talented PMMs struggle to keep these things relevant and useful for every season of the company’s journey. So rather than boil the ocean, make it everyone’s responsibility. If your best competitive and market positioning is in the sales onboarding guide, sales managers and VPs have an incentive to keep it accurate for new hires. Plus new hires can comment on/correct things over time. If you have personas, consider jointly owning them with the product team. Product teams have to defend their prioritization rationale every day. If you can build personas together, they will align product updates to personas and make it much more likely everyone speaks the same language.

This really depends on your product and industry. Let me outline a framework with four elements: * The customer perspective * The competitor perspective * The technology perspective, and * The marketplace perspective Take a look at https://www.linkedin.com/pulse/product-marketing-three-words-part-ii-rajendran-nair/ and https://www.linkedin.com/pulse/product-marketing-three-words-part-iii-rajendran-nair/. I have laid out the framework I use to listen to the market.

This is tough, but you can prevent foundational PMM assets from going stale by having (1) defined processes (e.g., establishing which components of your market intelligence are most important to update and on what cadence, and using what inputs), (2) quarterly prioritization to revisit key assets (e.g., dedicate budget and get buy-in from cross-functional partners to spend time and energy updating these assets as a part of quarterly OKR planning. If you don't dedicate and protect the time and budget, you're likely to let them fall by the wayside), and (3) cross-functional participation (e.g., consider delegating aspects of updating some of these bigger bodies of work to a SWAT team of marketers, product managers, sellers, business operations folks, etc. if it makes sense and you can get buy-in). We have a 'competitive intelligence SWAT team' that includes a cross-section of stakeholders who each own a small part of the market intelligence ecosystem and are responsible for updating materials once a quarter. 

I'm big on updating information based on actions that need to be taken / decision that need to be made.  When it comes to market research and personas, clarify what decisions you need to make based on the information and the cadence to which you will make them. If you use market research to inform half-by-half planning then updating the information prior to the beginning of each half is a good starting assumption.  I recommend keeping a regular pulse on the competition, though. For example, by regularly read news about your industry. If there are public announcements that necessitate changes to claims you make in sales materials - update the materials as soon as possible. The same goes for if you hear and can corroborate intel sourced by industry facing teams. Some changes don't need to wait. 

Starting with the customer insight is always the #1 job of a product marketer. Ideal customer profile, target verticals, buyer personas, etc these are things that aren’t going to change on a weekly or monthly basis. However, as part of routine planning cycles – perhaps every 3, 6 or 12 months depending on your market or industry, it’s always good to re-evaluate with sales and CS leadership and understand if we’ve been seeing any shifts in user base or even with the demand gen team to understand how mix in titles might have changed in your inbound lead mix. Competitive insights are a separate topic. Overall kill sheets probably need quarterly refreshes, but understanding your competitors and what they’re doing can be a daily task depending on how crowded your space is. For this, I’d definitely recommend setting up Google News alerts for all your competitors, and if possible, writing a weekly digest for key stakeholders across sales, CS, product, PR/comms and others to see how/what competitors showcase themselves. Also if you have the budget, listening tools like Chorus.ai that can scan sales calls and alert you via Slack or email when competitors’ names are mentioned on calls also help you hear the context of how prospects and customers are discussing other players in your space.

The good news is sales people notice when materials are out of date, and will let you know it is time for a refresh. :) Joking aside, here are some proactive tips on how to keep materials up to date. Market research: With Google alerts, you can capture trends, survey results and news for the topics your personas care about. If you subscribed to analyst research, be sure to have a look at new research on a regular basis. As PMMs, we write about many of these trends in blogs, and use updated stats in sales presentations and prospecting emails. You could make it a policy to refresh sales content on a quarterly basis (or at least check to see if you need to) and then communicate to the field the new changes. Personas: In my opinion, persona research needs to be refreshed less frequently. Some triggers that could require a refresh: * Your product has a major new feature that could serve a different persona * In analyzing wins/leads, you find that your primary persona has shifted * There is a disruption in the market which could cause responsibilities/buying centers to shift Competitive: Competitive should be kept up to date as much as possible. You don't want your sales team caught off gaurd. Competitive intel often comes from your field teams, so it is critical to have good relationships with the field and a mechanism to capture this intel. Usually the best way to capture sales intel is via 1:1 interviews or having monthly listening meetings. (We are implementing a listening tool soon, so that might provide additional insights.)  It's also beneficial to have a person or team focused on capturing competitive insights from across the organization (PM, PMM, field, and external research such as product reviews and documentation). At Snow we are blessed to have someone on our product insights team focused on doing just that. Publishing up to date battlecards and competitive newsletters are ways to keep the field informed. It is even better attend sales meetings to review recent findings and have the field share their win stories with their colleagues.

You have to establish a cadence of updates for different assets, which will vary based on how they are used and your market dynamics. Personas don't change often, so revisting them every 6 months might be enough, but if you are on a competitive market it may require a quarterly or more frequent update of competitive battlecards. The important thing is to establish a schedule for revisions and set time aside for updating those materials. Another part of your process should be communication to the sales team and others that might use them. Depending on how drastic the update was (e.g. minor edits vs major overhauls) you will also want to have different ways of notifiying the team. A Slack message about a minor update could be good enough but you probably want to do a full enablement session for major revisions that could impact a sales person's abilty to deliver the message or close a deal.  In sum: 1. Identify 'expiration dates' for all your assets 2. Establish a cadence for the revisions and updates 3. Block time on your calendar to work on the updates 4. Agree w/ the sales teams and others on the best way to communicate those updates

Talk with at least 1 customer a week and you'll never be surprised by any changes! I like to follow Gartner and Forrester for changes in the market, as well as keeping a pulse on new PLG companies who are bootstrapping (don't underestimate those folks).  The truth is, most companies do these items once a year at best. If you're able to spend time every 6 months, I think you'll be ahead of the curve.  It's a lot of work up front to create, but shouldn't be much to update. I like to check them any time a new product is launched or a new competitor enters the market (usually sales will notify you). Also keep an eye on your competitor for news surrounding funding or new product announcements. 

While you can have really compelling per-product pitches, the real challenge of selling a platform is getting prospects and customers to buy into a vision that unifying their systems is going to be a force multiplier for their company. The value is that 1 + 1 > 2. In selling a platform, it’s imperative the messaging is above-the-line focused because you’re trying to convince customers about the vision. There may be cases where a platform only has 80% of the features that a combination of point solutions have, but still wins out because the sales team was able to align the customer with the idea that a unified platform is better. Tactically, this means shifting your core narrative from having a narrow products focus to having a vision and use case focus. It means creating case studies that span multiple products, etc.

This is a tough question to answer because it is so multifaceted. So let's start with the basics when you are moving from product to platform, you're moving from selling one solution to selling multiple solutions. My first recommendation is to hire a separate role that focuses on Sales Enablement. The reason is that you will have to shift from application marketing to solution marketing and this also means shifting to solutions selling, and you will need someone who has a sales background.   If your company isn't ready, then you should partner with sales and cs to craft the level 2 and level 3 messages. Level 2 is messaging on assets and Level 3 is scripts and talking points.

It depends on where you are in the growth journey. If this is a strategy change - in terms of no longer selling a product to selling a platform, it's more about messaging & the art of the possible with a platform.   If you're further in the growth journey and have a complex product portfolio, where now you need to layer on a platform message, then it's about really ensuring your AEs have that foundational knowledge down. Regardless, with a platform, I find that (1) it's a more technical sale (2) you need to really upskill the AEs or bring in your technical SEs to own the conversation (3) your buy may change from the business to IT but since you want to avoid that (since IT tends to be a cost center), you really need to still try to get the business to see the value of the platform and the art of the possible, so they can advocate for it.

Let's start with the difference between a platform and a product: Almost every SaaS product has APIs that let it integrate with other applications. A platform, however, plays a more active role in creating an ecosystem and acts as a central hub where how multiple products work and can thrive together. If the platform evolves to a point where it can serve up a marketplace for other products, then the sales enablement process must include the partners who are part of your ecosystem. In my mind, that is where the game changes for sales enablement. The sales rep now has to look at the combined value prop of the core platform and the partner products that will support a niche use case. For the sales rep, this is fantastic because it makes the solution selling approach a lot easier.

In my experience the shift from Product selling to Platform selling has meant that we've had to update the buyer personas we sell too, or at least expand them. It has meant we're no longer selling to a single buyer, but rather a buying committee - so sales has to be equipped with knowing who the members of that committee are, and what is important to them. Selling a Platform will also inherently evolve the pitch and sales motion as well. Sales enablement will be tasked with helping the sales org sell the value at the highest level and ask the right discovery questions to hone in on the parts of the platform that are most relevant for the prospect - while still selling the vision of the entire Platform.

When selling a platform, you're selling what a customer can accomplish, less what a customer is buying. Obviously in the SaaS world, a lot of our marketing is based on the product being the thing that gets a customer to a desired future state, but that's even more true when selling a platform. The big change is the customer's journey to get to that desired future state. Their path to usage is different, their stage in the purchase path is different, and the stakeholders needed in the room are different. So I would suggest you stick with the same thematic narrative of enabling your sellers to showcase offerings from your company that solve customer needs, but be sure to also enable those sellers on the nuances of the platform sale--what does the usage journey look like? How can an SDR get an appointment for the AE? How can an AE get the customer over to an SE? How do you make the platform consumable to a seller, but not overlapping with your "standard" products? How does your sales team's core persona engage the necessary persona for a platform conversation? Oftentimes at the companies where I have worked, Sales can gravitate to the path of least resistance, so you'll need to make it easy for them to 1) understand platform nuances and 2) have a path to keep the sales conversation going when one of those nuances comes up. Platform customers tend to be stickier than others because of all the work they have to do on their own to leverage the offering, so if you can get a sales team to not feel like they are stumped in the conversation and that they can convert leads at parity with other products, then there is more money in a platform sale. So the opportunity is there, you just need to find what your sales team needs so that they are confident in their talk track and have the path detailed towards next steps. 

Sales enablement programs have to be designed with a hierarchy in mind, just like how there's a messaging hierarchy. You lead with the hero and follow with the supporting cast.  Based on the way this question is phrased, I'll assume that the move towards selling a platform (from product) was decided upon for good reason. And it does introduce more complexity: * More platform-type of information * Different packaging (and likely pricing) * Content curation for different teams Where enablement may have been a one-and-done event, it now becomes a continuous program. And the program can be delivered in stages, prioritizing the platform in stage 1 followed by products in stage 2, 3, and so on.

Good question! Over my career, I have seen release cycles shrink a lot and fewer and fewer requests for datasheets! My advice: 1. Minimize the number of "sources of truth." If you can get away with just having a web page, do it. If you need printed collateral, what about a piece that explains the value proposition and includes a QR code for a web page that shows the details? Likewise, makie sure that internal information is stored in as few places as possible.  2. Set a threshold for the number or signifance of features that would trigger a datasheet update. P1/ P2/ P3 releases.  3. Streamline the production process as much as possible, so updates aren't as painful. 

There are several steps that you can take to ensure that you have the most accurate description and version of a datasheet when features are changing constantly. These steps include: 1. Work closely with the product development team to stay up-to-date on any changes to the product's features or functionality. This can involve attending regular meetings or briefings with the development team, or having a dedicated point of contact who can keep you informed of any updates. 2. Use a version control system to manage the different versions of the datasheet. This can help you track changes to the document over time, and ensure that the latest version is always available to the relevant stakeholders. 3. Use a clear and consistent naming convention for the different versions of the datasheet, so that it is easy to identify the most recent version. This can help prevent confusion and ensure that the right version is being used by the sales team and other stakeholders. 4. Conduct regular reviews of the datasheet with the product development team and the sales team to ensure that it accurately reflects the current state of the product. This can involve soliciting feedback and making any necessary updates to the document to ensure that it is accurate and up-to-date. 5. Use a system to track and manage the distribution of the datasheet, so that you can ensure that the right version is being used by the sales team and other stakeholders. This can involve using a marketing automation platform or other tools to track who has access to the document and when it was last updated.

There are a couple of different ways to approach measuring sales enablement effectiveness. The main question I ask myself is, "Is the sales team confidently delivering the right message to our target audience?" From there, you can determine which metrics are best for measuring sales confidence. Some examples: * Conversion rates during the deal cycle (i.e., not just Closed Won, but earlier deal stages as well). If the deals are progressing well, it can be inferred that the salesperson successfully utilizes the message to drive progress. * Resource utilization, such as pitch decks, one-pagers, etc. Track how often your sales team is using these assets, as it shows alignment with your enablement efforts. * Sales feedback via surveys and/or feedback loops. This is my favorite one because it answers the question directly. The other two measurements are useful but depend on other factors outside of enablement. 

Measuring the success of sales enablement comes to having clearly defined metrics that PMM can influence. There are a few key metrics you can use to measure the success of your programs. These include: 1. Win rate: The percentage of deals that are won by your sales team. Useful sales enablement materials, training, and collaterals will grow the win rate. 2. Sales cycle length: The amount of time it takes for your sales team to close a deal. Again, the better sales collaterals, answers to typical questions, battle cards, and use-case, the faster SDR/BDR can close the deal. 3. Sales productivity: The amount of revenue generated by your sales team per unit of time (e.g. per month or quarter). 4. Sales team onboarding speed. The PMM sales enablement programs will help by providing comprehensive product training and giving access to the right resources (ICPs, case studies). So the new sales team members will ramp up more quickly and become productive members of your sales organization.

One way to measure the success of sales enablement efforts by product marketers is to track key metrics such as the number of sales-related resources that have been created, the number of sales reps who are using those resources, and the impact that those resources are having on sales metrics such as win rates and average deal sizes. Additionally, product marketers can also conduct surveys or interviews with sales reps to gather feedback on the effectiveness of the sales enablement resources and how they are being used. This can provide valuable insights into how well the sales enablement efforts are working and where there may be opportunities for improvement.

Background: Worked as a Community Manager and Product Marketer for an open source database software company DataStax; we sold a proprietary version of the open source database Apache Cassandra, targeting the developer and administrator personas. Developers are experts at searching for information; they're most likely to make buying moves after doing their own research and product comparisons. By the time a developer is actively engaged with sales, you can almost guarantee that they've made up their mind about what they want. One way to enable your sales team in selling to developers, while getting developers into earlier stages of your funnel, is to position your sales team during enablement sessions as educators and central sources of knowledge. By no means do they have to be—or should they be—experts on the nitty gritty of a technical and developer focused product, but they should be armed with proprietary and educational information to pass along. The more useful and hard-to-find this information is, the more your sales team will be viewed as a valuable source of information, rather than a nuisance. Also, make sure they don't bullshit (easier said than done); sometimes the product just isn't the right tool for the job. Knowing when you're barking up the wrong tree, and conceding, is super important.

Sales enablement changes when your company is "business to developer" to point at a different stage in the funnel: the charismatic, knowledgeable developer who probably already has a solution.   When you are pitching to developers it helps to build a scientific, clearly logical and reasoned case for them to abandon their current solution and adopt yours based on a productivity or efficiency gain, or because you enable them to do something they simply couldn't do before.   Keep it simple, explain yourself in plain english, and err on the side of less bs and more details and developers will respect your approach more.

Selling to developers can be difficult, often because they have a ton of say over the decision but not explicitly the budget, but marketing to developers is simpler than people think. Quickly and concretely explain what your product does and how it works/fits in with other stacks (as much as developers love to claim that they're immune to marketing/branding - just look at the stickers on their laptops. C'mon - that's brand loyalty/affinity on par with pre-teen pop music fans) then get them into some demo/free trial/"doing the thing with your product" as quickly as possible with resources (docs, tooling, code samples) they can self-service on and then get out of their way (and watch). If your product can't convince them of it's awesomeness through hands-on experience you have a tough road ahead of you. But if it's got the goods, and you have visibility via a modern SaaS offering so you know who's doing what, then sales enablement becomes all about:  1. Reading the signals from inside the product of who's getting value and ripe for value capture becuase your product has already created value for them - developer marketing / advocacy gets them into the trials/usage - not tradtional SDRs/AEs generally. Devs don't want to talk to those folks. 2. Navigating the org to find budget. If the decision lives in dev, budget could live in IT. So arming reps with the information they need to show who's already using the product a ton and finding out who can pay the bill. That's classic BANT stuff. 3. Ensuring they're ongoing nurture/always on signals to the devs about what's coming, integrations, more tools/code samples, etc so that the fly wheel can continue on it's own. Dev advocacy / evangelism is critical here. It's super important to not make Sales folks feel like they need to cram on all the technical knowledge to somehow pass as credible. Often when the decision maker is dev but an AE is most comfortable talking to IT (because IT has all the budget and buying experience), AE's will shy away here thinking they have to do the heavy lift to kick things off. They don't (or shouldn't) - devs getting value out of your stuff kicks things off. Good luck! 

I love this question, <3 Developers! The fundamentals of sales enablement dont change, it's more the way you communicate the needs of your audience to your sales team that changes. If we unpack developers and what they want, then it makes it really easy to figure out how to approach sales enablement. 1) Developers will question to the end. They will question every word on every slide and understand it as a direction or intention. So make sure that any presentation or pitch you build for your sales team is fully accurate and defensible. A developer will ask about every permutation of the concept you lay out so you need to educate and prepare your sales team to handle any random question that might come at them during a pitch. 2) Developers are the architects of ideas. Developers are often the masterminds of a new innovation or invention in a company. So you need to take them most of the way there. Can you make it super easy for them to find the information they need to start working with your APIs? Do you have an easy to clone github repo? Do you have a step-by-step tutorial for them? Do you have a demo video ready to go? Even if a developer does sit through a sales pitch, you need to give them a carrot so make sure that there is always an actionable CTA at the end of a presentation AND that the sales team knows how to answer any questions on the set up or even do the demo themselves. 3) Developers want to dive in - yesterday. If you announce something, assume it is 1000% ready to go because developers want to get their hands on it right away. If you are doing enablement around a product launch, you should make sure that you have a tight workback schedule and that your enablement happens well BEFORE your launch so that your sales team is empowered and educated to answer any questions that come up from developers.

Great question, something I think about a lot. I’m a huge proponent of specialization with technical products. I wouldn’t expect every member of our enterprise field organization (which is in the thousands) to be able to carry a highly technical conversation from end-to-end, nor would I want them to! But I am responsible for dev and ops-centric products, so it can't be ignored. What I try to do is zoom out of the customer lifecycle, pinpoint who on the team is having the conversation, and what they need to do to get to the next phase effectively – then I craft enablement for that, and that only! A lot of that is just asking the right questions – SDRs should be asking the questions to make sure they’re talking to the right person, AEs that there is a budgeted project to attach to, SEs that there is technical fit. But where rubber meets the road, the best case scenario is to have the practitioner persona matched directly with a technical specialists on the first go around – you lose folks when it takes 2-3 meetings to get to that point, or you lose folks when you try to pitch something you don’t understand in the first meeting. So my recommendation for sales enablement is to be very prescriptive by role – what they need most is a conversation guide that tells them what questions to ask and how to interpret them, and then how to move the conversation forward and with whom. While some reps have the natural tendency to want to carry it all the way through, they should be incentivized to bring in specialists where applicable – make it a win-win, and you avoid any objections to enablement guard rails. One area where I’m placing a lot of my focus is connecting the dots between product-led growth and enterprise sales. I have some thoughts, but still forming a clear hypothesis. Here’s a great post I read on the subject from A16Z (https://a16z.com/2020/07/29/growthsales-the-new-era-of-enterprise-go-to-market/)

When selling to developers your enablement activities are likely to take on a different focus so that the team understands how to engage in a discussion and build a community while keeping their sales pitches locked in a drawer.  It will also require in-depth technical enablement and understanding of technical use cases as well as how to answer questions without trying to sell them something.  The biggest shift might be the mindset, where the sales team needs to focus on what is the best answer to my customer/prospect vs what I want to sell them. It is a very different motion and requires people to be OK telling someone that your product/solution is not the best fit for their use case or even recommending a different vendor.  On top of all of that, enablement should also help sellers navigate the differences in the org structure, their roles and responsibilities, and how to reach to high-level decision makers.

I love this question. First, I would say to save your company's BDR/SDRs time and avoid trying to set up calls with developers. You'll avoid a lot of frustration on both ends. Gating content content from developers and forcing them to fill in forms might give you a short term bump in leads, but the quality will be low. Instead, think of the sales funnel as living side by side with the individual developer journey and look for ways to compliment the activities with the key decision makers and their technical practitioner teams. The developer journey can be sliced and diced a few ways. I like the Orbit Model and the way it looks at community growth, but if we have to make it work for the sales cycle, it gets a little bit tricky to integrate directly. Instead, I like to reference a journey outline that we came up with at Google Cloud: Connect > Engage > Learn > Adopt > Advocate Compare this to Awareness > Consideration > Preference > Purchase > Loyalty You can see the parallels. You can look for opportunities to do complimentary sessions between your Developer Relations team and your sales engagements. If you're doing executive briefings, compliment it with demos or hackathon with the dev teams. Remember that the pre-sales activities and post-sales enablement will involve the developer teams along the way. Do everything you can to make it friction-free for the developers - make materials self-serve when possible and do what you can to reduce meetings. It's important to keep in mind that developer learning is a bigger investment by an individual than a purchase decision made for an organization. That developer is giving up precious time to invest in learning how to use your product, and in doing so, making a bet on their career and skill set. Respect this investment as part of the sales cycle and you'll earn that loyalty.

This is a classical problem for many developer-first companies. Without mentioning names, many have successfully figured out the working model with both strong developer engagement alongside a thriving enterprise revenue stream. Learning from these companies, they always focus on the developer success by doing things such as corporate hackathons, architect support, engineering blogs, etc. that helps to build advocacy for their products. It will be hugely beneficial if the sales enablement programs can incorporate a developer-first mindset by acknowledging that developers are the key influencers in the sales cycle. That will then navigate the sales conversation away from selling towards minimizing the friction in the sales process. Developers use your tools for speed and scale to solve their problems but as the company/usage of the product grows, enterprise buyers ask for justification/business value for these products. As a developer product marketer, in addition to educating developers, you have to enable the sales enablement teams to engage in value discussions to justify the premium compared to DIY from the open-source distribution / low-cost providers.

B2d follows a whole different motion. A developer is not eager to talk to Sales (and they don't want to be sold to). Developers want to try out the product themselves, tinker with it, and only if they enjoy the experience (or get to the aha moment) will they evangelize the solution up the company's ranks. Developer motion strongly aligns with the product-led-growth (PLG) motion. The trial experience from onboarding to docs, inviting team members, and getting to the aha moments can play a pivotal role in converting them to customers. Growth marketing also plays a significant role because this team can run various experiments to remove the barriers to conversion and get to the aha moments faster.  One tactic that works well with developers is the concept of "playgrounds". Playgrounds are places where developers get educational value on specific topics, and there is limited to zero selling motion. Check out jwt.io as an example. This playground is created solely for educational value around JSON web tokens. It provides a cool debugger, tutorials, and libraries for developers to engage and learn (and yes, also buy some cool sway along the way!!). When it comes to sales enablement, just like you have a typical training motion for the sales rep, it is equally important to have a technical track for your sales engineers. SEs, in the end, will make inroads in a sales call and build that relationship with the developer audience.

It depends a bit on how your sales team is organized today. But in any event, your product value pillars should always translate to both individual and company-wide gain, so your core message is always consistent, even if the language changes a bit to accomodate the audience. You might consider a mapping exercise that lets you chart that narrative. For example, "velocity" is one of our core product value pillars.  For the individual: Code portability, modularity, and packages helps each developer code faster, to focus on higher value work. For the company: More developers coding faster means faster time to market, which means greater market expansion and revenue uplift. In both cases we're talking about how the product enables velocity, but we shift the message a bit depending on the audience. Your bottom-up materials should focus on the former example, while your sales enablement materials (assuming the target audience is an enterprise buyer, or team manager), should focus on things like revenue impact, quality, security, or other things that a manager is incentivized to consider.

I'd say the mindset shift in B2D is that it's no longer "sales enablement", but just "enablement". And that should be a shared goal across your organization, whether it's the marketing team, sales team, product or support team who are dealing with your developer.  You are correct in saying that developers do not want to be sold to, but they'll still want good support if they need it. That comes in different forms and the good news is that your organization can divide and conquer across this.  1. First of all your docs gotta be like butter. Most developers will try and figure out a solution for themselves and if your docs are not up to par, their patience will wear thin.   2. The second thing you'll want to do is make sure they can find answers where they expect them. Many of the companies I've been at have their own forums, but also know they need to be present in the Stackoverflows of the world.  3. Finallly investing early in community/dev real will be key. This is where real enablement comes from. You can tout fancy logos, ROI case studies, sales demos all day to the enterprise buyer persona (and by all means have that at the ready) but it falls flats with devs. Developers trust content for developers by developers, and having a great DA/DE team will be key. 

Your sales team needs a higher level of technical proficiency when you're a B2D company. It's important to hire sales reps that can form their own mental model of how your product works and integrates with the rest of a customers tech stack for them to be successful. They don't need to know how to code, but they do need to be able to develop a strong functional understanding of the product their selling.  Assuming you've hired sales reps that fit this criteria, enablement should focus on use cases and technical vocabulary. You should train reps on the types of implementation patterns or use cases they can expect. Technical vocabulary involves helping them understand the terms developers are likely to use and how your products performance in those areas will impact success. 

For companies targeting developers, it's a good habit to build up a culture of developer empathy. Practical exmaples include: * Provide them 101 sessions, enough for them to be dangerous and speak the lingo. What is an API? What is in a JSON payload? What is an SDK - and why does it matter if you support the customer's language or framework vs. your competitor doesn't? What is CI/CD or infrastructure-as-code, and if your product supports Terraform or GitHub Actions, why is that valuable to DevOps teams? * Make your sales people go thorugh (at least once) the introductory hands-on workshop you host for customers. Help them understand the typical developer pain points of: poor documentation, lack of transparency (product is black box / provides no error codes or troubleshooting assistance), lack of extensibility (can't inject custom code / lambdas). * Host internal hackathons and invite your PMMs, SEs and professional service teams to participate, alongside PMs and engineers. * Bring actual developers and let your sales people "ask them anything" to understand their careabouts and pain points.

In enterprise software, you can usually let the product and engineering team push new features when they are ready, as long as sales training is coming soon. Adoption of new features tends to be slower in enterprise software, particularly if using those new features depends on getting through a sales cycle. So, this is another area where it's ok to let go of a little control, and focus on the things you can control as a product marketer.  The other thing to note here is that feature flags (something we offer for free here at Optimizely :) can help you by letting developers deploy new features into your product behind a switch, so that customers can't see the feature, and then marketing can turn it on for specific customers as you're ready. 

This is a great question and one that unfortunately can happen quite often. Whether it’s sales training or another aspect of the GTM plan, it can be challenging to get all the timelines to sync up -- especially if the PMM hasn’t been looped in early enough to prepare the GTM plan and deliverables. In this type of situation, I first like to remind the product/eng team that if Sales doesn’t understand the features they build, they can’t sell them and/or help ensure that customers are educated and trained on how to use them. No developer wants to see their work go unused by the intended audience, so it is usually in everyone’s interest to make sure all aspects of the GTM plan (including Sales training) can take place. Help build an understanding of why it’s important for training to take place, and seek to understand the downside on their end of waiting, in the hopes of coming to a timing compromise. There may be instances where you can also re-assess how critical sales training is to an initial rollout. Is this a feature that’s really critical to new customer adoption? If yes, then you’d want them trained ASAP for the launch. If it’s a nice addition but not the top value prop, perhaps Sales Training can come post-launch. Even in the best situations it’s very common for a PMM to have to adjust their ‘ideal’ GTM Plan as launch gets close, so flexibility and problem solving at this stage is also key.

Impact. If you dont do the training, will the feature be used? Will it create more bugs? I think of this as a cost benefit equation--What is the cost of holding a launch to do a training vs what is the cost of launching without the training? Being able to articulate that potential downside to doing the launch "wrong" will help your XFNs understand why youre making a specific recommendation.  For example, if you can quantify that launching a feature without a sales training will equate to a X% conversion rate vs launching the feature with a training will equate to a 2X% conversion rate, then you can make the statement internally that the <week, month, etc.> that it will take to train the sales team will yield double the return, so its a slight cost of waiting a little for a larger benefit.  At a previous company I worked at, our PM team was excited about the speed at which they would innovate, so it was a big deal to them that we were launching new features at every sprint. The downside was that nobody was using them. So we had to create a monthly webinar series where PMM and CS had to manage (build, practice, present + create campaigns, emails, segmentation lists, etc.) to recap the highlights from the recent releases. I later worked at another company that did 3 large launches a year but it became so programmatic that it lost its value and the company actually generateed more MQLs off of highly relevant highly targeted singular feature campaigns than it did off the big release moment. So there's no set answer on how to do the launch, but more so what nuanced approach will work for your org to drive the most impact? 

Similar to the response around growth, adding some color here.  I encourage my team to be the ‘mini CMO’ for the products they cover. That means the single biggest metric to measure is pipeline (with a focus on pipeline generation). Depending on the specific in-quarter activities we have going on around sales enablement, we can see a dedicated focus on sales enablement and education show up in our sales-sourced pipeline in the trailing quarter. My advice here is to track a few things: Attributed pipeline = how are all your content activities showing up in your pipeline efforts, eBooks, webinars, etc. Sales-Sourced Pipeline = Did you focus on a specific and deliberate effort around sales enablement that you can tie to an increase in sales sourced pipeline around a specific product or use case?

This is a bit of an oversimplification, but I boil down measuring sales enablement success into three categories: * Usage: This would be the volume of assets developed as well as ways to measure how often they’re utilized. For example, maybe you post your sales collateral to a sales team portal where downloads / views can be tracked. * Quality: This is about getting feedback from sales on how useful the collateral you've developed is, which can be gathered informally in discussions with your sales team or formally through regular internal surveys.   * Impact: This would be oriented around correlating the content you develop with metrics such as pipeline influence, win rate, sales rep revenue, etc. This is a mix of art and science though, as it is sometimes not straight forward to be able to tie a particular piece of sales content to a specific business outcome. So think about how to triangulate data points – e.g., did you train a specific group of sales reps in utilizing new sales enablement assets? How do the metrics differ from one group to another?

Ultimately is about revenue attainment. Are sales reps being able to make their numbers? If yes, you are likely doing your job well. Now, if we look more closely at how to impact revenue attainment from a product marketing perspective we end up with the following metrics: * Win / Loss rate: this can indicate if the messaging/positioning needs work and if sales reps have the right tools at their disposal. * Competitive win rate: indicates how effective are the battle cards and competitive training. * Conversion along the marketing funnel: this will give you anindication of content performance and messaging. * Pipeline coverage: are we targeting the right personas, the right companies, and are reps able to convey value. Other metrics that the sales enablement team will be monitoring include sales ramp time, quota attainment, etc. which may not be relevant for product marketing unless your team is also involved with these activities.

Measuring the success of sales enablement comes to having clearly defined metrics that PMM can influence. There are a few key metrics you can use to measure the success of your programs. These include: 1. Win rate: The percentage of deals that are won by your sales team. Useful sales enablement materials, training, and collaterals will grow the win rate. 2. Sales cycle length: The amount of time it takes for your sales team to close a deal. Again, the better sales collaterals, answers to typical questions, battle cards, and use-case, the faster SDR/BDR can close the deal. 3. Sales productivity: The amount of revenue generated by your sales team per unit of time (e.g. per month or quarter). 4. Sales team onboarding speed. The PMM sales enablement programs will help by providing comprehensive product training and giving access to the right resources (ICPs, case studies). So the new sales team members will ramp up more quickly and become productive members of your sales organization.

Oh this is fun! Adding new features and or functions to grow into a new market or persona is a great way to grow. The sales team on the other hand may not get excited for it, this is new things to learn, new messaging, new persona when they might have gotten used to the last one. I position this as a new market and new sales goals that will increase their effectiveness and they get to make more money off commissions. So I usually show them the size of the new market or how many of these persona's there are in the industries we are going after. Once they realize how big the growth opportunities are and the impact on their commissions that is when we start doing fun programs like Q & A's with these persona's where the sales team gets to really know this type of users, Trivia with prizes that allow them to compete for amazon gift cards or a dinner out, we also offer first call help where product marketing will jump on their first call with the new persona to help them sell! This all makes sales jobs so much easier and gets them super excited for the opportunities to make more money!

In this case, you would first want to enable your sales teams on the new persona, including what this persona generally "looks like", relevant pain points, and other information to help sales successfully reach these personas. You will have more a heavy lift in educating sales on how to successfully sell this product compared to a product that's built for the personas that your sales team is already used to targeting. Beyond sales enablement, new target personas will sometimes require a broader rethink of the go-to-market strategy. Is your messaging and content properly targeted to this audience? Has your Growth Marketing / Demand Gen team adequately generated leads from this new pool of buyers? Does the new target persona require additional aircover from brand and PR? Will targeting multiple personas create conflict within sales and are there ways to segment sales and/or sales channels to better manage this conflict? These are important questions that Product Marketing and Marketing more generally should consider as part of the new product launch.

If your sales team is like any sales team I've been privileged enough to work with, your team is full of highly savvy individuals who know what needs to get done to hit their numbers.  As a result, anything you want your sale team to sell must first be sold to them as a way that they can, in the end, meet and exceed their targets.  Your job is to create that excitement. Perhaps this new persona influences the traditional buyer, and selling them the product will help not only net new sales but also grow existing customers. Or perhaps this new persona is an entirely new market full of greenfield accounts that your rep can now prospect. In any case, you need to figure out how to sell your sales people on how this new product aligns with their incentives. And if it doesn't, you need to solve that problem or else you really should not expect much interest or action from your sales team.

Go back to the basics and develop the buyer persona assets for this new buyer. You can’t effectively sell to someone you don’t understand. Training and workshops for the sales team to fully internalize this new buyer persona, and ask questions in a group setting or 1-1 is important to get the team ready to sell to a new persona. You should be demanding the time necessary to make this happen if a new product class is introduced to address a new persona.

I have never worked at a company where the sales team did not get excited about a new product or persona - this typically means a larger market for them to sell to.  The goal with any enablement is to make sure you are clearly defining why this is important, and how it will help them sell more to hit their numbers.