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

A few answers here, based on use case! Naming inside the product (like features, tabs, or experiences) would be handled by PMM during the launch process. PM is likely to have ideated an internally-referenced name early on, but as we get past the beta and understand what value users actually derive from the feature, PMM adjusts to better match what the user would expect to see, for the task they want to complete. Other copy in the product UI that describes what a function is, or does, in the shortest and sharpest way, is handled by our design team (which sits inside our product org). Copy that might show up under an information icon, or within an onboarding flow which explains the value of the feature, or how to use it to get the most out of your work, is written by PMM. Of course, now that we have a Growth PM, I suspect she'll focus on testing and tuning the language used in any part of an onboarding flow that would have material impact on customer activation.

DATA. But I don't think the word "influence" is quite right. I really don't think PMMs should have an agenda when it comes to roadmapping. I think our role is to represent the needs of users, and bring data to PMs to help them navigate that decision making process. We can provide: * NPS score trends * Customer interview themes * Data on win/loss rates * Insight into competitive investments * Product feature usage by differnet personas * Data on where folks get stuck in using the product * Top questions asked in online forums and in support tickets * Top features requested, and * Information on new or expanding personas that we're seeing in product. Set up a plan with your PMs to deliver updates to some or all of the above on a quarterly basis. Make clear what they can expect from you and when, and you'll be solidifying your place in their workflow.

Ah I'm sorry you're in that situation. PMM should be part of product roadmapping meetings, since everything that's in the queue should be going through some sort of business valuation (what is the cost/benefit of putting this feature into the world). But I think stepping back to understand the motives here might be a good place to start. Maybe there's a company OKR on product differentiation, or a cross-team initiative to reduce competitive losses? Or maybe product<>market fit isn't quite there and the team is experimenting with different use cases for different audiences? If none of those situations apply, then I would say that PMM can play a huge part in shifting roadmap direction. But first, you need to show why you think some features are needed, and others aren't. Have product usage, ARR, or conversion rates gone down in your target audiences since these new features were shipped? If not, you will have a hard time making the case for why shipped features aren't useful to customers. If you do have those data points, implementing an NPS system is a good start. Interviewing detracters, and/or churned users from accounts that were identified as otherwise fitting your ICP (ideal customer profile) can help you elevate the biggest problem areas for product to consider. If you just want to help reset the product team's understanding of your ICP and target users, sharing new research on segmentation, win/loss rates, buyer feature-value rankings, and surveys can help.

oh mylanta I love this question. I think a lot of this can be an interative process with the PMM, but I think the things I see most often left out of these documents that could completely change the way a new feature is positioned includes: - Not just what problem this solves, but how was the problem solved before this feature existed? (Was there a workaround in our product, or did users lean on external solutions?) - Not just who will use the solution, but who, downstream, benefits from its use? - Not just the business value, but the value for an individual that will prompt them to give it a try. - Not just why users would use it, but why they wouldn't. - Not just where the widget appears, but how and when a user should access it. Add some sample workflows that show the user journey from problem to resolution (should include interactions outside the product that prompt a user to go in, how they'll navigate to the feature, where the ah-ha moment is, and what they'll do with that info when they leave the product). - Not just how it works, but what are all the ways it might not? What should the CS or Sales team be prepared to answer? Where are users likely to get stuck, if anywhere?

Any frustrations I have are either a reflection of my ego getting in the way, or a failure on my part to communicate expectations or demonstrate value. Some examples: * Sometimes it's frustrating when sales comes up with their own messaging, and slideware. However, if they're doing that it's because what they have isn't working, or they haven't been properly enabled, or they're not convinced of the results existing content can produce. This can actually GOOD to some extent, because you're getting continuous testing of new messaging. * Sometimes it's frustrating when product doesn't partner closely on new launches. However, if there's a clear launch playbook to follow (that PMM can create), then collaboration becomes a necessity—just a series of accountabilities split across the two groups. * Sometimes it's frustrating when folks at the organization want to start at the message and back into position and product: "This is how I would explain what we do—we should have this tagline!" But, if you have a plan to revisit positioning, and test messaging, the answer just becomes, "let's find out!" instead of "no that's a baseless suggestion."

