Priya Kotak

I’m a big advocate of getting messaging in front of customers and potential customers directly. Here are a few ways I’ve done that recently: * Test messaging in product betas: At Figma we often launch features to a subset of customers in beta before making them generally available. I like to use this as an opportunity to test some messaging ideas. Not only can you test messaging in recruitment comms and onboarding decks you can join feedback calls to hear use cases and benefits in the customers’ own words * Test landing pages with target audience: When we launched FigJam we created 3 versions of our landing page, each leaning into slightly different messaging, and partnered with our research team to test them with customers in our target audience. We had them react to each page as well as answer various questions to gauge which messaging was easiest to understand and most compelling. I feel comfortable knowing messaging won’t be 100% perfect at launch and that it will evolve as we learn how users actually use the feature/product. If you’re already sending surveys and talking to customers you’re on the right track — from there you can iterate post launch. Here are some things you can do to learn whether you need to tweak your messaging: * Review performance: Look at metrics for your landing page, blog post, etc. How are they performing compared to benchmarks? Are you seeing the traffic and conversions you expected? If not, this might be a sign that the product messaging isn’t resonating — a good next step would be talking to some customers and your Sales team. * Learn from Sales: Check-in with your Sales team to learn from their experience. How has the messaging and pitch for the new product been landing? Are they using the materials you created or have they changed them? Joining or listening to calls is a great way to understand this first hand. You can also look through data in your CRM to learn who’s buying so you know whether your messaging is targeting the right personas

A common pitfall when trying to improve feature/product adoption is to jump straight into tactics. This often results in emails and in-product messaging that doesn’t have the intended impact, and annoys users. I like to start by better understanding the users that have adopted a feature/product. Ideally, I can look at product usage data in addition to talking to users. I want to know who they are, how often they’re using the feature, what they use it for, and what they like/dislike about it. In addition to understanding the users that have adopted a product/feature, I find it helpful to talk to users that have not adopted. In my experience, this has largely been qualitative — via sending out a survey and talking to users directly. When reaching out to these users, I focus on understanding on whether they know about the feature or not, and if they do, why they haven’t tried it yet. Is there a workaround they prefer? Another product where they’re doing this activity instead? Lagging adoption can be the result of many things (e.g. poor discoverability, lack of product-market fit) — taking a step back to first understand the root cause allows you to tackle the right problem and be targeted in who you reach out to. Example: Recently at Figma, we launched a new product, FigJam, so I’ve been thinking a lot about how to drive adoption. When we first launched in beta, we wanted to better understand adoption from our existing user base, so we surveyed active users and users that had abandoned after trying it. One learning we had was around templates —active users loved and relied on these, while abandoned users identified these as a feature gap. We realized our problem was discoverability, and took action by prioritizing changes to the product UI and creating a template-focused re-engagement campaign.

In April 2021 we launched our second product, FigJam, into beta, allowing anyone to use it for free for 10+ months until we released it as a paid product. Here are some ways to get Sales excited about selling a new product: * Make it clear why they should care: This might sound obvious, but a big part of this is making sure the Sales team knows why they should sell this new product. This should include why it’s important to the company, but also what’s in it for them. Does this help them expand deal sizes? Hit their numbers faster? * Thorough and consistent enablement: Doubling down on enablement is critical. A new product means new messaging, new competitors, new personas, and new resources. Not only does your Sales team need to know how to talk about this new product, they need to understand and share how your product suite works together. So much about the sales process changes with the introduction of a new product — if the team doesn’t know who to talk to, what questions to ask, and why it wins, they won’t be motivated to sell it. * Prove out your partnership: Selling a new product isn’t going to be easy — reps will be running into new objections, competitors, and questions all the time, which can get frustrating, especially if they don’t have a way of sharing feedback and asking for help. When we launched FigJam we created a channel in Slack specifically for feedback from Sales, encouraging them to share anything and everything. This channel was a top priority, with folks from the Product team, GTM team, and Executive team reading and responding to every comment. And we made changes to the product, the positioning, and the materials based on what they shared with us. This effort made it clear that their feedback was important and motivated reps to keep selling and keep sharing. * Celebrate wins: Selling a new product is no easy task, and wins should be celebrated. Highlighting wins in newsletters, sales calls, and public company Slack channels shows everyone how important the initiative is, and encourages more of the same behavior. * Align incentives: A second product is always going to be harder for reps to sell than a product they are already familiar with. Incentives such as commission adjustments, SPIFs, and contests can help encourage Sales to prioritize a new product.

