Read on Twitter
Been thinking a lot recently about developers as a customer and user. How much do they matter?
Obvious for dev tools companies, but most SaaS tools today are at least dev adjacent.
So how should you think about them? Design for them? Market to them?
Some lessons learned!
Obvious for dev tools companies, but most SaaS tools today are at least dev adjacent.
So how should you think about them? Design for them? Market to them?
Some lessons learned!
My company @rainforestqa is a QA platform, and we've grappled with this question for years - a clear and focused ideal customer profile is crucial to thrive.
Are we a developer tool? Kinda. Somewhat. Depends.
My guess is most SaaS platforms will have to deal with this question.
Are we a developer tool? Kinda. Somewhat. Depends.
My guess is most SaaS platforms will have to deal with this question.
We're developer adjacent. Developers are a key user for us. Developers are roughly half of the weekly active users on @rainforestqa.
But we also have very non-technical users that we need to make successful. Designers. PMs. Some QA folks. Support. CS. Founders even!
But we also have very non-technical users that we need to make successful. Designers. PMs. Some QA folks. Support. CS. Founders even!
And so a lot of the traditional developer tools approaches don't make sense for us:
- non-devs need to interact with our core product (testing), so we can't rely on code
- devs don't want to do QA on their side-projects
- the QA team isn't usually a decision-maker
¯\\_(ツ)_/¯
- non-devs need to interact with our core product (testing), so we can't rely on code
- devs don't want to do QA on their side-projects
- the QA team isn't usually a decision-maker
¯\\_(ツ)_/¯
What we realized over time is that developers care A LOT about their workflow speed and focus and they will veto your product if it materially messes with this workflow.
So if your product touches developer workflow in any way, you must focus on not making it bad. (This is hard)
So if your product touches developer workflow in any way, you must focus on not making it bad. (This is hard)
Developers have implicit *veto power* over your product if it touches their workflow.
There is no other role inside a company - except the founders - with this level of power.
It doesn't matter if your end user is not a developer... just if it impacts a developer's workflow.
There is no other role inside a company - except the founders - with this level of power.
It doesn't matter if your end user is not a developer... just if it impacts a developer's workflow.
This can be _super_ hard to diagnose as a cause of churn.
Because you may not think of yourself as a developer company, and your 'core' user may be very successful with your product... yet your retention isn't good enough.
("Good enough" is 150%+ net $ retention <$20mm ARR)
Because you may not think of yourself as a developer company, and your 'core' user may be very successful with your product... yet your retention isn't good enough.
("Good enough" is 150%+ net $ retention <$20mm ARR)
How to make products that are not annoying for developers' workflow?
The only way to truly find out is to ask developers. You have a team of them! Start there. And then coerce some developers at your customers to speak to you.
But here's a few ideas to start...
The only way to truly find out is to ask developers. You have a team of them! Start there. And then coerce some developers at your customers to speak to you.
But here's a few ideas to start...
*Speed matters*
Devs are obsessed with fast workflows. This is for a reason - so they can stay in the flow state. You may not believe it, but writing code is a creative act. If you can avoid breaking their flow state, you can be... not bad.
We're talking seconds, not minutes.
Devs are obsessed with fast workflows. This is for a reason - so they can stay in the flow state. You may not believe it, but writing code is a creative act. If you can avoid breaking their flow state, you can be... not bad.
We're talking seconds, not minutes.
*Documentation matters*
Devs want to solve problems themselves. In general they will play with something to make it work... failing that they will read the docs (no marketing speak!)... failing that they will probably give up.
They will rarely speak to your support or CS.
Devs want to solve problems themselves. In general they will play with something to make it work... failing that they will read the docs (no marketing speak!)... failing that they will probably give up.
They will rarely speak to your support or CS.
*Integrations matter*
Devs want to use your tool within their own workflow, which typically lives on some mixture of their IDE, CI, or company chat.
Building good integrations for whichever makes sense for your tool will help minimize workflow disruption.
Devs want to use your tool within their own workflow, which typically lives on some mixture of their IDE, CI, or company chat.
Building good integrations for whichever makes sense for your tool will help minimize workflow disruption.
*APIs are optimal*
If possible, expose a documented API to your product, and tell your customers. This allows the developers to integrate your product tightly into their workflows, for the tools that you haven't already integrated.
You will be amazed by what they build!
If possible, expose a documented API to your product, and tell your customers. This allows the developers to integrate your product tightly into their workflows, for the tools that you haven't already integrated.
You will be amazed by what they build!
