Developer Marketing at Postman

Adam: Welcome to Developer Marketing Stories. I'm Adam DuVander.

Matthew: And I'm Matthew Revell. And in this episode we're speaking to Kasey Byrne, who was the first marketing hire at NPM and also was heading up marketing at Postman at a really crucial time in its history. Today, Kasey works with early stage startups to advise them on marketing.

Adam: And Matthew, one of the things that Kasey talked a lot about in our conversation is marketers getting into that developer mindset. And if you're listing to this or at the end of this, when you realise that you need some help with that, you can go to developer marketing, which is the coaching and training programme that Matthew and I are running. And we will help you to be able to identify those areas and frameworks to be able to really get inside the developer mindset. So again, check that out at developer marketing. And now let's get to the conversation with Kasey.

Matthew: Hey Kasey. So welcome to Developer Marketing Stories.

Adam: Thanks.

Matthew: You were VP of marketing at Postman in a really interesting time for that company, and even today people who were original users of the Postman Chrome plugin are somewhat salty at times about what happened as it grew into this whole other product. What was it like heading up marketing at a time when a beloved developer tool was going through such a big change?

Kasey: Yeah, I think that's an interesting question because from the inside perspective at Postman, I think the vision had always been to create an extensive platform for APIs, always developer focused, but very much the Chrome plugin was the beginning of a journey to what was in the founder's and Abinov mind, although you can't speak to that his mind necessarily, but from inside the company there were just a hundred things on the to-do list to add to the product based on customer feedback and the usage that the folks within the company had created. The Chrome plugin was eventually, if I recall correctly, was eventually sunsetted because the format just didn't support the extensive things that were being added to the desktop app, I think. But I think from your perspective in selling a product that people beloved so much for free at the time, we got a lot of just love from the community, which was I love the free tool, and I bet if I paid, I think it was five or $6 a user a month at the time, I bet there's something in the paid version that I would use too.

And when you come to a developer tool that's at that price point per user, that's usage based, and particularly as we added additional features, it was a very easy decision, particularly if you used more than just if you were more than what I used to call the 5% user. If you were a 5% user of Postman, the Chrome plugin probably would have always been what you wanted and you didn't need anything else if you were a 95% user of Postman features. Even after when I joined the Chrome plugin was out and that was about it, and then maybe a couple months later we started to the desktop app and all of its features began to grow, and then eventually, maybe a year later, we sunsetted the Chrome, I think. But if you were a 95% user of even just the five or six features that were out, the paid version made complete sense to you because you used those features, you either liked them or didn't like them, and you probably wanted more if you liked them.

So the goal in marketing was to get you from a 5% user to a 95% user. That was it. Because once you got to an 95% user, either you needed it honestly or you didn't, and there were enough people in that pipeline that if you got all of them kind of along the journey, then the paid product made a lot of sense. I can see your point though. I haven't heard that before. I have, but I guess I didn't understand it until you just said it, that for the 5% user, the rest of that was just probably kind of annoying. That's what you're saying. If all you wanted to do was send a request, get a response, make sure that the API worked and then go back to what you were doing, then all the rest of the stuff just wasn't, was just overhead.

And I suppose having to get an account and create a collection and download the desktop app was a burden, whereas if you used any of the rest of them, it was the environment that made all of that possible.

Adam: Probably because you already had some of those things. You had that account set up because you needed that to save the collections or

Kasey: Right, right, exactly. Or you needed the environment allowed you to do code snippets and you use those regularly or you use the platform to do small bits of programming. If you were hitting a series of APIs or you wrote collections, because plugging into Postman to run automated testing was part of your workflow and it needed to live somewhere. But the marketing challenge was great because I tell people that when you're marketing to developers, that the thing going through your mind, the thing on your mind, if I was trying to sell you a car, the thing going through your mind, my mind would be buy this car and I'll have money. That's the marketing story. Buy this car, buy this car, I'll have money. But the marketing story, if you're trying to get a user from a 5% free user to a 95% free user is use this free tool and you'll get to build something really cool. And that's a totally different energy and so much more fun from a marketing standpoint, we had a great free tool.

It did a lot of stuff and in an area that developers consistently expressed pain, you mentioned Curl earlier, that's what Abinov has quoted as saying a number of times, which is he created Postman because he couldn't stand Curl and I'm with him, right?

