Zach is a messaging consultant specializing in helping DevTools communicate why they're awesome. In this article, he shares his method for helping clients get specific with their pain points.
Developers don’t hate marketing, they hate pages of irrelevant information.
After all, they are making technical decisions. They need to know the specifics of what you do, how you can help and if you’re the right fit.
Don’t sell the drill, or the hole. Sell a better drill.
Imagine you were selling a drill to a professional carpenter. The old advice of “don’t sell the drill, sell the hole” wouldn’t apply since they already have a decent drill.
You would instead have to pick out specific issues with their current tools. For example, maybe your drill’s inbuilt stud finder removes the risk of drilling into pipes and wires.
Selling DevTools is a similar challenge.
Your product is probably replacing an existing part of their workflow, something that they are already somehow either solving or have chosen to ignore. That means your messaging needs to demonstrate that you fix those specific pain points.
Concrete processes to avoid vague pain points
I’ve seen various guides around positioning, messaging and copywriting for DevTools. They have good info, but rarely help you go beyond “you need a pain point”.
That’s why I wrote my guide about messaging for DevTools, of which refining pain points is the first step.
To nail the messaging you have to zero in on the specifics of each element. Stating your software is “easy to use” isn’t going to convince anyone.
Over the years I’ve helped many clients dig into what’s motivating their ideal prospects in order to pull out relevant benefits, features and imagery. I want to give you a couple of specific processes to make yours as specific as possible.
But, first, what’s their context?
First, what’s causing the pain?
When it comes to pitching DevTools, context is everything. You’d never pitch a JavaScript 101 course to a senior dev. Yet, companies often forget about context.
Your software is probably replacing an existing way of working. That means the pain point isn’t the overall issue, it’s the irritations in their current way of working.
Let’s take autoscaling. Slowdowns aren’t the pain point if people are already fixing them through manual scaling. The pain point is getting Slack alerts in your free time.
That’s why our first step to better messaging is acknowledging how they are doing things. You might be replacing:
- Something barely optimized or handled manually
- Using the DIY or free OS option
- An established way of working
For each one, the pain points become the issues with that current way of working, such as the headaches from outgrowing an OS tool.
I’d say this is the key step for defining prospects. Even if you have direct competitors, your potential users might be comparing you to just handling it manually.
Now, you might have potential users in more than one scenario. For example, I imagine Datadog probably has some prospects who are using an OS monitoring tool and some using a competitor like Dynatrace.
But, you can only talk to one audience type in any piece of content. It’s tempting to hedge your bets and talk to multiple scenarios, but that creates a weak, watered-down pitch. So, be brave, pick a single context for each page you create.
Identifying pain points through the lifecycle
The challenge is now to define the pain points in their scenario.
Instead of picking them freeform, use the lifecycle as a prompt. Write out the pain points at each step of carrying out the work. There can be potential headaches during:
- Set up and integrating
- Normal daily use
- Maintenance
- Outcomes and results
- Troubleshooting issues
Don’t worry if some are irrelevant, the point is to explore the options.
This should give you a good initial list, but you want to get the pain points as specific as possible. So, here are two methods I use with my clients.
Refining pain points: Expectations vs reality
Try to describe how a process should ideally work vs how it really plays out.
For example, I once drew out this comparison of an expected vs actual git workflow. It helped us to pinpoint various pain points in the process.
Repeat this expectation vs reality for each step of the DevTool if relevant. Does it reveal specific headaches when it comes to troubleshooting issues? How about in maintaining integrations?
Refining pain points: Root cause analysis
You can get specific through a variation of Root Cause Analysis. You’ve probably heard of RCA through the 5 Whys method for uncovering what caused a problem.
Try applying this method to each of your pain points. See if you can pick out why it’s a problem or why it’s so annoying.
Let’s take rebasing branches as an example. They’re annoying, but why? We can pick out two specific points:
- The typical rebase race is an annoying distraction
- A broken main branch interrupts the whole team
It will probably only be relevant to go one or two levels deeper. You don’t need to define extremely obvious issues like why work interruptions are a pain point.
Note: Pricing is an unreliable pain point
I would generally caution against using pricing as the key pain point.
Even if you save a company thousands a month, it might only be 0.01% of their revenue. That saving might not matter when balanced against migration headaches and platform risks.
For example, Heroku is more expensive than AWS. Yet saving DevOps staffing costs and headaches make the price worth it to users. So, I wouldn’t recommend putting all your eggs in that basket.
An example for each scenario
Your pain points won’t necessarily be called out directly in the content (we’ll get to that later). But, the features and benefits you include should show that you solve them.
Snyk, replacing manual research
Snyk plays into the headache of manually staying on top of security news.
This section clearly promises to automate the research away, calling out the issue in the subheading before giving details in both the body copy and imagery.
CircleCI, upgrading from the cheap option
CircleCI need to justify the switch from GitHub Actions, since that is included in their free and starter plans. Despite that CircleCi also has a free tier, they need to show why it’s worth switching.
Their speed comparison is a great way of addressing the pain point of waiting for builds, showing themselves as the better alternative.
While the visual is great, it is a shame that they used the wrong Benefit Layer in the corresponding copy.
Linear, ditching the old default
Linear isn’t solving the generic issue of tracking issues, as existing tools already do that. Instead, they need to solve the frustrations with those alternative trackers.
That’s why their first homepage section is all about improving usability. It’s not just “easy to use”, it has three concrete ways that it overcomes issues around speed and clunky UIs.
You’ve identified pain points, what’s next?
Ok, hopefully you’re now able to go and dive into the pain points! That’s the first step in planning out your messaging. The following steps are:
- Consider if they are aware of or ignoring pain points
- Identify when to use features vs benefits
- Make sure you’ve covered every objection
- Assemble the points into a coherent flow
- Finally create copy and imagery
I cover the rest of this process in my Messaging Guide for DevTools. I hope it proves useful, drop me a message if you have any questions.
For more expert-led content, tune in to our podcast!
Teresa Garanhel
