The complete developer marketing guide: selected excerpts from Picks and Shovels

These are selected excerpts from Picks and Shovels. I arranged them in the order a developer marketing program actually runs: what the job is, then positioning, content, DevRel, events, go-to-market, sales, ads, AI, measurement, and the team.

Get your copy of Picks & Shovels: Marketing to Developers During the AI Gold Rush today.

What developer marketing is

From chapter 0, "How Can I Help?"

The primary goals of developer marketing are to drive awareness of developer-focused products among developers, convince developers to adopt your product, and nurture developers so they feel comfortable using your product, providing helpful feedback, and doing business with you. That shouldn't be too controversial, as it's the same marketing challenge with any product: awareness to adoption to conversion.

But developers are different.

Developers want truth and integrity. They don't want marketing puffery and will turn away from companies that engage in sales and marketing pitches and bombastic claims. They want to know if a product will really work for them, and they are more than willing to use a product themselves and evaluate it without any help from outsiders. Only after a successful self-guided evaluation will they consider working with sales or, as is increasingly common, purchasing on their own.

However, developers are different in another way: They are willing to try new tools quickly. The consideration cycle for developer products is much shorter than for traditional IT products. Developers love shiny objects, and while they will insist on evaluating a product on their own, they are very amenable to the prospect of finding new picks and shovels.

All of this gets to my fundamental philosophy for working with developers:

Help First.

In everything you do, seek to teach and be helpful. In the act of doing so, you also set broader context. If your company becomes known for just one thing, be known for being helpful. Being helpful confers a brand promise of "trust" that you simply cannot buy through ads or event sponsorships.

• When you write a feature-launch blog post, think about the broader context and the problem you're trying to solve. Teach developers about the history of that problem, the many attempted solutions over time, the kind of solution necessary to solve the problem, and the myriad benefits of solving it. And then talk about how you solved it.

• When you speak at a conference, don't do a product pitch session. Pick a problem that your product solves and dive deep into it. Or pick a problem that you solved in the act of building your product, and talk about how your engineering team overcame it.

• When you attend a meetup, ask the event organizer if there's anything they need. Don't assume it's pizza or a box of T-shirts. It may well be! But start by asking how you can help.

From chapter 1, "Getting Started"

Every successful company or organization has three core elements dialed in:

1. a deep understanding of the market and customer and a specific problem that they have a burning need to solve
2. a product strategy that solves this problem in a unique, differentiated way
3. a go-to-market motion that, in a repeatable and scalable way, identifies potential customers and convinces them to try your product

Fundamentally, marketing and developer relations exist to serve the go-to-market motion and ensure that the entire organization understands the market, customer, and problems being solved. With some notable exceptions around synthesizing and delivering product feedback, our job is to make it easier for the company to sell its products and services.

Developer marketing layers knowledge of the developer persona atop traditional B2B SaaS go-to-market strategies, sharpening our approach to reaching the market and customer with greater candor, focusing our product strategy on features that solve complex problems, and building a go-to-market motion that simultaneously reaches the technical user and economic buyer. It's difficult to take a traditional marketer and throw them at a technical product. It's less difficult, but still hard, to take a technical user (or founder) and ask them to run go-to-market functions.

Positioning, messaging, and ICP

From chapter 13, "Segmentation, Positioning, and Messaging"

Without proper positioning, your product and company are lost in a wilderness of look-alikes. Positioning puts your product or service in a particular place that is unique, differentiated, and winning. It distinguishes you from the competition and makes it clear why a well-articulated segment of customers should consider it.

Fundamentally what we are trying to do is connect the product that we're building to an audience or segment. It's all connected. Think of it this way:

• Product: What we are building and want to bring to market.
• Positioning: The place within the broader market that the product occupies, and how that place differs.
• Messaging: How we talk about the product.
• Messenger: The company, brand, or person that is going to carry the messaging to the audience.
• Audience: The customer or segment we intend to target with the product.

Most of the time when products fail, it's because there's a disconnect somewhere in that chain. To put it in Amazon parlance, we start with the customer and work backwards.

Segmentation is the foundation of marketing. Developers are a diverse group with varying needs, technical skills, and goals. Taking a one-size-fits-all approach will lead to boring, ineffective marketing tactics. Instead, start by homing in on the type of developer that will need your product.

Take, for example, these three ostensibly similar open-source PostgreSQL-based databases. Each focuses on a different segment of the developer population, with a different type of problem and lens on the technology choice.

Company	Who are the targets?	What is their problem?
Timescale	Senior developers in medium-to-large businesses with substantial existing investments in PostgreSQL	They've made substantial existing investments in PostgreSQL and need to get more out of them.
Neon	Startups, SMBs, and individual developers who are building new applications and want a low-cost, high-efficiency database	They are building microservices or multitier applications, and they need a database to go with it.
Supabase	Front-end and full-stack developers in startups and SMBs looking to rapidly build new applications and prototypes	They need to build an application, and time to market is more important than obsessing over each architectural choice.

