Value Prop Workshop: A “State Matrix Audit”

Alright, let’s try something new for this week’s reader question.  As regular readers know, I do a “you asked for it” column where I answer reader questions.  But lately, I’ve been getting a specific form of questions.

People ask for help with their free agent/moonlighting value propositions.  Sometimes, these requests even involve offering to pay me some sort of hourly consulting rate.

Well, since I don’t do B2C consulting, and since I do have a blog to write, I’ve decided to start using these requests as fodder for blog posts.  My hope is that some examples round out various posts that I do on the subject.

So here’s what I’ll do.  If you have nascent ideas on positioning and value propositions and want feedback, hit me up via email (erik at daedtech) or on Twitter or something.  Let me help with your positioning ideas.

I haven’t yet fully worked out the best format for this, obviously, but I figure we can iterate.

The Value Proposition

Alright, let’s get down to business.  Here’s the first idea for a value prop that a reader sent to me.

I sell State Matrix Audit to small dev teams.

My ideal client is a team that built an app which works most of the time. But the devs or the management want to be sure it is correct and has [high availability]. My contribution is to audit the tech stack and application code and provide a report – which sequences of failures would lead to error states (downtime, data loss, etc). Along with estimated recovery times, automation suggestions, stack tweaks, etc.

I have a great track record of doing just this as a salaried employee and am thinking about converting this into a consultancy company of one.

The request was some help in refining this value proposition.  So let’s dive into this.

There’s a Lot to Like Here

First of all, let me address the state of the current prospective value prop.  And, I think it’s a relatively strong one on its face.  There’s a lot to like here.

The first favorable thing is that this sits in the realm of road-mapping.  In a post I wrote some time back, I talk about four phases of problem solving.

• Diagnosis of a problem.
• Prescription of a therapy.
• Application of the therapy.
• Re-application/maintenance of the therapy.

The further left (up?) you move with this, the more you’re perceived as an expert.  This means higher rates, better treatment, more demand, and generally a better life.  One of the problems with miscellaneous app dev is that it tends to sit squarely in the third bucket (with the first two often given away for free and called “discovery.”)

We don’t have that problem here.  This is diagnosing and prescribing therapy.

There’s also a clear appeal to the people within the organization that hold the purse strings.  People in leadership have a definite interest in acquiring knowledge ahead of time when it comes to potential outages, errors, etc.  It also helps that you offer remediation.

This is the core of something good.

Where You Might Struggle

Let’s now look at the flip side.  I’m going to put myself in a role that I’ve previously occupied — IT leadership — and imagine my own response to this pitch.

If I were feeling short on attention or cynical (or just like a mean human being), I might snarkily respond to this with “oh, so you’re a software developer?”  Point being, just about any software developer in the world can:

1. Offer an opinion on the app and whether it has high availability.
2. Offer an opinion on the tech stack.
3. Point out possible failure vectors and what should be done.

Now, as a manager (particularly if my team’s app has a history of flakiness or bad code), I might need your services.  And, if you offer me a series of glowing references and past work case studies, I might believe fully that your offer is just what I need.

But think of the optics.  Your hire is, in effect, me telling my team through actions “welp, I think you all suck, so here’s an outsider with a similar background who I’ll listen to instead of you.”  It’s not exactly a recipe for a high-morale situation, even if you do deliver what you promise.

With both the good and potential bad in mind, let’s look at some refinement ideas.

Narrow Down the Ideal Client

“Small dev team” is better than “dev team,” but it’s still not super specific.  It’s also not entirely clear why the size of the team matters at all.  I’d think big teams would be even more likely to have flaky software, but that’s just a hunch.

I’d forget the size of the team and brainstorm other ways to identify it.

• Maybe teams that have just gotten a round of funding, or some other indicator that they’re going to need to scale imminently?  In this case, you could focus your positioning on being an enabler of scale.
• You could target teams with a history of outages.  This would mean getting away from the “mostly works” concept, but that’s probably fine.  Teams don’t typically look to outside help, particularly at the risk of pissing off their existing staff, when things are mostly good.
• If your employment history has oriented around a particular problem domain, maybe focus on that (e.g. if your employers had historically all been banks or something).  This makes it easier when you’re marketing yourself to have what Jonathan Stark refers to as “rolodex moments.”  If you tell someone at a cocktail party that you help “small app dev teams,” almost no one will say “oh, I know who you should talk to.”  But if it’s banks, someone might say “my brother-in-law does IT or something at a bank… you should talk to him.”

Think of a Pain-Dream-Fix Scenario that You Could Explain

I once talked at length about positioning in the context of pain-dream-fix.  That post included this awesome graphic.

So, looking at Mario here, your value proposition, in “who and do what” form, would be “I help plumbers develop superpowers to slay their enemies.”  It’s not so much about what you deliver (the flower) as it is about how your client’s lives will be better when you’re done.

It’s not really clear to me what the pain-dream-fix scenario is here, mostly because the current segmentation seems to be “people that might have a little pain”  (an app that “mostly” works).

Earlier, I mentioned potentially targeting companies with visibly flaky software.  This makes pain-dream-fix easy.

• Pain: are you tired of customers eviscerating you for too-frequent, embarrassing outages?
• Dream: wouldn’t you like to release software, completely confident that it would stay up and behave reliably?
• Fix: let me come in, provide you with a risk assessment and a roadmap for remediation.

Now, maybe you have good reason for wanting to help customers with apps that “mostly work” instead of ones that are problematic.  If that’s the case, though, you need to identify some other pain that they’re feeling and for which your offering would be a dream.

Build an Offering Ladder

I’ll close with one last thought.  This circles back to the idea that you’re proposing something that sorta competes with the existing dev team.  (I understand this uniquely, since my codebase assessment practice has historically done exactly that).  You’re asking for a high degree of trust.

It’s often pretty hard to ask outright for a lot of trust.  It’s easier to do something small to get started, and then do a bigger engagement following a successful first step.  An offering ladder is a great way to achieve this.

An offering ladder is where you have a series of ways to engage, ranging from a cheap (or free) option up to a really expensive one.  This might mean that you have an eBook for $9.99, a 2 hour consultation/audit for $500, and then a full-on engagement for $15,000 (or whatever).

So think of a potential way to engage that gets you in the door more easily so that you can build trust.  Bonus points if this ingratiates you with the developers and even has them recommending you to the manager.  If this happens, you neatly sidestep the personnel issue.

Best of Luck with It!

So this wraps my first post in this series.  My sincere hope is that this is valuable to the specific reader that wrote in, but also, more broadly, to people looking for potential value propositions and business ideas.

It’s really hard to talk through all of this in hypotheticals.  So maybe if we put some tangible ideas out there, we can make some progress.  In that vein, please don’t hesitate to write in with your ideas, if you’re interested in my take.