Lauren Craigie

We have a strong community in the dbt Slack channel, but it's not inclusive of all dbt practioners. So we use four main channels to get in front of our target audience: 1. The dbt Slack community, when announcements are highly relevant to their work 2. Quarterly product launch events targeting existing users that want to go deeper on new releases 3. A "how to" write-up for our DevBlog paired with a "why we did it" blog for our Corporate Blog 4. A monthly product newsletter that might include an invitation to participate in the beta, or quotes from early users. Bonus 5. I think we'll start bringing back product team office hours to make ourselves more available as a resource for digging deep in new functionality.

My first advice here is to not accept an interview if you’re being asked to create a full GTM plan for a product they actually plan to ship :) But aside from that, I think the best way to start is by asking a few key questions you should already be asking in the normal interview process. In my opinion it’s the questions alone that PMMs ask that helps me decide whether they’d be the right fit. Some examples of what you could ask prior to getting started on the assignment: * Describe your ICP for this product and include example titles and psychographic info like where they get their information * Tell me the goal of this product—upsell, new user acquisition, competitive maintenance, market share grab, TAM expansion, etc. * Give me a budget to assume when creating this plan * Give me a timeline to assume—you could just tell me “3 months” or “one week” but it would help to include any info you don’t want me to assume like the date when the product PRD would be complete, when the beta program will be kicked off and complete, and when you expect this to marketing launch * Should I assume this can be bundled with any other recent launches? After you have those questions answered I would bulletize some of the activities you would undertake, grouped by category (research, positioning, pricing, packaging, promotion, etc). And outline how long you expect them to take and what resources you would need to bring them to life. It’s important for your hiring manager to know exactly what you can do alone if that’s the role (first pmm), or with a team (10th pmm with a full gtm team to support)

I wish it wasn't different, to be honest. If I say what people normally say here, like, "it's more honest, it's straight-forward, it gets right to the meat of it," I'm left thinking... Why don't we market that way to everyone? Why don't we create tiered experiences that let you get right to the details if you want, or float up high in the "business value." But, to be actually helpful here, I think developer marketing typically happens in a company with product-led-growth, which means you need to optimize for just trying the thing. Hook them on an understanding of why this thing will meaningfully improve their day-to-day, and then give them the narratives they need to sell it up the stack, if needed, later. Don't let anything get in the way of that trial experience, and that includes making onboarding too complex, introducing too many use cases, or not being clear about how to immediately share value.

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.

I think everything new in the product is launched to some degree, but we do use a launch tiering system— Tier 1 to Tier 3. I've seen this model at other organizations and it works well to align on a standard set of actions for each launch depending on the goal. Major product initaitives that will materially impact your brand, audience, or bottom line? Tier 1—press release, sales enablement, videos, one-pagers, website landing page, paid promotion, blogs, guides, social posts, etc. Adjustment to your product's UI that will change or open a new workflow? At the very least you need to ensure you 1) write up a messaging house everyone can align on when talking about it (from support to sales), 2) Ensure the support team knows it's coming and is equipped with the most common questions they'll likely get 3) Create a beacon in your product that alerts folks to the change. You could also add it to a "Recently improved" category in your monthly product newsletter, or save several of these smaller launches for a larger "momentum" annoucnement that shows that you're really working hard to improve user experience. 

Curiosity and a desire to be understood. These two qualities over nearly everything else. You can easily learn the frameworks--steps for a successful launch, format for a battle card, considerations for pricing... you can also improve your writing to align with brand and write high impact choppy copy. But it's not easy to teach someone how to be curious about how a user ACTUALLY feels about your product. How to dig into data to find which features aren't being touched. How to keep iterating on sales enablement until they REALLY get it. How to ship surveys to test messaging because you really care about connecting with your target audience. These qualities are worth their weight in gold when you find them in a PMM candidate.

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)

 Detailed use case stories. Not just case studies--not "customer in healthcare vertical uses us to ensure data is correct" but the nitty gritty details--"Customer in healthcare with a distributed data team uses our product to keep payroll shipping on time every week." The more detailed, including which teams and roles are involved in the use case, the easier it is for them to connect with prospects facing the same problem.

Normal caveat of "it depends." But generally, if you're hiring your first PMM, focus them on becoming your audience expert. I think a lot of folks tend to focus too severely on ensuring PMMs are product experts in the first 90. "HOW CAN THEY TALK COMPETENTLY ABOUT THE PRODUCT IF THEY DON'T KNOW HOW IT WORKS?!" Personally, I don't care how someone who isn't my target audience experiences the product. I don't care what a PMM thinks about onboarding. I don't care if they know how to demo it. At least not in the first 90, becuase I have other people who can do that right now, in engineering, sales, and product teams, and honestly do a better job of it. What's more valuable, and a gap you likely haven't filled through those other teams, is expertise in your audience—who you've reached today, and who you want to reach tomorrow. Put your new PMM on customer calls, have them send out surveys, talk to analysts, talk to partners. Have them write case studies. And THEN have them use those insights, directly from the mouths of customers, to improve how the product is messaged, demoed, and eventually—built.

I've heard before that product marketing KPIs can be squishy—that it's hard to quantify the value of what we do. I don't agree! I have a few KPIs that are unique to PMM, and a few that are tackled with PM, just from a different angle. I'll focus mostly on the shared KPIs: Shared: Feature adoption. Self-serve or Sales-led/assisted - PM would be responsible for continuous feature use over the lifecycle of an account (is the thing we built actually useful and intuitively designed?) - PMM is responsible for adoption within the first ~30 days (did we get the right message in front of the right audience as soon as possible?) Shared: Competitive win rate. Self-serve or Sales-led/assisted - PM influences by delivering net new or incremental improvements to feautures where we have a key competitive advantage - PMM influences by getting hyperspecific on how these features are positioned and messaged on the website, in app, and through sales enablement Shared: User Acuqisition and Conversion rates. Self-serve. - A growth PM can influence how intuitive a self-serve trial experience is for new users, and how quickly they get to the 'ah-ha' moment, increasing rate and speed of acquisition and conversion. - A PMM influences rate of acquisition and conversion early in the buyer journey, through supporting materials like demo videos and guides that help align product expectations with the reality of product experience. Unique: New market penetration. Self-serve or Sales-led/assisted - PMM influences by tuning messaging to amplify existing product features and use cases that matter most to users in new markets