For a time, there was a push to create human-relatable personas to encapsulate segmentation. The idea was that everyone on the team would develop empathy for a fictitious representation of their customer.

The problem is that personas are too imprecise and subject to misinterpretation. You can't take a description of a developer and reliably reverse-engineer it into, for example, a set of high-performing keywords. There's a huge difference between these two descriptions:

• Persona: "A seasoned developer who prefers highly technical documentation when building React applications."
• Segmentation: "Developers with over 5 years of experience in React, located in North America, and working at a company with between 25 and 100 people."

Segmentation is only the first step. Ultimately, you want a good handle on your product's ideal customer profile (ICP). Starting with segmentation is a rigorous and more scalable way to arrive at your ICP.

The ideal customer profile (ICP) is a detailed description of the type of company or individual that represents the perfect fit for your product. It goes beyond basic demographics or job titles, focusing instead on specific traits that indicate a strong likelihood of successful engagement, adoption, and retention.

The ICP is laser focused. It's a profile of the customer that will not only derive significant value from your product but also contribute to the product's growth through retention, advocacy, and expansion. The ICP gives your entire go-to-market team the alignment necessary to prioritize work.

Put simply, your ICP is a more specific analysis of your most effective segment.

One helpful strategy I use is to make sure that I can "find" my ICP using LinkedIn Sales Navigator. If my ICP includes as part of its definition traits that are not easily searchable and filterable in common sales-intelligence tools, it becomes very difficult to actually use.

Positioning is a strategic exercise, a foundation that defines how the product fits into the market or market segment. It isn't a tagline or a slogan; it's what is unique about your product and describes the place in which your product lives in the market.

Positioning involves answering specific questions: What category does the product belong in? What makes it different from existing solutions? And why should a developer, engineer, or decision maker choose it over another? The key here is clarity. Positioning must clearly and unequivocally explain the product's specific advantage for a given audience and use case.

Each of them ostensibly offers the same thing (albeit packaged differently): full Postgres in the cloud. But each occupies a different place (position) on the spectrum of developers.

• Supabase: open-source Firebase alternative built on Postgres
• Neon: Serverless Postgres for cost-effective, efficient deployments
• Timescale: Postgres made powerful for high-end workloads

Here are some other ideas from companies you may know well:

• Stripe: payments infrastructure for the internet
• Twilio: the communications layer for every product
• Docker: build, share, and run any app, anywhere
• Vercel: develop, preview, and ship web applications

Somewhere around the middle of the 300s BCE, the Greek philosopher Aristotle devised a rhetorical framework that shapes (among many things) marketing messaging to this day. He posited that the best, most effective persuasive messaging contained three elements:

• ethos, an appeal to credibility and authority
• pathos, an emotional connection
• logos, logic and reasoning

With developer marketing, we take Miller's work and suffuse it with Aristotle's rhetorical framework, and our positioning frameworks often look like this:

Positioning statement

• An emotional point about why you will love this product
• A logical point about what unique capabilities this product has for you
• A credible point that explains why you can depend on this product

This is the positioning framework I created as the first director of marketing for Amazon Web Services:

Amazon Web Services gives you a cost-effective and dependable cloud computing platform that makes it easy to provision infrastructure so you can build anything quickly.

• Flexible: easy to use and get started
• Cost-effective: no contracts, pay as you go, transparent pricing
• Dependable: scalability and reliability from the company who knows how to run infrastructure at web scale

In my experience, most developer-focused products evolve their positioning into some form of the following:

Positioning that identifies the uniqueness of a product in a market

• A supporting point about productivity improvements or ease of use (appeal to emotion)
• A supporting point that dives into what's unique about the product and what that enables (appeal to logic)
• A supporting point about dependability or scalability, or both (appeal to credibility)

When I went through my Greek philosopher phase in my early thirties, I was shocked and humbled to learn that Aristotle was a far better product marketing manager than I was.

Messaging is not the same as positioning. Indeed, messaging translates positioning into the words, visuals, and examples that make that positioning compelling. Messaging takes the strategic foundation of positioning and builds the story around it.

• Supabase: Build in a weekend. Scale to millions. Supabase is an open-source Firebase alternative. Start your project with a Postgres database, Authentication, instant APIs, Edge Functions, Realtime subscriptions, Storage, and Vector embeddings.
• Neon: Ship faster with Postgres. The database you love, on a serverless platform designed to help you build reliable and scalable applications faster.
• Timescale: Over 3 million Timescale databases power IoT, sensors, AI, dev tools, crypto, and finance apps, all on Postgres. We use Postgres for everything; now you can too.
• Stripe: Financial infrastructure to grow your revenue. Join the millions of companies of all sizes that use Stripe to accept payments online and in person, embed financial services, power custom revenue models, and build a more profitable business.

Content

From chapter 5, "Building Great Developer Content"

Content marketing works.

It's the best bang for your buck in terms of developer marketing. If you build a reputation for producing excellent technical content for developers, you will largely solve your brand, awareness, and growth woes. People will seek out your opinion because you are technically deep, humble in how you teach, and prolific in understanding and addressing developer needs in real time.

