This Common Mistake Causes Most Developer Tools to Fail.
I used to believe that building a successful developer tool was relatively straightforward. Build a product that makes your customer’s life easier. Reduce friction in the integration phase. Watch success happen. That is intuitive. It’s what everyone is doing. And it’s also completely wrong.
The truth is that this is backward. Building a successful developer tool is counterintuitive, and to succeed you’ll need to take the opposite approach. You may find it hard to believe, but you will need to Cause Your Customer Pain.
By the end of the article, you’ll understand why most developer tool products are built backward and you will have a new way to think about building them.
Through this article, I’ll walk through some of the challenges you could face if you were designing a code linting tool. The same challenges will apply to any developer tool. Instead of focusing on feature functionality, the goal of this post is to start with the customer and work backward.
Here’s how it is…
Developer tools are hard. Friction is unavoidable. Even for a relatively simple product.
I’d argue that most linting tools are relatively simple products, too. If you were trying to drive adoption of a code linting tool, like ESLint, you’d likely face a lot of pushback, too.
The goal of this article is to learn how to think about a code linter like our customer. Once we understand how they think about our tool, we can help them think about it in a way that would help persuade them to use the tool.
After learning about what aspects of the product can help us drive adoption, we can think about how we can design a product around the things they care about.
Let me guide you to where your customer is thinking with this question.
Ever notice how when you integrate with a linter in your codebase all it does it complain to change your code?
A code linter adds friction to the developer process. It adds an additional step in an engineering workflow. It stops you from shipping code if it doesn’t meet an arbitrary ruleset. And it’s the perfect example to think about if you’re trying to build a tool that requires developer adoption.
Why do people use tools like ESlint at all? On the surface, it looks like it only makes work harder to do. Here’s a list of completely valid reasons you could choose to ignore if you were trying to convince someone to use your linting tool.
- It takes time to install and configure
- The tool itself doesn’t add any functionality to your application
- Once installed, it highlights all the problems in your application
- You’ll need to do a major comb through your application to fix the problems upfront
- Following that, every change you’ll make moving forward will require you to be vigilant to pay attention to the output
Despite all of these reasons a lot of people are using this tool.
Why would anyone opt into that type of problem?
If we can clearly communicate the value our product has to our customer, we can design our product around what they care about.
If we are unable to communicate the value our product has to a customer everything from feature design to prioritization will only be possible through one strategy: guessing.
What would a developer value in a developer tool?
The Value Proposition you share with your customer helps them understand what you get if you use this product.
It would be intuitive to tell the developer what the product does, so let’s start there.
Selling the Features
Let’s take our linter example again. Here are some facts about ESLint that I just made up right now. They may be true, but for the sake of this article let’s pretend they’re true.
- Our linter tool is compatible with the new es2085 syntax.
- Our linter runs 85% faster than the fastest alternative.
- Our linter includes checks for a whole new variety of problems you may have not even considered.
Sounds good, right?
If you’re experienced in sales or marketing you probably see the problem here. This messaging is promoting a feature, it’s not promoting the benefit.
In short: describing a feature is talking about the tool from the perspective of the technology.
It answers the question how is this product the best? If you’re on the market for a new linter tool, these reasons will resonate and be extremely persuasive.
The problem is that if a developer isn’t actively comparing different linting tools, no features or functionality of our product could genuinely interest a user with this mindset.
In short: A potential customer probably won’t care. They will likely think something along the lines of this when you tell them:
“Sounds neat, I’m sure someone could like it. I just don’t need it.”
There’s a place for sharing the features of a product, but it can’t be the first thing you share.
Selling the Benefit
Let’s step up our game with this linter example. I think most of these details should be accurate based on my knowledge of ESLint.
- Our linter tool will help you write better code.
- It will make it easier to collaborate with your teammates.
Sounds better, right?
Sharing the benefits of the product with the customer helps them understand what will this product do for me?
Most engineers will want to write better code. Making collaboration easier sounds good too. Selling the benefits will pique a user’s curiosity, even if they aren’t in-market for the tool you’re offering.
Curiosity will take most customers up to the first obstacle. Unfortunately, they’ll usually give up at the first sign of resistance. Or they’ll forget about it because they’ll focus on something else.
The Status Quo: Your Worst Nightmare
The status quo is great for your customer and it’s your worst nightmare. Your customer probably thinks it’s served them well so far, and because of that, they don’t have a big motivation to change.
In the case of ESLint for example, most developers like the idea of standardization, assuming you’re standardizing around how they like to do it. It wouldn’t be crazy to find a developer who liked most of the standards but wanted to do it differently in just a few cases.
“That works great for other people. My code is different.”
– Almost Every Developer
I have a feeling at least once a team has started to migrate to a linting system, the conversation devolved into a complete waste of time about trivial details, and the project was scrapped.
That brings us to the cornerstone of solution selling:
No pain, no change.
People are happy with the status quo. If you’re trying to drive adoption of your developer tool, if you’re not pushing your customer towards pain, they’ll stop at the first sign of resistance.
Selling the Problem
The problem that your customer has will give them the motivation to work through obstacles, challenges and implement your solution. When you’re designing your product, you need to build it around a problem the customer has and make it as big as possible.
It’s your job to help the customer realize how the status quo is a major problem that is wasting their time, hurting their career, and costing their company money. A lot of it.
Talking about the customer’s problem isn’t complaining. It’s helping people realize how unsustainable the status quo is.
JavaScript: Their Worst Nightmare
Let’s return to our linter example. Talking about the benefits of using linters might not justify the amount of work required to implement a feature like this. The problems linters solve, however, could be the trick.
In “JavaScript the Good Parts,” it has a section called “JavaScript the Bad Parts,” where it outlines all the problems in the language. This could be a good place to start. One clear example is the difference between double equals and triple equals:
1 === '1'; // false
1 == '1'; // trueThis is a cause of major problems in a lot of applications in the real world.
If you were looking to convince a team about the need for a linter, talking about this problem could be helpful. More powerful still, would be to find a few major problems in their codebase where this mistake caused problems.
- How do you prevent these types of problems, today?
- What if a bug in this type of logic happened in the critical flow of the application?
- When was the last time your application went down because of bugs that were shipped?
- What’s the impact of these problems?
- What does your manager think about them?
- How do these problems impact your business?
Helping the customer focus on the answers to these questions will help them focus on how unsustainable it is to not use a linter in their code.
Since I don’t have access to your codebase, now, we can focus on the problem that linters solve in a different way.
Watch this whole video right now. It’s 4 minutes long. It’s completely different than you’re expecting and 100% worth every minute. I promise.
Watch: Gary Bernhardt’s WAT video
I used to think that programming languages were intuitive and easy to reason about. This video destroys that perspective. If anyone tells you that programming languages are simple to reason about and linters are only for rookies, maybe you can ask them this question for me:
Wat?
Now, ES6 has fixed a lot of problems and linters don’t solve all problems that exist in languages, but if you could solve large categories of them, do you think they would make sense to?
How do you build up pain?
That’s the secret with regards to the developer tool you’re building. You probably don’t have a short 4-minute video that you can link to that will do just that, but there are systems and formulas you can use to do it at scale.
Your product needs to be built on top of a problem you can develop for your customer. When discussing your solution, you need to put the problem first.
I’m planning to write about those later, so subscribe to my newsletter if you’d be interested in diving deeper on this topic. If you don’t want to I completely understand.
Pulling it all together
As an engineer, it’s intuitive to think about the technology you’re building, first. Then thinking about your customer second. This is how this article was written, to be intuitive to understand.
Most people think about things in this order when they’re thinking about building technology: the technology that is built, the user’s outcome, and the problems that the solution solves (in that order).
This order is layered backward when putting the customer first.
Instead, you need to build it in the opposite way. Start with the problem, layer on the benefits, then talk about the features. The problem you’re solving for the user needs to be at the foundation of everything.
Here’s a strategy you could communicate about a linter if you wanted to convince a developer to try a new linting tool.
A few example questions…
To apply these principles on a sales call with a potential customer, you could start where they are with the problem and learn more about their situation and needs before diving into the feature functionality of your problem.
These questions frequently span multiple conversations, but these can give you an idea of where to start.
Build the Problem
Did you know double equals is different than triple equals in JavaScript? Why do you think that is? Do you think it matters?
When was the last time your application went down because of bugs that were shipped?
Benefits
Do you think it’s important to have consistency in your codebase? Why?
Have you ever shipped bugs in your application because of consistency issues?
How do you collaborate with other engineers on your project who have a different personal coding style than you? Would it be helpful if you coded in the same way? How come?
Why do you think people use linters?
Features
Our linter tool is compatible with the new es2085 syntax.
Our linter runs 85% faster than the fastest alternative.
Our linter includes checks for a whole new variety of problems you may have not even considered.
If you started a conversation with a potential customer and explored the implications of each of these questions, they would start to think about the problem in the same way as you: important.
I’ll unpack strategies for building up need in future articles.
How do you design a developer tool product?
The most common mistake that developer tools make is that they work from the technology to the user. By understanding how your user thinks, you’ll be able to understand what they value.
As a product designer, you’ll need to first understand the problems the user is facing. If your product is a viable solution to their problem and it will make their life better, they’ll be willing to change their workflow to adopt your product.
The things you need to prioritize are the things that will make your tool a credible solution to their problem.
This is more important than prioritizing feature functionality because those details will only matter for users who have already decided to implement a solution like your tool.