I think both, though the latter (naming, branding, messaging, etc) seems to be the default for most PMMs. If PMMs want to partake in the beginning of the cycle—what's actually being built, they need to bring new data—not just personal opinions. Product managers have a product vision that aligns with the company mission, incredibly deep market grounding, a keen understanding of what's actually possible given engineering resource, and (hopefully) a clear understanding of product usage. They have strong hypotheses about what to build. So I think PMM's participation would look a little less like, "build this brand new feature!" and a little more like a repeatable set of contextual inputs that the PM team should expect from PMM every year. Like: * Where and why we lose today * The YoY delta of objections that come up most in the sales cycle * The point where everyone gets stuck in onboarding * The markets where we tend to see fastest adoption and the biggest land. * Features that are getting more or less use by certain personas (to influence areas of expansion or iteration) * The advent or growth of new buyer segments. Truly, I don't believe most PMs realize PMMs can help with the above, just through the ICP and sales cycle analysis + customer interviews we're already doing. So PMMs should take it upon themselves to set this expectation, and sign up for the job.

Interests: What kind of questions do you want to answer? This is just my personal take, and probably oversimplified, but if you're driven by optimization questions like "Who is getting the most value out of this?" "How do we better articulate what this thing does?" "How do we increase close rates at the enterprise?" then you're more likely to want to stay in PMM. If you're driven by value creation questions like, "What would make this product really exciting and engaging?" "How do we stay ahead of the competition?" "How do we build world class experiences?" AND you're incredibly comfortable with engineering cycles, you might be a better fit for PM. 

I've always felt like this question felt a bit like, "who owns features, engineering or product?" Both teams are responsible for different points in the lifecycle. In my ideal version of the world, pricing overhauls (a new pricing strategy like moving from seats to usage), is managed by a project management team. It's a lot of chasing folks for research, input, and decisions. PMM should play the role of: * Understanding market comparisons (how complementary and competitive solutions price) * Feature value ranking—to inform what value customers derive from the product in order to inform the levers on which its priced * Packaging—what features are most valuable to whom, and how should they be grouped * Customer interviews—to understand what might cause confusion during pricing roll-out * Themeing/writing the press release (how does this pricing help customers, and help our business achieve our goals) * Sales tools and enablement—calculators and rules for pricing, as well as how to communicate changes PM + FInance should play the role of: * In-product changes that need to occur to facilitate new pricing (especially in a self-serve world) * Setting price point based on business goals, understanding expected delta for customers migrating

Customer segmentation—who cares the MOST, why are they using us, what are their alternatives, why would they stay, why would they leave. Both qualitative (interviews), and quantitative( (product usage and sales cycle data). I think getting incredibly clear on user profiles, habits and motivations is a critical input for every other area of the business. Things like posiitoning and messaging fall out of user understanding, and the very downstream activities many PMMs attach themselves to—things like enablement, demos, content creation, pricing and packaging, etc can all actually be split off from PMM as a business grows. They don't define our core work, they are products of our core work.

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

Oh interesting! I've done both, but I truly believe PLG is the future for everyone. Or, I should say the paths are likely to converge! New organizational structures that are empowering end-users to make more decisions for themselves, coupled with extremely efficient try>buy experiences are reducing sales cycles and making the "executive buyer" persona less relevant (not irrelevant, just less of a blocker than it used to be). As hinted about, none of this means sales GTM motions are going away. Anywhere a problem and solution isn't extremely well understood, a sales person can provide necessary guidance. I just think that process will start to look a little more like sales-assisted growth motions, where we use product analytics to get smarter about where and when to insert humans into the loop. If you're considering stayin in SLG as it exists today, you're likely committing to: - More organization-level ICP research that will help the revenue marketing team better segment outbound initiatives - More sales enablement (pitch practice, decks, competitive matrices, objection handling, and demos) - More enteprise-grade content that can be gated for pipeline building - More focus on executive-level CABs If you're considering the PLG path, you're likely committing to siting a little further "left" into the headspace of end-users rather than navigating several stakeholders and organizational networks. This means: - More end-user interviews and more product usage analysis - More testing and iterating in the onboarding flow to help successfully activate and convert users - (if you don't have DevEx or DevRel that has content quotas) more tutorials and use case guides - More ungated assets like blogs, explainer videos, and solution pages I should also note that I have both a Developer or "Self-Serve" PMM and an Enterprise or "Sales-Assisted" PMM at dbt Labs. Their work often does mirror one another (ICP, segmentation, and persona analysis), but does diverge when it comes to enablement and sales playbooks.

Yes depending on the type of feedback sought we have different owners, but we are trynig to move to a place where the Customer PMM owns tracking of outreach (we don't want to ping the same account 7 times across different deparments). In-product NPS is owned by customer success, but interviews off the back of low or high scores are often handled jointly by CS and PMM. Beta feedback is owned by the product team, but PMM might often tag along for interviews so we can see from a customer's perspective how they would describe the value they receive. Product UX feedback is owned by design (sits in product). Website feedback is owned by Acquisition Marketing. Testimonials and case studies are owned by Customer PMM Value-fit and pricing interviews are owned by PMM