Developers arrive at your website in various stages of readiness to consider your product. Traditionally, we have referred to this as upper, middle, and lower funnel, and each stage requires different content to push the prospect further along the path to adoption:

• Upper funnel: These developers are conducting broad research, often without a specific problem or solution in mind. They might stumble across your content through a blog post shared on Hacker News, a tweet, or a recommendation in a community forum. They are generally looking to broaden their knowledge. They have a low propensity for converting into users, though they may sign up and file you away for later.

• Middle funnel: These developers have a specific problem and are researching solutions. They can be influenced by targeted content that defines the problem and explores solutions, including the history of solutions that may have partially addressed the problem in the past.

• Bottom funnel: These developers are ready to make a purchase decision and are actively evaluating products.

While this remains a good framework for content development and seems logical, the modern developer consideration framework is less a funnel and more a series of seemingly random steps toward building closer affinity to your brand. A customer may start by seeing a mention of you on Hacker News, then coming to your website, then visiting a subreddit where you are mentioned several weeks later, then finally coming up with a project idea for which your product could be valuable, and eventually signing up.

The truth is, if you decide as an organization to put your energy behind and commit fully to any one of these types of content, you will probably find at least some modicum of success.

The best advice I can give is to measure everything and use the data to recognize when it's time to cycle off of one form of content and onto another. What got you here may not be what gets you to the next stage. You'll know it's time to move on when the performance velocity (e.g., leads, web traffic, click-throughs) starts to level off for two to three consecutive months. Holding on too long is often a mortal sin. Whereas, if you abandon a tactic too early, you can always come back to it with a fresh perspective and pick up where you left off. So when it comes down to it, skew toward embracing new perspectives and approaches. As I like to say, value innovation over tradition.

Here are the types of developer content that I like to produce:

1. blog posts
2. benchmarks and side-by-side comparisons
3. tutorials and how-to content
4. microsites
5. calculators, templates, and other lead-generation tools
6. programmatic SEO
7. video
8. infographics and interactive content
9. checklists and listicles
10. case studies, case study videos, and customer interviews
11. white papers
12. ebooks
13. courses
14. webinars
15. podcasts and streaming shows
16. swag

You'll have the opportunity to create two kinds of content. The first is what I call inside out. Inside-out content is about you and your products. This content is of interest to a very narrow portion of the population, effectively, the folks who are already in your camp. Inside-out content includes launch posts, changelogs, video tutorials, documentation, and other material related to your product.

Outside-in content takes matters of great interest to developers in your target market and provides historical context, summarization of the problem, discussion of solutions and alternatives, and ultimately information about what products or services you provide to address the matter.

Outside-in content will (hopefully) drive leads, while inside-out content will drive conversion and customer satisfaction. They're both great, but for content marketing I'm mainly going to focus on outside-in content.

Documentation

From chapter 11, "Developer Documentation"

Throughout my career, I've held a hypothesis that your developer documentation is your greatest and most effective sign-up vector. In my experience in evaluating developers and analyzing how they use websites, I've noticed that they will spend an inordinate amount of time on your landing page (if they came from an ad or somewhere else); your homepage; perhaps your products page (but not always); your pricing page; and finally, your documentation. Your documentation is typically the last place a developer goes before they elect to sign up.

The first advice I have to give you is to get your documentation right. Don't expect your developers (internal or external) to write it and for it all to be good. Invest in a quality documentation platform; a dedicated web developer for docs (at least in the initial stages); and an excellent technical writer (or several, if you can afford it).

I think of documentation as fitting into four categories:

• Learning: getting-started guides, concepts related to the product, and features and explanations
• Tutorials: tutorials and how-to guides for completing common tasks or solving common problems related to your product
• Reference: API documentation, schema definition, configuration settings
• Troubleshooting: FAQs, knowledge base, common errors

The first thing is to never mistake documentation for marketing content. What I mean is that documentation should never be full of marketing language or bombastic claims. By now you already know that all our marketing content as it relates to developers should be free of florid marketing language or bombastic claims, but this particularly needs to be the case for developer documentation.

The inverse is also true. You should never be so precious about your documentation that it doesn't have calls to action or upsell information. If you have both an open-source and a cloud product, for example, the documentation for your open-source product should absolutely include a callout or message that the cloud product is available and has certain advantages.

The biggest thing to remember when you're using documentation to further your marketing efforts is that it should do the heavy lifting of your most complex marketing challenge: enabling developers to imagine life with your product as an indispensable part of their daily workflow.

Developer relations

From chapter 4, "Developer Advocacy"

Developer advocacy (once referred to as developer evangelists, and these days sometimes referred to as DevRel) is the tip of the spear in terms of customer engagement. A developer advocate's mission is to show developers a vision of their world with your product in it. To do so, they should identify problems in our industry and provide solutions, assuring customers that using your product will help them work better, faster, and more efficiently.

