Claire Maynard

I believe it's important to start out with how product marketing is the same across a self-serve/product-led motion and a sales-led motion. In my opinion, the core pillars of the product marketing responsibilities remain: * Target audience and buyer definition * Positioning and messaging * Pricing and packaging * Product narrative and storytelling * Product and feature launches * and so on... With either motion, you have to be an expert in your product, customer, and market. Where the function starts to differ is how you design your GTM strategy. What is the main mechanism for bringing your product and story to market and then accelerating a customer through their adoption journey? Is it via a sales team, marketing-led, product-led, or a combination of all three? In my experience, most companies use a combination of product, marketing, and sales-led approaches for different parts of the customer life-cycle, different types of audiences or maturity of company/product. Here are a few ways the product marketing function may differ with each type of motion: * The team(s) you enable with the customer, product, and market knowledge. In a sales-led motion, you are enabling a sales or demand gen team with the buyer knowledge, messaging, sales collateral, etc. so they can successfully describe the value to a customer and guide them to purchase. In a self-serve motion, you're partnering with your growth, content, or support team to design, what I like to call, an "automated sales journey" where an end-user can move through the same milestones without needing human touch. * Metrics you may be responsible for. If you work on a product with a sales-led GTM motion, you may focus on # of leads, revenue, close-rates, or effectiveness of the sales-enablement assets you create. You may look at traffic, brand awareness, or acquisition metrics in a marketing-led motion. Product-led (or self-serve) will focus on the entire funnel of product adoption metrics from acquisition, activation, retention, and referral. The focus is on how efficiently you move a user or customer through these stages. * Your target audience: Typically, in a self-serve or PLG motion, your target audience may look more like a consumer in the B2C world. They have the freedom to search for, select, and purchase software without needing a ton of oversight or permission. Your goal is to make this process as frictionless as possible and enable the user to spread the product organically, using "bottoms-up" motion. If the product you're selling is intended for larger teams, is more complex, or has a long sales cycle, you're likely going to have a "tops-down" motion and be focusing on an executive, C-level buyer, or multiple buyers. I typically recommend teams focus on product-led growth first. Make your product as intuitive and frictionless as possible, encourage viral sharing mechanisms, and product hooks that keep users returning. Add marketing-led or sales-led motions to supplement or accelerate your growth as you mature.

I cannot speak to how the Slack team built their land and expand strategy but I can speak to how I understand and think about the strategy at Atlassian. We have two methods of land and expand. 1) Product expansion - a user, let's say a product manager, lands in one product, Jira, and finds a ton of value. They then discover that Atlassian also offers Confluence, a knowledge management product that they can also use, so they expand into that. Then they discover one of the new products in our portfolio, Jira Product Discovery, designed specifically for product managers, so they adopt that. In this case, the same user expands from product A (Jira) to product B (Confluence) to product C (Jira Product Discovery). 2) Team/Company expansion - Let's say a product team is using Confluence to write up their product specs. They share a spec with their product marketing counterparts to consume for an upcoming launch. The product marketing team quickly sees how they may be able to use Confluence for their own needs such as writing messaging or sharing customer interviews. In this case, Confluence has expanded from team A (product) team B (marketing) and so on. This is Atlassian's bread and butter and it doesn't happen by accident. All teams including product, marketing, sales, and CS are aligned and focused on accelerating this motion. On my new products team specifically, we think a lot about our land and expand strategy. Many of the products in my portfolio were built by thinking through our existing audience needs and jobs to be done, and how we could solve for them. When I was working on Confluence, we thought a lot about how we could extend the use-cases of the product to not only meet the needs of technical teams but increased the breadth of use cases to non-technical teams like HR, Marketing, etc. A few concepts come to mind when thinking about building a portfolio: * Adjacent jobs to be done (JTBD): Think about your existing product. What JTBD does it solve and for what audience? Does that audience have another JTBD that you could build for? An Atlassian example: Product teams need project tracking so they need Jira > they also need project documentation so they need Confluence. * Adjacent audiences: Think about your existing audience. What other teams does this audience work with? What other audience has the same pain as your existing audience has? An Atlassian example: Product teams use Jira for project tracking > Marketing teams also need project tracking. Once you have the product strategy, here are a few ways to think about accelerating motion: * Use cases: have a variety of use cases and examples on how real customers are using your products in different ways. On Confluence, we built a giant template library so that any type of team from Product to Marketing or HR could get started with a use case that was related to their job. Also, have customer use cases that describe how your customers use your products together to solve an overarching JTBD. * In-app cross-sell: We talked about this earlier but the best expand tactics we've tried are in-product. Think of how you can create contextual experiences in your product to help take a user from one product to another within their workflow. For example, one of our best expand experiences in Jira is the "Pages" tab in the sidebar that takes a user to Confluence in one click. * Feature-limit vs user-limit: You want as many people using your product and getting value from it as possible. If you limit the number of users who can use your product, you're limiting the spread. Instead, think about limiting the features they can use and implementing a free tier so existing users can share with as many folks they like. 