This always starts with defining your audience. Once you know who you’re trying to reach, you can prioritize the best channels to reach them. There are two questions that I try to answer before I jump into channel strategy: 1. Will this feature drive new user acquisition or adoption within our existing user base? 2. Which of our users will care about this news? It is tempting to say that a feature is relevant to both new and existing users across personas, but prioritizing audiences can make a big difference in choosing the right channels. I always recommend establishing a priority between new and existing users, and to limit personas to a max of 2 so the launch strategy stays focused. Once you’ve identified who to target, you can focus on the best channels to reach them: Where does this audience get their product news? How do they like to hear from you? Is there a specific channel that makes sense for this particular announcement? Example: At Figma, we’re currently planning for an update to our Slack integration. The update itself is relatively small, but has been a top request from users of the integration. Given this, we’re prioritizing existing users for this launch, and planning to reach out to them directly via Slack (as opposed to email).

I believe the key to having a cohesive launch narrative comes down to putting your new product into context of your existing product(s). While each product will need its own positioning, and may even appeal to different audiences, an overarching narrative can help tie everything together. We recently went through this process at Figma when we launched our second product, FigJam, an online whiteboard. Here are two activities I found helpful in this process: * Articulate the “why” behind your new product: To tell an authentic narrative we started by thinking about the “why” behind FigJam — what inspired us to build this product and why did it make sense for Figma in particular to be building it. I chatted with folks on the FigJam product team (product manager, designer, researcher), our head of product, our CEO, and more, to understand why we were investing in FigJam — where did we get the idea? why now? and how did this fit into our broader vision as a company? This exercise forced us to be introspective, and helped ground the narrative we ultimately shared with the world. * Review existing positioning and tease out how your new product changes this: Your launch narrative should make it clear how your products fit together and why your customers need both. At the time, we were positioning Figma as the place for teams to design together — by design, we meant creating mock-ups and prototypes. We asked ourselves how FigJam changed this narrative — what additional activities and use cases did it unlock? How did these activities relate to mock-ups and prototypes? And how did they make the outcomes of what teams were already doing in Figma, better? Forming a cohesive narrative is no easy feat. Here are a few principles to keep in mind as you think through how to tell a single narrative across multiple products: * Future proof it (as much as possible): A narrative that is extendable to future products is a huge plus * Keep it simple: A narrative should be easy to explain internally and to customers * Be flexible: As you launch and learn, your narrative may change, and thats ok

As teams scale and more processes are put into place to streamline go-to-market, PMMs can become overly reliant on launch playbooks. We’ve all been there — you identify the tier, fill out the launch plan, and start working through the corresponding checklist of tactics. In many cases, this will result in a smooth process and pretty good launch — after all, the playbooks are there for a reason. But great launches come from taking a step back from the playbooks and processes to think about what that moment really needs, instead of just what’s required. Once you have your GTM plan, ask yourself what’s one thing that could be better? One thing that would make this launch more impactful? This could be anything from extra attention to detail on a narrative to taking a risk with a creative new tactic to a user-centric go-to-market strategy.

Measuring success starts with defining what success looks like. This is most successful when it’s a cross-functional effort, and teams across the organization are bought in. Ahead of launch you should align on a metric. This will differ from product to product. You need to figure out what metric matters most to the success of your product, and make sure its easy to understand so folks can rally around it. For FigJam we focused on an engagement metric, Weekly Active Users (WAU), which we also track for Figma. Once you have a metric, you need to set a goal. For a second product, it may make sense to look at external benchmarks or benchmark against your first product. Having a goal that’s time-based is also helpful — we set an end of year goal when we first launched FigJam. It’s important to have regular check-ins to understand how you’re progressing against this goal, especially with a new product. I recommend involving the core cross functional team in addition to leadership. This keeps everyone accountable and allows you to adjust as needed. In terms of expansion vs net new acquisition, even if your second product appeals to a larger audience than your existing customer base, focusing on current customer adoption first will likely be easier than acquiring net new customers. From a self-serve prospective, they’re already in the product so you can reach them directly. And from a Sales perspective, the team has existing relationships that they can leverage.

