Episode Transcript
[00:00:09] Speaker A: But I would love to hear more about what you're doing, Christina. So maybe you could kind of start off by giving us just rundown of what you're doing and the problem that you're solving.
[00:00:16] Speaker B: Yeah, yeah. So I founded Pandium a couple few years ago with the co founder that I've worked with. We've worked together now for almost 11 years I think too long. And we are integration infrastructure for B2B SaaS companies.
[00:00:29] Speaker A: So.
[00:00:29] Speaker B: So we work exclusively with mid market ish software companies to help them build more apps that their customers then use. We got all kinds of cool stuff kicking around with AI and MCP and all that now, but really at our core we aim to be a scalable, powerful platform, but a lean experience for engineers so they don't have to learn a whole bunch of new stuff to get a lot of the value of an integration platform which have historically been pretty bloated and like focused on operational non technical users. So yeah, we've been at this for a number of years now.
Tens of thousands of businesses use our apps every day and it's been a fun journey.
[00:01:05] Speaker A: I'm super curious about just basically the whole journey and I think let's go ahead and start at the beginning because I think you're going to be such a cool case study for anyone who's listening. So Pandium is an idea that I feel like not many people would have come up with. Like if you quiz people like hey, what's the business you could start like oh restaurant or like trampoline place or like whatever, you know, like it's anything but Pandium. So I'm really curious, One, how did you figure out what to build? And then two, kind of how did you start identifying your icp?
[00:01:31] Speaker B: Yeah, yeah, you know, it was either this or trampoline parks as you said. No, I'm just kidding. So I won't go all the way back to like my beginning journey as a professional, but I've been working for a long time. I did like fast food management, retail management, service industry jobs and in college I managed to land at one of the very few technology companies in the town I grew up in. And now it would be called a startup. But I think then it was just like a company that had a keg and bagels and with a bunch of young people. Right. I worked in sales. I was an SDR and making like 80 calls with paper lead lists. You know, it was before auto dollars and all that stuff. But anyway, really liked working with systems. Like I just loved working with Technology that was my first introduction to Linux. And there's a point to this, that company was doing an in house build of a CRM. What I now know is a CRM, this was in the early 2000s and, and they needed a steering committee internally to work on that project. And I was the expert from the sales team. So that was like the first time I really got like professional experience working with building technology.
And after I graduated from college I moved to New York and kind of found my way through a bunch of different jobs, but landed at a consultancy where I was doing ERP consulting. So consulting with Fortune 50 companies in the manufacturing space to take them from paper and pencil to the computer, it wasn't even the cloud yet is like going from carbon copies to using a computer was a big story. And that is where I was exposed to integration for the first time. So I didn't go to school for comp sci, I went for criminal justice and creative writing. So, you know, really, really closely aligned with what I do today.
And even then integration work was really sort of like the second class citizen to software building generally. So as the most junior person at this very small consultancy they were like, Christina, go figure out how to connect this ERP that's living on a server to the cloud. And all these like now we would call SaaS companies. And I had a knack for it and I really liked it. So I was getting to work with engineers as like almost a product manager but like in a confined way building these integrations and I just caught the bug. And then as I was moving through my career working at other SaaS companies and working with technology, I just kept finding my way back to the problem of integration. And right before we started this company, my co founder and I worked together and we were looking to solve this problem right? So like software is modular. In order to be useful you need to connect to all the things, other, other, all the other pieces of software that your business users are using. And I had experience doing that. So I was slotted into that position and I at that point had used like every kind of tool I think that existed for integration and they were all very similar.
And we went out to try to look for something to help make this better and easier for my team of engineers. And we selected something and it did not, it provided some benefit, but it was really a terrible experience for my engineers to use as a pm. It was a terrible experience for me and it wasn't built for this idea of these integrations as features that you're like Giving to your customers. And so, yeah, my co founder and I, he's got like 25 years of experience in the space. Like me and backend engineer, we were just like, this problem is big and is getting bigger and deserves a dedicated solution. And I'll say for any listener that is like thinking about starting a company or, you know, maybe early on in their journey. What I tell folks that I mentor through accelerators is that you have to really be in love with the, the problem, not in love with the solution.
And this was a situation where my co founder, Sean and I were like texting each other at three in the morning, waking up, being like, oh my God, what if we did it like this? What if we did it like this and just could not put it down? Like, we just couldn't stop thinking about it and it's still the same. I was texting with him at like 6am this morning about some AI idea. I was like, what about if we talked about it like this? So, you know, it's been, I've been working with him, like I said, for like over a decade and we're still kind of still stuck on that, you know, and yeah, so that landed me here. We just really love the problem. We built something that was novel and people want to use it and want to pay money for it. So here we are. And I think you mentioned something about icp.
[00:05:45] Speaker A: Yeah. I'd be really curious how you identified your ICP for that, especially because the way you kind of framed integrations as just like an additional feature you're adding for users. I mean, there's a million businesses that need additional features if you use them. So in that kind of pool of a million businesses, how are you identifying the ones which you really want to go after?
[00:06:01] Speaker B: Yeah. So, you know, the, your ICP can evolve, right? Like, the companies that we were targeting when we were three people or two people are different than the companies that we're targeting now a little bit. But I think defining your ICP is related to defining your goals as a company to a certain extent. And I don't mean with the technology. I mean more around, like, what do you want this business to be in the short and long term?
And I think there's a couple different ways to think about that when you're a new business, especially in technology, and you can optimize for different things. Like you can optimize for the current kind of quote unquote hype cycle. Like, hey, we really want to get venture funding. Like, this is where the money's Going let's go try to do that and like then see where it goes. You can optimize for users. Like we want to get a bajillion signups, like we want to get this in front of as many people as humanly possible. That is how we're going to dominate this market.
And you can, and, or you can optimize for revenue which is not necessarily the same as those other two. Right. Like I think when you're building those three things can be very distinct early on. Like you got to pick one. And Sean and I wanted to optimize for revenue. Like I've managed budgets for integration projects for years and I know how much money were really companies were willing to pay to solve this problem and how much they were spending both in technology and in humans.
And for he and I to have conviction about the product and the business being real, we needed to like have people pay for it. Like I just felt like that was what we needed. And so we very quickly, with that kind of in mind, saying like we want people to pay for this, this product out the gate with that in mind. That really determined our go to market and that determined our Persona within an organization which then determined what we now know as our icp. So I say that to be like we could talk to companies to figure out like where is this the problem and what department does this problem kind of sit in. Then talk to the people in that department and try to figure out who the primary stakeholder is and if that pain was acute enough for that stakeholder to care.
And that really tied into like our pricing model and stuff. We, we learned really early on that marketing directly to developers is really difficult with a paid product. They really are looking for free stuff, plg, like open source things. So we knew that we had to do a top down approach. And then we also realized early on that really small companies, like you know, 10 person startups were really jazzed by our technology but had no real, like they didn't have the budget, they didn't have the technical need either. Like you don't need an integration platform when you, you yourself only have five customers. So we decided to you know, go where the poll was which was really in that like mid market kind of company. Companies that have a thousand plus of their own customers and that's where we still sit. And it, you know, it's really, it's affected our product roadmap. It's really driven like what we're building. And in a way that I'm really proud of, like we have, like, unique benefits for that segment that the small guys, like, wouldn't care about and wouldn't need and wouldn't pay for. And that's fine. Like, I'm not mad. It's just a different. It's just a different buyer. And, you know, the, the method by which we figured this out was just like brute force. Right. It's like having conversations. I don't know if people are listening to this, but we're on video and, you know, saying what Pandium is in lots of different ways early on and seeing, like, at what point do your eyes glaze over if I say a number for price? At what point do you look like you're going to burst out laughing? And at what point is it like, okay, I can like, kind of make that work. Like, there's no way to shortcut that. I don't think if you're doing something like that's kind of new and novel.
It's just doing those types of conversations hundreds of times over the course of six months. Like, hundreds and hundreds. I just locked myself in a phone booth and did like 30 minute back to back to back. Anyone that would talk to me at a SaaS company, at a B2B SaaS company, I would have the same conversation with. And it could be kind of demoralizing, but it's fun, you know?
[00:09:56] Speaker A: Yeah. And Sarah, I'm sure you're great at getting people to burst out laughing. You've been making me laugh just this whole conversation. So this is already going super great.
[00:10:04] Speaker B: I mean, getting them to laugh, like, at a joke is one thing, but if you're like, hey, would you pay $500 for this? And they're like, abs. Like, they burst out laughing and they're like, absolutely not. Like, that's a good indicator. And like, does that mean that it's not worth 500 objectively? It doesn't necessarily. It's just not worth 500 to you. And like, is that. Is it ever going to be worth $500 to you? Is it worth $500 to a different buyer at a different sized company? And if so, are there enough of those buyers at those companies? So, you know, we started our price obviously low and it's gone up over time. But, like, it was really useful to see the patterns within different sizes of companies more than anything else. Like, it wasn't vertical specific so much. It wasn't like the tech stack or anything. It was really like, what level of maturity is this business at in terms of their own technology and like their ecosystem and Go to market strategy. Like that was the, the big differentiator between people laughing at me and telling me that I'm crazy and people being like, oh yeah, no, that like it replaces headcount. Of course I would pay that much. I'm like, what about a thousand? What about 2,500? What about 5,000? And you just keep asking until somebody's.
[00:11:10] Speaker A: Like, maybe not keep asking until they start laughing.
[00:11:14] Speaker B: I mean, yeah, like early on, why not?
[00:11:17] Speaker A: So related to this kind of pricing is just the pain itself. And you mentioned falling in love with the problem. So let's dive into the kind of the problem a little bit. Just maybe give me even some better context. So maybe coming from a non technical decision maker standpoint, for one, why are integrations such a hassle? Because it seems like it's just like you just like you just call your nerds and you send them to connect this one thing to the other thing and then it like all works. So why are integrations a problem that need to be solved and why do they feel like, like this thing that can be so frustrating sometimes?
[00:11:47] Speaker B: Yeah, so I have a lot of answers to this.
I think a lot of folks underestimate the complexity that goes into building these integrations that are going to be used by a lot of your customers. Like if you're building like a, hey, I just gotta get like contacts out of HubSpot for one customer. You could do that in an afternoon yourself with no tooling. Just like you could figure out how to hack that together, set it up on a schedule, like no big deal. But if you want to then have 500 customers or 50 or even 10 customers using that thing, that's like a different kind of level of expectation and really down at its core. A lot of this comes down to like the problem of disparate systems generally, right? Like if you're building a feature for your own product, you know the four walls that you're living within, right? Like you have full access to the code base. You probably have people that have been there a long time that kind of know the product and know the problem you're solving and like, you know the gotchas, you know the dragons in the dark corners.
And you can kind of just, you know, you probably have design RPM and stuff, but you kind of just get to go in and like jam and figure out how to do it. When you're building integrations, the technical part of like talking to the API and like writing a get request is not the hard part. Like that is a solved problem. There are libraries for that. Now we have AI that can write that code. Like writing the code that does the integration itself. Like the business logic isn't the hard part. The hard part is figuring out how you want it to work. And then when you get to those corners and I'll just pick on HubSpot, we love their API for the record. But like when you get to that like weird little dragon in a corner that you hadn't seen before or maybe wasn't documented, like, that's when you need to have a good comp sci fundamentals and like a good vision for how you want this thing to work. And that part I think is underestimated and often very challenging. So to your point, you call up your nerds and you're like, hey, I need to get contacts out of HubSpot. Should be easy, right? I just said like, do it in an afternoon. Done and done. And early companies would be like, I could build all this in a, in a, on a Saturday morning. Like you probably can for one customer. Like go for it. But what happens when like you're getting duplicates? Well, how do you want to dedupe what happens when your customer wants to filter on only specific contacts within HubSpot? What happens when the HubSpot API is down and you need to do retry logic? And like this is all very kind of table stakes stuff, but you can get really deep into like all of these nuances that exist outside of your own product, right? So building integrations correctly requires that you know the other system at least a little bit.
To do it really well, you need to know the other system pretty extensively and how your customers are using it.
And I think companies, we see over and over, companies estimate, you know, they tell them, the engineer says, I'll do it Saturday morning, it'll be done by Monday.
And maybe it is. But then sales sells the next big deal with that HubSpot integration. And all of a sudden it's been six months of trying to rebuild this thing to make it work for more than one person. And then when the Salesforce project comes up, the CTO is like, hell no, we're not going down that path again. Like, I don't want to spend the time. It's annoying. It's not cool.
So, you know, I think there's a lot of factors and I could get into all like the technical reasons why integration can actually be hard around like auth protocols and refreshing and crawl jobs and long running jobs and making resiliency, but like really at its kind of gut I think it comes down to like it existing outside of your system. Like you're interacting with another person's technology plus the data that your customer has put in that system, which like, who even knows?
And there's just a lot of dependencies that, a lot of dependencies that in my opinion most integration tools are not actually going to help you that much with. Like they might enforce some logic around like you have to do retries in this specific way which like on the surface it's like cool. Now I don't have to think about that, but when you get your 51st customer, they're going to want to do it in a different way and you're going to need to do it in a different. And then you're back to where you started with a tool that in our opinion is a little bit like more complicated than you potentially need to like solve that problem. So like a long answer, but I think it's, you know, it's both like, it's both not a sexy problem and like a problem that people don't want to work on and more complex. I think that than it seems on the surface. Especially like you're a go to market guy, right? Like the sales team's like, yeah, connect to NetSuite, like it'll be easy. It's like, no, actually what does that even mean? Like netsuite integration? Tell me more like what exactly do you want to do? Yeah, that's kind of where, where we come from. And yeah, I could totally nerd out on all the technical complexities, but I won't bore your listeners with that. I could scare them, scare them into buying a panty.
[00:16:17] Speaker A: Well, that's very kind of you. All this stuff sounds like super technical and I think tech is like generally an area that's kind of male dominated. So I'm really curious as what's been your experience being a female founder leading a tech company.
And just to clarify this, I'm interested in sort of the difficulties and the opportunities that you might have found here that might not exist for others.
[00:16:38] Speaker B: Yeah, I mean, look like I am. I don't want to be old enough to be able to say this, but I've been in this space for like long enough that you know, I've seen it transition a little bit from being like very male dominated to a little bit less so.
So, you know, I think it's challenging for all the reasons that you probably or your listeners expect. It's challenging. Right. There's not that many women in leadership and technology companies. Very, very very few VCs, which may be a byproduct of the fact that not a lot of female founders have had exits yet because they historically weren't founding companies. So like the money hasn't trickled. I think we've got another like 10 years before, a lot of, before a handful of female founded companies have had good exits to kind of point to. And you know, it's, it's, it's always a challenge. It's. Every job has its unique challenges for every person. I think being a woman who is not an engineer in a reasonably technical product is an additional layer. But one thing that I think has been, I'm not going to say it's superpower, it's just a side effect perhaps of sexism, if we want to say that, or just like gender norms is that I don't think that like male founders or employees are like not able to build empathy. Right. Like I obviously everyone is able to build, build empathy, but I think it's not as heavily, it's more heavily frowned upon in traditional like male gender roles. Like, right, we talk about like masculinity and like loneliness and all this stuff. It's less frowned upon for women to have empathy for their colleagues and I think also their customers. So I say that, I bring this up to say that like, I think when we were going out to market for the very first time, it helped me with the perception that I actually like, give a shit about you and your problem that you're trying to solve, which I do. I mean, I wouldn't be doing this for this long in such a boring space if I didn't actually care about you as a human. Your career, like your company, the problem, the people that work for me. And I think being able to lead with that is maybe something that would be less comfortable for a lot of male founders or co founders. You know, there's this perception that like you have to just be total hard ass, like hustle culture, crushing it on LinkedIn, you know, everything is awesome all the time. And like that definitely permeates to the startup life generally. But I think it's sort of antithetical with like, hey, like, we want to get you promoted. Like I really care about each individual company, like that type of thing, whether that's the reality or the perception is sort of immaterial. And it's also helped me in my own personal career prior to Pandium, because I have always been a person that if I don't understand something, I just say that and I'm like, hey, I'm dumb. Like, how can you explain that to me? Like, why are we doing it like that? Why isn't that working? Like, why are we thinking about that that way? And early in my career, that helped me from a technical perspective a ton because I was just like, I have no ego about the fact that I have no idea what you're talking about. So, like, can we sit down for 15 minutes? You could just walk me through it. And I'll never forget the first engineer that explained an API to me when it was like, brand new. And I was like, you guys keep saying API. I don't know what that means. I know what a web services endpoint is. I know all these other ways to transfer data. But what is this API thing like? Oh, it's just like the way that systems on the Internet talk to each other. It's like opening a door you can walk through. I was like, oh, that's not nearly as complicated as I thought.
[00:20:10] Speaker A: Are you saying that you have turned mansplaining into an advantage?
[00:20:13] Speaker B: Well, I mean, then I'm able to add, ask follow up questions. I will say, okay, so the difference with mansplaining is that they're doing it to you when you already know. Right. Like, I'm asking, like, what is an API? But if I have definitely had the experience of having folks mansplain, like development practices and things like that to me, when I'm like, I've been doing this for 15 years at that point, like, I know, I know.
[00:20:38] Speaker A: Yeah, maybe you should mansplain to them.
[00:20:41] Speaker B: Yeah, I got so many. I have so many pithy things I could say to that. But.
But no, I think that also comes from, you know, like, finding people that you work with that are receptive to that. Because a lot of people are like, hey, what's that mean? They'll be like, f off. Like, I don't have time to explain stuff to you, which I think is shitty.
I hope I can say that on this.
[00:20:58] Speaker A: My mom doesn't watch these, so it's okay.
[00:21:00] Speaker B: Even if she does. I think she'd probably agree with me if she's cool.
No, I think asking, asking why? And if you. If. Folks, I'm sure everyone is tuned into all of the content I've ever done, but, like, I've done other podcasts where I've said, like, asking why. I think having, like, the humility and the confidence to ask why is something that I want to take with me throughout my entire career. Like, the humility to say, I don't know what you're talking about or I need further explanation and the confidence to say. And that doesn't make me an idiot.
It just means that I need an explanation, a further explanation of this one thing. And that goes all the way back to, you know, when I started working when I was 14. Like, and maybe I don't understand it. Like, I don't need to know every single thing every person at my company is doing. I hire them because they're better at all those things than me. But I think it's still, it's always appropriate to ask. And again, I think that's a little bit antithetical to the, like, the hustle culture of like, oh, like, I know how to do everything. Like, I'm crushing the game. I'm gonna do my cold plunge and like, then I'm gonna come out of genius. Like, like, okay, sure, I'd rather hire. I want to hire only people that are smarter than me. Like 100% of the time. I work for them. Right. I work for my customers and I work for my employees.
[00:22:07] Speaker A: So speaking of your customers and empathy and kind of asking why a lot, I think this all sort of brings us to one central place, which is like, how do you stay customer centric in software? And in particular a software that's like super nerdy. Like, like, because I think there's, there's a tendency in more tech heavy softwares. Like, I think it's not truly a spectrum, but it almost feels like a spectrum sometimes. Like, the stronger your tech team is, the weaker your customer team is. And that's just been my experience. I'm not saying that's true across the board, but I'd be really interested to hear your thoughts on like, how do you stay focused on the customer when you're building stuff that's like, sometimes a little bit. Like, maybe the customer doesn't know exactly how to get what they want or there's some tension there.
[00:22:49] Speaker B: Yeah, I mean, I've worked at a lot of software companies that sell to SMB, like tech, but like a lot of just SMB businesses. So, like, that user is very different than our user, which is like an engineer at a SaaS company. So I get it when, like, sometimes the customers should be using a computer.
But, you know, we don't have that problem here at Pandium. So like, you know, for myself personally, maintaining like customer empathy is very easy. I love people, like, I will talk to anybody at any time about Pandium. Like, I love problem. I think building a customer centric organization, to your point, is like, the bigger your tech team is, sometimes the further. The further the company gets away from the user. And so when we hire and we tell everybody this, that we hire, every single person at Pandium is customer facing every engineer. And we tell them in their very first part of their interview, you will be expected to talk to customers on the phone on Slack. Like, you're not necessarily going to be doing it every day, but, like, if that is a problem, we are not a good fit for you, full stop.
And what I have found is that a lot of engineers actually really like that. Like, they love seeing the product in action, right? Would they love that if we were selling to, like, a brick and mortar bodega and they had to, you know, like, maybe not. But, like, we sell to engineers, right? And so when they get to see how folks are using the product and then, you know, if someone's having an issue, like, talk to them directly. They don't have to go through with the X person. Like, just get on the phone real quick and, like, figure it out. They really enjoy it and they respect our customers and, like, the things that they're doing.
And I think that if you're able to do that, that is really helpful. And even if you're doing, like, brick and mortar stuff. Like, when I was working at my previous company, it was B2B Sales Order Management, so the users were like sales reps out in the field. And I remember there's a trade show here in New York called New York now, and it's. I think it's gifts. It's basically a huge trade show with, like, every kind of good you can sell, like, furniture, toys, makeup, everything. Like, people just post up there. And then people that work in retail stores as buyers go in to, like, buy stuff. And trade shows is where handshake was born. Like, that's what it was for. So we sent our CEO, sent a bunch of the engineering team to the show and was like, just walk around and, like, see how people are doing it with paper pencils. See how people are doing it with our thing on an iPad. And they all came back like, oh, my God. Also, I can see now why XYZ thing is so annoying that, like, we don't think it's important to fix. But, like, I get why they're super pissed off. Or, like, this would be so much better. And those people are about as far as engineers as you can get. Like, these are folks that, like, sell couches for a living wholesale, right?
So I think staying in close contact with the customer for the entire organization helps you remember like what your North Star is and also helps folks like enjoy what they're doing. And I've worked at too many places that and seen too many places where like the bug tickets are like, everyone's like, ah, who cares? Like, we don't have to fix that. It's not a big deal. And I'm like, it is a big, it's a big stupid. It's a stupid big deal to like our customers.
And I never want that to, I never want to hear that conversation happening here. You could say we're not going to fix that. But to be like, I don't care, like that's dumb is like not an acceptable talk track to me.
[00:26:12] Speaker A: Yeah. So if you have basically the whole company talking to customers on a regular basis, how do you distinguish between like data and noise? So like anecdotes versus like, oh, this is a thing we really need to solve.
[00:26:25] Speaker B: Yeah. So again like we are very lucky and it's a side kind of a byproduct of selling to product engineering teams at companies that I had not anticipated. They have like really good feedback and like if they're running into an issue, they have already tested it, They've tested it in multiple environments. They're coming to us with like, this is where I tested it. This was a sample data. This was my expected result. This is my actual result. I did a retest. I can reproduce. I'm like, you guys like wrote the whole ticket for me.
So like when folks are hitting us up for something, it is almost certainly like actually something that they need, which is great. Like we don't get a lot of just straight noise like really barely ever. And you know, we have a good internal process around like validating bugs and fixes and release management and all that stuff. So we don't get as much of that. You know, there's always at every company people that are requesting things that you're not going to do or requesting things that are not like aligned with your mission or you know, are going to not be on roadmap. And that's up to our CX team to like have that conversation. And you know, they ultimately own the relationship. And to be clear, it's not like the engineers are doing like CX work all day. We rotate and like it's really pretty light. But you know, they, I think again they, our engineers respect our customers and respect the things they build on us. And we work with big companies, we work with Companies that have 70 person engineering teams and like, you know, like that you're doing something right if you're a unicorn, right. Or you're a publicly traded company. Like, are there issues with every company and are there always issues with technology? Of course. But like you're doing something right if. If those types of companies are using us, we're doing something right. And you being employed by whatever that company is, you guys have found something out and I respect that. And I think they respect that also, which makes them. Drives that empathy and makes them excited to solve these problems. Because it's like, hey, we're solving a problem for a company that like, I just saw in CNN talking about the partnership that we are underpinning. Nobody knows that because we're infrastructure. But still cool to see.
[00:28:26] Speaker A: Super cool New mom's probably.
[00:28:28] Speaker B: It is. It's like really cool. We also only hire people that think that that kind of stuff is cool. Like, we work a lot with three PL companies and like every once in a while someone will get like a box. Like you order something online and it'll be one of our customers that shipped it. And it's like, oh my God, I bet we touched that. Like seeing like physical things coming out of the computer, I just think is like a really cool and like an old school nerdy way. Like putting things into boxes on trucks because of some of the stuff that we're getting to have a hand in, I just think. Cool.
[00:28:53] Speaker A: Yeah, well, I mean, that's just straight human biology. Like we just get things that we can touch with our hands more than things we can touch with our minds.
[00:29:00] Speaker B: Maybe. I don't know, like the whole like crypto blockchain thing kind of switched that up for me. People were like so jazzed about like this, you know, at the time, very abstract concept. And I was like, no, no, I'm a simple person. Just like put a widget in a box and like, you got me. That's all I need.
[00:29:14] Speaker A: All I need. So speaking of kind of doing things right, one thing I wanted to touch on was there are some other companies do integrations that are quite large. So I'm curious as to your experience and any advice you have as far as just competing with giants and in particular how you as a founder can lead sales efforts, lead customer efforts, basically sort of lead the company in, not like getting overwhelmed by just the. The sheer size of competition.
[00:29:39] Speaker B: Yeah, well, it's interesting because the integration space has been around since like the late 90s. Like this segment is not new. When we went to market in 2019, the embedded iPass thing, which is where we kind of sit now did not exist. So like we. Our go to market effort was so different than, than it is now because we had to be educating the market that you could buy something. Like, there was no SEO because no one was searching. There's no ads because no one was searching. Like, we weren't MuleSoft had just IPO'd a couple years prior, but we weren't really competing with them. Like, they still like large like manufacturing firms and stuff. So we were really greenfield and it was a lot of like in the beginning, me being out there and just being like, hey, I'm gonna speak at an event and be like, by the way, Pantium, you can buy stuff. Like, you know, you can buy a thing. You don't have to build it from scratch. Now there's a whole industry around this, which is a whole like vertical, which is kind of cool. I think focusing on your differentiator is really important, right? And whether that is a product differentiator, a focus, like what the specific problem you're trying to solve, or even like your brand, which is like kind of lame to say in Enterprise B2B SaaS, but, like, there is a brand. All of those things can be really useful in standing out, especially in a space that's as dry and boring as ours. Like, integration technology is lame. Like, I love it, but it's lame. So, you know, we have a differentiated approach in terms of our implementation, but we also deeply, deeply, deeply understand the problem set because we've been doing it for so long and now we serve like really large companies that have really large problems. And so we have both like, technical differentiation. Like, hey, this is like the cool features that we have, which is, I think is less important than the like, brand voice and the focus and that comes from the top, which for better or for worse is myself and my co founder.
So, and I, you know, we were really careful, especially early on when we were doing a lot of that content marketing, which has been our primary marketing driver is content that we never have used AI to generate content. We don't outsource our content barely ever. We'll do guest posts and stuff, but like, we hand write all of our stuff, Everyone on the team writes stuff. And it's really high quality.
And also in our voice, like in our voice as a company. And if you're listening to this podcast, you can probably tell that, like, I'm a bit of a crazy person. And we try not to make it so crazy in our voice, but there is like benefit to being A company that people want to work with and people think care about them. Again, the empathy and like trust with their business and that is something that you cannot copy. Like our competitors can, you know, outspend us. They can out hire us, they can bid on all the, the ads and do all the, the flying and all the dinners and all that.
And that will always be the case for every company. Every company. Somebody can outbid you, but it's really hard to take away the like when you have a very strong reputation within a market and that is long lasting and it is more important, I think than the technology in a lot of ways.
We want our technology to be awesome and they're very commingled. But what will, what will take you? What will bring you through the hard times? Like Covid, which was like our real first, our first year in go to market was like late 2019 and then 2020 was going to be our year. And like establishing that brand and continuing to just stick with it has helped us get through all of the shenanigans that have happened since then as a, as a reasonably small company and continue to grow and continue to iterate. Yeah, I don't know if that's like a good answer. I feel like there's like so many people on LinkedIn that are like, here's my top 10 tips and it's like very tactical. Like use a Google sheet. I'm like, I don't know, like you just gotta be like a cool person and make sure you hire cool people and continue to like look cool and act cool.
Like I don't know. Is that a, is that advice? I have no idea, but that's what we're doing.
[00:33:40] Speaker A: I bet that's advice probably a lot of people I know could use. You mentioned reputation and then also writing. So just to dive into this a little bit. Is it mostly everyone in your company who's writing often or is it sort of you and the founder writing or what's that looking like?
[00:33:54] Speaker B: It's not us. We do write some but so our marketing team spearheads this stuff and the marketing team's small.
In the beginning, early on we, you know, we wrote everything and did a couple of long form pieces that were like very targeted in terms of like if you are downloading the definitive guide to launching your in app marketplace, you are almost certainly actually thinking about this.
And those things are evergreen. Like we update them but we could still. That was in 2019. We still use that piece and we also use that to then get a bunch of guest posts in other people's. On other people's sites, just like, rewriting parts of it or highlights or whatever, which drove traffic to us. Like, we were featured in, like, Scott Brinker, he's a HubSpot, like, cheap ecosystem guy. Jay McBain has picked up, like, folks that are, like, influencers in as much as you can be in our space.
And that has been great. Like, we still get traffic from some of this stuff from 2020, so that's a great way to like, hack your way into traffic. If you can't do, like, again, we can't do SEO. Like, like embedded integration. There was zero search. Like, there's no. There was no way for us to get in front of people. We had to, like, pull them in when they were actively looking.
And then now we do more writing and we have, like, a larger kind of content strategy. The, you know, the marketing team does most of it, but we do divvy out blogs and stuff internally, especially the more technical ones. Our engineers, like, do about like one a quarter that each of them either write themselves or they dictate to the marketing folks and they help write it. But again, we really try to keep it, like, in their voice. Like, when I read them, I can tell who wrote each one just because I know the team really well based on just without knowing who it was. I'm like, oh, like that. That sounds like so and so. And we try to make them, like, actually help. Like, it's not like, again, some AI like, BS rewrite type of thing. Like, we're writing, you know, like, tips and tricks for interacting with the NetSuite API. And, like, let's go into the difference between, like, using their REST API and their SOAP API. And like, this is stuff that you only know if you've, like, really been in it. And I would rather do that. And Google, God bless with their new algorithm would rather rank that than, you know, another, like, integration tip kind of blog post.
[00:36:14] Speaker A: Yeah.
[00:36:15] Speaker B: So there's no. There's also no hacking this. Like, people ask me, they're like, you guys have so much website traffic. Like, how can I do that? And I'm like, well, we've been writing content for five years, six years now. So, like, it just takes time. And you got to write stuff people actually want to look at.
[00:36:28] Speaker A: Yeah, I'm curious. Maybe this is just sort of my hopeful romantic side coming out, but I was wondering if there's like, any hidden benefits for writing. And the kind of the way that I'm thinking about this is I can tell internally when I Write things. My personal thoughts are clearer. Like, not just the things that I've written on the page, but, like, actually the way that I think about problems is just, I think, much more organized and probably prettier to hear, like, internally. My. My internal voice gets nicer when I write things out. Like, it just gets more organized, less. Less kind of clutter going on inside my mind. So I was wondering if you've kind of seen the similar things in your company. I know it sounds like you're not doing a ton of the, like, external writing these days, but even in the writings you guys have done, am I just being, like, hopeless romantic with writing, or are there some kind of other benefits to writing that maybe aren't just traffic and search and reputation related?
[00:37:18] Speaker B: Well, I will say, especially when it comes to internal documentation, which is different than marketing, writing things down is important because you will forget how things work and how they work, especially from a technical perspective. Like, hey, it's really good to be able to refer back to that because, like, I did that six months ago and I forgot. I think, like, what you're alluding to is actually really individual. Like, what, like, what helps you solidify thoughts? And I know some people on my team, like, the writing super helps. Some folks, it's like diagramming. Some folks, especially marketing people, it seems like, like, like the visual aspect of it, like, decks and charts and stuff. I myself am a crazy person and, like, I just need to do.
Doing is like, you can give me a deck and I get nothing out of it. I need to, like, feel it and have, like, a personal conversation about it. With that said, you know, from a product perspective, I think having like, a product manager and a product org that, like, does write stuff down and starts to, like, formalize thoughts and sits with the engineering team to really go through what are we trying to do can be really helpful, especially when it. When folks start to get, like, really in the weeds to, like, zoom out, it's like, okay, let's go back to, like, the objective of this project. And it's not to be, like, mean or to, you know, be rude to anybody. It's just like, hey, let's. Like Sean and I, my co founder, I think, like, two of our most commonly used phrases at this company are let's zoom out or let's take a step back. It's like, oh, we've gotten, like, so deep. Like, okay, what are we actually trying to do? Like, let's just come back. And I do think that writing can help with that. Like, organize the thoughts and not make it feel so frenetic. Especially when, like, I am a person that just operates in kind of a frenetic way. It's good that we have people on the team that are more like you, that can, like, be like, great. I just had a meeting with Christina. She, like, machine gunned a bunch of things at me, and now I'm gonna go and I'm gonna, like, take a walk and write stuff down, and then we're gonna come back.
And my marketing team is incredible at me. You know, they know if I slack them, like, you got a sec? Get out the notebook. Because it's not necessarily that I have great ideas. It's just like, there's gonna be a.
[00:39:23] Speaker A: Bunch of stuff that's funny. Well, Christina, it's been so great having you. People want to learn more about you, what you guys are doing. Where should they go?
[00:39:31] Speaker B: Pandiam.com is the place for all the pandium things. And you can also look me up, Christina Flashan on LinkedIn. Feel free to add me and then you can follow along with all of my incredibly insightful LinkedIn posts about fostering cats and general sassitude on LinkedIn.
[00:39:50] Speaker A: Sassitude. Christina, thank you so much. This has been a great episode. I really appreciate you coming on.
[00:39:55] Speaker B: Awesome. Nice chatting.
