AMA: ThoughtSpot Senior Director of Product Marketing, Christine Sotelo-Dag on Messaging

Creating a closed-loop messaging program / projects largely sits in how you set these programs and projects up. When I've done Company / Platform messaging creation or updates I like to kick the project off with aligning on the goals of messaging, ensuring my internal stakeholders know: 1. What a messaging house is 2. How it should be used, and by who 3. What goes into creating good messaging (ie. this is not a silo'd writing project that is quickly whipped up) Here is an example from one of my former messaging houses: This guide exists to ensure consistency in our messaging across our activities and channels, and reduces re-creation of messaging. Use this messaging guide: * As a foundation of any content you create about company and our products (both internal and external). See the grid below for different message levels, and when to use each. * Messaging is not copy, it is OK to change working to suit specific contexts and formats, but the core message and intent should stay the same. * Whenever you are creating content, you should also take into account our brand voice [insert from brand team]. * You can ask Product Marketing to review any content created or have any questions. We have different messaging depending on whether you’re describing the company, our platform or a specific product/solution: Messaging Levels COMPANY To use when describing the company - why we exist, our vision and mission, etc Examples: About us page, Profiles on sites like Wikipedia, Crunchbase, GR profiles, candidate content like job description, Investor, press or analyst content. PLATFORM To use when describing the product/ platform as a whole. Examples: Sales pitches, Homepage / What is ThoughtSpot pages, Thought leadership content, Brand campaigns PRODUCTS To use when you’re describing one of our specific products / solutions. Examples: Product level landing pages and content offers, product / solution campaigns, Pitch deck slides, etc When updating or creating company, platform or product messaging which is likely updated less often, you should consider doing an internal roadshow to educate stakeholders on how these updates impact their functions and an inventory of assets that should be updated. For feature messaging, this should be included in your launch kickoffs so teams know how to incorporate it in their work streams appropriately .