So the marketing is really fun when you get to do that because it's about usage and it's about building something cool and it's about helping out the developer if they can. And then there's the last 10% is, and if you want more of it, we have a paid plan. And that's just a completely understandable thing.

Matthew: So that's kind of the crux of this is, and just to be clear, I've met lots of developers who absolutely love Postman as it is today, as well as those who for a while pint for the old version. But the really interesting question I think is you have this user base of people who are using a free tool and you want to convert some percentage of them into paying customers. But I think I saw a talk once where someone said, how do you convert your free customers without being creepy? And there is this sense that it becomes a bit icky and you can really do it in the wrong way. So what are some of the principles that you adopted at Postman to do it the right way?

Kasey: Yeah, so I think that's a really fair question, and I don't think, I don't know personally, I don't know if that nut is cracked. I know I haven't completely cracked that nut, right? It's not immediately clear how to do it, but I can give you some examples of things that felt good and didn't feel good. For sure. Anything in the app kind of felt fine as long as it wasn't too overt. And that was always a discussion like I'm in marketing, I want to sell the product. I'm always on the line of make it big, make it blink, make it red.

I mean, I'm saying that about myself with great affection. It's just sort of how I am. Whereas the product designers were more on the line of we can put this tiny little star next to this settings wheel to give a notification that if they click through make two clicks, they'll get a suggestion that they're getting close to their usage limit and they might want to upgrade to the next plan. So somewhere in the middle between those two guideposts is not creepy. I clearly feel the latter is not creepy enough. I mean, it's just not right. If you're coming close to a usage limit, you should get an appropriately clear, annoying, easily dismissible, you're getting close to your limit. Do you want to upgrade in the app? Yeah,

Matthew: And I guess that counts for free limits as well as paid limits.

Kasey: I can give you an example of something that I don't think worked, although I did it and I probably still do it, which is if you see in your app somebody adding usage or adding users or getting close to their limit, a lot of times we would trigger an email flow that says, we've noticed you're getting close to your limit or you're adding users. Mainly it would be something like, I noticed we're adding users, would you like to consider the enterprise plan? And I don't know, the uptake on that email was bad enough that I assume it was just annoying. I don't know. People didn't unsubscribe that worse than normal, but it wasn't like people went, yeah, that's a good point. I should do enterprise. That's not really how developers think about these things. They hit the limit and then they realise that for there's something in enterprise that their company wants them to have single sign on discounted limits, maybe better security, not in the case of postman, but in the case of my current client, they want self-hosted the things that are enterprise, but sending 'em an email saying like Consider enterprise.

There are a lot of people, I don't know if it was creepy, but I don't think it did anything.

Adam: How do you find those right signals? Because sometimes, so a traditional marketer approaching the developer audience would put up a big gated form to fill out, and when I fill it out and I put in my number, somebody at that company says, oh, that signal means that guy is ready to spend six figures a year. No, I wanted to read the thing. So we all on this, and hopefully most of the marketers listening to this, no that'ss, not a signal. That's maybe on the creepy end if that's the scale that we're using on this version, and you've identified another one that is some would say, oh, that's a signal. They're adding people. How do you get it? What are the signals that are real signals,

Kasey: Right? Yeah. Yeah. Now in Postman, we had great product telemetry. So really this is my simplified. I always find this ironic that I was an engineer undergrad, and now I'm like, yeah, yeah, directionally I just go to the top level because we used to have all these really great data about every single feature and how it was used and how they were related and how you would see usage in one. And I'm like, yeah, it doesn't matter. My interpretation of that was, as long as you see increased usage along at least two axes, it's worth a conversation.

Two axes, meaning two product features. If you're using a lot of one product feature, like their propensity to buy, if you look at the regressions was good, but if you had two or three, you were on the journey to my 95% user, and you may as well jump in early.

And in that case, what the right thing to do is jump in early with an offer of, have you taken Postman Academy or whatever we called it. My current company calls IT Academy. My current client calls it Academy. So that's what my brain, but have tried. You tried Postman certification, that's what we called it. Do you have a Postman certification? Right? Because people, engineers in particular, developers love that, right?

Because not only, that's the other thing about developer marketing is that you're marketing the product to the person right now, and you are marketing a skillset to them, which will help them with their career if you're big enough and lucky enough. And in Postman, that was true. The people liked a Postman certification because they could put it on their LinkedIn, LinkedIn, wherever it was at the time, and it was something that might help you get your next job. So that was a better signal. We got a lot of uptake on that, and that felt more like you're actually handing something to them that they want.

