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.
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).