Experimental Marketing with Natwar Maheshwari

Natwar_220522
===

[00:00:00]

Jack: This is Jack from BitReach and you're listening to Scaling DevTools. The show that investigates how dev tools go from zero to one today's guest is Natwar Maheshwari. Natwar is a developer marketing lead at Algolia and has a ton of experience in developer marketing. Including with MailChimp working on their APIs.

And before that, as an automation engineer, so clearly has a lot of experience on both sides. Natwar it's an absolute pleasure to have you today.

Natwar: Thanks a lot for having me Jack, super happy to be here.

Jack: How do you think we should think about developer marketing when we're just getting started?

Natwar: That's a good question. We have talked about this in the past, but I think at the very beginning, you just have to look at what you think is cool and put it out there. I think, that's the first thing. I learned some amazing things and they don't think like, oh, it's okay.

You know, it's not that great, but for someone in this small. Fricking cool. Right. I think put things out there, the things that you're working on, don't think this is not done. Don't think that, you know, others might not like it. That's not the goal. The goal is to be you at least in the beginning.

I mean, the goal should always be to be you, in the beginning, when you have very limited audience, when you are trying to find your first few customers, Just be you, and be, be very careful about what you read, from traditional marketing places. I'm not saying that wrong. I'm saying that might not work for you. There's a lot of skill that comes into picture when someone took the blog from zero to 1.5 million in 18 months. This is not a skill there that's not mentioned in that blog that you read. To be a little bit careful about that, but at the same time experiments, I think, I think in the beginning, experiments are the only thing that work. Work meaning that will tell you what is, what for you? But a lot of experiments will fail coming from the developer side of the world. If you are yourself, a developer, you're used to doing something it work or not work, and then you troubleshoot it, it's not that fast in marketing. What happens is you do something and then you wait and then you have to just wait.

That's why experimentation is important you need multiple experiments at the same time and figuring out what's working for you. Something that worked for a midsize company or a really big company might or might not work for you, but it's a good place to start thinking in terms of experimentation.

One more thing that I'll say here, your whole team if they're doing cool stuff, put it out there, don't care that or Twitter is not the platform or LinkedIn is not the platform or whatever. It doesn't matter if you're doing cool stuff out there. If you think it was your place, go ahead and do that.

That's fine. If you think, you're doing something that can be used in an open source project and you should use contributors, do that. Right. Think your customer base, which is other, the developers, right? That's why you're building a utility. Would they think this is cool? Right? I think that's a lot and documented process.

I'm very, bad at this. I'm sure Jack, you have struggled with this. We tell people how we reached to a place, even if they have issues with our steps, it's still very, very helpful. And that's something that's seen a lot of people do very well. Again, I don't do this very well, companies like Amazon, right?

I know we all have mixed feelings about that but are certain things there and they just do very well in terms of documentation, off like seven things.

Jack: Just digging in that is there. And the things that we can do to kind of create that experimentational culture.

Natwar: That's an absolutely fair question Jack and it's hard, right? Again, coming from the development side of the world, we'll do certain things in a certain way. And if you're testing certain things, we see results. Even if you're trying a different data VPI for something that you've used different product from the past, you see the result by doing it. This is not going to work for this reason. Or, this is having some issues with other, utilities within my code base, whatever that is. Right. In marketing it's different. So, the mindset has to change. The culture has to be different, I'm going to try this and it's going to take time and that's okay.

Telling yourself that, telling your team that, that it's okay. That this thing will take time. Marketing takes time, a brand building trust in the ecosystem that these things take time. So, in terms of experimentation, have a very good part around what it looks good and what looks bad.

We can get lost in analysis paralysis. We have all the tools in the world to capture data, to capture clicks, to capture scrolls today, you can be captured. Everything is not product these days. So get lost in analysis paralysis,

Because it's a lot of fun too if you've implemented things like Mixpanel or segment or GA for that matter. It's a lot of fun to just spend a ton of time there and drive insights from it. But I would say like in the beginning 80, 20 rule works really, really well. 20% of your work will give you 80% of the insights. The goal should be to get those and move on to the same experiment or so for an experiment, you have to be clear on what you're trying to do. What does good look like and what does bad look like? You'd need to define, when will you stop doing this? But me saying that statement, right?