Adam: So you've mentioned the 5 95 a few times. I think I probably understand what it means, but maybe break down what that is, and it seems related to what you've just said about being able to pull someone in closer,

Kasey: Right? So with Postman, I use this a lot. When I think about marketing to a technical person, and maybe it's not even leave out the technical person because I think we'd all agree, right? You get a new tool, I just got added to an HR tool that I've never used before and I'm stumbling around in it. I can do one thing right now and I need to do four or, and maybe I'll get to four. But the fact is that my connection to that tool is highly dependent on how facile I am with it and my attachment to it will be also increased the more I get into it. The thing about this particular tool though, the one I'm using is that what it does is relatively clear to me. So there's an attachment.

The more I get to be a 95% user of this tool, but in addition, it's not going to do anything that I don't understand already.

In the case of Postman, what we found was that it was because the tool was growing so quickly in terms of functionality, and it was well known, but only really for this one, send a request, get a response, examine the response that the features that were in the tool were not well understood. The idea of an API platform didn't really make sense at the time. It was like Kong had an API gateway, which is kind of a wholly different thing. They were customers of ours. So the idea of having a platform on which you would really programme a bunch of tests or even small programmes, and you would use this platform to do all of your API work, rather than use it as a quick tool to find out whether the API works the way you expected and then go take that formed curl response out of Postman and put it actually into your actual code.

That was the workflow originally. But the idea that how much you could do there was required really an imagination that lived within the company. So if you get to a 95% user, not only did you have somebody attached to the tool, and the more facile you are with the tool, the easier it is to get attached to it. But also they could see all the usage cases because they understood what each of those pieces did, and then you'd have actually more usage because there were things the tool could do that you were not doing or that you were doing in a different way or a less efficient way, or in a way that could be improved or you could imagine. So it was getting people to use the features that they didn't know about, and then that opened up this vista of, oh yeah, okay, that can help me here or there.

And so it was all about usage use cases, examples of how you can push something. When we did our first Postman conference, I kind of made a rule that the only people who were going to be speaking were customers or users, not customers as I wanted the most diverse set of use cases of Postman up there as I could possibly get. We ended up adding a pre-day, which was a full Postman certification day because we got a lot of community people who were speaking and all, they didn't have room for the company to talk about the product, which is what you normally do at a conference. So we added a day that was, here's the product, and then the second day was really just let's blow your mind with stuff you didn't know you used Postman to do.

Adam: Yeah, and it sounds like increasing usage, and that would be across use cases, across features. So anyone who has a product and going back to your looking for usage on two or three different different features then increases the likelihood that they go from free to paid. So you talk about inspiring through use cases and putting people on stage. I remember you had a dishwasher app,

Kasey: Right? Right. No, I got a lot of grief for that. That was really funny. Yeah. Yes. So I'll start with another one. Our dev advocate.

Our first dev advocate used an API collection to water the plants on her rooftop deck when she wasn't home using Postman, and it had used a raspberry pie and a bunch of other, it was fun. It was fun. But yeah, no, my dishwasher app came up because as all small offices do, you have a kitchen that no one takes care of because you don't hire somebody, and it inevitably, the dishwasher wouldn't get loaded and wouldn't get run. And I decided I have enough children of my own and I am not the office's mother, so I wrote a little postman collection that would keep a list of who had recently and who had it had been their day for the dishwasher.

Actually, that's what we had agreed. We'd agreed that you'd have your day for the dishwasher, but unless somebody nagged you, it just didn't happen. And so I wrote this little collection that kept this list of everybody, and I synced it to their calendars, so I knew if they were in the office or not, or out of town or on vacation, and I would keep track of who had done it recently, and then I would randomly select somebody. Actually, it wasn't even randomly, I think I selected it based on least recency. So you didn't do it two times in a row, and then it kept track of it, recorded it, and then pinged on Slack. The person who was supposed to do it that day until they responded, it just kept pinging them until they said, yeah, I'm going to do it. And shockingly, it really worked.

It actually, you just needed to be nagged. But the reason I'm laughing about it now, the reason I did it is it was a nice little example of a feature that most people didn't know about Postman, which is you could ping a series of APIs and pass the information on from one or the other and embed in Postman the logic to do the, I mean the programming, you didn't have to put it someplace else. You didn't have to run a CR job between that case. So the post, the collection was scheduled to run every morning Monday through Friday, and it pinged the calendars, it pinged, I think I was using an Airtable to keep track of who had done it when, and then it hit those two APIs for information and writing back, and then it wrote to Slack and Ping Slack to see if it got a response.