Developer advocates are responsible for teaching people the myriad possibilities that come from using your product or service. Ideally they have a showman's mind; they can take dull technical products and turn them into magical wonderlands. They can write prose and write code. And they love to shmooze, online and IRL.

I organize developer advocacy around four specific areas. That's not to say that any individual does or does not do all four. Commonly, some developer advocates specialize in one or two areas over others. That's OK, and it helps you build a well-rounded team.

1. capture and represent product feedback
2. build credible and authentic content that offers value to technical audiences
3. connect and build relationships with community leaders
4. attend and speak at events

The core definition of developer advocacy mandates that we spend time with prospective communities or customers to get them excited to try (and adopt) a product, and really good developer advocates have a strong idea of how well those prospective customers receive the product. Great developer advocates are expert observers and connectors: they earn the trust of engineering teams by crisply summarizing customer feedback, explicit and implicit, and then use their solid reputation and credible technical arguments to drive action within their organization.

Some developer advocacy teams are also responsible for product documentation, which is advisable, particularly at early-stage companies. Your docs should represent the spine of your growth strategy. You may have the most beautiful website, but developers will quickly scan the homepage and search for "docs" or "developers" in the top-nav. To the chagrin of many traditional marketers, they'll bypass white papers and opportunities to sign up for a webinar and head straight to your docs.

Great content is a reflection of your personal brand. You can do all the SEO and organic-discovery tricks in the book. But the difference between consistently good and consistently effective content is how often people seek out your opinions and authority.

Thus, while all developer advocates build good content, great developer advocates build their reputation, and through their reputation, their content becomes sought-after.

You have to earn your way into a community. The way I've always done this is to join one and lurk for a while, learning the culture and common questions. I'll then author content to answer the most common questions. In those content pieces, I take the time to research the background behind the question. Why has a particular issue persisted, version over version, for a product? Often there's a good reason, with reasonable trade-offs. Providing that background is important. Later, when an opportunity organically arises, I'll jump in and answer questions, providing links to resources that provide more background on the answer.

Be authentic friends to your community.

You should never ever do fly-by-night activities or marketing tactics with these folks: Don't ask them to tweet something for you, don't ask them for a quote in your press release, don't ask them to endorse your product in exchange for a fee. These shortsighted approaches are inauthentic and will do far more damage than good.

Events tend to be the most glamorous part of the job, and I always intentionally put it last.

Events

From chapter 8, "Developer Events"

Events are the final component in the developer advocacy mix. They are certainly the most time-consuming and the most expensive. The first question to ask yourself is whether events are even worth it as part of your marketing mix. Because of the costs involved, you should make the investment intentionally.

That said, there are many types of events you can participate in:

• third-party events (hosted by others)
• first-party conferences (hosted by you)
• first-party road tours
• first-party sales and customer breakfasts or dinners
• business roundtable events
• virtual events

To answer whether events are a worthwhile investment, you need to clarify your objectives. What are you trying to get out of events? Typically we elect to do them for one or more of the following reasons:

• to generate leads
• to build brand awareness
• to strengthen community relationships
• to engage with existing customers
• to launch or promote new features or products

The reason could differ from event to event. For example, you may elect to sponsor a small regional roundtable because you want to strengthen community relationships with the organizer. You may want to attend a major conference and invest in a large booth in a premium location to build brand awareness. And you may want to attend a sales event with many buyers in attendance in order to generate leads.

Your goals will help you determine metrics for measuring the efficacy of the event, and you can use that information to decide whether to attend similar ones or the same one next year. But always start with evaluating your goals up front for each event.

Typically, the ways you can participate in an event fall into three non-mutually exclusive buckets:

• sponsoring it in some manner
• submitting a talk proposal
• attending and networking

It is possible to sponsor the event but not attend. I've done this for a few very small events for a small amount of money in order to support an influencer or community of interest. But most of the time, if you sponsor, you will attend. And many times if you sponsor, you will get a free sponsored talk as part of the deal, and you should negotiate for this every time!

Go-to-market

From chapter 19, "Overview of Acquisition Models and GTM Strategy"

Products aimed at developers can employ a variety of go-to-market models. Often companies use more than one of these approaches to build a complete customer journey.

• product-led growth (PLG), bottom-up user acquisition
• sales-led growth (SLG), top-down user acquisition
• combination of PLG and SLG
• open-source, community-led acquisition

The idea behind product-led growth (PLG) is that some substantial cohort of customers will want to try your product on their terms before deciding whether to pay for it. The hallmark of PLG is low customer-acquisition costs (CAC) and almost no burden on the sales team to try and close the deal.

At the core of PLG is the idea that a user's journey can be initiated, nurtured, and monetized with automated digital systems and minimal sales involvement. In a typical PLG funnel, users go through four primary stages:

• Awareness: They discover the product through organic channels, SEO, content, events, or ads.
• Conversion: They sign up for a free or trial version, with the aim of experiencing the product firsthand.
• Activation: They reach an aha moment in the product, seeing value that hooks them into further use.
• Payment: After seeing consistent value, they decide to pay, often via a self-service process like entering credit card details.

