Stephanie Zou

For me, the most helpful thing is to talk to customers. Here's an example of something I recently did to help inform messaging that hopefully sparks some ideas for you. When I first started at Figma, I wanted to better wrap my head around what "collaboration" meant. The word "collaboration" is so generic. Everything is "collaborative" and works "better together". So I wanted to get to the bottom of what parts of Figma's collaboration capabilities do customers really care about. Caveat: I'm not a trained researcher. But everyone and anyone should feel empowered to talk to customers. Sorry for any research faux pas here :) I came up with a couple exercises I wanted to get customer feedback on. Mocked it up in a Figma file, shared a link to the file with the customer, and asked them to do the exercises live. Exercise #1) I wrote down all the common things related to collaboration I've heard customers say about Figma, like being able to have all their design files in one place on the Web or be able to co-edit a file together. Then I asked them to stack rank based on what's most important to their workflow. Here's a screenshot of that exercise. Exercise #2) Then I wanted to test some sample messaging/copy. To do that, I created 3 landing page variations of a "collaboration" webpage and asked them to talk out loud as they read through the pages, express what things meant to them and talk about how the messaging made them feel. Here's a screenshot of that. What I learned was while we often think about "collaboration" in Figma as co-editing in a file, the async parts of collaboration are perhaps more important. It's like working in Google Docs. It's nice to be able to write copy together, but how often do you actually do that? What makes something like Google Docs also great is that it's one doc that's always up-to-date, that auto-saves, that has built-in versioning, that you can add comments, leave feedback and have conversations. 

Here are a few questions I would ask... 1. What’s the goal for your launch? Is it a new product/feature that’s going to bring in more revenue or new signups? Is it a catch-up feature to nix competitive objections? Or is the goal about product usage? Your tactics should serve that goal. Example: Let’s say you’re launching a new feature that’s on your Enterprise plan, like Figma’s analytics launch. The goal was two-fold—to make sure we see a certain % of regular feature usage among our Enterprise users and drive upgrades to our highest plan. The tactics should serve one of these goals if not both. 2. What tactics have worked in the past? Don’t discredit what’s working or something you’ve always done as “boring”. Example: Contrary to popular belief, long-form product announcement blog posts perform really well for us in terms of both signups and sustained engagement 30 days post publication. We take a more journalistic approach to uncover the “angle” so the article more than just a feature announcement. Even someone who knows nothing about Figma can still learn something from it, like this very in-depth piece about type line height. In today’s world where everything seems to be about short, scannable content, perhaps our approach helps differentiate us. 3. Where are your customers? Where do they get your news? Where do they get industry news? Example: At Figma, our customers are designers. They’re very active on Twitter. They often go to industry meetups and events. They’re savvy with online research—searching for YouTube tutorials or relevant blog articles. They also frequently connect with their peers to exchange ideas. Where designers live is often where we focus our efforts. 4. Don’t forget about your customer-facing teams! They are the best “marketing channel”. We arm support teams with “saved replies” that they add to their support tool. We also often times send out personalized campaigns on behalf of our sales teams and give them a “hit list” of customers to reach out to.

Launching the Figma Community. Some quick context: Figma Community is a space where individuals and brands can create a public profile and publish design files to the world, so anyone in the world can inspect, remix, and learn from their work. A couple of things made it hard... * It’s a novel concept. No design software has built something quite like this before within their product. Designers can now share a design file on the Web. Anyone in the world can go to inspect that file, learn how it’s created, and duplicate a version of the file to start riffing off of it. Designers are used to online communities where work was displayed as static images, not interactive files. So customers definitely had lots of questions around what they should publish as public files and how it all works. * We knew we needed tons of customer examples. It was kind of a chicken and egg problem. We needed customers publishing stuff for launch, but we needed to also give them inspiration first so they can inspire others. We had to do lots of pitching and meetings with customers. We pitched Slack, Dropbox, VMware, Unsplash, City of Chicago, and many others on our vision, brainstormed with them on what they could publish to the community, and worked with them to create their profile. And as we all marketers know, getting customer approvals in order to talk about them publicly is yet another fun hurdle :) * And this is just the beginning...we have a lot more hard work ahead. We are still in beta and we need to amass enough individuals and brands publishing and using resources regularly in order for this to be a true community. 

