Technical Product Marketing

I don't believe that any technical skills are required in product marketing. However there are a few caveats to that blanket statement. * You should be as technically proficient as your target customer. So if you sell to developers, then you should have enough technical background to speak intelligently to those professionals. This doesn't mean you actually need to be a great developer, just that you understand the needs of great developers. * If your company is highly data-driven and does not have visual reporting software, you may need to know basic SQL or another databas...

I’m a huge proponent of Jobs To Be Done, both for building products and for marketing products – in product marketing, though, you don’t necessarily have to be able to do the job of your audience, but you most definitely have to get it. I often joke that I’m just a good enough programmer to know I shouldn’t be one. What this really means (aside from being a really bad joke) is that I can write about *it* and hold a conversation about *it*, so I can be an effective marketer to those who do *it*. Now *it* has changed for me over the years – I’ve worked on dev tools products, cloud infrastruc...

As a product marketer, you should strive to have the same degree of functional understanding and empathy as a product manager and the same ability to contextualy step through/use the product as any technical pre-sales role (like an SE). This, in my experience, is necessary (but not sufficient) to thrive as a product marketer. Especially when you're new to the role, put the time in to do both formal training, like Sales Engineer (SE) certification, and to use your product (and ideally, competitor products) to do the things/jobs your customers need to do be successful. Once you gain fluency h...

I've been fortunate enough to work with some amazing Technical Product Marketers, and I've found two extremely strong backgrounds are technical pre & post sales (SE, services, etc) and practioner, meaning a role in which their job was to use your or similar products everyday to do their job. Both backgrounds ground a TPMM (or TMM) in credible, hands-on skill and domain expertise which is key to the role. If a PMM's job is storytelling, then (through demos, videos, guided tours), a Technical Product Marketers job is to tell the story through the product. Pre & post-sales folks have had great...

Background: Worked as a Community Manager and Product Marketer for an open source database software company DataStax; we sold a proprietary version of the open source database Apache Cassandra, targeting the developer and administrator personas. Developers are experts at searching for information; they're most likely to make buying moves after doing their own research and product comparisons. By the time a developer is actively engaged with sales, you can almost guarantee that they've made up their mind about what they want. One way to enable your sales team in selling to developers...

Sales enablement changes when your company is "business to developer" to point at a different stage in the funnel: the charismatic, knowledgeable developer who probably already has a solution.   When you are pitching to developers it helps to build a scientific, clearly logical and reasoned case for them to abandon their current solution and adopt yours based on a productivity or efficiency gain, or because you enable them to do something they simply couldn't do before.   Keep it simple, explain yourself in plain english, and err on the side of less bs and more details and developers wi...

