How to create value proposition for developer tools (with 20+ examples)

When creating a dev tool value proposition you should talk about value, right?

Most dev tools are productivity tools so they save time, save resources, and help you do things “better”. 

And so many dev tools end up doing some version of the following. 

“Build better software, faster” - not the greatest dev-focused value prop

Saw it at least 30 times by now.

If you market to developers, this is not a good value prop.

It doesn’t say anything about your dev tool to your audience. Anything. You need to make it more explicit, more real.

Ok, so you should talk about the benefits/outcomes/results, right? 

Yes and no.  

Depending on your developer persona and the stage of the market category you are in, you often should talk about features, not benefits. 

I’d argue that going with features in dev-facing websites is a better default. But it really depends. swyx got people talking about it in this Twitter thread:  

But here is a twist.

Did you see a recent GitLab homepage?

So how do you explain that?

Well, if you have a top-down enterprise sales motion and a strong dev community, it may be that you actually want to focus on dev managers on your homepage. Or even VP, C-level or other business folks. 

Or maybe you are at the stage where your homepage is serving other needs like hiring or educating potential investors in your publicly traded company.

And then, the “build better faster” is probably not a bad option (or at least the starting point). 

Ok, so stating the obvious, what you put in your value proposition “depends”.

In this article, I’ll try to talk about what it depends on and give you good examples of how dev tool companies created their value propositions. 

But first thing is first. 

What is a value proposition (definition)

Look, I know, you know what it is.

But since I will talk about value propositions for the next 3000 words I want to make sure we are on the same page. 

I like how folks from Hubspot define it:

“A value proposition is a short statement that communicates why buyers should choose your products or services. 
It’s more than just a product or service description —
it's the specific solution that your business provides and the promise of value that a customer can expect you to deliver.”

They also do a great job of explaining how the value proposition is different from a slogan, tagline, and mission statement. 

They give this Nike example and I figured I’d add Auth0 from dev-tools:

Value Proposition: 

• Nike: “Customizable performance or lifestyle sneakers with unique colorways and materials.”
• Auth0:  “An easy to implement, adaptable authentication and authorization platform. Basically, we make your login box awesome.”

‍Mission Statement: 

• Nike: “To bring inspiration and innovation to every athlete in the world.”
• Auth0: “Customer Identity for Everyone. Auth0 makes authentication and authorization easy.”

‍Slogan: 

• Nike: “Twice the guts. Double the glory.”
• Auth0: “Secure access for everyone. But not just anyone”

‍Tagline: 

• Nike: “Just do it.”
• Auth0: “Make login our problem. Not yours”

The way value proposition typically manifests itself is in the website header. 

It has three parts:

• Headline
• Subheadline
• Supporting visual 

And this is exactly what I will explore in this article. 

What do you need to create value proposition (before you start)

Ok, you want to “put something reasonable in the header” but to do that you actually need to do a bit of homework. 

Before you craft your value proposition you need to know (at least some of):

• your developer persona
• pains they have now
• values and benefits
• jobs to be done that people solve with your product

Ideally you’d have your positioning and messaging ready but thinking about your value proposition can actually help with that. To be honest those things are strongly coupled in my head. 

Anyhow, when it comes to value prop, there are some simplified frameworks that will help you get most of what you need like value proposition canvas. 

But ultimately, you need to know a lot about your audience, your product, and your market.

For the sake of this discussion, I assume you have those ready (whetherbased on research or thin-air bets).

Either way, I will not talk about those here. 

What is a good value proposition and how to test it

If you want to create a good value proposition, you should probably know what “good” actually means.

Typically people talk about:

• Clear and memorable
• Relevant to persona
• Differentiated
• Enticing

I like how Hiten Shah talks good value propositions on Everyone Hates Marketers. 

He argues that the value proposition:

• is created and exists in the readers' (users') mind. It is not yours to create rather than name. It is what people think and say about you to others.
• because of that it should be created based on the voice of customer data. Based on what people actually say, not what you’d want them to say. 
• it should be easy to remember and spread with other people even if the person seeing your value prop is not ultimately going to use/buy it (which is most people). 

I think the last point doesn't get talked about enough.

"Value propo should be easy to remember and spread with other people"

Word of mouth is super powerful acquisition channel, especially in dev tools. So making your value prop in way that makes word of mouth easier sounds like a good idea.