My team at Atlassian has a framework for how we launch new products that I would love to share. But before I dive into more detail I'll give you a few tl;dr tips for beta programs. * Create hypotheses that you want to test before your beta begins: Decide what you're trying to answer about your customer, product, or design via the beta program. This is important to keep your focus and ensure you come out learning something. * Great for product & marketing: Beta programs can be used to gather product and design feedback, refine your target audience, your messaging, and get early insights on your pricing and packaging strategy. * Get notable customer references: Betas are a great way to gather notable customer references or stories before your main launch. * Build anticipation: Before launching a beta, you can use a beta waitlist to help build anticipation for your product and gauge excitement. I lead the new products GTM group at Atlassian and we've developed a framework for how to build, launch, and grow new products. I won't go into all the detail, but below I'll explain a bit about how we run the beta portion of the program: In short, each new product within the portfolio follows a series of milestones: * Wondering - Identify the problem/pain in the market * Exploring - Find problem-solution-fit: evidence that customers care about certain jobs, pains, and gains * Building - Build the MVP (an Alpha or Beta customers can start to use) * Showing (customers)- Find product-market-fit (the value proposition is actually creating value for customers by alleviating their pains and creating the gains they desire) * Charging - Find business-model-fit: the value proposition is embedded in a profitable and scalable business model * Scaling - Identify a sustainable distribution model During each stage, the team develops a set of hypotheses focused on what they are trying to answer about the product, customer, or even GTM motion. We have check-points during each phase, where the team presents their findings and process to the leadership group to move to the next milestone. In the 'Building' phase, we will select a handful of early adopters to work closely with the team to provide feedback on the product, design, and even early marketing assets. At this stage, you'd get a valuable (but limited) set of qualitative data on your hypotheses, which you can further validate in the beta phase with a wider audience and more quantitative results. We typically launch a beta waitlist once the product meets a quality threshold and has early signs of product-market-fit with the alpha testers. Here are a few reasons why we launch a waitlist first before opening up the floodgates: 1. Build anticipation for the product: a beta waitlist can help to gauge excitement for a product/solution and help you generate anticipation in the audeince for your product. 2. Refine your targeting and messaging: By gradually allowing customers into your beta and not opening to too many users, you can not only test your product's performance but also buy yourself time to learn about your audience, the value they experience in the product, how they talk about your product, and more. All this helps you refine your target audience, messaging, and gather customer references before the grand reveal (your GA!). 3. Design the self-serve/onboarding journey: As you let more folks into your product, you can start to understand where users may be getting stuck, have questions, or need extra support while getting started with the product. This extra time and insight will allow you to build out your customer's onboarding journey - email drips, in-app flows, getting started guides, help docs, and more. We then open up a beta for self-serve adoption, meaning that a user can start using the beta without signing up for the waitlist or interacting with a team to be authenticated. Because we have a larger set of customers in the beta phase, we can start to validate some of the hypotheses we've earlier uncovered about the product or customer using funnel data or customer surveys. You can learn more about how we design the zero-to-one new products group at Atlassian by listening to my episode on the Women in Product Marketing podcast.

(copying this question from a previous answer) At Atlassian, we use many methods for understanding customers both qualitatively and quantitatively. The most standardized, larger-scale tool we use across all of our cloud products is our Happiness Tracking Survey known as HaTS (developed by Google). Our research teams sends out weekly emails to employees who subscribe that give the overall customer satisfaction score and short clips of customer feedback such as what customers find frustrating about our products or what they like best. This is a helpful way to keep customer feedback top of mind. For more in-depth research on a particular audience, product, or feature, we use Qualtrics to send wider surveys to specific audiences. On my new products team at Atlassian, we use the Product-Market-Fit score which asks users 'how would you feel if you could no longer use the product?". We usually aim for early products to at least reach 40% of their earlier adopters to say they would be very disappointed. You can read more about the survey here. We also use a variety of analytics tools to measure our funnel and in-app engagement such as Segment, Amplitude, Redash, Tableau, etc. On the qualitative side, we run customer interviews, user testing sessions, focus groups, customer advisory boards, etc. I mentioned this in a previous answer, but I believe the best way to structure research is to develop hypotheses you are trying to prove or disprove before crafting your survey or research questions. You want to be clear about what you're trying to understand. Typically, you can start with customer interviews, a qualitative approach, develop your "hunch" and hypothesis, and then use wider surveys to validate the hypothesis.

