Selling to Developers: Ten Lessons Learned
Selling to Developers: Ten Lessons Learned
Discuss this article or ask questions of your own for Povilas Korop.
Selling to Developers: Ten Lessons Learned
Discuss this article or ask questions of your own for Povilas Korop.
Thanks for writing this, it's filled with actionable suggestions for selling to developers and gets straight to the point.
I'm a developer selling to other developers as well and it's not easy
It's a totally different ball game. So much so that people have built entire businesses around how you can approach selling to developers (HeavyBit and Justin Jackson's Marketing for Developers)
One thing that's always been a little bit difficult for me is shifting gears from developer to marketer. There is always so much dev work to be done that it's easy to spend the entire time building and no time on marketing.
So far, the best solution I've come up with is to make sure I start with marketing (or any other administrative type work) and then finish with developing. Trying to do it the other way around just doesn't seem to work for me - it's easier to switch into developer mode than out.
Does anyone have any suggestions/techniques for balancing different roles and handling that context switch effectively?
Just dropping in to say: thanks for getting https://devmarketing.xyz @benm! Really appreciate it.
For me I've been in progress of switching the roles for a while now - I have an in-house team of developers, and for client work we divide the work depending on the project. And my goal is to do as little coding as possible, cause money actually come not from coding, rather from finding customers. Every time I remember that, it makes me close PHPStorm and open something related to marketing or finding clients.
Inspiring article, thanks Povilas!
I'm also targeting developers, so it really resonated with me. Especially "Obstacle 1. Developers love to write code, not buy code" - they sometimes become irrational that spending $50 a year for a solution is worth spending hours and days writing the code themselves. Because they enjoy it.
The result is higher price sensitivity, so I'm curious - I read that you raised the price from $30 to $100, how did it work out?
Thanks @dsvb for giving the article and answering before I did :)
Yes, Kenn, it worked out really well for us, but before the raise and release of Agency plan I had no idea if it would work out. Was kinda scared that no one would buy and we would go bankrupt. But people saw value, that's the most important point.
I guess the overall conclusion is that your price is irrelevant if it saves/earns more money to the client. In our case - our tool saves hours/days of dev time on the CRUD things they actually HATE doing time after time, so $100/200 for a year (unlimited projects!) is almost a no-brainer for "Western" world with bigger hourly rates.
Thanks @PovilasKorop!
Maybe the most important question: Do you think the fact that you started at a lower price point, helped?
Because if you started with $1000/year, you were probably unable to have enough data to validate the market, or could have failed, even. By starting low, you have more chances to probe marketability of the product, then have room to raise the price afterward as you grow aligned with increased value - increased brand, increased features, etc. - so I'm coming to think the common advice "always raise the price" can be misleading for a fresh new project, as if you should have started with a higher price point.
What do you think?
As always, the answer is "it depends". You cannot charge more upfront just because you want to charge more, you need to deliver value. So in the beginning with only simple CRUD generator we couldn't (or we scared) to charge more, and also we were trying to just charge anything at first - to see if someone would pay for that, cause the biggest price barrier is between 0.00 and 0.01.
Then we grew and that price increase came mostly from our expenses - more customer support, more features demanded, but also customers pushed us to charge more cause they wanted faster turnaround and bigger value.
So there were a few gradual increases, and maybe the current one isn't the last if we come up with some other model like offering hosting/deployment solutions or something.
In general, I am a fan of delivering value first and then raise prices. Of course, there's a chance that by having lower price you get into wrong market segment, and "big guys" don't even look at you, so sometimes the price is just ridiculously too low, so be careful with that.
Again, fantastic answer! 💯
Maybe I'm on the rare side that raising prices didn't work well. On the bright side, I'll have more to tell in the future!
Maybe it's because you JUST raised the prices and didn't deliver more value with it? Or maybe you have cheaper competitors? Hundreds of reasons could be there.
Yeah true.
In my case, we have some (more expensive) competitors, but they are not recognized much either.
But (perceived as) cheaper solutions do exist, it's custom coding with a free tool like mysqldump or pg_dump. So back to your point "Obstacle 1. Developers love to write code, not buy code." as this comment on IH typically shows.
It did work out for them pretty well: https://medium.com/successful-it-projects/how-we-raised-prices-3x-twice-and-got-happy-customers-a12f0b9ec6d6
Thanks for the link! It's a great read as well!
Man, this is one of the best articles I've read about selling to developers. With my project backtrac.io I am really suffering with selling. Will need to revisit every single point you've raised. Probably will reach out to you personally some time later. Thank you!
Thanks Povilas for great insights into developer's mind, Early I used to launch the lite version in some market places like Codecanyon, then introduce premium version, but all are general scripts not for developers.Anyway thanks for your actionable steps, I'll check your admin panel.