Sara Rosso

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.

Having worked on both the B2B and B2C markets, as David above says, the sales cycle length is completely different, and B2B can be weeks or months depending on the product and budget approval needed. With a startup you might be able to get to the decision maker or budget holder much faster than an enterprise, but depending on the product it might not be an essential buy for them depending on what stage they're in - make sure to factor in what Series / stage the startup is in to your planning. 

It depends on what you'd like to accomplish - Zoom is great for video because you can shift between a very personal feeling like showing all participants on video, to more formal broadcasting with focusing on you as a single speaker or spotlighting an entire panel. I don't think Zoom's chat function is as robust as it could be compared to other tools, so if you're dependent on that to surface questions or engage customers you might look at others. We've used GoToWebinar and Crowdcast as well. If you're looking for webinars as a lead funnel versus engaging with or educating existing / known customers you'll value different features. 

I think you need a mix of experiences AND data to transform what might seem like different opinions into persuasive arguments with impact. Experiences provide the context and detail, relatable quotes or example customer pain points, etc., and Data provides the measurement - how big of a problem is this? How easily can we quantify it? What impact might it have? That way it can be prioritized. In your example, perhaps a sales team says "Customers tell us they want this feature / benefit we don't have." with the data, you're also able to say "And we lost X opportunities this month because we don't have it" and perhaps influence the product roadmap or at least the competitive messaging in the short-term.

Foundational qualitative research should be done as soon as you are able, and also ahead of any major product shifts or market expansions. We've also explored qualitative research with "the ones who got away" - lost, paying customers. Understanding where we've failed them or where competition has become a better alternative has also been really helpful - sometimes it's a solution we already have that they weren't able to find easily and we can make changes without largely changing the product. The quicker you can engage lost customers, the better, because once they've left their desire to give feedback (or even remember) greatly diminishes the more time has passed.