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

Video or advertising is likely where a lot of your spend will go for high priority launches, and justifying it would likely come down to whether you're expectlong this launch to have meaningful impact on pipeline, deal-size, market share, etc in the next 3 quarters. If it's a brand new product that is meant to generate pipeline I'd see paid ads coming into the picture... (but now I'm speaking out of my depth as that work would be owned by rev or demand gen marketing.) I have done third-party video production for full new product line launches. Not just demo videos but high quality visual assets. "Explanimation" videos are likely to run you $4k-$15k per 2 min clip, and video testimonials/demos with high profile customers that have maybe used the product in beta could run you anywhere between $5k and $50k depending on scope, crew involved, travel, etc.

I'd say this can change based on the organization, contributing teams, goals for the launch, market you're in, audience... but a few things I would never launch without: 1. Naming. Sounds simple, but the way that your engineering team refers to something is very often NOT the way you should be communicating it externally. Take the time to name. 2. Pricing and packaging. Work out EARLY whether this should only be available to certain tiers. 3. Target personas. Exactly who is this for, and why do they care. What are their alternatives? 4. Extending from the above— a messaging house that every internal team can align behind. The way Support talks about the thing should be aligned with how Sales and Marketing talk about it. Words matter. Framing matters. Value prop matters. 5. Documentation. Whether this comes in the form of a changelog update, a new docs page, a one-pager, or even a blog. Ensure you have public-facing documentation to share. For large launches, you'll find it handy to also have: - A list of internal and external FAQs - Sales & CS enablement + slideware for them to also talk about the thing in meetings - Blog post + social assets - Demo video or other imagery - "How it works" as part of your messaging house—what's the user journey, what should they do before and after? - Metrics for success. How do we know we did the thing well?

Good question! Mindset shift suggestion: Every release, or update, or upgrade is a launch. BUT there are different tiers of launches which enable us to provide a very low level, but consistent level of support. It's not the job of PMM to create fanfare around every single update, but it IS our job to create understanding around each. Getting ready to ship v0.1.13? You don't need a parade or a linkedin post, but you do need to make sure your audience understands the changes. Have your product or docs team be responsible for updating the changelog, or set a reminder to ping them every two weeks for what's new so you can do it yourself. Optimize for reducing questions around anythign that launches—both internally and externally. If you don't expect a lot of questions, even better!

Answered above but everything is a launch in my opinion—you just tier them differently. The value of this approach is that you have a documented plan for everything, even the very small things, that includes messaging and enablement (maybe even just for the support team), at minimum. Bug patches are still valuable for customers to know about, and you might consider including those in a changelog, or noting which sers have flagged related concerns and shoot them an update email.

I might be misunderstanding the question but you usually can't get them to prioritize new products unless it's built into their targets :) Introducing a new product into their deal could unecessarily complicate and extend sales cycles (which isn't good for them or you—as an employee of a business that relies on that revenue), so if they're not goaled on that by their sales leader they won't attempt it. If they have been told to focus on it, but still aren't, it could be because they don't trust it (this has happened to me!). Show them positive data/quotes from the beta, explain the uplift it'll provide to ACV, give them clear use cases, ensure your FAQs are tight, and above all else, just ask them why they aren't selling it. You might hear something you can solve really easily--like they need a call script for a bit until they feel more comfortable.

Like what could cause it to fail? 1. You don't have a handle on the target audience, and what they'll find most valuable about the product, or the frame of reference they hold when introduced to it 2. You don't have an accountability partner in product management that is equally on the hook for the success of the launch 3. You haven't prepared the sales AND support teams to field questions about the launch

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

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.

I wish I was able to ask this person to expound a little more on this one! I'm not entirely sure what's being asked but my top tips for developer-focused messaging during launches are: 1. All PMMs love to elevate the why over the how, but in developer marketing your why is worthless if it's not focused on why the INDIVIDUAL should care. They want their business to succeed, but not at the expense of a bad workflow for them. Let's use ourselves as examples. If a competitive intel tool launched a new feature for PMMs, your first question isn't, "how will this improve my businesses' bottom line?" it's usually, "Will it be EASY for me to ensure the sales team gets value out of this feature? Because if they're not happy I'm not happy... but I only have so many hours in the day." You may have to answer the first question eventually, (if you have to ask finance for more money), but you already vaguely know the business problem you want to solve, otherwise you wouldn't be engaged with this solution to begin with. Save the macro why's for the budget-holders. Your micro-whys are your moment to explain to a developer why THEY should care, and why your solution is unique. 2. In the same vein, appealing to a feeling is more likely to be successful than trying to wax about a larger problem with hyperbolic words. Instead of, "Ensure your sales team has seamless access to information when they need it—saving you time and effort." try, "Want to build a relationship with sales but tired of that only looking like the same Slack ping for new competitive intel? Keep your time and their trust by letting them self-serve answers through out solution." The latter prompts you to actually remember that time your sales team did that to you, and how you felt. That's what prompts action. 3. Write to one person. There are MANY developers. Trying to list all of the cool things about your launch will never be as effective as keeping one persona in mind, and creating messaging for that segment. Create multiple messages to different audiences if needed, but don't dilute your moment to capture their attention by trying to cram it all in one post.

I use 30 day adoption as the primary KPI for measuring launch success (did we target the right audience with the right message and make it painfully obvious to do the thing?). I think success of the product or feature, over time, is another matter—where message testing and evolution is critical. But for the former, you'll need to get very crisp on your measurement tactic, especially for features over net new products which are easier to measure as line-items in an order form: 1) Who do you actually expect to use the thing that's been launched? If adoption is 10% of your entire user base, that's not great, unless you've just launched a feature that's only applicable to 10% of your base... 2) Ensure your data team needs to know exactly what "counts" as feature adoption (clicks a thing, takes multiple steps, uses for a week, takes an action off the back of the thing, etc), and that they can reliably collect this data. There are tools out there like Heap, Amplitude, and Pendo that make this a lot easier if you don't have extensive data team support.

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. 

 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.

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.