Driving Platform Adoption: The Missed Opportunity of Marketing

This is the first in a three-part series. Read also:

• Driving Platform Adoption: Is Swag The Secret to Getting Developers to Use Your Platform?
• Driving Platform Adoption: Community Is Your Value

After spending the last decade studying enterprise platform initiatives, we keep encountering the same story: technically excellent platforms struggling with low developer adoption.

Platform engineering teams are befuddled. The internal developer platform (IDP) they’ve built seems to match exactly what developers asked for. But as the months go by, those same developers aren’t rushing to use the IDP. It’s a recurring question we’ve heard over and over: How do we get developers to use this awesome platform we’ve spent so much time building? How do we get a return on our platform investment?

This repeated pattern points to three commonly missing elements in platform initiatives: product management, community building and platform marketing. While product management and community building are more trusted by and familiar to technical teams, marketing is often viewed with skepticism and misunderstanding.

This is a missed opportunity because marketing can be understood and applied just like any other engineering discipline. So set your marketing prejudices aside, and let’s explore how to apply a systematic approach to marketing that will raise awareness, understanding and adoption of your IDPs.

Side note: There’s a great paper from IT Revolution called “The Developer Platform,” which we highly recommend. It offers valuable insights on IDPs, including platform marketing. We’ll be blending its ideas with lessons from platform teams.

Defining the Customer

Before planning out how to raise awareness of your platform, you must define who your audience is. Good marketing strategies spend a lot of time defining the customer, or audience, for all marketing activities. When it comes to IDPs, your primary customer is right there in the title: developers.

Instead of just settling on “developers,” it’s good to narrow down as much as possible. First, these are likely application developers. They’re not developers writing embedded systems, for example. They’re probably not the developers creating the platforms in question, nor programming the custom development tools your application developers use.

Also, narrow down on the types of applications they work on and in which parts of the business. Are we talking about developers in the trading desk part of a financial institution or developers that work on the e-commerce frontend of a car manufacturer? Are these Java developers that are adding AI functionality to existing applications or developers exploring how to integrate air fryer interfaces with Apple Watches?

To effectively serve diverse development teams, platform teams should initially focus on a select few developer archetypes. This focused approach facilitates a deeper understanding of specific needs and allows iterative development of platform functionalities. The insights gained from collaborating with these initial teams can then be used to scale operations and expand to a broader developer base.

Though we’re focusing on platform marketing, spending time defining “who the customer is” is also done by platform product management. Those functions and roles are incredibly valuable and are what make platform engineering different from more traditional IT service management and delivery. As you do more and more platform marketing, you’ll find that it overlaps with product management a lot, and this is good!

Once you have your customer identified, you can move on to the core parts of platform marketing.

Core Marketing: Messaging, Positioning and Value Props

Once you’ve defined who needs and wants your product, or platform, consider the three core parts for any marketing strategy: messaging, positioning and value propositions.

1. Platform Messaging: What Is It?

Messaging is how you communicate the value of your platform — the main points you want developers to understand and remember. Think of it as your elevator pitch, distilled into clear, memorable statements. Your messaging should connect platform capabilities to developer pain points and needs. Developers don’t care about the platform itself; they care about how it helps them build their software.

When defining your platform, your messaging should start with how it benefits developers, not just a rundown of its features. For example, lead with the benefit developers will gain, then specify which part of the platform delivers that benefit:

• Deploy to production in under an hour using the platform’s automated CI/CD pipeline.
• Zero environment setup time thanks to the platform’s Infrastructure as Code (IaC) templates and frameworks like Spring Boot.
• Less waiting and fewer security review meetings due to built-in security compliance and integrated vulnerability scanning.

Each message has two parts: the benefit and how the platform achieves it. When brevity is required, just state the benefit. Define the platform by what it does for developers, not just its technical specifications.

2. Platform Positioning: What Is It Good For?

Positioning defines where your platform fits in your organization’s technical landscape. It answers the crucial question: “When and why should developers choose this platform over other options?”

Oftentimes, platforms are positioned as the everything solution that solves all the problems and, thus, should be used for all applications. This might be technically right, but narrowing down to a set of smaller, specific positions is helpful at first.

Here are some examples of how to position your platform:

• Your platform is good for cloud native applications, not just any type of application.
• Your platform is a good destination for modernized applications. Many modernized applications target cloud native architectures, moving apps to containers and microservices architectures.
• Your platform is the best place to run Java applications, especially ones that use the Spring Framework.
• Your platform is a great place to develop and run AI-enabled applications.
• You could say that your platform is good for classic three-tiered web applications: something with a UI, a middleware and business logic layer, and then a database.
• Another position could be that your platform is good for highly regulated apps that need to run in air-gapped environments.

You don’t need to pick just one positioning for your platform. After all, platforms are usually general and intended to be used for many different types of applications. However, coming up with multiple positions like the above allows you to speak to specific teams, making it easier for them to sort through all the options and figure out whether your platform is the right fit for them.

3. Platform Value Propositions: What’s in It for Me?

Value propositions, often shorthanded as “value props,” are the concrete, measurable benefits your platform delivers. They answer the developer’s question: “What’s in it for me?” with specific, provable outcomes.

Good platform value props focus on specific benefits, not abstract capabilities or business outcomes. For example:

• Time and tedium savings: Reduce deployment time from two days to 30 minutes. Eliminate 80% of security review meetings.
• Toil reduction: Automate and handle infrastructure configuration, simple network routing and load balancing, all so you can write apps, not program YAML.
• Developer experience: Self-service environment provisioning. No more ticket queues for infrastructure.
• Frictionless onboarding: New developers can start contributing to production-ready code in hours, not weeks.
• Quick access to services: Self-service, pre-approved access to databases and AI models. No tickets needed.
• Built-in observability: Automatic logging, tracing and monitoring help debug and optimize applications faster. No need to build these systems into your app.

As you can see, developers like ease and speed. Even more so, they hate having to file tickets and waiting around for the ticket to be addressed.