AMA: dbt Labs Former Director of Product Marketing, Lauren Craigie on Developer Product Marketing

It depends a bit on how your sales team is organized today. But in any event, your product value pillars should always translate to both individual and company-wide gain, so your core message is always consistent, even if the language changes a bit to accomodate the audience. You might consider a mapping exercise that lets you chart that narrative. For example, "velocity" is one of our core product value pillars. For the individual: Code portability, modularity, and packages helps each developer code faster, to focus on higher value work. For the company: More developers coding faster means faster time to market, which means greater market expansion and revenue uplift. In both cases we're talking about how the product enables velocity, but we shift the message a bit depending on the audience. Your bottom-up materials should focus on the former example, while your sales enablement materials (assuming the target audience is an enterprise buyer, or team manager), should focus on things like revenue impact, quality, security, or other things that a manager is incentivized to consider.

Same! In my case, I was also dealing with phased launches--bits of the solution released every few weeks. And I understand why–when you're working with a developer audience there's less appetite for a big splashy release, and more interest in a phased roll-out of a given feature or product just to get hands on it ASAP and iterate as quickly as possible. That was tough to get used to. I would start by finding out a little more about what's causing those delays in product. If it's intentional, to phase releases in order to get beta feedback, I would consider setting up a power user group. Same group of 20-30 developers that agree to test most things that come down the pipe and provide feedback in a private Slack channel. That might provide more confidence in on-time releases. If this is something the product team ALSO wants to fix, and maybe it's just an engineering resourcing issue, I would have them commit to not releasing anything without your knowledge at least a week in advance. That will give you enough time for customer comms and enablement, which are your most important tick boxes. In a previous role, I realized that my product team thought that product marketing was just about blogs and social media posts, because they would say things like, "we don't really need marketing for this release," and then would launch without my knowledge. Ensure your product team knows that half of your job is awareness, and retention, and you can't accomplish either without being in the loop. Once the thing is out the door, don't feel like it's "too late" for a larger marketing campaign. Even a quarter or so later you can bundle a number of things that have already lanched and create a larger campaign.

I start with personas. I develop a thesis about core personas based on sales and customer success feedback, and then conduct user interviews to validate or invalidate those ideas. That's probably the most important bit–my job isn't to just synthesize learnings from within our business, it's to continually test and validate those learnings externally. I then circulate research + personas with key executive leaders (CEO, Head of Product, Head of Sales), until we agree on the shape of each. Then I create a messaging house for the business, and each product line, according to the primary persona we agree is most worth pursing. From there, launching new features, new content, new playbooks, etc becomes much easier when we take it back to our core persona.

Your documentation needs to be extremely thorough (technical), and your resources need to leave no uncertainty in how or why to use new products and features, but your topline message doesn't necessarily need to be "technical"-- at least not how I think of the word, which is detailed and revealing-full-complexity. It just needs to be frank. Exactly what is the thing, and what can you do with it. Eliminate unecessary superlatives that developers often find dubious like "best" "fastest" "end-to-end" "complete solution" and describe it exactly how you would describe it to a developer within your own company. Developers don't buy silver bullets, they appreciate and celebrate a thing that does one thing very well. When it comes to presentation materials or demos, I think a common misunderstanding is that developers don't care about the "why," and you should skip your up-front narrative. That's absolutely not true. You just need to tighten and tune that narrative to speak to that audience. What do they care most about? Maybe talk less about cost savings, retention, long-term business value... and more about time-savings, burnout, skill-sharperning, and individual career-value. You don't have to leave off the problem statement to be frank: "Widgets were time-consuming. Our product lets you develop without using widgets."

* Don't gatekeep access to hands-on learning * While the org-wide value story is important, developer product marketing should focus a little more on "why now, why me" Ensure there are materials that help people ramp quickly and easily. * Ensure packaging and pricing reflects an ability to not just try, but get sticky, with an incentive (product-based, as in it makes their lives easier) to share with others. * Be frank, be sharp, be honest * Create visibile opportunities to contribute to making the product better. Host AMAs, office hours, quarerly roadmap reviews... enable the community to have a material impact on product development and positioning

This is also why I think a great Dev PMM doesn't really need any PMM experience. Look to solutions architects, pre-sales engineers, or just developers in your space. It's much easier to learn PMM frameworks than it is to learn a new domain, and gain the respect you need to tap into the best insights

A great question. I should caveat by saying that if your organization has a seperate DevRel or DevEx team that reports into product isntead of marketing, I don't expect them to share the same methods of measuring community engagement and uplift. For marketing targets, I would look at new feature and product adoption (within first 2 weeks after marketing launch), upsell, retention, and maybe even network effect (mentions elsewhere). Are folks sharing what they've learned from you and writing blogs, Discourse posts, social posts, etc? If they're sharing your tool/features with their network, it's a good sign they believe in it. 

