Jon Rooney

For new senior PMM hires (like Sr. Director/Director team leads), I think of 30-60-90 plans to follow a basic flow: assess (30 days), design (60 days), run (90 days). During the "assess" phase, a senior PMM has to listen, observe and learn as much as possible: meet the team and figure out the current state of how basic stuff (sales decks, product launches, campaign content/strategy, analyst relations) gets done. Learn the product cold, not just the demos but how to actually use it. Watch how teams (whether PMMs or PMs or Sales Engineers) demo the product - how consistent are those? How do customers react? How does our demo pitch compare to competitors? Same thing with sales pitches - how many homegrown/Frankenstein pitch decks are floating around? What seems to land and what doesn't? How are reps - particularly in a fast growing environments when new reps are joining all the time - getting enabled on the product? How are they grabbing assets when they need them? Go through the same onboarding as a new sales rep. And, once you have a little bit of grounding, do ridealongs with reps - even if it's just Zoom calls. Attend a QBR or two if you can. Watch demos/keynotes/etc from competitors to help you understand the landscape - how differentiated is everyone? Could you infer your company's positioning from the space left over from how competitors position or is the landscape pretty murky. Finally, understand the current marketing machine and how it works. How does content end up on the website and how/why does it change? What's the demand gen hand-off with sales and how is marketing being measured? Why do we invest indo certain events, how do they get executed and what do we hope to get out of them? Who defines campain themes? Who reviews and has to approve copy/content/press releases/analyst presentations? How are launches planned and executed? For the "design" phase, map out how PMM works with sales, product and the rest of marketing and lay out what should stay the same and what needs to change. Engage with all relevant stakeholders on what you think needs to change and why (particularly, how these changes will make their lives easier and help them meet their goals). This is the hardest part, no doubt, but if everything was operating perfectly they probably wouldn't have needed to bring you on in the first place. Ladder up these changes to the top level GTM goals (revenue growth, product usage/activation, net customer retention) and explain how these changes will help meet those goals. Then map it all out with everyone, making sure it's all as simple and straightforward as possible so that everyone will be ready ready to implement these changes. Finally, during the "run" phase, put it all in practice with a growth mindset of measure and iterate. Go in with the assumption that you didn't get everything right so be ready to tweak things - whether it's as simple as adding another reviewer for web copy updates or as major as who should be an analyst spokesperson for a major launch. Cover your own responsibilites but also stay close to team doing new things in new ways so you can both support them and get firsthand feedback on what's working and what's not. Synthesize that feedback, adjust and run again. Of course, in the midst of all of this in your first 90 days you'll have tasks and firedrills flying at you from all over the place - it's critical that you juggle both and don't lose sight of methodical assess-design-run work or else you'll end up as a reactive "short-order cook" rather than as a strategic partner to the other functions. This is an awful place for PMM to land and it doesn't really help the business or your team. Don't let that happen. 

Some years ago, I was running a PMM team at Splunk when we introduced a new product that was a persona-driven solution for IT built on top of the core platform - it even featured machine learning capabilities before AIOps was a thing (Gartner was calling it ITOA at the time). To date, we had had a ton of success with IT practitioners and buyers but we saw an opportunity to move up the value stack and deliver something more purpose-built. When we drafted the value prop hypothesis and initial messaging, we realized it sounded a lot like a category of solutions (Business Systems Management or BSM) from legacy vendors (BMC, CA, HP, etc) that had promised a lot but failed to deliver a few years earlier. So we had to thread the needle that “yes, this new product actually does all the great stuff that BSM vendors promised and more - but it’s NOT BSM, because of the approach, etc, etc.” So we did all the methodical research laid out in the other answer - analyst feedback (they were adamant that we don’t position this like BSM 2.0), 3rd party panelling and, especially, beta customer research as part of a formal New Product Introduction (NPI) process. Nurturing those beta customers to be reference customers and putting those testimonials at the center of our launch was key to landing the messaging, as what customers say resonates much more than what vendors say (naturally).

The early work Twilio did to quickly convey what the service did and who it's for then get developers to dig into the product and have an a-ha moment with a couple of lines of code was pretty great. All of it tic and tied back to the brand and voice of the company, which had a sort of open source community vibe despite being a commercial entity. 

When I was at New Relic, the PMM team was organized by buying center/persona with a platform team that worked on foundational capabilities and use cases. Rolling out new messaging was generally tied to a big event (user conference, sales kickoff, etc) and started at the top, with delivery from the most senior leaders immediately backed by enablement (including certifying on company overview decks, etc) and content refreshes.

