AMA: WordPress.com Former Director of Product Marketing, Sara Rosso on Product Marketing Processes in a Remote Company

One of the biggest risks of operationalizing a GTM plan is the lack of a common understanding of the time it takes to do good marketing work, internally. Marketing shouldn't slow down product; but at the same time, the more time and advance notice marketing has, the more we're able to enrich, adapt, and customize a GTM plan appropriately. A GTM playbook is a best-case scenario and a guideline which has to be adapted rapidly and practically to the lead time available. The marketing team for WordPress.com is relatively new (around 5 years old for a product almost 15 years old), and speed is very important to product development and serving millions of existing customers. Our engineering teams are pushing to production several times or even dozens of times a day, and so we have to work together to make sure we give sufficient time to amplify the great work they're doing with existing and prospective customers. Ideally we're involved as soon as it's known the product team is preparing a feature or change for launch, so we can identify the channels, messaging, and timing needed to market the work as soon as it's ready to ship to production. We don't use formal documents like a market requirements document, but I've documented and communicated top elements of that process the engineering team should be thinking about when they're preparing a feature for development, and it's an exercise they can go through at kickoff instead of when the feature is ready to test or launch. We can partner with them to identify any gaps, or help answer those questions, and then come up with a realistic GTM strategy with the time available. Here's an excerpt of the exercise I shared internally: We’re building a feature or product to solve a problem or do a job for customers, and then tell as many of the right customers as possible that we’ve solved it for them. - What product or feature is being developed? Focus on user perception and usage – features, needs, usability, methods of usage. How does it apply to customers of the entire family of Automattic products? - Who are the target customers? What user behavior, demographics, or other attributes do they have? How might they be different? Does this apply to current or prospective customers, or both? A subset of customers? - Why are customers likely to want this product/feature? (aka: what problem does this solve for the user? Why would they ‘hire’ it to do a job?) - When will the product be available? How much detail can you share about the timing? Can you include any ballpark dates or checkpoint dates which could be helpful for those involved to know about? - Any pricing-related information? Is the feature being added to a plan? Does it replace a paid feature, lower a plan price, or change the potential revenue from a sign-up?

As a fully distributed / remote company, we operate slightly uniquely than other companies - the two biggest differences are 1) we don't use email and 2) everything by default is public to the entire company. Instead of email, we publish everything on our intranet, which is naturally powered by WordPress, and it's also public to the entire company. The intranet is essentially hundreds of WordPress(.com) sites, which we call P2s after the theme they run. P2 is available for anyone to use https://p2theme.com/ and the design enables easier front-end posting & inline commenting, so it's less of a broadcast tool and more of a conversation or social network. The P2s can be dedicated to teams, projects, or topics, and they're all networked together so that you can mention a colleague, or cross-post to a team's p2 to loop them into the conversation. The wonderful thing about having public information is that you can involve any person in the company in seconds, and they can read the specific comment, question, or conversation they're being asked to weigh in on without forwarding them a chain of emails. The information is threaded and available, and they can see what everyone else has said before them, and people can even like the comment / answer. We post vision and strategy, calls for discussion, project outlines & to-dos, tracking of major efforts. Discussions, decisions, documentation. It's all privately public.

See this answer for how we work as a 100% distributed company. We work a lot in "public." As for updates, the entire company publishes bi-weekly updates on a special p2/site that's meant to aggregate the most important updates from each team or division across the company. This is the opportunity for the team to highlight wins, lessons learned, or changes the rest of the company shouldn't miss. And it's great to be able to link to specific project, research, or test results for more details without overwhelming the person reading.