Now, say that you have that "good" value proposition. How do you actually measure that it is good?

Long-term, you should see lagging metrics go up like word-of-mouth referrals, higher conversion rates, better lead quality, lower churn, and all the good stuff. 

But you will see those in the future. What do you do today?

Ideally, you run message testing (or other tests a/b, social ads). 

The concept is simple:

• You take your value proposition (header mock-up for example) 
• You put your value prop in front of people from your ideal audience
• You ask them questions (directly or indirectly) and see what they say

What questions?

Taking from that Wynter article:

"""
In message testing, your quantitative and qualitative research should focus on these key dimensions of your message: 

• Clarity. How well you communicate your offer to your customers and how well they understand it.
• Relevance. How your value proposition aligns with customers’ needs.
• Value. How important, timely, and beneficial your message is for your users.
• Timeliness. How effectively your message inspires customers to take action soon.
• Consistency. How uniform your brand tone is throughout your website.
• Differentiation. Why your offer is different from the rest.

"""

Obviously, it will not make it 100% certain that your message lands. But it is better than pushing it out and waiting for X sales cycles to see if things moved. 

There are tools that can help you do it:

• Qualitative user research with tools like UserTesting or Wynter (a specialized tool for message testing).
• Running ads with different value propositions on socials (Twitter, Linkedin) and comparing CTRs. And yes, you can run ads to the developer audience successfully.
• Running A/B tests on the website and comparing engagement. 

 Ok, but how do you actually go about creating value prop? What should you think about?

Developer tool value proposition considerations

Any messaging, value prop included, should meet the audience where they are. 

That means speaking their language, their pains, their hopes and dreams, and their depth of tech understanding. 

The actual person you focus on matters a lot. Is it a dev, team lead, or a CTO. And that will heavily depend on your product's go-to-market. 

To meet devs where they are, you need to understand their level of understanding of the problem.

Do they "get it" and you just go with spec-like features communication or do you need to spell out the benefits?

Or maybe the second-level effects of solving the problem are what drives real value?

Zach Goldie brilliantly describes it in his dev tool messaging guide with four layers of benefits.

Or if your product category is full of competition, then you should focus on the differentiator. 

But if you are the only one you should “sell the category”. As Peep Laja explains here:

In fact, if you are doing marketing at a dev tool startup you often should market the problem and your users will market the product for you. 

Anyhow, from my perspective there are 3 dimensions of this value proposition space:

• market/tech adoption maturity
• competitive landscape
• your product, and go-to-market maturity

Let me go over these one-by-one. 

Value proposition and market/tech adoption maturity

Swyx talked about it on the Scaling Dev Tools podcast (go to 16:55 if you are impatient).

Basically, he applied the classic Crossing the Chasm methodology to dev tool marketing. 

Every technology market (dev tool category included) goes through adoption stages. As the technology gets adopted different groups with different priorities adopt it. 

It starts with Innovators:

• For them, understanding how your tech works is important. 
• Especially in dev where knowing exactly how tech works can make you feel confident about adopting something. 
• They can survive with little docs, no examples, bugs, bad support etc.  
• By showing how it works, and which framework/lib are used under the hood you let them understand features and benefits. 

Then you get to early adopters:

• ‍‍They are a bit more pragmatic than innovators who care about "the tech".
• They want to get the benefits of the tech.
• They can survive suboptimal developer experience but they expect more than just the code. Solid docs at least.
• They want to see the features as they can figure out the benefits it brings to them anyway.
• I'd argue that many devs are in this category, more than in other markets.

Then you enter the early majority:

• Pragmatic buyers, who want safe improvements. 
• They want great docs, examples, support, community using your framework etc.
• They listen to others like them. Basically, they want what is safe. 
• They want benefits. 

Then you get to laggards:

• They adopt new only when they absolutely have to. 
• So you need mass adoption of your tech to “force” them. Or top-down enterprise sales motion :). 

So:

• innovators: how it works
• early adopters: features
• early majority: benefits
• laggards: idk, really, push

Swyx argues that in dev tools you can usually figure out in which stage of the market you are at:

• estimate the size of the market (java dev on LinkedIn, StackOverflow hashtag, Reddit community)
• estimate tool adoption based on your traction and competitors. 

And in dev tools, while you focus on single dev adoption, you are in the innovators or early adopters phase. And so communicating via “how it works” or “features” makes sense. 

