Value Proposition Guidance for Recovering Programming Generalists

I saw something awesome earlier this week.  Because I’m in the content business, I was trying to explain the concept of “pain, dream, fix” to a client.  It’s a way to write landing pages that focuses on customers and their pain points rather than on product features.  Anyway, in looking for a good explanatory link, I found this gem from Anton Sten.  It’s great advice for landing pages, full stop.  But I’m going to build on it to offer you advice about your value proposition.

Getting a value proposition right is hard enough.  But when you’re used to being a software developer, it’s almost impossible because of how badly everyone teaches us to get this wrong.  So let’s look at the bad advice we get so that we can then start with first principles.

Here’s the picture from the gem of a post I found.  Let’s start there.

The Basics of Pain Dream Fix and the Value Proposition

About a year ago, I wrote about how to start freelancing/consulting as a software developer.  In that post, I emphasized the idea of a “who and do what” statement.  This is a mad lib that takes the form of “I help {who} do {what}.”  This is a value proposition — a way to convince prospective buyers to buy from you.

In the software world, we constantly get this wrong.  And this image illustrates perfectly how we get it wrong.

We tend to talk about our products in giant lists of features.  Or we sell ourselves as an alphabet soup of skills and tech stacks.  And, in doing this, we completely neglect to mention who should care and why.

“Pain, dream, fix” (and this picture of Mario) is a way to jolt ourselves out of our professional solipsism and to start thinking of others.

1. Pain: Poor Mario is too small and weak to survive in a world of Goombas and Koopas.
2. Dream: But he could be twice the size he currently is and able to slay his enemies with flamethrower arms.
3. Fix: All he has to do is eat this flower.

Flower provider value proposition:  We help undersized plumbers kill their foes by giving them super powers.

Seems simple.  But we really manage to get this comically wrong.

Software Product Makers Get This Wrong by Obsessing over the Flower

Sales copy writers tend to get this wrong in a specific way (especially in the software niche).  Instead of talking about helping Mario by turning him into Mad Max or whatever, they talk endlessly about the flower:

• Our flower is 12% taller than competitor flowers.
• It has both yellow, flesh-colored and red ovals as part of its art.
• At least two leaves per stem, guaranteed.
• Now with fewer thorns.

You get the idea.  I imagine you can imagine this as 75% of all product pages you’ve ever seen for SaaS and software products.  There’s nothing like putting blood, sweat and tears into something to make you want to bore everyone to tears listing every detailed aspect of it.

Enterprise Devs Get This Wrong by Obsessing Over the “Craft” of the Flower

But as cogs in the enterprise machine, we actually make this even worse.  We do this when we’re not a team of 5 folks building a SaaS from scratch, but instead, part of a team of 500 enterprise devs building some massive enterprise system.  Our contributions don’t even rise to the levels of actual features in this environment.

So, lacking even the ability to point to a flower, we point to the process around the flower.

• We don’t grow flowers — we craft them.
• It’s every flower grower’s responsibility to use only organic, toxin free soil to ensure proper growth (craft?).
• Mineral water is the proper water to use both for the soil and for misting the petals.
• Only a complete noob would clip the thorns with a scissors — you prune them with a special tool!

Meanwhile, Mario’s just over here saying, “WTF are you guys talking about?  I want flamethrower arms, not horticulture pissing matches!”

Interlude: Going Solo is Just Getting Away from Flower Navel Gazing… Right?  Right?!

Programmers are, almost as a rule, smart people.  So when I have conversations explaining these things, the bit tends to flip.  Quickly, in fact.

From there, the value propositions flow.  And then tail off.  And then stop.  People I speak to understand “I help {who} do {what}” but struggle with the {who} and {what} mightily.  They come to me with idea like these.

• I help software teams realize that their architecture is suboptimal.
• I help software developers port legacy web apps to NodeJS.
• My specialty is to help companies improve their data access layer’s performance.

And I reply with, “ugh, not so much.”  The trouble is, though, it’s easy enough for me to articulate what the problem is here (and I’m about to, in detail, using Mario).

But it tends to be hard for me to offer a nudge in the right direction.  Instead, I find myself offering vague advice like “well, freelance for a while as a software pro and you’ll start to get better ideas.  Now, though, I think that I can deliver somewhat more helpful advice.

But first, back to Mario.

Mario Isn’t Your Actual Buyer, And The Actual Buyer Doesn’t Want Flamethrowers or Flowers

Remember that this Mario metaphor aims to give advice on writing landing page copy.  I’m taking it further, so please don’t interpret what I’m saying here as an assessment that the metaphor falls short for its purpose.

No, it falls short for mine.  And here’s how.

As an erstwhile developer and novice freelancer, you’re used to speaking to and trying to impress your peers.  We measure industry cred in Twitter followers (who are also developers) and we task individual contributors with developmental titles (e.g. architect and “senior” developer) to administer interviews.  This forces us to think in terms of appealing to these people as buyers.

But these people don’t have the kind of money to hire you to write software.

When was the last time that you, as a software developer making $120K/year or whatever, hired another software developer making $80K/year out of your personal salary?  That’s what I thought.  Developers buy programming books and video courses.  So if you’re going to sell to developers, make those things, and get out of the app dev business.

You’re not selling flowers to Mario, and you’re not even selling flamethrower dreams to him.  You’re not selling anything to Mario.  You’re selling things to the kid that downloaded the Mario game on his console.

And, do you know what?  That kid doesn’t even like flowers and flamethrowers.  He wants the leaf and to make Mario fly.

Mario doesn’t want to fly — he’s afraid of heights.  Mario and you both agree that Mario should eat your flower and blast Goombas with fireballs.  But tough.  Mario’s management demands Racoon Mario, and works with vendors that supply leaves and dreams of flight.  Mario’s objections are noted and unimportant.