And so I think that the purpose of that was most people wouldn't have thought that Postman did that, that you could really write a little programme inside of Postman. And it was kind of the beginning. It's kind of the intro to, oh, I can imagine what a collection would do because the collection would, that's what a testing collection does is you run it and it runs some tests and then there's logic in there about what you do next if there's a failure. And so it was a nice little example of something that if you'd only sent a request and gotten a response in the Chrome plugin, you wouldn't know was a possibility. Yeah, it had to have the infrastructure, right. I also wrote a little programme to decide for while there, our office was in between two BART stops and depending on traffic, they're close enough that if I went left, that was actually to the BART stop that was closest, went to my house, but the other BART stop was generally emptier. So if it was really crowded, I would go the other way so I could get a seat. And I ran this little programme because BART has an API.

Matthew: So thinking about that 5% to 95% journey, did you map it out and think, okay, this seems like these are likely to be the signals someone's using two or three areas of functionality or was it observed and then you built a strategy in response to that?

Kasey: It was the latter. We had some really great data scientists on the team in Bangalore who were working on looking at signals, and it was very early stage when I was there. I'm sure since then they've gotten a good deal more sophisticated about those signals. At the time, really, we had more information we could act on, and there was so much unknown about Postman and the product was developing so quickly that bringing the audience along, essentially nobody knew what we wanted them to know about the product. And you have signals about people using stuff, but there were much stronger signals of large numbers of people not using the product as much as we'd hoped for. So we did a lot of that, but it was not, I assume since they're a much larger company, they're much more sophisticated about it. Now I have a neighbour essentially who's in marketing at a large well-established tech company, and when she talks about what their marketing team can do in terms of signals, I'm like, wow, we were just toddling around trying to get people, but but we had the data, but we were in baby steps on how people would respond to our outreach.

Adam: Have you seen other companies where it's flipped, the amount of data you have is so little that you're sort of just grasping for whatever those signals are?

Kasey: Almost every open source company that I've worked with has felt that way. I mean, I don't know if it was just, I spent a lot of time at Postman and I was spoiled by knowing what, because most people created an account, it was just easier to save things. So we had enormous signals about what people were doing. But any open source company, even if the company, if the open source owned within the company rather than in CNCF or NPMs, open source resides resided within the node foundation. But even then, it doesn't matter, even if you're wholly owned open source, there just isn't a lot of signal about what open source folks are doing. And there's quite correctly an enormous resistance to trying to get telemetry on that.

I'm sounding depressed right now because it just feels like there's just so much information there. And I don't know, I'm a marketer, so I feel like a really well placed ad is content. If you have the right signals on me, I don't know. I say people now that the fastest way to get somebody to serve me an ad for running shoes is for me to buy running shoes. And that's exactly the wrong time. That's exactly, that's precisely when I don't need running shoes is when I just bought a pair. But if somebody could send me a note six months after I bought running shoes, it's content to me appropriately used information is going to make my life a little simpler. It'll take the load off my brain.

But that's not how most people think. It's definitely not how developers think. And there's just this very hard bright line with open source that heightens the creepiness factor.

If you use any information. So I'll just give an example from NPM is you have all these people at the time NPMs website, very highly used, but I don't know don't, it was an average use of page. The average was one page 45 seconds or something like that. Because what happened is people would Google NPMA package name, they would find it, they'd land on the page, it would be wrong, and they'd leave in two seconds. So it would be right. They'd download it, read a little bit, and then disappear. And I was like, can I have just a little box on the side? Yeah, it's a big page, just a little box on the side that says, looking for private packages.

Do you need private packages? And that was just really, really painful. It wasn't hard to do technically, but it was a really, really painful decision. And I was thinking of it as you mentioned open source, because what I visualise when somebody says, do you want more information on open source? I think I just want more information in a little box on the discord on the community, the community team on the community discord, just I want a little place that says news and announcements or I want just some information about what they're doing there and why they're doing it and what they're finding interesting. And it's so painful. Just information, more information.

Adam: The pain there is getting any sort of message that might be interpreted as marketing to a developer. And the pushback is not only from the developers themselves, but probably in open source companies leadership that probably started as developers is that