Selling to developers can be difficult, often because they have a ton of say over the decision but not explicitly the budget, but marketing to developers is simpler than people think. Quickly and concretely explain what your product does and how it works/fits in with other stacks (as much as developers love to claim that they're immune to marketing/branding - just look at the stickers on their laptops. C'mon - that's brand loyalty/affinity on par with pre-teen pop music fans) then get them into some demo/free trial/"doing the thing with your product" as quickly as possible with resources (docs, tooling, code samples) they can self-service on and then get out of their way (and watch). If your product can't convince them of it's awesomeness through hands-on experience you have a tough road ahead of you. But if it's got the goods, and you have visibility via a modern SaaS offering so you know who's doing what, then sales enablement becomes all about: 1. Reading the signals from inside the product of who's getting value and ripe for value capture becuase your product has already created value for them - developer marketing / advocacy gets them into the trials/usage - not tradtional SDRs/AEs generally. Devs don't want to talk to those folks. 2. Navigating the org to find budget. If the decision lives in dev, budget could live in IT. So arming reps with the information they need to show who's already using the product a ton and finding out who can pay the bill. That's classic BANT stuff. 3. Ensuring they're ongoing nurture/always on signals to the devs about what's coming, integrations, more tools/code samples, etc so that the fly wheel can continue on it's own. Dev advocacy / evangelism is critical here. It's super important to not make Sales folks feel like they need to cram on all the technical knowledge to somehow pass as credible. Often when the decision maker is dev but an AE is most comfortable talking to IT (because IT has all the budget and buying experience), AE's will shy away here thinking they have to do the heavy lift to kick things off. They don't (or shouldn't) - devs getting value out of your stuff kicks things off. Good luck! 

I don’t count internal debate/discussion or “inside the building” opinions to be testing per se, so I assume you mean external validation. In the realm of enterprise software (which is where I’m coming from), I’ve found 4 ways (best run in parallel then rationalized) to test messaging once you have some initial draft/hypothesis messaging to test: 1. Hopefully your company has some sort of beta/early access program to validate new capabilities and products - usually managed by product. What customers say organically and unprompted during this beta/early access process (what actual words they use to describe what problems they’re trying to solve, how your solution works - or doesn’t - and how it helps them - or doesn’t) is the single most useful signal I’ve gotten for crafting messaging, particularly for something new. So as a PMM, join all of the calls and just listen. Don’t put your draft messaging in front of the customers for feedback, just listen carefully to what the customer’s going through and how they describe it. Chances are, their words (when rationalized across a handful of beta deployments) will give you the foundation you need to write compelling messaging for launch. 2. If you have budget, contract out for market research to be done with target personas in which the problem statement, solution/product description and value proposition is presented (even without screenshots or any type of demo) then ranked/scored both with and without your company name being attached to it. The key here is ensuring that the customer panel is selected correctly (this is super easy to do wrong and thus invalidate the entire exercise) and the information presented is clear and differentiated enough to provide specific feedback (so don’t ask about overarching things like “digital transformation” - get specific). 3. If you don’t have budget - and you sell enterprise software through standard procurement processes - get your hands on as many RFPs as possible and read them carefully. Make note of how exactly customers talk about what they need and be sure to make note of words and phrases that show up over and over again. You’re probably obscuring the value of what your product actually does in vague descriptors or cliches. What you pull out of reading a bunch of RFPs will improve your messaging, no doubt. 4. Again, this is more for enterprise software, and I know this might seem like a no-brainer, but reach out early and often for feedback from industry analysts (Gartner, IDC, Forrester, 451, Red Monk, etc). They talk to customers and likely every one of your competitors, plus most have practitioner backgrounds, so they know their stuff and have ideas to share. Lots of vendors make the mistake of treating analysts transactionally and developing adversarial relationships around rankings and such. That’s a huge mistake and, if that’s where your head’s at, change it today. If you genuinely approach analysts for their thoughts and ideas (so present for 10% of the time, listen for 90% of the time) you’ll be surprised at how frank many of these analysts will be and how helpful their feedback can be. Don’t take it all for gospel - be sure to triangulate and synthesize - but it’s a great input when gathered correctly.

