AMA: New Relic Former SVP, Product and Solutions Marketing, Jon Rooney on Messaging

I’ll (mercifully) go away from tech here: My go-to example is Thomas Moser, which makes really high-end, handmade furniture in Maine, has limited distribution and sells their designs at a decidedly premium price point. Years ago, before owning even a single chair was remotely in my budget, I came across one of their catalogs and thought “super cool, but I can get a chair for $20 at IKEA.” Then friends registered for a set of chairs for their wedding and, having chipped in for a portion, I was added to their mailing list and got sucked into the brand via their voice, narrative, design and overall approach. You’re not buying a chair, you’re investing in functional, handmade art made by artisans in New England for your heirs. A chair not for the person you are today, but the person you could be. Super well done and I still think about those catalogs in terms of messaging/storytelling. I also love how the Criterion Collection has created their brand and managed their product line through big technological and behavioral upheaval, from the super collectable Criterion Collection DVDs (I’m Gen X, so those DVDs are totally in my wheelhouse) to their current streaming service which, while not for everyone, has a dedicated audience. Their YouTube channel also has a ton of great content that reinforces their brand and voice. Also, while there are some inexplicably amazing official Twitter accounts out there (I’m looking at you @NJGov), I can’t recommend @MoonPie enough. So, so great.

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.

Consistency is super critical and the modern agile/”move fast and break stuff” ethos does nothing but make that effort feel Sisyphean at times. If you’re in tech (particularly in an engineering-driven culture), you will fight this battle every day since, as the saying goes, everyone wants to build but no one wants to maintain. Two keys to staying ahead are 1) have as few core messages as possible and repeat them over and over again and 2) be vigilant about policing their usage in places over which you have more control/influence (website, videos, sales decks, keynotes, collateral, enablement, analyst decks, 10-Q’s/K’s, etc). Get really crisp on roles/responsibilities and work processes with folks who create copy and content (content marketing, demand gen, docs, sales enablement, etc.) so that they’re adapting messaging, not creating their own. That’s where problems start. Good luck, it's weeding a garden unfortunately - you can't set it and forget it.

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).

If by technical value, you mean “what does this thing actually do?” - a lot. Most technical categories are super crowded (and if they’re not crowded, they’re nascent and not well-understood), so being precise on “we’re different in that we solve these problems in these ways” is super important so that those details aren’t left entirely for SE’s in a discovery meeting with a prospect. If you have a highly technical product offering chances are you also have highly technical users/decision makers that you're trying to reach - treat their time and intelligence with respect by getting to the "there there" of what your offering does and how it helps. Business value is of course important - like good old “reduce MTTR” which is a mainstay in my space - but the HOW is often the differentiated part, make that clear without getting into the weeds of feeds and speeds and you’re golden.

You need to consider competition before you even start your messaging. For me, messaging should build off of positioning and a strong positioning statement should encapsulate differentiated product strategy, including how this thing we’re offering is better than other stuff that’s out there. That’s how you keep your messaging from sounding vague and generic and ensure your company has a point of view on a space and problem set. I’ve seen a bit of a trend recently where PMs, especially, don’t want to go deep on competitors (as if to not sully their own novel ideas I guess?) and so competitive positioning is sometimes de-emphasized or is generated downstream, in a GTM team rather than baked into the rationalization for why to even build a thing in the first place. That’s nonsense - every one of your customers is scrutinizing your offering against your competitors so you need to know what’s up.

I assume by segments you mean industry/vertical and/or company size (SMB vs large enterprise, for example) - in that case I’d consider running methodical research work (see the other question answer on 4 recommended approaches) in different tracks aligned to each of the 3 segments, ensuring there’s a common umbrella message and thread through it all so it doesn’t sound like 3 different companies. Anchor in each segment and bring the message about your brand to each segment rather than the other way around - you’re too susceptible to confirmation bias that way IMO. Also, brand messaging is different from product messaging - the brand is more about who you are and what feeling you what to evoke/what associations people make with your brand from customers/prospects vs. what your product/offering does and how it helps customers. They have to be coherent and ladder up, but conflating the two only causes trouble.

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.

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.

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!