Pranav Deshpande

I've written about this in detail on my blog, so I'll summarize my thoughts below! Messaging and positioning work is never complete, so always treat your positioning doc as a living document that will evolve with your business. The framework I like to use involves starting with jobs to be done: Step 1: Start with the ‘jobs to be done’ What: Define the ‘jobs’ your product can be ‘hired’ to perform Why: As Peter Drucker once said, customers don’t buy products or features, they buy benefits. Jobs-to-be-done helps you look at your product from your customers perspective, making it easier to separate the benefits from the features. Step 2 Segment your TAM What: Segment customers in your TAM using obvious and visible characteristics. Why: For segmentation to be effective, it needs to be based on obvious and visible characteristics to accurately validate your messaging. Step 3 Map jobs to be done to benefits What: Map the ‘jobs’ each segment cares about to the benefits delivered by your product or feature. Why: Each customer segment does not care about all the benefits you have to offer. Mapping helps you identify which products or features, and therefore benefits you highlight when positioning your product to a particular customer segment. Step 4 Analyze competitive alternatives What: Analyze alternatives available to each customer segment for these jobs Why: You can’t identify and articulate benefits in a vacuum. Step 5 Articulate your value What: Articulate the value your product provides relative to the alternatives in a way most likely to resonate with each segment. Why: This is where you bring your positioning home. Having identified the jobs to be done, benefits, customer segments and competitive alternatives, it’s much easier to articulate the value of your offering.

You can't think of developer GTM as just another channel you can tack on to an existing GTM motion, like paid social or sponsorships. Developer GTM needs to be an integral component of the company's strategy, with product, engineering, and sales all aligned towards making it successful. It requires hiring a different breed of marketer, specifically developers-turned-marketers, to operate. I think its also a lot easier to build this function during the early stages of your GTM journey to make cross-functonal alignnment easier. A developer GTM strategy requires a strong content and community focus. For some companies, especially those that come from open-source projects, the community focus is programmed into their DNA. They need to focus on hiring the right developer marketing team to produce content the community will find helpful. Marketing to developers looks more like education than marketing. Building content, reference implementations, and tools to make developers' lives easier should be the goal. But you also need to think about what happens after a developer signs up for your product. There needs to be a well-defined plan to nuture them over time or introduce them to a sales rep to discuss their use case in more detail if they have plans to use it in production. The nature of sales changes too, becoming more solutions-oriented and consultative. 

In my opinion, benefits need to describe the outcome of using the feature. The outcome should address a real pain point for the target customer of the feature. The benefit should also be relative to the next best alternative available to the target customer. When we draft positioning statements for our products at Modern Treasury, we make sure they separately articulate pain points, alternatives, and top benefits for each key product feature. For example, for our Payments product, 'Direct bank connectivity' is a feature and 'Focus on shipping your core product faster instead of figuring out how to integrate with different banks and payment methods' is the associated benefit.

To start I'd say thorough competitive research is the foundation of great product marketing, so it's great that your company is investing in it. It's really important for the PMM that owns a product to be an expert on both direct and indirect competitors. Competitive research shouldn't happen in a vaccuum — it needs to be informed by persona research and the long term vision and product strategy. Especially at the early stages of a new product, the competitive landscape can seem vast and intimidating. Knowing what your core personas care about and where your product and engineering team is investing helps narrow it down significantly. At Modern Treasury, the PMM team maintains a list of jobs-to-be-done for our target personas that guides everything from how we look at competitors to our product positioning framework. Our approach to extensive competitive research involves producing a Competitive Deep Dive, a 4-5 page document designed to uncover everything product, sales and customer success teams need to know about the company. These documents typically include a list of the company's products, an analysis of their positioning, screenshots or screengrabs of their product experience (if self-service), their media presence (if any), pricing (if available) and customer reviews (both andecdotal and from review sites if available). Since we're an API product company, we also break down API documentation and devex if available. These deep dives serve as the foundation for battle cards, objection handling and other sales enablement content, in addition to being used by product teams for product strategy. Hope this was helpful! I'm also happy to chat about it 1:1 any time. 

Your sales team needs a higher level of technical proficiency when you're a B2D company. It's important to hire sales reps that can form their own mental model of how your product works and integrates with the rest of a customers tech stack for them to be successful. They don't need to know how to code, but they do need to be able to develop a strong functional understanding of the product their selling. Assuming you've hired sales reps that fit this criteria, enablement should focus on use cases and technical vocabulary. You should train reps on the types of implementation patterns or use cases they can expect. Technical vocabulary involves helping them understand the terms developers are likely to use and how your products performance in those areas will impact success. 