There are a few parts that go into this at the foundational level, that I think help when doing the tactical writing for gap closing features. Prior to writing any code, you and your product counterparts should have aligned on the why behind building this feature (ie X competitor has it, and we are losing deals because we don't) but you should have also established the differentiation in what you're building. If the feature is basic, and functionally the same - it is still a part of your wider organization and supports your company's specific value props and is built with your company's ethos. Leverage this more macro messaging to craft the feature messaging to really help differentiate. Another area to consider here is audience. Likely you have some kind of tiering system. Tier 1 and sometimes 2 features are usually defined by being something truly different in the market - and therefore used to attract prospects, where tier 3 and 4 are likely gap closers or table stakes and the audience is likely existing customers. This should also be worked into your messaging strategy.

While I was working at Intercom under Matt Hodges he recommended our entire team read 'On Writing Well' and I still go back to this book often for tips on good writing. Although, it's not specifically teaching how to avoid cliches, it does help the reader with tips on keeping writing clear and succinct and compelling. So I'd check that out. I also follow Emma Stratton at Punchy and I have consumed SO MUCH of her content. She does specifically tackle how to avoid jargon, and why it doesn't work - so start following her ASAP if you don't already. And more tactically, I try and write like I speak as much as possible. I don't use works like best-in-class or seamless in my day to day speak and neither do our customers. We have to remember that even if we work at a B2B organization the buyer we sell to is a human - who wants to be talked to like a human. If you have the resources to do so, partner with great copywriters to help bring your message to life in a human way that aligns to your brands tone. And lastly, message test as much as possible.

Message testing is really important and often overlooked, however there are several ways to qualitatively test your messaging that are rather easy to implement. 1. A/B Testing: Conduct A/B tests where you create two or more variations of your messaging and expose them to different segments of your audience. Measure key metrics such as click-through rates, conversion rates, and engagement to determine which messaging resonates best with your audience. There are great and affordable tools out there that help implement this as well. 2. Surveys and Questionnaires: Design surveys and questionnaires to gather feedback from your target audience about your messaging. Ask specific questions to assess comprehension, appeal, relevance, and clarity of the messaging. Use quantitative scales to measure responses and identify trends. 3. Website Analytics: Utilize website analytics tools to track user behavior on your website in response to different messaging variations. Monitor metrics such as bounce rates, time on page, and conversion rates to understand how visitors are interacting with your messaging. 4. Heatmaps and User Testing: Use tools like heatmaps and user testing platforms to visually analyze how users interact with your messaging on web pages, landing pages, and digital assets. Identify areas of interest, patterns of engagement, and points of friction in the user experience. Most of the above can be done affordably and in a self-serve manner that give quick feedback that you can marry against your qualitative feedback.

This changes slightly based on whether this is Company Messaging, Platform Messaging, Product or Feature Messaging, but my frameworks usually contain a mix of the following: * Target Audience * Description * Key Message (in 1-2 sentences) * Key Value Prop(s) * Customer Pain * How we solve it (in a differentiated way) * Product Proof Points * Customer Proof Points * Hero Use Cases * Key differentiated features 

This definitely depends on your business, strategy, industry etc. In my past experience the more macro level messaging like Company or Platform messaging is iterated on less frequently. This is usually updated in relation to specific events such as company level strategy shifts, net new product (product SKU), acquisitions, etc. Maybe once a year. Product Messaging likely gets updated more often. Definitely when you introduce new (Tier 1) features that may open your product to new segments or audiences. Or after a collection of features have been introduced that now allow you to tell a fuller, richer macro product story. Keeping an eye on competitive messaging is important too as competitors often look to each other to see what is being said, and adapting their message - which leads to diluted messaging in the market. All that said, I'd look to update product messaging on some level on a quarterly or bi-annually basis.

This likely differs based on how your company and teams are structured. In my experience PMM. creates messaging with the input of key stakeholders such as product. However final sign-off sits with Marketing (if that is where the PMM team is situated) meaning Head of PMM and/or CMO (depending on the magnitude of the project) are final approvers.

The best way to mitigate this risk (and this is a very common risk) is to stand up messaging projects as a formal project. This means: * There is a clear project plan that gives stakeholders the opportunity to feed into messaging with their insights and opinions. * Related to the above, try and steer stakeholders away from gut opinions as the only input, what data or evidence do we have to back up those opinions * In the project plan bake in a couple rounds of feedback prior to approval * Create a clear DACI / RACI that outlines who is the final approver on messaging (This is key because at the approval stage there may need to be the decision to disagree and commit) * Share a plan for testing and iteration that allows for iterations if message performance isn't performing

Value props are directly linked to customer pain. If you truly understand the pain you are solving for (through customer, prospect and market research) then you can take that pain and map it to how your product or solution solves that pain - which is your value prop. Clearly communicating those value props also requires that you state your value in a way that is tied to the impact the customer can expect from using your product, and how your product solves their pain in a way that competitors can not (differentiation).

Research! Basic messaging is usually written quickly, based on what is believed to be true or what a business wants customers to know about their company and product. Messaging that has an impact comes from understanding your audience the customer research, and speaking their language.

Quantitive metrics (see above answered questions) such as A/B testing, Website data, etc. Combined with Qualitative feedback: * Sales feedback * Customer feedback * Analysts feedback * Social channels

This is not an easy problem to solve and definitely depends on what tools your company uses. In the past we've used Coda or Notion when those were the tools our entire company was leveraging as an internal portal. However, the easiest way to do this is likely to create a google drive that has folders for templates, your company, products, feature messaging and you can point stakeholders to the folder.

I love this question and I'm a huge fan of JTBD again from my time at Intercom where this was a huge part of how we build and marketed our products. This actually needs to start before you get to the messaging stage. This needs to start at the product scoping stage, where you and your product team should develop a PRD (Product Requirements Doc). This doc should clearly define what is the problem to be solved (what is the job customers want to do). Once this has been defined, and a solution is defined and built, you can build your messaging around the Jobs this solution now enables your customers to do - versus feature and functionality.