Great question. We actually have a third unit – Developer Experience. I'm sure it differs at other organizations, but at dbt Labs... Developer Relations is focused on growing the community (measured by Slack members and weekly active projects in the open source product), building lasting relationships with members, enforcing community guidelines, elevating diverse and marginalized voices, and highlighting the contributing work of members around the world. They build trust. Developer Experience is focused on creating content for developers that aid in their day-to-day work. Think playbooks, best practices, technical how-to guides etc. They create value by authoring self-serve educational materials, and encouraging developers to create and share their own. They accelerate engagement. Developer Product Marketing both underpins and feeds off of the above work. DevPMM shapes messaging and overarching narrative, informs product roadmap, and even sets pricing and packaging for paid products. DevPMM works with the above two groups by ensuring the way we talk about product use and value is consistent with core messaging, and focuses on extending conversations on core topics in the form of blogs, interviews, and even long-form guides. We also learn a great deal more about our core personas from DevEx and DevRel. We build narrative consistency.

Get crystal clear on the developer persona, and establish a framework for regularly updating it. I don't think there's any better use of your time than talking to folks 1:1 and using the way they frame value to write your own messaging framworks. I would also take the time to clearly establish roles, boundries, and overlap with any DevRel or DevEx folks at your organization. What are the goals of each. Why are they different? In what ways are they the same? Ensure alignment with that group on core value, voice, and tone.

We all miss the mark here. I'm not even sure I would trust a PMM that says they don't struggle with this! You can stack the deck though, to show that you're exploring every possible avenue: 1. Consider a competitive monitoring solution like Crayon. I've used them in the past and even if they can't dig up things like exact product pricing, they will aggregate signals in market like a executive job posting in EMEA that shows they're about to expand internationally, or a change to their pricing page where they've dropped a freemium trial, or removed a feature, or a shift in homepage messaging or tone that signals a change in target audience. You could probably do that on your own if you know what to look for but something that monitors 24/7 and surfaces little indicators like these I've found to be really valuable. 2. If you have a slack community, ask frankly to interview folks that have made a switch. Create a case study out of it, but also use the insights to inform competitive positioning 3. Talk to a Gartner rep. Even if you don't have a subscription, you can set up a convo with a rep and tell them what research you're interested in exploring. They'll send it to you as a pre-read. In return, you can agree to start doing more regular briefings with them so they stay abreast of your technology as you grow. 4. Don't discount the audience. We often take for granted that our competitors are aiming for the same persona we are. If you can show that you're going after slightly different use cases, or slightly different audiences, the exact details of their offering shouldn't cloud what your product roadmap looks like 5. Get in those other products, or recruit someone on the product or eng team to give you a tour. Bring someone from the product design or UX team along (they may have already done this work, or be in the process of conducting this research). 6. Check out the forums for people comparing your solution to another. Check Hackernoon, StackShare, and even Reddit for posts.

If your company is focused on community building, then I think now is the right time to bring that resource aboard. If you mean Dev PMM or Dev Ex (folks a little more focused on creating resources), you can build this capability internally before dropping someone in: Ask other technical folks at the company that you think already have a great voice, and have already built trust in the community (founder, solutions architects, pre-sales engineers, product team), to write and present more. Saying "you should write a blog!" will almost never get you what you need on a timeline that you think is appropriate, so you'll have to do a bit of set up. Consider a prompt format-- ask them to write 50-100 words (expand that if you have someone who wants to build their brand a bit more and is willing to play a bigger role) on why a given feature is useful. Or, why now is the right time for the new product you're launching. Or, why the market is ripe for disruption. Whatever it is, keep the focus extremely narrow. Use those prompts to build out longer blogs, reports, etc. Ask the product team to record Loom videos when they're shipping. It's easy for them to do, and gives you another resource for content when you prepare your launch. Lean on quarterly community surveys to ensure you're capturing top of mind thoughts, ideas, and concerns. Not having someone focused on day-to-day interaction is ok in the short term, but your community has to feel like they have an outlet for being heard and understood.

I'm sure it's different for everyone but here's roughly what it might look like if you have a paid product you want developers to convert to: Classic funnel: Website, search, or paid ad > Content/event/sales engagement that shows intent > purchase > expansion/upsell Developer journey: Free trial > noteworthy event (API call, project launch, program publish, etc) > conversion to paid > evangelize (write/present/talk about your solution in communities)