The Developer Marketing Funnel

How to optimize product and content marketing targeting developers

Today’s growth marketers know too well the intricacies of the customer funnel. Whether you’re using the AARRR framework or growth loops, every journey has a degree of awareness, consideration, and conversion stages. 

Specifically, SaaS targeting developers — also called developer tools — belong to a unique market category simply because software engineers are a unique audience. If you’re in dev tools, you might know that you “don’t sell or market to developers.” But this is just the tip of the iceberg.

The way developers discover, compare, and buy software to get their job done doesn’t follow a traditional funnel. 

That’s also why so many developer marketers get it wrong. Marketing to developers is a whole different ballgame compared to marketers, designers, or salespeople. It’s not just a matter of TOV but a set of nuances spanning product marketing, content, and UX.

Read through as we lay out the developer marketing funnel we used at companies like Vercel, Airbyte, and Humanitec to grow developer adoption and advocacy to the hundreds of thousands!

Traditional vs. Developer Funnels

The traditional customer funnel is made of three stages:

1. Awareness: The lead is either problem-aware or unaware, and the business goal is to use content, ads, outbound, or referrals to re-ignite their problem-awareness and activate their solution-awareness by hinting at your product!

2. Consideration: The lead actively considers multiple alternatives to pick the solution that best solves their problem. The organization’s goal is to package and position its solution as the most fitting.

3. Conversion: The organization now verified that the lead has the potential to be a customer and use the product, and the conversation shifts to how to negotiate pricing and implementation to ensure a balance between time-to-value for the customer and sustainability for the business.

The developer funnel is very different, and that comes down to the nuances of their unique persona.

• Radical practicality. Developers are time-poor, radically practical problem-solvers who always seek the path to the least resistance to understanding, learning, and implementing efficient solutions. This means sugarcoating your marketing copy with too many adjectives, narratives, and so on won’t work with them; it’ll put them off. Instead, optimize for practical messaging, TOV, and efficient UX/UI, especially at the top of the funnel.

• Community-first. When scoping new alternatives, developers are very proactive, scouring the Web and tech communities like Hacker News, Product Hunt, Stack Overflow, or Reddit, always checking for peer reviews to evaluate whether a new solution is worth their precious time. It becomes paramount for marketers to establish a consistent presence on these channels and invest in community.

• Learning by doing. Developers are curious self-starters, always looking for ways to improve their workflows and productivity. They prefer learning new tools and apps by deploying an MVP in a demo environment. This behavior has critical consequences as it prescribes a UX that is entirely self-serve.

• Rational introverts. Software engineers tend to be introverted. They love solving complex problems but might prefer to avoid talking to salespeople. Also, they might not consider themselves the best salespeople or marketers if they need to pitch a new solution to their manager. It’s important to keep contact with your sales team at a minimum and,  when they’ve decided on adopting your product, empower them with the tools to make a successful internal pitch.

Taking the above into account, the developer marketing funnel becomes quite different from the traditional one, more like this:

1. Exploration: The developer is already problem-aware and proactively scouring the web for alternatives to solve their problem and fit into the team tech stack. Your goal is to invest in a consistent community presence and ensure that your marketing site is compelling, straightforward, and BS-free.

2. Demo: The developer is now solution-aware and considering multiple alternatives by implementing an MVP of a few alternatives into their demo environment to test technical viability, solution efficiency, and fit within their stack. Your goal is to design the demo experience as self-serve, radically practical, and effective.

3. Internal sale: The developer now verified that the solution is technically viable and right for the business and now needs to pitch it to their manager to advocate for company-wide adoption. Your goal is to empower the developer with the right content to drive an effective internal pitch of the solution with the right stakeholders in the business and assist the champion every step of the way to close the deal.

Now that we’ve cleared the air about the fundamental steps of the developer funnel let’s dig deeper into how you can align your product marketing and content to drive conversions.

1. Exploration

In the exploration stage, your content goal is to convince developers: a) why your solution is solving their problem effectively, b) better than existing alternatives, and c) doing so while being compatible with their existing tech stack.

This is mostly a product marketing exercise that happens on your marketing site. When marketing to developers, it’s key to design a landing page that optimizes for:

• Compelling differentiation. Your differentiation messaging must be very clear, compelling, and high up on your information architecture. Whether your unique selling point is a specific feature, integration, or price, it has to be crystal clear. Most product marketers enjoy using abstract narratives and fancy terms, but this approach doesn’t work with developers. All they want to know is why your product is different or better than others, in plain English, with no frills. Use the “Grandma test,” and ​​don’t over-explain or over-adjectivize your benefits.

• Hovering navigation. Because developers are time-poor, they don’t click on elements of the marketing site; they hover around. To optimize for that, design interactive drop-down elements with icons and copy one-liners that help them gauge your value prop quickly (see Vercel’s example below). Include these on your main navigation or your product features. You need to answer this question: “What do your champions need to know about your product?”

• Compatibility markers. One of the key questions developers will have about your product is: “Does it fit with my programming languages and frameworks? Is it fast to implement? Do they have SDKs and sample for it?”. Just like company logos, programming languages, and frameworks, logos also work as social proof markers for developers, as they provide peace of mind that a) they’ll be able to use the product, and b) the more logos are there, the more reliable the product is.