Philosophically, I'm a fan of a "full-stack" PMM model where they look after their product area end-to-end. We have one product at the moment, so our PMMs are aligned by areas within our product. One of our PMMs look after our Editor, Prototyping, and Community product areas—essentially making sure Figma works amazing for today's designers and the next generation of designers. The other PMM looks after our Collaboration, Enterprise, and Design Systems product areas. In other words, how does Figma work across teams at large organizations who need to scale their design processes? We have a 2.5:1 PM/PMM ratio at the moment and I'd like to maintain that over time as we grow. Outside of the traditional PMM role, "PMM" has a slightly more expansion role at Figma. We also have marketing manager who looks after our Education segment, as that's a special segment for us. Our customer marketer is also part of the "PMM" team as we all work very closely with our customers.

I think one of the best parts of being a PMM is you get to bring a bunch of different people/teams together to work towards a common goal. I’ve probably done more launches than I dare count and manage people who’ve managed people who’ve done even more launches than me. I guess the launches that I remember most are the ones where we worked well together on. Product announcements are great moments for your company because it brings people together and it’s an exciting and celebratory milestone. I guess what makes a great launch is one where you really got people bought in on your vision, capitalized on everyone's strengths and contributions, and conquered all the peaks and valleys together. Often times, PMMs may not manage big teams. But you can have so much influence on other people and teams if you choose to rally and empower the troops. 

At all the companies I’ve been at, the one consistent segmentation lens has always been company size. Bigger company = more people = more licenses you can sell. Other lens can be the types of customers they serve, type of business (e.g. subscription, marketplace), industries, role/departments, and more. Unfortunately, I don't have time to go in-depth in segmentation here, but one piece of advice is to keep it overly simple and don't overcomplicate things. I've seen so many overcomplicated segmentation exercises that live and die in a presentation deck, because everyone in the room is like "duh, I could have told you that." Lots of people and websites say don't talk to internal employees to gather insights about customer segmentation (since it's biased). I say there's probably a lot of institutional knowledge that exists. 

I believe that it’s the PMM’s responsibility to make sure your internal teams are informed about a release. If your internal teams aren’t well-versed in what’s new, how do you expect your external customers to be? Some things we currently do: * Setup Slack channel(s) for release updates and launches that everyone at the company can join and follow along * Enable sales, support, success (basically any customer-facing team) at an opportune learning time (their time zone, not Monday mornings or Friday afternoons). For a release that introduces substantial change to the product, processes, or customer experience, you may need to do multiple enablement sessions. For smaller updates, a short Slack post in the sales team channel will do. * Dog food your own feature. The best internal communication and marketing tool is using your own feature. * Get your whole company excited. I am a big believer in internal marketing before a public launch. So you can think about doing things like presenting at lunch and learns/all hands, making posters, or organizing an internal celebration. As we get bigger, I would probably introduce things like internal newsletters and more in-depth enablement programs and certifications.

The answer you’ve probably heard many times before (but I will say it again because I believe it): I believe PMM should be a critical partner to product as early as the product requirement definition stage (or however way you kick off planning). What value can PMM add so early on? You can add value in so many ways! Write the story you want to tell when you launch, so product builds a compelling enough feature. Lend your expertise on the competitive landscape. Define the various use cases and best practices on how the feature is used (not just what it does). Sounds dreamy. How do you get there? When you join an early-stage PMM team, it’s really common for PMM to be “looped in” when the feature was ready to launch. At every company I’ve been a PMM at, I’ve had to work my way to be “looped in” earlier in the feature development process. You have to earn it. No PM or engineer is going to care about your opinions and POV if you don’t develop your knowledge about the product and space, and that takes time. If you’re looped when things are ready to launch, push to get involved in the beta. When you’re looped in during the beta, push to get involved during beta planning. When you’re looped into beta planning, push to get involved in user research…so on, so forth. Just keep inching your way earlier in the process one step at a time.

Email me at [email protected] and let’s talk more so I can better understand your use case? 🙂 In general, I’m a fan of rolling thunder launches (aka a collection of feature releases that are launched at different times but ladder up to one umbrella message). Most of your customers are going to miss your announcements. Rolling thunders help you hammer a message home over the course of multiple releases. So let’s say a customer only catches a couple of those announcements, they’ll at least get the bigger story you’re trying to convey. I would be weary to do too many big tier releases. Both you and your customers will get launch fatigue. Plus your job is much more than just product launches and your time is finite 😉

Most often than not, features are going to get cut in what product ships. It's probably going to be more MVP than everyone had hoped for. I'm a fan of leaning forward and telling a bigger story that includes features you plan to build, as long as you and the team are confident that it's coming soon. I know not every company or product team is comfortable with this, but I think it's such a great opportunity to talk about your vision and what you hope to be/achieve. We get asked this all the time by our customers. We love your features, but tell us more about your POV!