AMA: Cortex Head of Product Marketing, Lauren Craigie on Go-To-Market Strategy

If there’s alignment on the ICP you’ve helped codify — alignment both where you win today and where you want to win tomorrow — it’s significantly easier to influence product roadmap. But there’s two ways to think about this: 1) advocate for the problem to be solved 2) advocate for the solution to a known problem If you have an established product management function #1 tends to be the fastest route to action. PMs always need help collecting data about the market and users, and PMM should be doing this at least quarterly from customer calls/interviews and market surveys. But they also tend to have the most expertise on the functional requirements for solving that problem in a way that fits engineering capacity, user experience, and budget. If you feel strongly about a particular feature, you can also advocate for that (#2), but you’ll need to prove that exactly what you’re describing is what customers have asked for. This often comes up in follow-on questions in an NPS (“Why did you choose that score?” Or, “what would have to change for you to give us a 10?”), and so can be a direct source of evidence when speaking with product, design, and engineering.

A few things come to mind— * You get the audience wrong. You’ve built something you think will be useful, but your marketing and messaging isn’t tailored to the right audience, so adoption wanes. * You get the pricing wrong. I think every pricing change will feel like you’ve gotten it “wrong” because you’ll hear the loudest feedback from what may be a minority of your buyers. But if you haven’t tested your pricing in smaller groups or done adequate interviews to get the packaging, model, price point, and discounting correct, you risk losing a large swath of existing users or turning away prospects that may not give you another shot * You haven’t set up adequate tracking. You push something into the world and believe from a few conversations that adoption will be high, but you haven’t set measures of success or a plan to come back in the first week, 6 weeks, and 3 months to reassess.

My first advice here is to not accept an interview if you’re being asked to create a full GTM plan for a product they actually plan to ship :) But aside from that, I think the best way to start is by asking a few key questions you should already be asking in the normal interview process. In my opinion it’s the questions alone that PMMs ask that helps me decide whether they’d be the right fit. Some examples of what you could ask prior to getting started on the assignment: * Describe your ICP for this product and include example titles and psychographic info like where they get their information * Tell me the goal of this product—upsell, new user acquisition, competitive maintenance, market share grab, TAM expansion, etc. * Give me a budget to assume when creating this plan * Give me a timeline to assume—you could just tell me “3 months” or “one week” but it would help to include any info you don’t want me to assume like the date when the product PRD would be complete, when the beta program will be kicked off and complete, and when you expect this to marketing launch * Should I assume this can be bundled with any other recent launches? After you have those questions answered I would bulletize some of the activities you would undertake, grouped by category (research, positioning, pricing, packaging, promotion, etc). And outline how long you expect them to take and what resources you would need to bring them to life. It’s important for your hiring manager to know exactly what you can do alone if that’s the role (first pmm), or with a team (10th pmm with a full gtm team to support)

Good question—there’s always some grey area on lines of responsibility so I’ll add which other teams might own/participate in each phase: * Research: can be owned by or with the UX and PM teams but should include user research, jobs to be done, alternatives for your solution, and language used * PRD (product requirements doc): owned by the PM but the PMM can help contribute problem and solution framing. This is what I treat as gospel for exactly what the engineering team will commit to building, by when, and whether there’s any contractural obligations for current or future customers. * Build: owned by engineers but PMM needs to stay close to ensure all priorities committed are trending according to schedule—it’s not your job to prioritize work for engineering but you don’t want to be the last to know if something you’re already planning to market won’t be ready in time. * Messaging: owned by pmm but should work closely with product in completing. Cover audience, benefits, and boilerplate messaging for web, slides, blogs, etc * Content: often owned by pmm but if you have a content or corp comms function they may just need your messaging house as defined above. Think one pagers, demo videos, social, slides, case studies, beta testimonials, and PR. * Pricing: often owned by pmm, in partnership with the data team of one exists, finance, sales, and product. * Enablement: owned by pmm unless you have an enablement team embedded in the sales org (you’ll be heavily contributing content for training either way). Think calculators, cheat sheets, objection handling, persona-specific messaging and playbooks. * Rev Recc: mostly handled by sales ops—how your sales team records opportunities.

* PRD (I don’t create but it’s vital for me to have so I ensure one exists) * Launch plan in a productivity or shared tool, plus a slack channel for all GTM leads * Messaging house-snippets the team can use whenever they talk about the product on web, in digital, campaigns, outbound, etc * Outbound templates for SDR/BDR and sales to give them accurate messaging in a succinct format * Website landing page if a significant new release * Press release if a significant release

Everything comes back to the launch tiering for me. T1-T3. In a nutshell: T1 is revenue-generating or new market opening — you should have a landing page on the website, pricing and packaging, and a long-tail content strategy T2 is usage/adoption or competitive win rate increasing — you may not need pricing/packaging or a landing page but should have a plan to talk about this feature again in all of your go-forward content T3 is user experience improvement or churn reduction — you need customer comms but won’t need pricing, a landing page, or a dedicated content strategy.

I want to answer this one because I think it’s important to take note of the framing :) The marketing team shouldn’t have to be “convinced” after you’ve already created a plan. They should be aware of/excited about your launches well ahead of that. Sit down with the team and do quarterly or monthly campaign planning centered on expansive stories where your launch can be a key pillar holding up a lot of their own efforts. If the launch isn’t big enough to influence their plans, that’s okay! It might be a tier 2 or 3. But anything that you deem a company trajectory-changing launch should be central to the entire company’s OKRs.

You could consider a weekly or monthly product update email, public running change log, or in-app notifications (or docked changelog) for your current customers.

What a cool question! And project for you to undertake! I think the good news is that if your market research, audience focus, and messaging framework were as robust as you’d hope, you don’t need to think too hard about refactoring core positioning. So I would refocus your effort into three (sizeable) categories, ordered by time needed to execute: 1) Pricing/packaging: If you’re moving one of your products to self-service there’s significant infrastructure that will likely need to be considered to enable someone to swipe a credit-card. Payment infra, data capture and monitoring, and compliance come to mind. Don’t underestimate the complexity of this work—most of which will be owned by product and engineering. Your role will be in nailing pricing, packaging, discounting, and upsell or expansion playbooks. 2) Promotion: Your content needs to span several mediums, and allow users to self-serve everything from thought leadership about the problem your product serves to how-to guides, videos, forums, etc. Your social, digital, paid, and ad strategy should also change. If you don’t have teams owning those things already that should be a major consideration in timelines for launch. 3) Support: A self-service product centers on self-service support. Are your docs crystal clear and easy to find? Do they cover the “why” as well as the “how?” Do you have an onboarding guide that can be used for different use cases? Does your support team have proper routing and escalation set up for significantly higher volumes? How will you update users on changes if there’s no Account Manager or Account Executive in the mix?

I think it’s less important to worry about consensus seeking on every step (there should be dozens for every launch regardless of size), and most important to align on 1) what constitutes a really big launch, a medium launch, and a small launch 2) align on roles that you hope/expect your peers in product, sales, marketing, and engineering to assume 3) align on the understanding that launch planning is significantly more than just the launch blog—that it includes PMMs involvement in research before the PRD is ever written.