I have assumed a lot, for example, if you're running an SEO experiment, right? If you're saying that you, what, I'm going to write this 2000 word blog post about X, Y, or Z Viking on Google with search engine optimization time. So let's say you have to have that knowledge. That's what I assumed.

You have to have that knowledge, that things, certain things take time. Your redirects. No, they don't take time, but will looking for something and ranking it. That takes time. Having that basic knowledge of what things take time and what doesn't is very helpful. I would say if you can, like, in past, when I was an entrepreneur, I had a bunch of entrepreneurs or a bunch of founders.

We had a group where we'll talk about these random things to each other, I did like two experiments. Products and Mixpanel and someone is doing something else and we'll learn from each other. If you have other developers that you can talk to about these things, it's very, very helpful because I know especially around like our community right? The tons of people who have done this, have been doing it for some time. They'll at least help you. Hey, you know what, if you're doing this, this is going to take time and it's okay. If you're trying to do something, let's say, copy changes on a website. That's technically a marketing experiment, right? That will be depending on how much traffic you get, much net new traffic you've got because someone who visited that site before yesterday is not going to show up to there just because you change the copy. Right. That's what will happen unless you're running retargeting ads, which I'm guessing you're not. So having that basic understanding is helpful in terms of experimentation, but really it's be comfortable cutting your losses and coming back to it today, you have domain authority of 20 and a year. Your domain authority will be sufficient. Yeah, that same experiment made work later on.

Having that cadence of, okay, I'm going to look at the backlog of my experiments and see what else can I kind of pick it up as things have changed? I've kind of gotten all over the place on this, Jack, does this make sense?

Jack: It makes sense. I feel like one of the key points you're saying is not being afraid to do things that you don't have a lot of knowledge on and try them out just because they seem like a good idea. But also try to get at least a little bit of expertise thrown in there so that you're not for instance, doing an SEO experiment over 24 hours and expecting see some results.

Natwar: Absolutely. You put it in a much better way than I did, man. Yeah. Doing like one-on-ones of basic concepts around marketing is very helpful. So for example, brand marketing, It's very hard and it take some talent times, so you can read about it a little bit and decide you're not doing this.

I'm not ready for this, right. SEO. You can read about it four to eight hours and say, worth doing it because it gives me sustainable traffic or consistent traffic over a longer period of time. And you get to pick and choose that partnership, that's another way of marketing.

If you think about kind of, you know, partnering with other people who have bigger audience than yours, because you have better tools, better cooler product, whatever. Figuring those pieces out because marketing , you can do a hundred thousand things and start a joke. You can actually do so many things, but you have to pick your own things depending on your skillset, depending on what you're trying.

Jack: I really like this. There is no specific playbook that's going to work for you. And your goal at the beginning is to just figure. What things could work for you. And there's not really any expert out there that can tell you what will work for you. You just have to keep trying different things.

Natwar: Yes, 100%. If you can find the developer founders or marketers, if you're finding a decent one, they'll tell you that they don't know a lot and they'll tell you that. I don't know if this will work for you or not, because there's so many reasons for something to work and something to not work.

It's, mind-boggling things that we don't think about. Right now I struggle with things like preconceived notions about a brand. Let's say you have used my product in the past, or you're seen the logo in the past, I don't know in what context have you seen it? Have you seen it on the open source products or have you seen it on a website which you hated? There are so many things, there are so many reasons behind why some things work and why some things don't. All I would say is work with someone who has done things and is comfortable saying, I don't know. , and because you don't because you also don't know.

I think having a peer group is very, very helpful. I'm not talking about like consultants or whatever, but having peer groups is super helpful.

Jack: One of the things you mentioned in there was about brand. Algolia has a very good brand. I use Algolia it's great. I only hear good things about it, but when you're experimenting with different things, does that play into brand building as well?

Natwar: It definitely does. And it's a very, very important piece of the puzzle. Especially if you're trying to build a product for developers, that the trust that brand is that trust, like trust of what trust of the fact that they're not going away tomorrow, to the fact that the things will work the way that they said it works. Just to behind the fact that I'm not going to take and sell your data, trust behind the fact that if I'm giving you an, a rapper or a library, first to find it and I'd break down if it breaks down, I'm sitting behind it, that support behind it.

Trust is not just this one thing, trust is a lot, a bunch of things, around. Are they going to be around for five years? Because there are certain products that we take and then we put into us. And to rip them out, it's going to be a lot of work. So like trust around that.