I think it's important to discuss the objective of investing in marketing to developers before answering this question directly. At Twilio, the Developer Marketing team described their mission as 'inspiring and equipping today's developers to build the next generation of communications'. Their goal was to make Twilio APIs an integral part of the toolkit of any developers, regardless of whether they had an immediate need from them or not. The thesis (which prove to be spectacularly correct) was that if individual developers know and trust Twilio products and use them in their side projects or during hackathons at work, they would advocate for Twilio when it was time to sign an enterprise contract. Content and community participation was core to this strategy. Twilio was at every single developer event, whether large ones like PyCon and even smaller local events or those focused on upcoming languages and technologies. They churned out a steady stream of developer guides, blog posts and viral Twilio apps like the Santa phone. With this objective in mind, I think Developer Relations can be thought of as a distinct function under Developer Marketing that focuses more on the community relations side. It involves building relationships with individual developers, especially those with influence in a certain language or technology, as well as managing your presence at relevant developer events. It can also include your social media presence as well as virtual events like Twitch or YouTube livestreams. Dev Rel works with the Developer Education function (responsible for developer guides, reference apps and other content) to distribute content to the right developer audiences. In my experience, most companies do not have this level of specialization until they are a lot bigger. It's usually the same people responsible for both Dev Rel and Dev Ed. However explicitly recongizing this distinction can help with specialization down the line.

There's both qualitative and quantitative ways to test messaging, and in my opinion both are equally important in the long run. The qualitative approach involves directly validating messaging with your target audience by: 1. Joining sales calls, pitching the product yourself, and seeing how they respond. 2. Interviewing your sales and customer success team to understand which aspects of the messaging you've drafted for them are resonating. 3. Listening to recorded customer conversations. At Modern Treasury, we're huge fans of Gong. I spend about 2 hours every week listening to Gong calls. 4. In-person events are a great place to test messaging. Some of the best signals I've received in the past have come from conversations at events. 5. Trade publications, newsletters, and other industry media that your target audience consumes are great places to find new messaging ideas! The quantitative approach involves: 1. Buying LinkedIn or display ads targeted at the roles that comprise your ICP and running different messages for the same CTA to measure relative performance. This can get expensive though, because you need to reach a large enough number to achieve significance. 2. A/B testing copy on your website. You need to make sure you can get enough unique views over your test period to achieve significance. 3. Similar to 2, email campaigns are also a great way to test different copy. If you're at a startup that's just found p/m fit, quantitative testing can be harder to do because your sample sizes might be too small. In that case, I recommend starting with qualitative approach first! 

We've followed a three step process in the past that's helped us identify messaging for multiple audiences in an effective and efficient way: 1. Start with listing the core value props of your product at a high level, irrespective of the target persona. For example, if your product is more efficient, flexible or scalable than existing alternatives, the core value props are Efficiency, Flexibility and Scalability. 2. List the core jobs-to-be-done for each target audience. You should already have this as a result of your persona research. If you don't, I highly recommend running a persona research exercise first, where you interview existing customers or prospects representing each target persona. 3. Map the jobs-to-be-done to value props. Each persona might care about different value props, and this exercise helps you identify those explicitly. 4. Draft key messages for each mapping between jobs-to-be-done and value props. This is where the rubber meets the road. Once you've explicitly articulated which value props each persona cares about, it becomes quite easy to draft messages for different formats and channels that can be used in the launch. Deciding which marketing materials to use depends entirely on the nature of the product and your understanding of how customers and prospects engage with your company. For example, if your product demos well, key messages should be incorporated into live or recorded demos, webinars and if you have a self-serve product, the product onboarding experience. If you primarily engage via B2B content, incorporate it into whitepapers, webinars etc. I hope this was useful! Happy to chat more. Drop me a note at [email protected]

To be honest, this has been difficult to figure out. I don't think we have the best solution yet, but for now, we write down positioning statetements for each product, which include key messages, to ensure that we have one clear reference for other teams in the company. Each positioning statement is versioned to make sure we're tracking how often its being changed. What I've found is these internal docs are most useful to PMM or the rest of marketing. But they aren't great at dissemination. The most effective way to disseminate your messaging is repeating it as many times in as many formats (web pages, content, developer docs, internal sales training) as possible. 

Great question! The relative importance of these tips depends on your GTM motion (mostly top-down or mostly bottoms-up), but in principle they're all about contributing meaningfully to growing revenues and customer count: 1. Case studies - sales and demand gen love customer case studies. Nothing sells or converst quite like social proof, so creating a few case studies is a great way to get some early wins. 2. Competitive intelligence - competitive deep dives and analyses are foundational to PMM, but also immediately useful to product and customer facing teams. 3. Better web copy - if you've joined as the first PMM, chances are your company's websiste could use some work :) 4. Content - which types of content convert best for your business? Focus on those initially. At Modern Treasury, SEO was a clear winner for us earlier on so I helped drive the creation of Learn, our payment operations glossary.