You Know What, Though?  It Turns Out the Kid Isn’t the Buyer, Either

Once you wrap your head around this, you can start to make some sense of it.  Helping teams realize things about their architecture or convert to NodeJS is helping Mario get flowers.  Whether you sell them on the basis of your loving watering techniques, the flower’s features, or Mario’s dreams, you’re still wasting your time.

You’re wasting your time because you need to be selling them to Mario’s management.

So you set about tweaking your pitch about architecture or NodeJS to the audience of a (perhaps non-technical) manager.  You scratch your head as you refine this pitch.  Better architecture helps managers… do, what, exactly?  Deliver projects on budget or something, right?  Or, maybe, do more features?

But then, just when you’re wrapping your head around this, the camera zooms out and throws another stick into your spokes.  10 year old kids don’t have money.  Your actual buyer is the executive — the kid’s parents.  Sure, the kid might pick a Mario game with a gift card, but actual budget approval comes from on high.

You can go to the kid and say, “hey, flamethrowers or flight — whatever you want.”  But the kid will just say, “oh, awesome, but I don’t have money!”  Your actual buyers are the parents.  Their pain points are screaming kids in the house on rainy days, and their dreams are pacifying those kids with some game — any game — that isn’t horrendously violent.

Your Absurd Situation, Summed Up in Mario’s World

Let’s now take stock for a moment of what it is to work in the workaday software world.  Let’s look at just how disconnected you probably are from a value proposition.

You and your teammates spend a ton of time fixated on the craft of video game flower growing techniques.  You don’t really consider the end-flower as anything more than an abstract concept resulting from the application of your techniques.

From this position, you’re trusting that your labor creates a beautiful flower.  You’re then hoping that Mario, who doesn’t really care about flowers, picks yours for its beauty.  Then, you’re hoping that he’ll like the flamethrowers so much that he convinces the kid playing the game to direct him to eat flowers instead of leaves.  And you’re hoping the kid likes that so much (in spite of it not being his first choice) that he goes to beg his parents for money.  And, finally, you’re hoping that the parents so much want a non-screaming kid that they’ll respond with “okay, fine, here’s a gift card.”

That is an awfully long series of events from flower craft to purchase — from you selling NodeJS skills to someone with actual money deciding that such skills are useful.

In fact, this is such a complicated situation that it requires an entire, complex entity called a “corporation” with a complex thing called a “standardized hiring process” to pull it off.

In case you missed me being witty, what I’m saying is that the only way to find actual buyers for “NodeJS” is to interview as an employee (or a staff augmenting contractor).

Blow It All Up, Start from Scratch, and Find Your Value Proposition

Seeing this cartoon and applying this metaphor amused me.  I’m not going to lie.  I’ve had a lot of fun writing this post.

But it also clarified something for me.

Specifically, the standard corporate software developer is so incredibly insulated from a value proposition that they can’t cross the chasm.  It’s like learning terrible technique in something (say, like bowling) and locally maximizing.  You need to stop trying to create a value proposition out of your current work.  Forget it.  Blow it up.  Start over.

Some Heuristics for a Legit Value Proposition

This is what I’ve been doing wrong all this time in advising people.  I’ve been trying to have them start from where they are and figure it out.  Don’t do that.  Instead, forget about any specifics of what you’ve been doing.  Forget your tech stacks, your specific roles within your current and past groups, etc.  Retain only the understanding that you can automate things if need be.

Here’s what finding a value proposition from scratch might look like.

• First, decide if software developers are your buyers.  If they are, understand that you’re going to make a living selling them things that cost $500 or less a pop (training courses, videos, tools, etc.)  Full stop.  Do not build a business that involves trying to get Mario to convince a kid to convince the parents.
• If your current/past employers have clients and you understand their needs, think about how you might serve them directly.  This doesn’t necessarily mean directly competing with your employer.  Maybe you work for an app dev shop and have bank clients.  If the employees at the bank consistently complain about losing emails to full inboxes, you could think about helping corporate employees streamline their inboxes.
• Likewise, if people at your company complain about something like this, you can go that route as well.
• Schedule chats with managers and executives within your organization (or past employers) and do some exploratory inquiring about their biggest professional pain points.
• Lurk on forums for things that interest you or products that you like, and see what people consistently request or complain about.  Think about how you could help.
• Get into the habit of constantly observing and asking yourself, “hey, does {who} need {what}?”

Leave Behind Your Role, Not Your Skills

Software development (really, automation) is an incredibly valuable skill.  As I mentioned in my most recent book, it’s a skill that you use to give people back their time and to increase efficiency.  So please don’t think that I’m trying to sell that short.

What I’m selling short his how weirdly silo-ed and disconnected from any kind of value proposition we’ve allowed ourselves to become.  We’re so focused on things that absolutely no one more than 10 feet away from us care about, like which design pattern to use, that we’ve completely lost sight who pays our salaries and why.

And, that’s actually fine within a corporate context.  But if you leave that incredibly padded room without learning how not to bang into stuff, you’re going to get hurt.  Specifically, you’re going to hang out your shingle and then you’re going to find yourself competing on Upwork for commodity labor and interviewing for staff aug gigs with almost no distinguishing features from employment.

And, even that is fine, as long as you know what to expect going in.  If you lack a viable value proposition you might have to slog through a few years of pseduo-employment before you land on one.

But if you start thinking of this stuff now, you’ll find that you have a much softer landing as you gear up to leave the corporate workforce.  The best time to start was 5 years ago.  The second best time is now.  So start imagining the super powers you can grant people and stop worrying about pedantic flower growing arguments.