Commit

Positioning vs. messaging in cloud native && open source

Positioning and messaging are two discrete strategic concepts that every startup in cloud native && open source will have to nail, but you might find yourself slipping up here for a few common reasons:

  • You think they're all just branding, which feels like a problem for more mature/more deeply-funded companies.
  • You muddle the definitions of these concepts, leading to muddled strategy and execution.
  • You swap the concepts entirely and then need help figuring out why your target audience doesn't resonate with what you've built or how you talk about it.

When your positioning is right, and it inspires empathetic and inspiring messaging, these concepts begin to work in tandem to help you stride through those critical first few steps toward community, commercialization, and revenue.

What is positioning?

Positioning is the most precise statement of what your product is in its current state.

Let's take some examples from companies I've been researching in platform engineering, application delivery, and Day 2 Ops. Some are pulled directly from their copy, while others are my interpretations of their positioning.

  • GitLab: An AI-powered DevSecOps platform
  • Amazee: A fully-managed application delivery platform
  • Rafay: An enterprise-grade Kubernetes management platform
  • Codefresh: A GitOps platform for cloud native apps
  • VMWare Tanzu: A modular, cloud native application platform

While we might disagree on which positioning statements are the "most precise," you can see how they would be immediately understood by the companies' shared ideal customer—DevOps and platform engineers and the technical leaders who manage them—and deliver some information about where they have positioned their product within the existing market.

When your have clear and differentiated positioning, you have the first piece of your go to market (GTM) strategy: what actions you're taking to convince people to pay for the product you've built.

What is messaging?

Llet's note what positioning is not. It's not what value your product provides, who it's for, the benefits it unlocks for your ideal customers, or even the vision for your entire organization. These are all interpretive leaps only possible once you have solidified your positioning. Positioning always leads messaging.

It's worth repeating: You must be confident in your positioning before you attempt a messaging project.

Messaging is the ecosystem of strategy and language you use to pitch your product to different potential customers. Good messaging addresses all the things that positioning shouldn't, like who your product is for, how it's going to help them, and why your organization exists.

I always begin messaging projects with a brand story, an internal wayfinding device that aligns and inspires your people around what you're trying to do, informing the messaging ecosystem. You end up with a framework document that codifies how your write and talk about your company in the following categories and beyond:

  • A brand story
  • A brand promise, a distillation of:
    • Who your organization serves
    • What your organization provides (mission statement)
    • Why your organization exists (vision statement)
  • Ideal customer, developer, and community personas
  • Voice and tone standards
  • Unique value proposition (UVP) statements
  • Boilerplate marketing messages, including:
    • One-liner
    • Elevator pitch
    • Corporate/PR message
  • Key messages combining each ideal persona and UVP

Your messaging then percolates through every medium or channel where you write or talk about your product. That's website copy, promotional emails, social media, press releases, enterprise sales motions, GitHub READMEs, and beyond.

How being in cloud native && open source complicates the conversation

Closed-source and SaaS companies have one major tactical advantage when defining both positioning and messaging: Typically, they only need to do it once. Maybe with a few small tangents/off-shoots around a small suite of products aligned along the same GTM strategy.

But when you're in cloud native, or building for developers/engineers in general, which often necessitates some open source play, your work doubles. You need to understand and implement these concepts twice over—once for your open source project, and again for its commercial counterpart.

The positioning of your open source project is different from that of its commercial product.

The way you message your commercial product, down to the audiences you're targeting (e.g. those with the company credit card and approval to spend), will always be different than its free and open source partner.

Am I ready for positioning or messaging?

Ask yourself these questions:

  • Can you define your project && product in a precise phrase of 5-8 words?
  • Have you researched your target audience based on who might become a user, community member, and customer?
  • Have you validated your value propositions with real people within those target audiences?
  • Do you understand where your project && product fit within the ecosystem/marketplace where you hope to compete?
  • Are your open source project and commercial product differentiated based on features, use cases, and capabilities?

If you answer no for any of these, you're most likely still in the positioning phase.

If you've confidently answered yes to these questions based on concrete definitions, value, and audience for your project && product, then you're ready to transition from building strategy around what you do to how you talk about all the brilliant things you've accomplished.

It's an exciting new phase in your organization's growth journey that changes every bit and byte of how your organization operates, which means it's worth working with an external source with experience not only in your technology and audience, but the vibrant-but-picky communities of cloud native && open source.