If you're selling a devtool, and all I'm seeing is features OR benefits in your pitch, and I can't get limitations, tradeoffs, restrictions, drawbacks or any sort of information about the downsides of using that tool... Then it's still a marketing pitch. If it only lists positives and it's not honest about negatives, it's just marketing.
Show me your drawbacks and I might consider you are a serious vendor.
most founders refuse to admit that they're not fit for purpose for some things. yes need to promise the world to VCs but also it makes it harder for the developer to assess how much to trust you if you are in denial about TAM
> any other product from any market openly showing what it can’t do
ChatGPT, ironically enough given how many times I see people insisting that them saying “we can be dangerously wrong don’t rely on us” is some kind of marketing scheme.
To be fair, my argument has nothing to do with devtools, just that the distinction between features and benefits is pointless or is itself a marketing gimmick.
I'll only get to drawbacks/limitations once I get to documentation. And once I spend a significant amount of time researching a product. And when I don't I feel like I'm buying the marketing.
One thing I've consistently had to relearn in developer marketing:
"Talk benefits, not features" doesn't work!
Developers are sick of vague promises and wary of black boxes.
Instead:
- Demo - reach Wow! in <10 mins
- Explain how it works
- Show how real companies use in prod
and that really resonated with folks (heard some really good feedback from senior github people). excited to return to this topic with a better framework (https://pbs.twimg.com/media/F03sDA6agAEBf_M?format=png&name=...) for when to communicate with benefits vs features
But drinks barely have any features you can market. If they do, they're front and center (less sugar or calories, more vitamins or minerals, sparkling or non sparkling)
Same for cigarettes and other similar products.
Some people may prefer the flavor of one product over the other, but at the end, it's purely about lifestyle and the feeling of a brand, and that is shaped by marketing.
So if I create a brand around a drink I can just run a few commercials on TV to associate my brand with something people want (like I don't know, being percieved as sexy by the opposite sex) then I will have a successful business?
It only appears to work if you think that kind of advertising is how they got to their market position. Usually it's not.
Let's Docker for an example.
Docker did not get adoption because of some cliche marketing on their landing page. It got adoption from people doing tech talks and tech demonstrations and several companies writing blog posts about how migrating to Docker saved them from the headaches of deployment they were having before with the ad-hoc systems.
Complex enterprise tech gets sold by other means, usually personal relationships with key decision makers, and maybe some amount of bribery, who knows.
Docker failed to sell its commercial products to enterprises relative to the OSS adoption of its container runtime, at least at the venture scales they committed themselves to
Afaict what was being sold:
* Artifactory (hub): plenty of companies doing fine.. for product different than what docker did
* DC OS (swarm): managed k8s etc doing fine too.. but diff product again
They seemed close to PMF for both... But never quite hit it?
Selling to enterprises is hard.. I'm not sure what the lesson is here beyond git stars not being revenue, nor guaranteeing that it can turn into revenue. Successfully building one thing but selling another means you have to do 2 hard things not just 1.
Maybe a good analogy: Bloomberg has great reporters whose content goes out for free... But that's not what sells the terminal and data feeds
I’ve never sold dev tools, but this resonates with me as a buyer.
The other thing that I want to know, where I’ve had remorse in the past, is how much effort it’s going to be to integrate the tool with my current processes and workflows. I don’t want to change my processes, and I don’t want to find that I cannot get that wow because I’m using this homebuilt process over here or this specific third party tool over there or because we’re migrating to cloud in 3 months.
I don't think this is true... It's more nuanced than this. Developers are much more skeptical of a "benefits" pitch, and care more about a "features" (and limitations as mentioned above) pitch. However, if you're just pitching a developer, you're probably only pitching the user, not the buyer. The buyer VERY much cares about the benefits, otherwise they're not buying. The buyer won't using a single feature, so that type of marketing is lost on them.
This is the challenge: the right message (features or benefits) to the right person (user or buyer) AND at the right time!
Thank you so much for this! This structure is so simple, but super effective in helping me lay out my own thoughts. I'll try this during my next internal presentation. While not a sales pitch, I am trying to get people hooked on a tool I use a lot and really like, but it's so complex that I really struggled to structure my thoughts about why you'd actually want to use it.
This is really resonating with me. As a founder who is currently getting frustrated trying to market a devtool ((https://brisktest.com/) literally a competitor for CircleCI, Github actions etc) it's really hard to talk about the features of the product. It is multiple of times faster than the competitors but nobody believes you when you say that. Developers are so suspicious of something they've never heard about and really reluctant to take a chance even when they are bleeding from the neck. It's a real grind.
> It is multiple of times faster than the competitors but nobody believes you when you say that
I believe that in certain scenarios it will be much faster. But I would have to go evaluate if it works in my specific case and how much effort it would take to move from our current setup to a new platform.
Combine that with the fact that 15 minutes of tests really isn't that bad. I came from the semiconductor industry, where some simulations would take days/weeks, that was a really frustrating feedback loop.
The 15 minutes is only really frustrating in one case, where you are working on one high priority feature/bug fix that needs to be fixed and deployed ASAP. Those 15 minutes can be killer when you've got some bug crashing your server.
Maybe you could monitor incident post-mortems and attempt to sell to those companies. Chances are, in the incident report the time it took for the tests to run will be highlighted.
> Developers are so suspicious of something they've never heard about and really reluctant to take a chance
And that's in big part because they have been burned before. Someone bought a Product[tm] that supposedly Solved[tm] a Problem[tm]. Which then failed miserably to do anything of the sort. Then, to add insult to injury, these same developers are burdened with the need to maintain the expensive and useless thing that they can't get rid of.
If you are trying to sell a devtool, it should have next to zero cognitive burden even in the pathological case. Moreover, you absolutely can not lie, at all, about what your tool does or does not do.
Oh, and once the tool has proven to be useless, ripping it out of the stack should be friction-free. Easy? Hell no. But necessary? Yes.
Cheers, I'm glad my post resonated, although sorry to hear you're in a tough spot!
The bit in your welcome blog about local tests being unfeasible is interesting. Maybe there's a pain point around pushing untested code? Like wasting reviewers time.
Drop me a line if you want to chat it through, sounds like an interesting challenge.
I'm not sure. I think specifically with what I'm doing (making tests fast) there is a kind of a Stockholm syndrome. I've talked to people who say things like "It's fine that my tests take 15 minutes to run, I just check my email, or go for a walk". Or they propose that you don't run the tests or only run part of the tests when you merge.
I know personally that waiting 15 minutes for a test suite to finish is super frustrating, but people seem to have normalized it. I've also literally been hired to speed up people's tests, so it's not a problem that doesn't exist. Our current customers are also delighted with the speedups so I know it's a problem. But explaining that problem and why the status quo is bad to developers is especially hard. Btw I don't buy the "developers are immune to advertising" spiel, I actually created some of CircleCIs first ads so I have experience doing this. I just think developers are different and marketing devtools is different again (because of it's not a personal purchase and there are a lot of different stakeholders).
I hear you, but (devils advocate time) if that 15m delay is not enough for them to open their wallets, then perhaps pivot to a new product.
They probably don't notice that delay, because they are doing something else during that time ... Reading the next ticket, some git admin, replying to an email, checking slack, etc.
As a single example, I don't consider a 15m delay for a full test suite to be a problem. I've got plenty of 5m tasks to do that I can use to fill in that time.
I cannot think of any developer who sits and watches the tests for execute.
For me, it's more than just waiting for the test or doing something else, it's the fact that I need to leave my flow state and keep checking back in on this one task. Merging up from dev to prod is just a sequence of waiting and checking (and doing other tasks). I think it should be as close to instantaneous as possible - and you are always free to check your email then :)
I think some developers don't care, and some developers really really care and I haven't found a good way of partitioning the set and focusing on the developers who care.
It's also a lot about who holds the buying power and what's the incentive. If I'm a developer working for a company, I probably wouldn't bother raising it up to management. Especially when it's tools like this where there are lots of questions to answer: Will it actually be faster? How does it work? Would it be reliable? What's the cost of moving?
The uncertain "faster build time" would be nice. But is it worth raising it up and battling for it? Unlikely.
I think a different case can be made if you target the managers instead. "Make developers twice as productive" might be a better selling point.
I work in an industry that integrates in the CI/CD pipeline in enterprise workflows. Speed is a concern if it really slows things down, but at the end of the day it's not the top concern at all.
Compliance, reporting, scaling with number of projects/growth, interop with existing tools, and lastly a good word from other people in the same industry are what's going go sell your product.
In enterprise CI there are a bunch of other tools you're going to be waiting on, and at least from what I've seen on the field companies will run stuff like SCA/SBOM every build and keep a history graph of when and whom added things. The developer themselves typically does not care for that, but the 'enterprise' does
You need to find the target market where a 15m delay is a pain point i.e. partitioning the set.
I don't personally know of any Devs who consider that a pain point, so it might be a really small target.
Trust me, I am going through the same thing, and I'm constantly questioning whether this yet to be released product has a big enough target market. No good to me if the alpha users comprise the entire target market, so I'm ready to pivot the moment they say "this is great, but we don't have budget/use this less great free thing/can't get approval/will sign up next year/etc".
That's all code for "this isn't a pain point for us."
Product-market-fit is about having the right product. If you consider changing the market I guess this is about PMF, but most people think about PMF as changing the product.
So, I'm trying to find the correct way to market to the developers (and companies) who really need my product.
For what it's worth, it has the core features of all the incumbents, just better. So there is a market (unless none of those companies have reached PMF).
This starts with the assumption that people/devs are oriented towards continuous improvements for all their activities. Which is not always the case in real life. There is a small amount of people who will want this (which on the other hand do other productive stuff in the 15 minutes their tests run). While the majority are just "waiting" for those 15 minutes to have an excuse to do something else.
strange. Do you have any unusual settings around JS ? And what do you mean by "stops working" does it display ? Links don't work? Is this a desktop browser? Sorry for the 100 questions but it will help me get to the bottom of it, I do appreciate the feedback.
I had to re-skim the article a few times before realizing they're talking about "dev tools" not DevTools (i.e. page inspector). I've seen webpages advertise (usually job openings) on DevTools before, now I wonder how effective _that_ strategy is.
> I had to re-skim the article a few times before realizing they're talking about "dev tools" not DevTools (i.e. page inspector). I've seen webpages advertise (usually job openings) on DevTools before, now I wonder how effective _that_ strategy is.
Got me a first round at Google.
Unfortunately for them, I super suck and therefore failed in the first round.
Ain't nobody got time for leet code when they already have a job.
> Candidate disclosed that runtime complexity was 'irrelevant as he had 3YOE in a random web shop' and that we should 'use real technology like NuxtJs'
In my defense, I was more respectful than that.
Also, the "we should use real technology" was my response at Time Magazine, not at Google.
I stand by it.
Server-side javascript (isomorphic javascript) is stupid.
At least try to use typescript or something.
The interviewer clearly agreed with me.
Problem is it was above their pay grade as well.
Show me your drawbacks and I might consider you are a serious vendor.