Kasey: Sometimes, and definitely from the community manager, although it depends on the person, and I get it, it's a natural tension and it's an appropriate tension. And I keep joking that I'm a marketer and I'll accept advertising. I understand that the developer is the goose. We can't kill it and we can't do it. And you have to be very, very careful to not even give the impression that you care about them only because you want to sell them stuff. And it's true, we don't care about them only because we want to sell them stuff. We care about them because open source is an excellent strategy to build upon, but the company still needs to sell stuff.

Matthew: So there's this cliche that developers don't like marketing, and my response is always that nobody likes bad marketing. So when you talk about advertising as information and information, they're all just different bits of information. How do you get under the radar so that the marketing you're doing or the Marco Comms let's say that you're doing doesn't feel like something that a developer would complain about?

Kasey: I do think that there's a quality of message question. So let's think about the complaints of a developer who feels like they've been over marketed to, right? One complaint that I thoroughly empathise with is I is just word salad, right? Buzzwordy benefiting. I don't know what you're selling me. Just that kind of stuff that's written by marketing folks who don't fully understand the product. And that's actually something that I feel really strongly about. I am like, if I can't demo the product, there's something as the head of marketing or anybody in the marketing team should be able to demo the product and usually the fear in people's eyes when I say that, is it illustrative?

And I'm like, no, no, no. Right? If you can't stand at a booth and demo the product not for half an hour, but for five minutes, then you can't write Google ads that are going to be helpful.

So there's buzzword city and that's really annoying. There's over frequent, and I think that's possibly the most legitimate complaint about advertising is, yeah, I got it. You want to sell me this? You don't need to show it to me every time I go to the page. Or you don't need to. This is why I'm not on social media anymore because I can't am okay with ads. It shouldn't be the whole feed. And then maybe the third category is you never show me something that actually helps me, which might be related to the first one, but I think it's a little different because if I'm advertising back to the Postman certification, if I'm advertising the Postman certification, how upset can you get?

It's mostly free or free. You can run it anytime you want and it's a benefit to you. It happens to be a benefit to me too, and we all know that, right? It's a benefit to Postman because then you're going to be more, there's complete transparency. This is good for you and it's good for me, but there's a lot of advertising that this or that marketing that has a is completely one way. This is only good for me.

So how do you thread that needle? The first one, as I said, I tend to be very hardnosed that the language has to resonate with the user and really resonate with the user. The second one, I use a really light touch. I just don't spend, I have traditionally underspent on paid media, which has other issues that we can talk about professionally. There are times when a lot of paid media is the right thing to do, and I still am a very hard, the credibility is hard to get back.

Matthew: So I mean, if we talk about paid media, what do you do about the fact that while I'm saying it's a fact, it's what I think is a fact that most or at least many engineers use ad blockers, they'll use anything to prevent cookie tracking that they can. So attribution is one of the hardest things in marketing anyway. How do you prove that your paid media is working?

Kasey: That's such a good question. The next time I have this conversation with the CO, if it's startup, can I quote you? That's usually what I'm saying. I'm like, they're like, well, why don't we have attribution? I'm like, because a crapshoot, even if people didn't use ad blockers, I would say fewer engineers use ad blockers than they say they do. So I'm not entirely positive that like, yeah, I don't use that. And I'm like, really? Show me.

I don't think I do that. But the attribution's a mess. And even the parts that you can attribute paid media, paid media to a lead, let's say leaving out people who've opted out of that process, all that tells you is what all you get is the last five minutes of that story. Because that click on that link that ended up in a lead, that is not the first time that person has consumed your content or consumed your media.

By definition, the number I will stand and say, I believe nobody ever, ever once clicked on an ad and bought that day, right? It's not true. It doesn't happen that way. So attribution, attribution is comparatively helpful, but not on the aggregate accurate. So if I'm running ads on Google and I'm running ads on LinkedIn and I'm trying to get leads, the goal for both of 'em is leads. I can say, wow, this one's more expensive than that one. That's helpful. If I'm running ads on Google for awareness, what you have to believe is over this period of time, did this spend bring the usage that the visitors that I had hoped for?

And then you have to believe that those visitors somehow will translate. You have other activities to translate it, but you can't really the full attribution back to this neighbour I have who works in marketing at a large tech company, she was explaining to me once this amazing attribution marketing attribution system that they had put together. And it sounded great. I'm drooling over this, that's a little nerdy, but it was like everything is linked together and marketing has a pipeline commitment. And they go first touch and they compare it to middle touch and they do this and they have numbers and they have tools and plugged in. And I'm like, that's great. How long did it take to put together? And she's like, not too long, less than seven years.