One more interesting way to look at tech adoption is through the lens of expertise in particular tech: 

The argument goes that if your audience is an expert in particular tech and that tech category is widely adopted then you go for differentiation (and features). Otherwise, you go for value. 

I think in dev tools the audience falls into that bucket more often even if the category does not exactly exist yet. 

Remember that there is this funny thing with devs where they are one of your competitors. They build dev tools all the time. They may have built something similar in-house 2 years ago, or they may be considering building it now. 

So dev audience is by its very nature more in that top right corner and so feature-based communication makes sense.  

Another thing is naming the category/market frame. You may know what something should be called but the market “mistakenly” calls it something different. 

Should you correct them or should you adjust to what they say?

There was this  episode of open source startups:

Paul Copplestone the founder of Supabase, shared the story where everything clicked for their dev audience when they used “Open-source Firebase alternative”.

... even though it was far from factually correct and it felt sort of cringy for them internally. But it made a ton of sense for their audience and so it stuck. 

I think ultimately it is 100x easier to just claim differentiator on a known category than try and educate the market on something brand new. But there are examples of companies claiming a completely new category and winning big. 

Speaking of differentiators in known categories. 

Value proposition and competitive landscape

From the buyer's perspective the competitive landscape matters a lot. 

With many options, it is difficult to pick or even remember any brand.

It can all feel the same. 

Let me give you an example from the observability space. 

Here are six value props, some from well-known companies:

• “Modern monitoring & security
  See inside any stack, any app, at any scale, anywhere.”
• “The Unified Security and Observability Platform
  Go from visibility to action, fast and at scale.”
• “Real-Time Actionability From Your Observability Data. Powered By XXX.”
• “Modern cloud done right
  Simplify cloud complexity and innovate faster and more efficiently with observability, AIOps, and application security in one platform.”
• “Monitor, debug, and improve your entire stack.
  XXX is where dev, ops, security and business teams solve software–performance problems with data. “
• “Monitor Your Entire IT Environment Securely: AIOps. Full-Stack Monitoring. Observability.”

Read them? Ok. 

Do you remember any?

Which one is very different from the rest?

Now imagine you are a dev looking at these products.

Imagine them having to convince their team to choose one of these based on what they remember from reading website headers. 

That team will either go with the most known brand (incumbent) or the cheapest option.

Now, if you are the category leader, you are fine with basically explaining what the category does. You are ok with no differentiation and the status quo because the strength of your brand wins it for you. 

But if you are a challenger you need to, well, challenge that status quo.  And you could use the fact that the space is crowded and really own your differentiator. 

Axiom does just that in the observability space.  

They:

• name the category (observability)
• they name many competitors (competitive landscape)
• they explicitly claim that they are more scalable than everyone (differentiator)

Pretty bold if you ask me but I like it.

And it is definitely different and memorable. And the value prop (scale) pops and stays in your head. 

Value proposition and your product and go-to-market maturity

The maturity of your product and your go-to-market motion determine who you should be talking to and how. 

Especially in dev tools, many companies go through:

single tool -> suite of tools -> platform

You can look through Stripe progression through time for example. 

It went from a single tool targeting devs at startups to a payments infrastructure platform used by Fortune 500 enterprises.

Another thing to consider is your internal go-to-market motion. Many dev-tool startups go through the progression from:

free (open-source) adoption -> (commercial) product-led growth -> enterprise sales motion

Adam Gross explains it beautifully in this talk. 

But basically, you go from:

• free -> single value-proposition -> measured by adoption (dev)
• self-served/sales-assisted -> collaboration -> measured by MRR (team)
• sales-led -> compliance -> measured by ACV (enterprise)

And that has implications on your value proposition. 

Namely, the more you go in the Enterprise sales, the less effective keeping the single free user value proposition on your homepage gets. 

The more C-level folks go to your website the less should it serve your devs. 

And that is when the “business” website and “developers” portals happen. 

Look at Auth0 in 2013 vs Auth0 in 2022:

Examples of good dev tool value propositions 

There are many value proposition templates that you can use. 

But to be honest, most focus on non-dev buyer/user communication. 

And I’d rather look at what developer-first companies do. 

So I compiled this list of themes with examples for each one that I saw in the wild. 

Here we go.

“X alternative”

