Oh no, don't look - it's Developer Marketing
How we went to WeAreDevelopers Berlin, and scanned zero badges.
Hey! Daniel here with another digest 🌈
Before I get into it - we just launched our latest feature, Permit Share-If, on Product Hunt. If you can give us your support there, it would mean the world to me ❤️
Now, the avid readers of this newsletter (Hi Mom) would have noticed that we were a few days late -
That’s because we were at WeAreDevelopers Berlin, and I had absolutely zero time to write this between explaining what Permit.io is and handing out socks.
But that’s actually a good segway to this week’s topic - let’s talk about Developer Marketing.
More specifically, Dev Marketing vs. Dev Engagement.
Wait. Don’t go. I know that you, as the developer reading this, are as allergic to the word “marketing” as I am to sunlight and touching grass. But bear with me just a moment. You might find it more interesting than you might think (Or at least stay for the memes).
We Know Better Than You.
Marketing to developers is one hell of a challenge. Mainly because it is, in a lot of ways, completely different from classic marketing strategies.
The usual approach when it comes to marketing is usually along the lines of “This is frustrating (Because you suck at this). Let us take care of this for you (Because we are great at this).” Take the classic Old Spice commercial:
What’s the take here? “You are doing a bad job at selecting your products. Old Spice does it well, ensuring you'll smell fantastic”.
Now take this into the developer tool space. Try and tell developers that they suck at what they do, and they should listen to you when it comes to how their software should be built. Also, please do it on Reddit from a company account, and send me pics.
Marketing to developers means being connected to the developer community. (Yes, also on Reddit). You need to feel its frustrations, see what it loves, and laugh at its jokes.
If you do that, a really cool thing happens - you won’t need to write any sort of “messaging” to promote your product. If you are solving a real problem that developers are struggling with, the message is already out there - you just have to listen.
When you start channeling the real struggles and frustrations the developer community is facing, it’s going to be the community itself that helps your message resonate. You won’t have to convince anyone that the problem is real - it will be up to you to offer a solution.
In general marketing, your biggest competitor is another company that does something similar to you. In developer marketing, your biggest competitor is someone building the same thing as you are in the confines of their comfy living room. If you bash their approach and say it’s bad, you’re doing nothing more than to feed resentment.
Oh, I can’t build this myself? YOU know better than me? Watch me.
How do you fight this? You don’t. You suggest alternatives to people who don’t want to build it themselves, and you stand behind those who do and offer them help through engaging content. They’ll know where to find you if they decide they need you—and they’ll appreciate you more at this point.
Developer Conferences
This mindset also has a major impact in the context of developer conferences and what you expect to achieve from them.
You can, of course, put up a booth at a conference, pitch your product to whoever’s asking, scan a couple of hundred badges, and go home happy, expecting to have won the hearts and minds of developers all over the globe.
This mindset is often the result of us expecting to stumble upon the perfect persona who is in the precise mindset of instantly falling in love with our product, integrating it, and throwing as much money at us as it takes.
We do have this persona in mind, but we also understand that it takes a lot of time, effort, investment, and sometimes pure circumstances that don’t depend on us for a developer to get to that point.
This is why we try not to build our entire marketing presence to pander to that specific unicorn of a persona. Instead, we try to build a funnel that allows every developer attending the conference to gradually engage, on the level that fits them, with us, our community, and, eventually, our product.
We try to make it so every type of engagement for developers with us has mutual value. From grabbing a sticker or pair of socks at our booth to someone not laughing at a joke that I made during my pitch of the product, to people watching our livestreams, contributing to our open source, or being full-time clients of Permit - all these interactions teach us something and gives value back to the developer community (Well maybe not the joke one, that’s just for me - but you get my drift). This is what drives our marketing.
Check out the socks by Premium Socks Factory! How good are those??
And it helps that we don’t have the delusion that every person taking a sticker from our booth, reading our blog, or reading this newsletter will eventually become a Permit customer. We also don’t put this expectation on their shoulders - which people usually appreciate.
I’ve seen the sigh of relief when people ask me, “Do you want to scan my badge?” and I ask, “Why?”
But what does this have to do with Authorization?
We also implement this approach when it comes to our product.
Some people only use Permit to synchronize policies with a policy engine—they write all the policies themselves and don’t want us to generate code for them. Some use Permit’s Authorization Audit Logging feature - they have their own authorization system in place, but they didn’t want to build an auditing solution for it from scratch. Some only use Permit to configure policies but handle their own enforcement.
The point is - we don’t care. We want to give our users the freedom to adopt any part of the Permit they feel helps them the most without forcing them to adopt features they don’t feel like they need.
Sometimes these features can feel like small things that shouldn’t take long to implement, especially if you’ve started building something yourself, but between development, backend, frontend, processes, and approvals, you end up realizing that you’ve just spent a good portion of your quarter building a system just for it to look like a million other systems you’ve seen before. And you did it instead of building the cool and unique features of your application. And that sucks.
Not re-building something you’ve seen a million times before.
That brings me to our latest feature we're announcing today - Permit Share-If.
Watch the ad Filip and I made for this - it’s a doozy:
It’s a suite of prebuilt, embeddable UI components that make access sharing in applications much easier. Designed to provide fully functional access control, they make delegating permission management to your users simple and safe.
These components include Access Request, Operation Approval, and Approval Management.
Again, if you feel like it, please give us an upvote on ProductHunt so we can help make more developers aware this exists.
That was a long one. Thanks for sticking with me all the way to the end ❤️
Until next time,
Daniel