The first fallacy of PLG is that it is a technique restricted to the marketing team. In fact, for PLG to be successful at all, it needs to be a joint production between marketing, product, customer success, and sales. And beyond simply assembling a cross-organizational team, there needs to be a team leader who is empowered by someone in a position of power to make decisions, allocate resources, and change the product itself to run experiments that drive performance through the PLG funnel.

Thus, the first and most consequential challenge to executing PLG is organizational buy-in and alignment.

From chapter 20, "Product-Led Growth"

Dogmatic thinking has no place in business, which is, above all, pragmatic. Our job is to find customers, get them to pay us for our products, and grow our business. PLG is in vogue for a multitude of reasons. The cost of acquisition is fairly low, it's seemingly easier to find and qualify potential enterprise customers, and it puts the product at the center of the go-to-market motion. For technical founders, PLG is the "if you build it, they will come" strategy, where product decisions affect business outcomes most directly.

But PLG isn't for everyone or every product. I do believe that aspiring to a PLG experience is good for every product. After all, making it easy for people to get started and onboarded is a universally positive outcome of product design. But some markets and industries are better suited for PLG than others.

Let's take a look at two seemingly similar databases with radically different positioning:

• Database 1: A PostgreSQL-based backend-as-a-service that enables developers of all skill levels to build their application in less than a weekend. (This is the Supabase model.)
• Database 2: A PostgreSQL-based database-as-a-service that enables developers with massive amounts of data to query and use that data most efficiently. (This is the Timescale model.)

Here we have two Postgres-based databases, but they're targeting very different audiences. The audience for Database 1 is any web or app developer who wants an alternative to Firebase. This audience is large. It encompasses hobbyist developers building personal apps, entrepreneurs building small businesses, medium-sized businesses scaling and rewriting their applications to meet new demand, and even enterprise businesses building departmental applications.

The audience for Database 2 is existing developers with massive amounts of data. You cannot get value out of Database 2 without first ingesting all your data, indexing it, and building new applications to extract value out of it. You may want to undergo this process by yourself, and there are certainly a few developers who will. But most developers of this type are enterprise in nature. They won't just want to prototype; they'll want assurances from the company that their database is rock-solid and the company itself has the legs to stay around.

PLG makes an inordinate amount of sense for Database 1, which can build a very large, diverse, and resilient community because of the size of its market. For Database 2, PLG is a good aspirational goal for the product. After all, databases should be easy to get started with and easy to use. But the number of customers who will get value out of a database best suited for massive quantities of data is smaller. The average deal size for these customers will be much higher. And the process for evaluating the product will be much more involved, including teams from operations, security, legal, and more.

Two databases, two approaches, two different roads to the promised land.

From chapter 21, "Sales-Led Growth"

Sales-led growth (SLG) is a go-to-market strategy where the primary driver of customer acquisition, expansion, and retention is a dedicated sales team. Unlike product-led growth (PLG), which relies on the product itself to convert users into paying customers, SLG focuses on human interaction to guide prospects through the buyer's journey. This approach is often necessary for complex or high-priced products or services where personalized conversations and touchpoints can speed or impact the decision-making process.

Here are some of the hallmarks of an effective SLG motion:

• High touch: Prospects work closely with account executives (AEs) who take the time to understand their problem and tailor the messaging of the product or service to match the customer's definition of what they need.
• Longer sales cycles: The more niche and specific your product, and perhaps the closer it is to the infrastructure or security concerns of a company, the longer it will take to get all the necessary approvals not just to buy the product, but to begin a proof of concept.
• Customized: Typically the product or service you offer on your website must be modified for an enterprise customer.

In all these circumstances, the relationship you build between your company and the customer, specifically the technical and nontechnical champions within the customer's organization, will help you overcome the hurdles necessary to win the deal. In this regard, SLG is fundamentally a game about relationships. Our job in marketing and developer relations is to support the process of beginning and nurturing those relationships.

Sales enablement

From chapter 17, "Aligning Developer Marketing with Sales"

Collaboration between sales and marketing is critical in any B2B context, but especially so when it comes to developer products. Developers are a particular audience, and any tone that reeks of marketing or sales will turn them off and hurt your brand.

As I've outlined throughout this book, marketing is focused on a Help First mentality, which builds trust and confidence among the target audience. But the target audience doesn't make a distinction between a marketing manager, sales executive, or engineer. If they see that you work for a company and they are turned off by your tone, they'll immediately flip the bozo bit on the company, and it is very hard to recover.

Thus it is imperative that marketing and sales work together to establish the right tone, stay on message, employ the positioning framework effectively, and coordinate their efforts.

Sales enablement equips sales teams with the training, resources, tools, and strategies to effectively engage with potential customers and close deals. Remember, developers value authenticity and technical expertise above all, and they dislike overt sales tactics.

Moreover, developers at all levels in an organization can influence purchasing decisions. So sales teams need to be trained on how to engage with developers at all levels. Focusing on economic buyers or decision makers at the expense of individual contributors often results in stalled proofs of concepts and closed-lost deals.