Sometimes your category is well-known to your target audience. Or there is a clear market leader you can use to anchor your solution. 

In those cases, you can use an “X alternative” flavor of a value proposition. 

Somewhat often used is the “Open source X alternative”. 

Supabase and MedusaJS use this. 

This framing makes it very easy for folks to put you in a slot (vs market leader) and understand your differentiator (open-source). 

It seems to be working really well if you are doing your marketing on Hacker News where devs really like this open-source angle on things. 

I also liked a more subtle approach that GitLab took a few years back.   

They have a clear “enemy” that is obvious to their target audience and they don’t pretend that GitHub doesn’t exist. They name them and explicitly say they are better. 

Obviously, you need more than “we are better” to convince devs but if you have a separate page that talks about it deeply you should be fine. 

Buyers usually know that there are competitors and they may have used one or many of them. If you have a clear differentiator, and you should have it to enter a saturated market, then claim it. 

“What -> benefits/features”

I like this one because it is simple. 

It starts with a market frame like:

• Node.js and TypeScript ORM
• Collaboration platform for API devs
• Utility-first CSS framework
• Geofencing platform

Then it explains the benefits and features that come with it:

• data model, automated migrations, type-safety…
• packed with flex, pt-4, text-center… to build and design in markup
• APIs, SDKs, and dashboards for geofencing, place detection…

You can also flip it by starting with the benefit and then go for “what -> features” like TailwindCSS did. 

One more example with a cool interactive supporting visual from Radar (go to the site to check it). 

“X for developers”

If you are doing something that is generally understood (video, payments, media assets) but your target is the developer audience you can just say that. 

Especially when other vendors focus on other non-developer personas and this is your differentiator. 

Two visual asset examples from Mux (video) and Echo3D (3D)

And a classic from early days of stripe in the payments space:

“Slogan -> features”

I saw this one a few times. 

The headline is basically a slogan and the sub-headline explains features (or features and benefits) in detail.

I think this may make sense when:

• You are a very well-known brand and people kind of know what you do. The slogan is something people remember and spread. 
• You want to speak to two personas: Headline speaks to business, and sub-headline speaks to dev.

“Benefits -> more benefits”

Some companies just focus on benefits. 

I think if your category is new / non-obvious / not really formulated to your audience it makes a ton of sense to go at it this way. Especially if the jobs-to-be-done (and benefits) are clear. 

“What -> brag -> features”

If you have a great adoption and a ton of users or customers you should play that card. 

So the Header I see some companies do is this:

• What is it (customer data platform)
• Brag about huge adoption (25000+ businesses)
• Say what you do (API to clean/collect

I mean if you have strong dev user community than that is actually your differentiator. Use it. 

Ok, so let's put it all together and create your value proposition step by step.

How to create a developer tool value proposition step by step

Step 0: have your positioning ready:

• persona
• values/pains
• real alternatives
• benefits/features/values from your product

Step 1: Answer market/product/landscape questions:

• What is the technology/market maturity?
• What is the competitive landscape?
• What is our product maturity and scope?
• What is our go to market maturity?
• What is our adoption?

Step 2: Understand the current status

• Test your current value proposition on your ideal users.
• Take your current messaging and run user tests.
• Take you vs competitors homepages and run tests.

Step 3: Choose a value proposition option:

• Is there a clear market leader or many competing products? -> consider “X alternative” framing.
• Are you a market leader and have great numbers to show? - .Consider “What -> brag -> features”.
• Are you a tool that does something “normal” but for devs -> try “X for developers” framing.
• Is your category completely new? -> try “value -> value”.
• Is your category well known but you have a twist? -> try “What + value” framing.

Step 4: Test your value proposition:

• Same as before, run qualitative message tests via UserTesting.com or Wynter. 
• Run some social media ads on your audience.
• Finally run A/B tests on your website (if you are at that scale). 

Step 5: Run with it:

• Publish and don’t change for at least 3 months.
• Pushing a message to the market takes longer than you think.

Final thoughts and what is next

So here you have it, those are my thoughts on creating a dev tool value proposition. 

By no means I have it figured out completely but writing this article made things clearer for me and hopefully for you as well. 

Let me know if you have any comments/thoughts on this -> I genuinely would love to hear them. 

If you’d like to see more examples of dev tool value propositions, I keep adding them to my dev marketing examples gallery (usually under “copy” and/or “design”).