At Atlassian, we use many methods for understanding customers both qualitatively and quantitatively. The most standardized, larger-scale tool we use across all of our cloud products is our Happiness Tracking Survey known as HaTS (developed by Google). Our research teams sends out weekly emails to employees who subscribe that give the overall customer satisfaction score and short clips of customer feedback such as what customers find frustrating about our products or what they like best. This is a helpful way to keep customer feedback top of mind. For more in-depth research on a particular audience, product, or feature, we use Qualtrics to send wider surveys to specific audiences. On my new products team at Atlassian, we use the Product-Market-Fit score which asks users 'how would you feel if you could no longer use the product?". We usually aim for early products to at least reach 40% of their earlier adopters to say they would be very disappointed. You can read more about the survey here. We also use a variety of analytics tools to measure our funnel and in-app engagement such as Segment, Amplitude, Redash, Tableau, etc. On the qualitative side, we run customer interviews, user testing sessions, focus groups, customer advisory boards, etc. I mentioned this in a previous answer, but I believe the best way to structure research is to develop hypotheses you are trying to prove or disprove before crafting your survey or research questions. You want to be clear about what you're trying to understand. Typically, you can start with customer interviews, a qualitative approach, develop your "hunch" and hypothesis, and then use wider surveys to validate the hypothesis.

First off, is feature adoption the right KPI? In my opinion, focusing on feature adoption could be too narrow of a metric and doesn't shed light on what the end-user is experiencing. End users don't find value in features; they find value in getting their job to be done, done, and more effectively or efficiently than they did it before. At a basic level, product is responsible for building a feature that solves a job to be done effectively and efficiently. Product marketing is responsible for ensuring the value of the job to be done is described clearly and compellingly to the right audience or segment of customers or users. There are ways to measure these two things separately if you need to. After a feature launch, look at the feature adoption funnel just as you would a product adoption funnel. Where do you have drop-off? If the reach of your feature launch was significant, but very few tried the feature, you likely have a messaging or segmentation problem. Did you target the right audience? Was your message clear and compelling? If your engagement in the feature spiked at launch but the continued use was low, your audience is likely not finding value in the feature.

In my eyes, much of the time you spend and core fundamentals and responsibilities are the same. As a PMM for self-serve and sales-led motions, you need to be an expert on the product, customer, and market. Doing this well involves time with customers (and non-customers!), analyzing data, partnering with product teams, and so on. Where you spend the rest of your time will depend on the GTM motion (or combination of motions) you've decided are best for your product/company. See my answer to: 'How does self-serve product impact product marketing function?' Speaking from the Atlassian perspective, we have built a well-oiled self-serve machine but of course, alongside it, we have a sales motion that's critical to larger enterprise accounts. A few of the main differences I see between the two types of functions: * What team you're enabling: For example, a Sales team vs a Growth or support team. You may not be enabling sales in a self-serve motion but you are certainly partnering with teams like growth or demand gen to design programs that help a user move through an onboarding journey for example. You also need to enable internal teams, support teams, social teams and help them understand the value of the product, how to talk about it, and answer common questions that arise from customers. * Types of assets you create: Sales collateral vs product education assets like landing pages, videos, customer stories, or onboarding guides. As a self-serve PMM, you're using your knowledge of the audience, their lifecycle, and product to create assets that guide them through the products on their own, without needing a human touch. * Channels you use in your GTM strategy: Email vs thought leadership content or SEO, fueling UGC or a community. The channels you use in self-serve may look different than in a traditional model. Your job is to reach the audience as they are looking for answers around the pain your product solves, questions they have about your product in the consideration phase or purchase phase. You will also want to be involved in figuring out the viral loops that encourage users to return to the product and to share it with others. I have a background in growth marketing so what I love about self-serve product marketing is that your role touches every part of the customer journey and funnel. A sales-led product marketer's main goal is to drive leads and enable sales to close those leads. A self-serve product marketer designs programs that accelerate every step of the customer journey from acquisition, activation, revenue, and expansion.