• Quickstart guides and API docs. As soon as developers understand why your product is differentiated and compatible with their stack, they’ll want to check one last thing to see if it’s worth to demo: quick start guides and API docs. Keep these elements accessible from the main navigation, the final CTA, and the footer, and design them with a radically intuitive UX/UI. Invest in robust docs indexation, outlines and search (⌘K), rich templates, guides, and community features like popular articles, peer reviews, feedback inputs, and user-generated FAQs. 

Overall, these tactics will ensure developers will give your product a spin for a demo. Great examples of the above content include Vercel, Snyk, and Auth0.

2. Demo 

Once your developer has been convinced your product is worth a demo, they’ll sign up to try it and confirm their initial assumptions. At this stage, they’ll usually sign up with a personal email to minimize the risk of being contacted by salespeople. 

This stage is an exercise of technical content marketing and experience design. You want to enable them to get the demo off the ground as quickly and easily as possible.

• Working sample. Before even starting working on the demo, most developers want to see a working sample or template, a simple version of your product application that helps them experience it first-hand and double-check it meets the expectations set in the exploration stage. It’s even better to have a downloadable version of your sample that’s already configured with their account info (API Keys, secrets, etc.), as it streamlines the process.

• Templates library and design. You must create a few demos based on the different use cases, product features, and supported languages. Index your templates library similarly to your API docs to make them accessible. Also, investing in the design of your samples — including structured data, video demos, and quickstart copy — will set you apart from competitors. Even with radically practical users, perception is reality, and a simple, good-looking UI breeds thoughtfulness and reliability. It’s like the first impression on a first date. 

Great examples of the above include Vercel and Stripe.

Once ready to deploy the demo, your developer will dig into the nitty gritty and understand how your product connects to their stack. They’ll typically sign up again with their work email. Merge the two accounts in your data warehouse by tracking the browser cookie and the anonymous user ID. This info will uncover important insights on their end-to-end journey. Then, line up helpful content to help them deploy the demo.

• Step-by-step guides. Given they now need to deploy the demo into their repository — their org’s dev environment — they'll be looking for a full-blown version of the quick starter guide — the step-by-step guide — which includes a detailed explanation of all the steps needed to complete the deployment.

• Architecture scenarios. In these docs, it’s useful to articulate how every app component can connect to each other and existing tech stack components. Dedicated architecture scenarios include visual diagrams and technical explanations targeting senior engineers or software architects and help them understand the deployment process and integrations with other SaaS.

Want to dig deeper into the best strategy to scale developer adoption and advocacy across the entire funnel?

3. Internal sale

Now that the demo has been deployed, performs as expected, and integrates with the stack, it’s time to showcase it to the team. This stage aims to get management approval and unlock the budget that will lead to business-wide adoption. 

To do so, developers need to sell the platform internally. But because they’re not great salespeople, it’s your job to empower them to package the right content to enable the internal sale.

• Use case and solution pages. These product marketing landing pages work wonders as additional social proof markers for engineering managers because, despite the developer not reading them, they make it clear that your product matches the needs of “companies like them.” Make it easy for them to share them with their team as an appendix to the demo. Keep them front and center in your navigation, and include them as part of the ‘convince your boss’ content pack. We love how Strapi executes these.

• Enterprise-ready features. If your product targets enterprise customers, you must list all your enterprise-ready features — audit logs, SLAs, data and logs retention, support tiers, authorization, RVAC, etc. Check your enterprise readiness to see how far you are. As these features target mostly the VP of Engineering or CTO, it’s best to include them in your pricing page or a dedicated section of your developer docs. Again, developers won’t read this — they just want to be aware that these features are included and the full detail can be easily consumed when shared.

• ‘Convince your boss’ content pack. You can take things to the next level by packaging the working demo and the above assets in a so-called ‘convince your boss’ pack, empowering your champion to make a successful internal sale. This pack can include a slide deck or one-pager with:

  • Value proposition, features, and benefits overview

  • Case studies, social proof, and compatibility markers

  • Pricing, cost, and benefits, ROI calculators, or build vs. buy summary

  • Implementation roadmap details

• Email sharing templates. Sometimes, the email or Slack messages with which you share the content pack are even more important than the content pack itself because they help your champion kick off the conversation about the sale. These messages could be tailored to the company use case and/or the company stack, as well as to the relevant stakeholder that the champion is trying to convince — may that be the technical or economic buyer in engineering, product management, or even finance.

Very few companies do this right, but Smashing Conference provides an insightful example of how to do it right.

Closing thoughts

Unlike traditional personas, targeting developers demands a specific strategy and funnel. Developers are introverted people driven by practicality, community, and hands-on learning. This reshapes how we engage with them through marketing.

You must lead with clarity in differentiation and compatibility, a smart UI design, and encompassing quickstart guides and docs. Also, intuitive working samples and a well-designed template library are key. Design impacts perception, making aesthetics a powerful differentiator.

Lastly, don’t forget to empower developers to advocate the sale internally. Tailored email templates, enterprise-ready feature lists, and 'convince your boss' packs provide the tools they need to close the deal on your behalf.