Selling to developers can be difficult, often because they have a ton of say over the decision but not explicitly the budget, but marketing to developers is simpler than people think. Quickly and concretely explain what your product does and how it works/fits in with other stacks (as much as developers love to claim that they're immune to marketing/branding - just look at the stickers on their laptops. C'mon - that's brand loyalty/affinity on par with pre-teen pop music fans) then get them into some demo/free trial/"doing the thing with your product" as quickly as possible with resources (d...

I love this question, <3 Developers! The fundamentals of sales enablement dont change, it's more the way you communicate the needs of your audience to your sales team that changes. If we unpack developers and what they want, then it makes it really easy to figure out how to approach sales enablement. 1) Developers will question to the end. They will question every word on every slide and understand it as a direction or intention. So make sure that any presentation or pitch you build for your sales team is fully accurate and defensible. A developer will ask about every permutation of the co...

Great question, something I think about a lot. I’m a huge proponent of specialization with technical products. I wouldn’t expect every member of our enterprise field organization (which is in the thousands) to be able to carry a highly technical conversation from end-to-end, nor would I want them to! But I am responsible for dev and ops-centric products, so it can't be ignored. What I try to do is zoom out of the customer lifecycle, pinpoint who on the team is having the conversation, and what they need to do to get to the next phase effectively – then I craft enablement for that, and that...

When selling to developers your enablement activities are likely to take on a different focus so that the team understands how to engage in a discussion and build a community while keeping their sales pitches locked in a drawer.  It will also require in-depth technical enablement and understanding of technical use cases as well as how to answer questions without trying to sell them something.  The biggest shift might be the mindset, where the sales team needs to focus on what is the best answer to my customer/prospect vs what I want to sell them. It is a very different motion and requ...

I love this question. First, I would say to save your company's BDR/SDRs time and avoid trying to set up calls with developers. You'll avoid a lot of frustration on both ends. Gating content content from developers and forcing them to fill in forms might give you a short term bump in leads, but the quality will be low. Instead, think of the sales funnel as living side by side with the individual developer journey and look for ways to compliment the activities with the key decision makers and their technical practitioner teams. The developer journey can be sliced and diced a few way...

This is a classical problem for many developer-first companies. Without mentioning names, many have successfully figured out the working model with both strong developer engagement alongside a thriving enterprise revenue stream. Learning from these companies, they always focus on the developer success by doing things such as corporate hackathons, architect support, engineering blogs, etc. that helps to build advocacy for their products. It will be hugely beneficial if the sales enablement programs can incorporate a developer-first mindset by acknowledging that developers are the key influen...

B2d follows a whole different motion. A developer is not eager to talk to Sales (and they don't want to be sold to). Developers want to try out the product themselves, tinker with it, and only if they enjoy the experience (or get to the aha moment) will they evangelize the solution up the company's ranks. Developer motion strongly aligns with the product-led-growth (PLG) motion. The trial experience from onboarding to docs, inviting team members, and getting to the aha moments can play a pivotal role in converting them to customers. Growth marketing also plays a significant role because thi...

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

I'd say the mindset shift in B2D is that it's no longer "sales enablement", but just "enablement". And that should be a shared goal across your organization, whether it's the marketing team, sales team, product or support team who are dealing with your developer.  You are correct in saying that developers do not want to be sold to, but they'll still want good support if they need it. That comes in different forms and the good news is that your organization can divide and conquer across this.  1. First of all your docs gotta be like butter. Most developers will try and figure out a ...

Your sales team needs a higher level of technical proficiency when you're a B2D company. It's important to hire sales reps that can form their own mental model of how your product works and integrates with the rest of a customers tech stack for them to be successful. They don't need to know how to code, but they do need to be able to develop a strong functional understanding of the product their selling.  Assuming you've hired sales reps that fit this criteria, enablement should focus on use cases and technical vocabulary. You should train reps on the types of implementation patterns or ...

Great question that's very top of mind! The broader GTM organization will own the growth targets, while the broader Product organization will own the adoption targets. I believe where tech PMM can make the most impact on both sides of the house is with velocity targets. On the GTM side, that's things like sales cycle velocity. On the product side of the house, that's things like onboarding velocity. The content that gets created by tech PMMs should be an accelerator, so the KPIs should match accordingly. 

If by technical value, you mean “what does this thing actually do?” - a lot. Most technical categories are super crowded (and if they’re not crowded, they’re nascent and not well-understood), so being precise on “we’re different in that we solve these problems in these ways” is super important so that those details aren’t left entirely for SE’s in a discovery meeting with a prospect. If you have a highly technical product offering chances are you also have highly technical users/decision makers that you're trying to reach - treat their time and intelligence with respect by getting to the "t...

This is all dependent on the personas you're trying to target. In my opinion, your positioning should not change, but you should have messaging specific to your buyer and/or user personas, or those who will be influencing the purchase in a B2B context. For example, when we're talking about the breadth of offerings we have in Morningstar Direct for financial professionals, we need to ensure that we're addressing the overall business value to those execs who are making the decision to purchase our solutions for their entire enterprise, but we also need to ensure that we have more technical me...

[Insert “Why not both?” meme] :) The best thing you can do is bring these stories together – when technical value solves business value, you have yourself a winner. (I don’t think I’ve ever encountered the inverse of that, now that I think about it) This manifests itself in a number of ways, but you almost always needs an explicitly budgeted project to attach to. Thinking top down – execs who mandate certain initiatives send managers out looking for technical solutions. When a practitioner tries a product out and gives it the thumbs up, that works its way up the chain. Thinking bottom up ...

If you get to know who you're talking to, it's a lot easier to know what to say. That's a core tenet of messaging and being a good conversationalist in general. Your first step with a question like this is to establish buyer personas. Who's involved in the buying committee? Are they the key decision maker or an influencer? What do they need to know? If you don't know, start by doing win/loss in partnership with your revenue teams. Try to get a handle on who was involved in recent purchase decisions, what their process looked like behind the scenes, what motivated their decision, and where ...

Salesforce is my #1 in B2B. just overall content is amazing. very customer oriented

Intercom does a great job

+1 for Intercom. Also Buffer and Autopilot. All focus on training their target customer to be better in their job.

I also love Intercom. I took their Jobs to Be Done methodology and made a value prop project out of it! https://www.intercom.com/books/jobs-to-be-done I also think stripe has a great website for their products and reference it frequently: https://stripe.com/ Segment has pleasantly come a long way - they have a clear explanation of who their product is for, use cases, etc: https://segment.com/

Apple is the gold standard in my book. They have a strong point of view and aesthetic, and every product has a story, launch, and campaign behind it. Square has emulated this model as well, and their website shines as a result.   In the SaaS category, Zendesk and Mailchimp are some of my favorite inspirations, and of course Salesforce. Zendesk has been very successful at leading a broader category of cloud customer service, and the product pages on their website are always smart and relevant. Mailchimp's voice and tone are so unique and appropriate to its brand, and carry through in every...

May be I am baised, but in the large Global 500 space, infrastructure -- I would say my experience at Cisco was the best. For me thats kind of the benchmark now - both in terms of strategy and execution cadence that I learnt. From products to solution to positioning platforms, working with ecosystem partners, ISVs, Channels. Website alone to me is not a good indication, yes, today it is, but the real value is in business that is driven and impact product marketing is having in driving that.  In the Saas space, I would agree Salesforce is probably the benchmark.  It is easier when you ...

Spotify comes to mind with product marketing I really admire.  The particular element of their product marketing I most admire is their ability to elevate listening to music and podcasts on the go, to a data-rich, "teach me something about myself" package at the end of each year.  Dating back a few years, Spotify will summarize the time you spent listening to music and podcasts, your top artists, your top songs, your top genres, your top podcasts and other data points in a fun UI that is very socially driven.  Toward the end of 2019, I saw lots and lots of social posts from people ...

The early work Twilio did to quickly convey what the service did and who it's for then get developers to dig into the product and have an a-ha moment with a couple of lines of code was pretty great. All of it tic and tied back to the brand and voice of the company, which had a sort of open source community vibe despite being a commercial entity. 

I’m not allowed to say Stripe. Everyone says Stripe. So I’ll say…. Stripe? I kid, I kid. I’ll always have a soft spot for Heroku – they’ve always stood out to me as a company with a unique brand presence that never compromised on technical value and authenticity. Some of the Product Marketers I looked up to most when first getting into the dev tools/cloud infra space came from Heroku. A newer company I’ve had my eye on that I think is doing a fantastic job in this regard is WorkOS. Simple and clean – very direct to the job-to-be-done. But beyond that, they’ve hit a strong narrative that c...

Yes! Here are a few examples, mostly B2B SaaS. Asana: I love how they take, what is a horizontal app, and position it to address specific use cases by function & persona. Whether the target user is in Sales, Product, Operations, HR or some other function, the PMM team at Asana know your top use cases and help you understand how Asana can help. Notion: Also do a great job positioning a horizontal product but the highlight for me is the core content & messaging. Its so human and straightforward, no jargon or fluff. The tone of voice is also friendly and approachable. Webflow: I love ...

I have a fairly extensive persona methodology which I wrote about here (https://www.workinproduct.com/blog/elements-of-a-positioning-system-part-2-customer-personas). Rather than get prescriptive with an explicit example here, I’ll share something I run i nto a lot that I think gets it wrong – bucketing CTOs/CIOs into the same “Technology Executive” persona. There may be some overlap, and it’s tempting to consolidate profiles, but in any modern organization, these jobs are vastly different, and should be treated as such. Both are responsible for making company-wide technology decisions, ...

Developer personas are diverse! You could rename them "technical practitioners" to better describe this group of humans. High level, in the business world, they are the folks who put fingers on the keyboards, not the folks who write checks. The operators. Because of this, there are personas that will work for some products, and not others. Some of the ways developers can be grouped is by job title: 1. Software developer 2. Software engineer 3. Mobile developer 4. App developer 5. Web developer 6. Data scientist 7. Data engineer 8. Machine learnist 9. Network engineer ...

Good question – it can depend on a few things. In many companies, you’ll have to wear both hats... I know I sure have.  As Product Marketing teams grow, where it starts to break out into dedicated roles is at the target persona level – your more traditional PMM may focus more on the executive personas/solution marketing/business value route, while your more technical PMM may focus more on the practitioner personas/example use cases/how to guides route. If you're trying to figure out your own path here, one could either look to double down on one area or improve in others to gain broad...

Great question, I get in arguments about this all the time! Heh. You ask the question the right way - it’s about balance. Starting with my least favorite topic – SEO! The benefits of SEO isn’t lost on me, but for technical products, authenticity trumps all IMHO. I always cringe when I come across a bland, “what is [tech topic]?” blog post. I would much rather land on a “how to do [tech thing]?” blog post. But the best lesson I ever got in marketing was, “if you don’t cringe just a little, you’re not doing it right.” For those two examples specifically, the “what is” posts should be target...

I don't have a recommendation on the group, but a good next step if you don't get an answer here would be networking with a couple of PMMs at companies that sell to/engage with developers to get their perspective. Folks at Atlassian or Github, for example, could probably give you some really great insights.

One suggestion would be to see if you have any talented sales engineers that may want to make the move. These individuals have spent a lot of time speaking with customers, understanding their technical needs and frustrations.  It is not always the case that you will find an ideal candidate there, or want to "poach" someone from that group, but just something to keep an eye on as they already know your company and customers well. 

I should have a better answer to this than Twitter, but I haven’t actually hired for that role in a long time, so might be out of touch, sorry! One thing I’ll say, and this might be a bit controversial, but I’m personally cautious of high-profile developer evangelists. There is absolutely a ton of value in building a public profile, and the role lends itself to community, but a strong advocate is someone who spends more of their time talking with customers, less time talking with other evangelists. The best ones I’ve seen balance this very well, all grounded in being helpful – engage with ...