But remember, sales enablement is a two-way street. Salespeople engage with customers at the ground level, face-to-face. They will have firsthand knowledge of whether your messaging will work. Listen to them. If an experienced salesperson can't land your messaging without significant alterations, you need to go back to the drawing board.

Over the years, I've had a singular hypothesis about how developers buy products, and recently I confirmed it through data. By accumulating and analyzing IP addresses of visitors to my website, I was able to prove the following buyer journey:

• Awareness: A developer will discover your product through organic channels like blogs, forums, GitHub, events/meetups, community engagement, and social media.
• Consideration: It is very common for developers to be intrigued by your organic presence, visit your website, view your product page, view your pricing page, perhaps even view your docs, and maybe even sign up with a personal email address. But in this phase, they are not yet ready to buy. They have merely filed you away after understanding the use cases you address, and once they have an appropriate use case, they will return.
• Reconsideration: Perhaps the developer now has your use case, or perhaps they now work at a different organization. Regardless, they will come back at some point, and this time they may use their work email to sign up.

Let's play the long game with this data. We know that when someone comes back after having been on your site before, and perhaps even signed up, they are more serious and more likely to engage and use your product. They are now seeking you out.

Account-based marketing

From chapter 21, "Sales-Led Growth"

Account-based marketing (ABM) is one of the most effective tactics for generating high-value pipeline in developer-focused organizations. Instead of targeting developers en masse, ABM aligns marketing and sales efforts on a carefully curated list of target accounts. This approach allows you to focus your resources and create tailored campaigns that resonate deeply with your ideal customers.

ABM is especially relevant for developer products because their audiences are often niche and have specific needs that differ from the general population's. You are a great candidate for ABM if your product or service caters to specialized developer groups, such as data engineers at scale-ups or backend developers in fintech.

I happen to believe that all developer audiences are great targets for an ABM strategy, but they are particularly useful the more specialized your ICP is.

In contrast with traditional marketing approaches, ABM campaigns are much better researched, more focused, and have more potential for being cost-efficient. The flip side is that they are very time-consuming. You can't just decide you want to do ABM and be on your way tomorrow. It often takes weeks of preparation.

To start, you will work with your sales team (AEs and sales leadership, in particular) to build a list of target accounts. From there, you can work together to expand the list using ChatGPT: "Help me find a list of customers that resemble these, including industry type, company size, size of engineering team, and geographic location of headquarters."

You may want to further segment your ABM account list into tiers representing how much and how deeply you will research to support the outbound motion for each company:

• High Priority (Tier 1): custom pitch decks, account-specific landing pages, and workshops
• Mid Priority (Tier 2): industry-specific case studies, webinars, and semipersonalized outreach
• Low Priority (Tier 3): scalable tactics like newsletters and automated drip campaigns

Before implementing a full-scale ABM strategy, start small and build up the internal muscle as you go:

• Identify a customer that was successfully nurtured by your sales team into a closed-won deal. The best customers for ABM are "switchers," or companies that chose your product after previously selecting a competitor's.
• From there, build a list of 100 to 200 companies similar to that customer in terms of geography, size, and industry.

Effective ABM is a team sport. You and your sales team, indeed your entire sales team and your entire marketing team, need to be perfectly aligned every step of the way.

Ads

From chapter 9, "Building Awareness Through Marketing"

Developers are traditionally skeptical of advertising. Being the most technically savvy of all consumers, developers will often turn on ad blockers, either in the browser or at the router level. They are more likely to adopt a privacy-centric approach to their daily lives on the internet. And they are more likely to be turned off by overly pushy sales and marketing tactics.

So when adopting a paid-acquisition strategy with developers, you need to be intentional with your approach, with clear goals and an eye toward continual optimization and improvement.

The glib answer to "do developers click on ads?" is this: if your ads are good, on topic, and add clear value, yes, they will click on your ad. But of course there's more to it than that, and it all comes back to my central thesis of this book: Help First.

Your ads can't be overly polished or presumptuous. Instead focus on the problem, and attract developers to it. If they agree that they share the problem being described in the ad, then they will click through to the landing page, where you can talk more about the problem and how you solve it.

Before you invest in paid acquisition, define what success looks like for you. Are you aiming to drive sign-ups for a free trial? Build awareness of your product in a crowded market? Increase traffic to a specific piece of content or landing page?

There are myriad reasons why you would want to run paid advertising, and you need to be crystal clear about your goal. Mixing goals, or having two goals, or not being sure of your goals, all of these are recipes for overspending and being dissatisfied with the results.

Paid ads can take many forms:

• Google AdWords (bidding on keywords)
• LinkedIn, Facebook, or other display ads
• video ads on any of the main social networks

I'm not sure you'd ever need to run advertising for a broad-reach product that is steadily growing its following in a broad market. But you may well need advertising to reach developers in a niche market who have much fewer communities and newsletters feeding them information.

How AI changed the job

From chapter 25, "AI and Marketing"