Which brand comes into everything? And if I am not consistent, if we, as a company are not consistent around saying, you know, we stand behind. Then it's going to be very, very hard for someone to say, pick, something, and use, if you are a lot of my guesses, a lot of your listeners have been into, into companies where they were part of like B2B sales cycles [00:11:00] on either side of the table.

They used to be saying this, they're saying nobody gets fired for buying an IBM. That's an old saying like an IDs thing. The point being IBM has such a strong brand that even if everything that you implemented failed, you're not going to get fired. So it's companies which were competing with them.

That's what they're competing against. That's where a brand comes into the picture. It might not be very relevant to develop on utilities and developers. But it's important because someone who's going to buy your product, your tool, or when get into the ecosystem of their own world is putting their own, reputation on the line.

I don't think anyone's going to get fired point being they're still putting their reputation on the line. That's why trust is very, very important. being honest, being you. Being you and being honest about what you are and what you're not. Is very, very helpful because you don't have to remember a lot of things because you're just you. I know it's very, very easy to say this than to do it.

Jack: I love the way you kind of articulated, especially the point around, being painful to rip out if they go broke or, you know, something bad happens. When we talk about experimentation, is it experimenting within constraints? How would you describe the kind of process? Cause it sounds like you're doing that.

Natwar: Experimentation at different stages of our products of our brands different. A small curated newsletter site called engineering. The experience that I do, there are very simple, are very clean because of two reasons. One is I don't have a lot of time because I have a full-time job as well. And second is wanted to keep it simple until make, when I started and do this a lot, let me just start curating and that's it, like, that's how it started. So that context is that I'm not trying to make money off of it or anything like that. , so that's there, but if you're running an experiment on Algolia.

We use a proper product for an AB test, for example, right now, AB tests only work if you have enough traffic, otherwise, it's never going to be statistically significant. That's a constraint. When I used, in my own startup, I used to run an AB test and it used to be useless because I had 125 visitors on the website every day, even after the month, I will not have a decent kind of, data, on what copies working. What's not. Understanding that. In terms of criteria, when you're thinking about your experimentation, be very clear about what you have and what you don't have being brutally honest, there is helpful.

For engineering group, if you go there, right now. The text box where the email is even supposed to be. It's automatically selected. It's a really small tiny thing. Someone else did it. It was not my idea.

I looked at it, I went to that website. Yeah, I'm going to subscribe. I might consider was just there. Like it's, me, nothing if you think about it, but that's a small thing. I saw my own behaviour and I'm like, okay.

And I implemented it here. To be brutally honest with you. I don't know how my site would react or this engineering group would react if it was not there because I'd not run an expert. I see something I'm like, cool. I'm going to use it. And I used it. So sometimes you just see something like, that's pretty cool.

I think earlier when we were talking about, for example, strive documentation, you see something in the world that is definitely like, great. And like someone else is doing. Don't feel bad about copying it, especially around marketing? Strive documentation. If you're logged in right there, you don't have to copy paste your staging API keys.

It's a smaller thing again, did it, I think seven, eight years ago, something like that, it's been a while. You see something like this, use it. There is nothing wrong with that. And one might think that that's not a marketing tactic or a marketing thing, but in my opinion, that is right. Because even right now, 90% of the API documentation don't do that. So people will remember you, that's, trust that's brand building. That's that one thing that people like that was cool, man. I'm going to remember that.

Jack: Natwar. We are very, unfortunately out of time. That was very, very interesting. If people want to hear more, where can they find out stuff?

Natwar: You can follow me at N a T w E R 86, that's my Twitter handle. I work at Algolia. We are a search and discovery API company, any time that you see a website search it's powered by something? A lot of times it's powered by Algolia, super, super happy to be here.

We do a lot of work with front-end and back-end and we have a lot of utilities and a lot of things. Are open-source that an Ivan and whatnot. Other than that, I run a small newsletter called engineering brew. you can find it at engineering, blue.com and it's a curated, engineering blogs.

I like to read and, and distribute them as I'm reading them. And then I send out a newsletter and whatnot around that

Jack: Thanks for listening to Scaling DevTools. If you enjoyed this, we also have a newsletter on all things, DevTools at BitReach.io, please sign up and, we'll see you soon.