Product marketing performance should absolutely be measured, and both the outcomes and measurement parameters should be well-understood from the start to avoid a whole lot of folks running around doing stuff without a clear sense of "why?" and "how do we know if it's going well?". Every industry and business is going to be slightly different, but any PMM metrics and measurement should ladder up logically to the top 3-4 company objectives or goals - like grow revenue by X%, boost net customer retention by Y% or enter Z market with a compelling, credible offering. Once you have the top 3-4 company objectives or goals (and if senior leadership can't agree on those, you might be in trouble), the next step is to determine exactly what the product marketing team is doing (and, subsequently, not doing) to drive to those goals. For example, if a top company goal is to grow revenue by X%, the PMM team isn't responsible for owning accounts or closing new opportunities per se (that would be sales) or ensuring customers have the support they need to drive expansion and prevent churn (that would be customer success), but there is a lot that PMM does along the way. Don't let that work get lost - measure it so you can manage it. Messaging is a fundamental responsibility of PMMs, but don't just measure task completion (i.e. messaging docs drafted, reviewed and delivered), measure whether or not that messaging is working. In a modern PLG SaaS environment, messaging is critical to getting prospects not only signed up but using the product. If the messaging isn't landing (too vague, wrong audience, chock full of jargon), sign-ups will struggle and adoption will be even worse. But if people actually understand how your company's product will help, both at the top of the funnel and while they're finding their way around post-signup, that's a strong signal that messaging is working so take those KPIs for the PMM team. It's the same thing with sales enablement work like First Call Decks (FCDs), competitive battle cards, sales plays, demo scripts - the kind of work we tend to spend a ton of time on as PMMs. Don't just measure the completion and delivery of those assets (most GTM orgs are swimming in undiscovered or out-dated artifacts cranked out by PMMs), measure their impact on opportunities both being created (which in a SaaS/PLG team is measured by self-service customers "crossing over" and in traditional enterprise sales is measured by BDRs/SDRs creating an opportunity guided by assets likely created by PMMs) as well as opportunities progressing to close. Product marketing teams should be creating assets and programs that rally stakeholders, enable champions and fend off competitors during RFP bakeoffs to help drive early opportunities to close. Track when and where sales teams use those assets and programs and do cohort analysis to show the impact of when they're used vs. when they're not to help scale GTM and evolve past an account team "hero ball" culture that will likely have PMMs scrambling around like short-order cooks.

Your product launch strategy should be created out of answering two fundamental questions: 1. "What problems are we solving for whom and why are we uniquely set up to win here?" 2. "How exactly will we capture the additional value we're creating and what does that mean to our business?" Once you have crisp, clear answers to both, you can start building a launch strategy. Some launches are about introducing a new project for a new audience, which is a completely different motion and level of effort than launching something incremental to your core audience (see the Ansoff Matrix), so vagueness around question #1 will tank your ability to understand target, goals and tactics. Having a clear answer to question #2 will help guide tactics and investments, particularly the mix between awareness and demand/lead gen. If the goal is we need leads that convert to opportunities in a managed sales motion, then the plan should focus on those activities (webinars, events, content behind form fills) whereas if the goal is to drive users to try/use in a PLG motion, then the tactics will be very different. And throughout the process, be sure to anchor on strategy vs. tactics - "how will this launch help position us to do something that we can uniquely do to win in the market?" vs. "here's a plan with a bunch of action items and dates"

Everyone having a natural gift for messaging is an amazing coincidence, indeed :) Per "ways of testing question", the best approach is backing your messaging with methodical research that shows validation by customers, prospects and industry analysts/influencers. You still need to do your homework about competitive messaging and gather feedback internally from sales / field folks in particular. But formulate hypothesis / draft messaging (and gather internal feedback for that) then do your research per above, giving read outs but not keeping the blue-sky ideation phase going indefinitely, then defend it based on the merits of your findings and your synthesis as a PMM.

For longer sales cycles, the product marketing team should be creating assets and programs that rally stakeholders, enable champions and fend off competitors during Request For Proposal (RFP) bakeoffs to help drive early opportunities to close. Long sales cycles frequently involve RFPs heavily influenced by third-party artifacts like Gartner Magic Quadrants and Forrester Waves that map out critical capabilities, functional requirements and other vectors of consideration. The PMM team should create and own a "golden" response ready to go with core messaging, up-to-date product capabilities and pricing/packaging so account teams aren't scrambling to pull that info together at the last minute. Pulling a "golden" RFP response off the shelf and making a few tweaks based on the customer is a much better path to success for account teams. Long sales cycles often mean dealing with multiple stakeholders, so if you're selling to a line of business you'll also have to get through reviews from IT, security, legal, compliance, etc. Have spec sheets, whitepapers, demos and other artifacts ready to go for those personas. PMM needs to stay close to the account teams to understand what works and what doesn't then pivot accordingly. Internal champions at the customer/prospect are often critical in winning long sales cycles so the PMM team should figure out what those champions need to rally their peers and senior leaders to help win the deal. It might be a reference customer "brag book" that shows how other companies in their industry have been successful using your product or it might be architectural diagrams or demos to win over more technical audiences. Again, staying close to the account teams and building a relationship with the champion (if possible) will help ensure PMM creates the right content for the right audiences.