It's difficult to be a nontechnical person working in a technical industry. I've always held firm that in order to market developer-focused products, you need to have at least a modicum of background as a developer. I started my career as a software engineer and nearly (not quite!) received a degree in computer science. Not only is the organization and algorithmic thinking of software development useful in building and running marketing programs, but the ability to write code has become essential in an AI-driven world.

In the last week, as I've been writing this chapter, I've had to...

• build an ETL script in Python to move data from one system, normalize and transform it, and put it in another system.
• modify a website so that it rendered data stored in Airtable.
• build a landing page for a campaign.
• write a script to turn links in a newsletter into short links with UTM parameters.

These are tasks one would normally assign to a junior member of the team. But as a leader you are faced with two truths. First, team sizes are smaller than they used to be. Second, the larger your team gets, the slower it gets. Being comfortable with code is the difference between moving fast and... not.

As is the case with every industry, AI is transforming marketing at a rapid pace. From automating content creation to providing deep customer insights, the most successful marketers today will be those who embrace AI as a copilot rather than fear it as a disruptor.

In order to plug yourself into the latest technology waves, you must, even as a marketer, be willing to go deep into the weeds. I'm not saying you need to contribute code to the project. But the early days of any technology are full of hype, some warranted and some not.

As I've emphasized throughout this book, crafting a strong narrative for developer products requires a fealty to truth, honesty, and integrity. Developers can sniff BS a mile away. They can tell when something is overpromised and will be underdelivered.

Thus, you must be able to understand the technology deeply and find the narrative throughline that speaks truthfully to the benefits developers will enjoy when using your product.

The best way to thoroughly understand a technology is to use it. It's fairly trivial to use a tool like Lovable or Bolt, or, if you're more comfortable with code, Cursor or GitHub Copilot, to write an application that takes advantage of an LLM. In a weekend, you can build a simple application to ingest data from a source of your choice, store it in a database like Supabase, use an LLM to categorize it, and write a Next.js application to display it. You can then layer in your own product or service and start learning how it fits into the overall landscape.

By actually using these technologies, you may not be able to express the insights you gain with the eloquence of a seasoned engineer. But as you write down your thoughts and impressions, you'll be able to ask more intelligent questions of your engineering team. You'll learn the vocabulary engineers use when approaching similar problems. You'll get a feel for the landscape of complementary and competitive tools to your own. You'll get immersed in the communities where these technologies are discussed daily. And you'll earn immeasurable street cred with your product and engineering team.

You will be "the CMO who codes."

The good news is that the barrier to software development has been completely eradicated. Tools like Cursor and Lovable can imbue mere mortals with software development superpowers. Through a combination of Cursor, Vercel, and Supabase, you can have a fully functional website live in a weekend. It has never been easier to become a developer and optimize your entire marketing process. It's about time we held technical marketers to a high standard of technical aptitude.

You can now use AI to understand trends and hidden motivations in large datasets. You can easily find patterns in product-usage data. You can automatically segment data into actionable cohorts. You can quickly combine, reformat, transform, and normalize massive datasets, or have AI write a Python script to do it for you.

Already, we're seeing the rise of AI SDRs who can do warm-outbound prospecting easily (cold-outbound is still, at this moment, the exclusive domain of humans). We're seeing ABM tools enriched by AI-driven insights into companies and customers, and ABM itself becoming much more approachable thanks to AI-driven research.

I published a later chapter that did not make the print edition: marketing to AI agents. That one is new. The passages above are from the book.

Measurement

From chapter 3, "You Are What You Measure"

The modern developer marketing organization is driven by data. In the old days, you could get away with running marketing using key performance indicators (KPIs) that were delayed several days. Today you run marketing using real-time data that enables you to make fast, effective decisions.

There is only one metric that matters for marketing teams: revenue.

Yes, there are other metrics we can identify and measure. But our mission is to drive revenue. It isn't marketing qualified leads (MQLs) or sales qualified leads (SQLs) or number of sign-ups.

Our first priority is to drive revenue, and our mission as a marketing team is to do everything we can to support sales and bridge the gap between product and the entire go-to-market organization in the service of driving revenue. Pipeline is a function of revenue, but revenue (and revenue growth) is key.

If revenue is down, marketing leaders get fired first, sales leaders get fired soon after, and then everything goes to hell.

Your marketing KPIs are your leading-indicator metrics that show if you are doing the right things to drive revenue. While specific KPIs can vary based on the organization, every developer marketing team should measure the following:

• Is our work effective in driving awareness of our company?
• Is our work effective in driving revenue growth?
• How much money do we spend to make money?
• Which tactics are most effective at driving these metrics?
• How is our product perceived in the market?

When I begin to build out metrics for any organization, I break it down into four components:

• Awareness: How do you drive awareness of your product or service, and how do you get people to visit your website?
• Conversion: How do you turn site visitors into sign-ups or users, and from there, how do you convert them into active users?
• Expansion: How do you convince existing customers to use more of your product, more consumption, additional features, complementary products, and so on? How are your company and product perceived?
• Systems: What systems do you put in place to measure everything?

