Product Marketing

The first step is defining the customer journey and making sure your key functiona teams understand that journey. Then, recognizing that there may be stop gaps that need to be implemented to ensure customers can take advantage of the feature. What needs to happen on the delivery side of the house so CS and technical teams are enabled? How can we over communicate and document docs and materials for our teams and customers? What kinds of enablement efforts do we need to account for to make sure customers understand the benefits?

Welcome to the fun world of Enablement! And there are internal + external aspects of this. * External * Message x Value & benefits: What's in it for your users? Migration is a pain in the ass. Before you get to the logistics, you have to sell them on the why * Transition plan: What's the step-by-step guide? Is it one size fits all, or does it require different approaches for different types of users? These need to be documented and clearly laid out.  * Timing & cadence: Give your customers enough time to make the changes. I'll leave the communicat...

When launching new features in products, you can influence activation by reaching your customers where they are in their journey. Whether that's in-app with embedded posts, product tours, explainer videos - or reactivate sleepy customers with targeted email messages. Best resources to learn from: your peers! Join a community like product marketing alliance and try to find mentors (I am always open to chat and coach!). Books: Story brand by Donald Miller, Obviously Awesome by April Dunford, On Writing Well by Willian Zinsser. Podcasts: The Product Marketing Insider, The Product Marketing Exp...

It certainly depends on the launch tier along with other market factors/customer dimensions, but typically I am looking at the data to inform next steps. Did we hit our product usage target? Is the narrative landing in sales calls (listening to gong recordings)? Is the pitch deck working (checking deal velocity in SFDC)? I am continually tweaking to ensure we are landing in a place of impact and not stagnation. Aside from this, the mission critical post-launch activity should be - the RETROSPECTIVE! Get your GTM teams together to chat about what you should "start, stop, continue" so you're ...

Telltale signs of success: customer buy in. If you have customers that have tested the new feature (in alpha or beta phases), informed the roadmap, and have provided use cases that the feature has solved for - you know your launch train is headed in the right direction. Even better, get commitment from your customers to use their authentic testmonials in launch assets to bring your narrative to life and bring value to similar customer profiles. This helps customers get activated quickly while building trust. Without customer participation and validation, I'd be concered about launch perform...

I really like the story brand framework by Donald Miller. The narrative structure puts the customer as the hero of the story and your solution as the guide to their problem. The book also talks about picking a fight for your product with a focus on vilifying the issues your customers are having. This framework can be applied across stakeholders and performs very well from pitch decks to landing page copy. 

I have, a few times! To establish a Beta program, I would work closely with customer success and product as both stakeholders are needed to keep a beta program running smoothly. Define what good looks like between your stakeholders along with ownership areas and key responsibilities. CS should help determine best fit customers/beta participants, product should validate product efficacy/capture feedback to inform performance, and PMM should orchestrate it all - connect the dots and grab authentic messaging/use cases to inform larger launch moments. Establish non-negotiables for launch with p...

First of all, *hugs*. I've worked on both the vendor and client sides of research, so I've had the opportunity to work with many different teams with varying levels of interest in market research. When I'm working with a team that isn't "bought-in" on the value of market research, it's usually due to one of the following reasons: 1. They're in "start-up" mode and not creating space within their processes to leverage market research insights 2. They haven't made it a priority to upskill their team on how and when to use market research insights 3. They're focused on short-term gr...

Always come with data insights proving how your research will drive some numbers up.

Always come with data insights proving how your research will drive some numbers up.

When talking about product value prop, developers care more about: * functional benefits (aka "features") * security and owning the data * transparent messaging around expected outcomes (no fuzzy marketing promises)

The first step is executive alignment. When I start an engagement with a client, I do a thorough messaging audit including internal stakeholders, customers, and sometimes analysts. I analyze my findings, present them to the key stakeholders, and get their buy-in before beginning the actual messaging process. It's also important to note that some of these key stakeholders don't know what positioning and messaging are. They may not care. You'll need to educate them. Positioning is how your product fits in the world (product-market-fit) and different from alternatives. Messaging is the product...

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...

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 wi...

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 (d...

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 co...

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...

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 requ...

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 way...

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 influen...

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 influen...

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 thi...

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 me...

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 ...

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 ...