James Fang

When I was at Okta, I was part of an extremely effective PMM team. It was structured: * Core / Product-line PMMs * Technical product marketers * Solutions PMMs (own "GTM plays" & business value - e.g. ROI calculator) Core / product-line PMMs were given a broad scope, and in some sense they effectively functioned as "outbound product managers", owning GTM strategy (e.g. should this primarily be positioned as a day1 attach for prospects / new deals vs. upsell to existing customers), pricing and packaging, on top of traditional PMM responsibilities of product launches, messaging & positioning, content, enablement. I also think Salesforce does a tremendous job of selling the vision (given their history of pre-launching products and giving PMM the task of marketing vaporware). And they deliver a phenomenal experience at DreamForce - presentations, keynote demo.

Technical Product Marketers have a variety of career paths. Should they choose to stay in the PMM org, some more organizations offer management roles for Technical Product Marketing teams, which at some point roll up into broader product marketing leadership roles. Some choose to pick up more of the business / GTM strategy skillset and switch over to a "traditional" PMM. Others move into the SE, or professional services organizations. For code literate technical product marketers, dev advocacy is another option.

For companies targeting developers, it's a good habit to build up a culture of developer empathy. Practical exmaples include: * Provide them 101 sessions, enough for them to be dangerous and speak the lingo. What is an API? What is in a JSON payload? What is an SDK - and why does it matter if you support the customer's language or framework vs. your competitor doesn't? What is CI/CD or infrastructure-as-code, and if your product supports Terraform or GitHub Actions, why is that valuable to DevOps teams? * Make your sales people go thorugh (at least once) the introductory hands-on workshop you host for customers. Help them understand the typical developer pain points of: poor documentation, lack of transparency (product is black box / provides no error codes or troubleshooting assistance), lack of extensibility (can't inject custom code / lambdas). * Host internal hackathons and invite your PMMs, SEs and professional service teams to participate, alongside PMs and engineers. * Bring actual developers and let your sales people "ask them anything" to understand their careabouts and pain points.

The answer is you need both, but targeted to the right audience: business value for the economic buyer and technical value for the user / implementer. In some cases, the buyer AND the user are technical personas (e.g. Github). In other cases, the roles are split. For example, for mParticle, the buyer/champion is the Director / Head of Marketing Technology, but the data engineer is the implementer. In this case, the message to the data engineer is: We make your life simpler. We take care of data collection and integration, so you don't have to instrument tracking code every time your marketing team makes a data request or adds a new tool. But it's the business value that drives the purchasing decision. How is this data going to help your marketing teams deliver more personalized messages / build better customer segmentation? In these split scenarios, the technical persona won't be the champion of the deal, but they can sure kill it because of lack of technical functionality / poor developer experience.

This should be aligned with the key responsibilities of the role (see previous answer), but here are some sample KPIs: * Improvement in head-to-head win rate against a key competitor: typically for opportunities that progress to late-stage * Enablement / compentency metric: e.g. Send a survey around what % of the SE team feels confident to conduct a demo, around a newly launched product or major feature. Measure before and after enablement delivered results.

Techncial Product Marketers have a higher degree of industry knowledge and technical expertise. In a team, they are specialized in the areas of: * Competitive intelligence: owning the maintenance of battlecards, and acts as SMEs when going head-to-head in a late-stage opportunity * Technical enablement (SE, Professional Services): may entail building hands-on labs, creating technical content (e.g. reference architectures, demo environment + demo scripts, technical white papers) * Running betas / "dogfooding" product early-on: some companies have PMs run betas, others deploy technical product marketers to build the early onboarding materials / guide early customer deployments Building a PMM team does not dictate that Technical Product Marketers are required. In a lean PMM team, oftentimes the most technical leaning PMMs have regular day-to-day PMM responsibilites (e.g. aligned with a product line), but are also tasked with the areas listed above in a part-time capacity.

Great PMM teams have balance, across the dimensions of positioning & messaging, communication, industry depth, and technical expertise. It's rare to find the "unicorn" PMM that is outstanding accross all 4 dimensions. Most organizations build PMM teams so that they have a mix of expertise in order to get the best coverage accross all dimensions. You want to figure out what your "superpower" is, and continue to hone it. But if technical skills is an area of weakness, it's something that you should not shy away from, but learn to get more confident over time. So you can become more well rounded. The PMM Classification system is a great article written by Kevin Wu: https://medium.com/harmonic-message/the-pmm-classification-system-174539ab1e5c

The most important thing here is to ensure there is consistency and alignment across the entire company on the GTM motion, and the metrics that matter. While a large number of dev-centric companies deploy a bottoms-up PLG type of motion, it is not the exclusive model. Many also deploy top-down motions for enterprise customers, or use some combination of both. For bottoms-up, the north star metric might actually be active customers, and for top-down it's revenue. Your marketing strategy should then follow. For bottoms-up / PLG, prioritize an evangelism function, nurturing an active community, content/SEO, because that will drive more organic traffic, translating to user growth and building up the long tail pipeline. For top-down, there's a larger emphasis on pitch decks, sales enablement, beacuse that will create more short term pipeline. If it's both... then there needs to be alignment between sales and marketing on: where's the line drawn on which customers (typically enterprise) will this motion be deployed against, and given a limited budget, how should resources be split between the top and bottom motion to achieve the metric targets? In terms of the right channel, typically speaking developers don't like to be "marketed to", they like to learn. So instead of a webinar, host a hands-on workshop. Give them access to your product and teach them something, and then reward them for their efforts. Never make them sit through a 30 min slide deck presentation. The tone/voice of the content is important too: in a blog post, resist the urge to oversell your product as they are a skepetical audience. Have a SE or developer within the company proof read it before it goes live.

If technical buyers are critical to the sale, then you have to address their needs. Host accurate technical content. If you're choosing to reserve your primary real estate for your homepage / above-the-fold for your business / non-technical buyer, then create a clear path (discoverable in your nav bar or as soon as they go below the fold) to "click-here if you're a technical persona" such as "Docs", "Developers", or "How are we different?". Some good example of websites that do this are: * https://stripe.com/ * https://www.twilio.com/ For companies targeting developers, having accurate and thorough docs and offering a self-service offering for them to try out the product for themselves is critical.