I believe it may be important to start out with how product marketing is the same across a self-serve/product-led motion and a sales-led motion. In my opinion, the core product marketing responsibilities remain the same: * Target audience and buyer definition * Positioning and messaging * Pricing and packaging * Product narrative and storytelling * Product and feature launches * and so on... With either motion, you have to be an expert in your product, customer, and market. Where the function starts to differ is how you design your GTM strategy. What is the main mechanism for bringing your product and story to market, attracting customers, and then accelerating a customer through their adoption journey? Is it via a sales team, marketing-led, product-led, or a combination of all three? In my experience, most companies use a combination of product, marketing, and sales-led approaches for different parts of the customer life-cycle, different types of audiences, or as their company or product matures. Here are a few ways the product marketing function may differ with each type of motion: * The team(s) you enable with the customer, product, and market knowledge. In a sales-led motion, you are enabling a sales or demand gen team with the buyer knowledge, messaging, sales collateral, etc. so they can successfully describe the value to a customer and guide them to purchase. In a self-serve motion, you're partnering with your growth, content, or support team to design, what I like to call, an "automated sales journey" where an end-user can move through the same milestones without needing human touch. * Metrics you may be responsible for. If you work on a product with a sales-led GTM motion, you may focus on # of leads, revenue, close-rates, or effectiveness of the sales-enablement assets you create. You may look at traffic, brand awareness, or acquisition metrics in a marketing-led motion. Product-led (or self-serve) will focus on the entire funnel of product adoption metrics from acquisition, activation, retention, and referral. The focus is on how efficiently you move a user or customer through these stages. * Your target audience: Typically, in a self-serve or PLG motion, your target audience and how you reach them may look more like a consumer in the B2C world. They have the freedom to search for, select, and purchase software without needing a ton of oversight or permission. Your goal is to make this process as frictionless as possible and enable the user to spread the product organically themselves. If the product you're selling is intended for larger teams, is more complex, or has a long sales cycle, you're likely going to have a "top-down" motion and be focusing on reaching an executive or C-level buyer, or multiple buyers. I typically recommend teams focus on product-led growth first. Make your product as intuitive and frictionless as possible, encourage viral sharing mechanisms, and add product hooks that keep users returning. Add marketing-led or sales-led motions to supplement or accelerate your growth as you mature.

At Atlassian, we've found that in-app feature announcements work really well as you have the ability to reach the user when they are in the context of your product vs perhaps checking email and thinking about something else. Here are some tips to make your in-product announcements more effective: * Be highly targeted: Unless you're announcing a major feature or product that is useful to every type of user (which is rare!), it's most effective and definitely less annoying to customers, if you target your message to the users who will value it the most. Start with a specific group of users who have the highest propensity to find value and craft the message to their needs. You can always go wider and open up this targeting later. * Be contextual: Instead of using large banner announcements across every screen of your product UI, think about where and when a user would need to use this feature in their workflow or actions they are taking in the product that indicates a need for this feature. Add the in-app message in context to their user journey and the more likely they will be willing to give it a try or see value in the use-case. * Use clear and concise messaging: In-app is not the place where you want to be long-winded or use too much marketing-speak. Being playful is great but make sure the message is helpful, to-the-point, and delightful. * Experiment! The great part of in-app messaging if you have a larger audience to reach is that you can A/B test different messages, designs, placements, user events, or target audiences. Run experiments in the beginning until you find your sweet spot. * Don't overdo it and allow the user to quickly opt-out: Don't let in-app messages crowd and distract from the user experience. There should be governance over in-app messages to ensure the same user isn't getting many messages on the same day. Make sure you allow a user to skip the message easily. Even better, allow the user to hide the message to read it later or via email. 

An age-old question: how do you get product marketing a seat at the table? Product marketing has a vital role in product and roadmap development even within a product-led organization. There are many reasons why product marketing deserves a seat at the table. Here are a few: * Product narrative drives product roadmap: The product narrative should drive the product roadmap, not the other way around, and product marketers are the storytellers behind the product. * Voice of the customer, sales, and market: Product marketing can act as the voice of the customer (as mentioned in your question), represent sales, and be an expert on the competitor/market. * Connect the dots cross-functionally: Product marketing understands the GTM process - the customer adoption journey, the components of a successful launch, and they connect the dots across the various GTM teams who execute those launches. * Distribution: On my new products team at Atlassian, we encourage teams to think about distribution from day one. Distribution should not just be the marketing team's job but the entire team's responsibility. Having product marketing at the table ensures the team thinks about intelligent distribution early in product development. I understand that not all companies or product teams hold this same belief, so here are a few tips to make your case: * Bring something of value. Don't expect to be invited to the table if you don't have something valuable to add to the conversation. Look for areas that the product team is not paying attention. Hint: product teams often speak to existing customers. Start listening to your non-customers e.g. customers of alternative products have heaps of good intel on why they didn't select you and what you could build to make them convert. * Take on metrics or OKRs: If you have skin in the game, teams will likely see you as a strategic team member with the same aligned motivations. * Bring the market perspective: Product teams tend to think about what to build for the customer but less so about what and how to gain attention in the market. Launch timing, product differentiation, delightful features, or compelling stories often gain more attention from the media and the market. Show your product team how they can grow faster with strategic launch planning.