I was like, oh, okay. And that's when I stopped worrying about it. I mean, I track the heck out of everything and you make decisions based on the data you have, but this idea of one unified model to manage your marketing is the bailiwick of a much larger company.

Matthew: More than once. I've had friends come to me in confidence and say they're heading up marketing or DevRel at a small developer tool startup, and the CEOs have this great idea. Let's turn off marketing for six months and see what happens. Are there things that you would do when reporting to C-Suite that give them confidence? I guess

Kasey: So. This is another nut that I don't think I've cracked. I would say though, if a CEO wants to turn off marketing for six months, I would go find another job because there's no science experiment here. This is an unfortunate, it's like raising a kid. There's no AB testing that's going to really work here. If you turned off marketing for six months, you'll be six months behind. And if you believe your community can afford that, or if you're behind enough in your product that you don't think it'll matter, because what you'll be promoting right now is not sellable. I could make the decision, but it's not going to prove marketing to you.

It might be a strategic decision. That's the right way to manage your cash though.

What I try to do, but to answer the question, what I try to do is pick metrics along the funnel of relatively few metrics along the funnel that we all agree to report on, and we agree that we want to increase them, whatever they are. And we agree that the actions that marketing is going to do should increase these. We believe that there's a connection. This isn't just random, and then at the end of three months or six months or two weeks, you try to track and see where that goes. And then from there you can say, all right, so this one didn't work so well. And then I run a lot more numbers, more detailed numbers on every little bit underneath there, but I tend to sort of say, well, there's very top of funnel, which I use website visitors for How many people come to your front door?

I mean, again, this is technical developer companies. That's a decent number. How many leads you get, how many people that you can market to in your marketing automation, and then M qls or SALs or SQLs, whatever the sales team, the sales leader wants to track on and how many close from there. So four points on the funnel at most, but ultimately, if website visitors go up, you can always argue it was something else. The product was really good. It was word of mouth. You're like, yeah, that's fair. But it's very hard to prove when marketing works again, if you find a solution.

I think this is a work in process for each individual scenario. But yeah, if the CEO really is at a place where turning off marketing feels like a viable alternative, maybe because I'm a consultant now, I'd be like, yeah, it doesn't sound like we should work together because that's a position I can't prove you out of. I don't think.

Adam: Kasey, this has been great. If you think back to your first role working with devs as an audience, what advice would you give yourself?

Kasey: That's a good question. I might go back to something I mentioned earlier. Investing in understanding the product and the developer's usage is you can never overinvest in that topic. Even as a marketing person, every time I've gotten deeper into the product and understanding the customer's use case has reaped enormous benefits, and that's a hard one for a marketer and a developer company because you're going way outside your, in order to understand the pain point, you have to understand the product and they have to understand the usage. It's a lot to do, but that's just investing in understanding the developer's use case is just gold when you're trying to market.

Adam: And so as you're looking for team members, is that sort of curiosity?

Kasey: Yes, actually that's a good point. I just wrote a job description yesterday and I included my standard phrase, which is, you don't have to be a developer, but you have to be curious about the technology and the use case, and you have to want to talk about that. You have to want to say, wow, why do they care about security? Is it that the secret is, do we really want to emphasise that the secret is held within the, is it one control plane that matters or really is it the number of apps that matter? You have to be able to be curious about a level of technology that feels very foreign. Alright, thank you very much. This was fun.

Adam: Yeah, thank you Kasey. Yeah. Let's see. Where can people find you not on social media?

Kasey: Well, I'm on LinkedIn. I just don't check it very often. I have am the poster child for athe cobbler's kid is barefoot because my website is so out of date. It's embarrassing. It's been on my list of things to do for a couple of years. But yeah, I function under something called Full Point Marketing, which I work with early stage companies primarily on projects like a product launch or a particular a strategy plan for marketing to get it to accelerate in early stage companies marketing or help with hiring sometimes. Right now I'm the interim head of marketing for a little company that's looking for a full-time head of marketing. So I'm their head of marketing and what's necessary in all of those parts.

And it's fun. I love working with early stage companies and there's just a lot of, just a very exciting, it's just really exciting to work with a company that is doing things right away at a speed that would be unimaginable At a large company. You have a lot more freedom as a marketer. You do experiment with things. I like it a lot.