Ask HN: What's the best way to get developers to try a new devtool?

Perhaps your friends interviewed potential customers (i.e buyers not just users) and arrived at marketing it as a dev tool for dev teams...

In my opinion - I'm not so sure if the product should be marketed to "dev teams" per se! To me it looks like a collaboration tool around product development... not just for developers.

I would think the primary buyer would be PMs (Product / Project Managers) who would then push for the tool-use onto the dev teams as a way to improve collaboration and close the feedback-loop across all stakeholders (design, marketing etc). Yes, for that to be a success it requires devs to love it and indeed make thier job easier, but I don't think they're the primary buyers. Developers, in general, are notoriously hard to sell to because they filter out marketing jargon!

Speak in terms of benefits, not features. No cares about features. They care about themselves. "What's in it for me?" we all subconsciously ask ourselves. Benefits answer that question.

After that, make it super-simple to try out. The more friction, the less traction. Ironic, huh.

I would suggest that they develop and use the tools themselves. There won't be any better and diligent testers. Once customers join in they would have zillion of requests/ideas and then they have to sort between all of them to keep the product sound.

Of the two options, I prefer to start here — https://livecycle.io/

I'll have a look at a tool if:

1. What is does blows my mind and/or it think it might change the world.

2. I'm super curious about how it works (the technology behind the tool).

3. I think that today or sometime in the next 12 months the tool will help me get shit done.

For example, not one hour ago I was blown away by the potential of WasmEdge (https://news.ycombinator.com/item?id=33792322). Already downloaded it and run its Hello World program.

It has to be a lot better than what I'm using right now or give me a clear capability that nothing else has. There's that term, "There's no silver bullet" and that makes some people skeptical of the next best tool. It hurts if the learning curve is too long and good documentation/tutorials can help. Another consideration is if it comes out as a competitor to other tools in its class (e.g. UI Component libraries) during a version upgrade or when starting a new project, which is when I would evaluate which tools to use for the project.

How cane you expect someone willing to try your new thing if it’s not even clear from your website what is this thing even doing exactly?

I think if you just put more focus on what people get out of it, it will work. Engineers just don't like BS, so if you beat too much around the bush they just won't try it because you're selling too hard. IMO it looks very cool, I'll check it out over the weekend. If I can make my designer use it :)

I know the product and it’s a real gem. There are some cool use cases for this that I think can be showed off more. As a FE engineer I spend a lot of time being reviewed and having cycles of design and UX fixes and touch ups, doing this quicker and more accurately is valuable, maybe it’s possible to emphasize it more?

Write excellent documentation, with simple, interactive examples showing the value of the tool.

I can't tell what your service does. The website could use more clarity, maybe a few bullet points with precise screenshots or short animations instead of videos.

My team works remotely and it's actually looks like it could be valuable to us.

Like others have said, I'd suggest to polish the messages on the marketing site

I watched the video. The idea is quite good. I would skip all the talk and just demo the product to see if people like it... show , not tell!

search engine term "beta testing case studies", "finding beta testers", ""beta tester resources"" brings up a variety of possible concepts/sources.

Hire someone with sales/marketing experience, ASAP.

What type(s) of dev teams? sales, marketing, etc. Ah, ok end of 2nd sentence -> developers.

Why would someone develop NEW SDK for a 80's c64 commodore for sale reps when current stuff is supported/understood by by both in-house IT, sales reps and management.