At Figma we use a few different types of in-app messaging to reach users depending on what information we’re sharing. While in-app messaging can be a great way to reach users, it can also be distracting — PMMs work closely with their product and design counterparts to determine whether in-product messaging makes sense for a given launch, and if so, the best format and targeting. Here are four formats we primarily use at Figma: * Modals: We typically reserve modals for our bigger and most requested feature launches. We keep the copy on these modals more straight-forward, letting users know what’s new and how it can help them. We also try to keep users in the product, often including a link to a playground Figma file where they can try out the feature in a more guided fashion. For example, when we launched Auto layout, a highly requested feature, we used an in-product modal to announce the feature, linking to a playground file where users could try it out. * Playground files: This one is more unique to Figma, but a format we use often. Playground files are Figma Community files that our team creates to onboard a user onto a new product or feature. They include an overview of the feature alongside examples of how it can be used, and activities that you can try yourself. Here is an example of a playground file for Variants. * Tool tips: More commonly, we use tool tips to share new features and updates to the product UI. These are less distracting and allow us to highlight where exactly where users can find the new feature. For example, we recently used a tool tip to highlight how users could access new embed and Gif functionality in FigJam. * Banners: We rely on in-product banners less for marketing, and more for important comms — when we want to share information that we believe is critical for users to know. For example, we recently used banners in our Admin console to inform admins that FigJam would become a paid product starting in February of 2022.

Methods for keeping everyone up to date will vary from company to company, based on the communication norms in place. At Figma, here are some of the ways we keep internal teams up-to-date today: * Push out internal comms: At Figma, we primarily use Slack over email. We have a channel called #product-launches that PMMs update on launch day so that everyone in the company has visibility into what’s launching and can chime in with any questions or concerns as the feature rolls out. Every Friday, we also summarize the past week's releases and upcoming launches in this channel. In addition to Slack, we have weekly meetings to keep GTM teams in the loop about upcoming releases, and monthly launch calendar reviews where we review the quarterly launch calendar with Product and marketing leads. * Maintain a single source of truth: As we’ve gotten bigger, its become increasingly important to have a single source of truth where anyone can go to see the latest launch dates. We plan all of our launches in Asana and make sure they’re integrated into our marketing team calendar which includes important milestones across all of our channels. * Internal marketing/education: In addition keeping everyone in the loop, we also want to get folks excited about upcoming launches and new features. We often spotlight larger launches at our company meeting to generate this excitement — these presentations are a cross-functional effort between product, engineering, and go-to-market. We also partner with product to enable our Sales team, encouraging them to share the news with customers.

I’m generally in favor of being transparent with customers when it comes to the product roadmap. It can be a great opportunity for Account Managers to engage with customers ahead of renewals and expansion conversations. There are a few things to keep in mind when doing so: * Include a safe harbor. If you’re going to share future plans, it’s important that you include a safe harbor stating that nothing shared is 100% certain and that your product plans may change. Your friends in legal will thank you :) * No more than 6 months ahead. We all know that product roadmaps change. A rough guideline I like to follow is only including features we expect to launch in the next ~6 months. This gives us greater confidence in the features we’re including. It also gives us an opportunity to engage customers twice a year with this content. * Sales can share, but not leave behind. A product roadmap is a great resource for your sales team, but you want to avoid it getting in the wrong hands (like your competitors). We advise our sales team to reserve roadmap decks for live walk-throughs rather than leave behinds. * Consider keeping a few things under wraps. Depending on the timing, we might decide to exclude a feature from the roadmap. Typically these are features we plan to announce soon where we want to retain the element of surprise. * Transparency when things slip. When we’ve publicly shared launch dates (e.g. announcement at our annual conference), we proactively share an update to let users know if things have changed (explaining why when we can).