One of the things I like to do is modify my CRM (e.g., HubSpot or Salesforce) to include a custom field labeled Touchpoints. This field is a multiselect box that allows me to establish which of the following channels a customer used to interact with my company: Webinar, Event, Meetup, Sign-up, and so on. I can then build a cohort analysis of users to identify the most common touchpoints for common behavior. For example, "of all quality sign-ups, what were the most common touchpoints?"

The other thing I love to do is funnel product-usage data into my CRM. For every developer product, there are some "golden actions" that you want users to take. For example, a database product may want customers to ingest data and run a query. I can build Python scripts to aggregate data in my product-analytics database and sync them to each contact in my CRM.

In doing so I can identify and segment users based on specific actions they took within the product.

The team

From chapter 2, "The Developer Marketing Organization"

As we've discussed, the guiding principle of the developer marketing organization is to Help First. We aim to help developers (and adjacent technical professionals) succeed in their jobs and careers. We do this primarily by listening to their problems, finding solutions, and teaching them how to use the latest technologies (including, but not limited to, products that we are responsible for) to solve those problems.

Many in our industry use the shorthand "developer relations," or DevRel. It's typical to think of developer relations solely as developer advocacy: people who speak at conferences, write blog posts, and record videos. But as the name implies, developer relations forges a bond with the communities or segments within the developer world, ensuring mutual respect and understanding. This bond is based on technical knowledge and credibility.

Developer marketing applies B2B SaaS fundamentals to the developer space. Everything from measurement and metrics to content marketing to product marketing to traditional business models, all morphed to fit a developer persona.

Thus, developer relations is the essential component of a more expansive developer marketing organization. The developer marketing organization comprises the following distinct functional areas:

• Developer advocates: They're the heart of your developer relations program. They're technical experts, content machines, top-gun spokespeople, and the main community interface. As I always say, "Trust and integrity, not your products or services, are your primary currency."
• Developer marketing: Campaigns, programs, SEO, digital marketing, events, social media, comms, and content program management.
• Developer product marketing: The ringleaders of the circus. They coordinate consistent positioning and messaging, launches, and customer feedback and discovery, and they imbue the rest of the organization with mission and purpose.
• Developer education: Documentation, training, and (if you're big enough) certification.

If you're an early-stage startup, my advice is to find someone fairly junior but very eager and with a strong program-management orientation (read: hyperorganized and disciplined, a checklist junkie, with a penchant for getting things done). This person will coordinate content creation across your small engineering team, reach out to meetup organizers, and be tenacious about getting responses; they will be eager to connect with podcasters, bloggers, and YouTubers to find ways to place your founders for maximum amplification and awareness. If they're also technical, they can author a few blog posts and, at minimum, author case studies and interface with your customers. Thus, your first hire is for developer marketing.

Your second hire should be your first true developer advocate. You will know you're ready for one when you (forgive the facetiousness) have a product worth advocating for. Before you hire your first developer advocate, your product should be in customers' hands, and they should be actively using it and providing feedback. The sentiment has been positive and close to product-market fit. Your first few blog posts were successful, and you're in something of a groove regarding the tone and quality of your content.

It might be too early to hire a product marketing manager (PMM). In the early stages, your best PMMs will be the founders. They're the ones who can bridge customer feedback and product vision to identify messaging. You won't need a dedicated PMM until you have a sales team or a predictable engineering ship schedule.

From chapter 12, "Developer Product Marketing"

If developer advocacy is the heart of my developer marketing program, developer product marketing is the spine. Everything in the organization is orchestrated by product marketing. I like to call them "the ringleaders of the circus." In truth, they're the most knowledgeable in the company about the target customer and how the product or feature meets that customer's needs.

Where marketing builds programs to reach a group of developers, product marketing defines which types of developers the programs should target. Where marketing drives awareness, product marketing focuses on helping customers understand the problems a product solves and what the product does. While marketing builds programs and campaigns, product marketing gives sales and the entire organization the tools to convert interested users into paying customers. They work together, always in lockstep.

The mistakes I keep seeing

From chapter 1, "Getting Started"

I once worked at a startup that could never decide who their customer was. One quarter it was developers, the next it was data engineers. And because it couldn't decide on the customer, it couldn't land on a single, focused go-to-market strategy. One quarter it was product-led growth to developers, the next it was sales-led growth to engineers. Bad developer marketing is often a symptom of a greater problem. Clarity on your customer target is step zero, and of paramount importance.

From chapter 13, "Segmentation, Positioning, and Messaging"

The worst job I ever had was in a rudderless startup that changed its goals and strategy nearly every quarter. This startup didn't just build a product that very few people wanted; it lived in a category that almost nobody knew or cared about. People in this company kept obsessing over differentiation on the website, in trade-show booths, and in sales enablement. But the market situation called for focusing on why the category mattered to begin with.

The rest of the program is in the book: pricing, launches, partners, PR, budget, and the career chapters. Picks and Shovels is the full text. /help answers the usual questions about the book and the training.