What's going on? Everybody? Welcome to another episode of Adventures and DevOps. You know, Warren, you were just saying it's okay to pause and take your breath and you know, collect your thoughts, and then I just hit the go live button. I was like, what am I supposed to do? So I just blurt everything out there? But hey, Warren, how are you? Yeah? Good, good, good life strategy, really all right, working working so far? Yeah, so I'm Warren S too.
Authors you know, thanks for having me back. Well again, I can't help but notice your your name, well, the saaspoton. I feel like there may be some punctuations saying there. Gosh, how convenient is that? I didn't even put that together? Because joining us today is Michael Zerker from Prismatic. You're the CEO and co founder of Prismatic, which is focused on SaaS integrations. Right, that is right, thanks for having me. What
a coincidence, What a coincidence. That's amazing. So I'm gonna start off with a really cool fact that I know about you that I just now. I'm now I'm terrified to hear this, right, because we are alive and now I'm serious. I looked you up on LinkedIn, and I saw that you live in Soux Falls, South Dakota. Is that correct? I do that. That's so cool, Like Souit Falls is such a cool area, but also like a really interesting place to have a tech oriented company, I
think. But I don't know anything about the community itself, just the landscape. No, you are you are right. It is not exactly a historical tech mecha, that is for sure. I built my last company here, and so you have a you know, pretty decent sized network from that company, which which got to scale and I acced it a while back, and so that's where we started this company. We're fully remote at this point, so most of us aren't in Sioux Falls, but but I am. I
guess, so I guess we can claim it to some extent. That's cool. On kind of a tangent there, do you find yourself And I asked this because I'm in a similar situation where I'm in a I live in a really small, rural, agricultural town. I think I might be the only tech oriented person in the town. Do you find yourself talking with like younger people in the community who are interested in getting a path in technology, like software engineering or anything Yeah, certainly, you know, I think I think
there's probably everywhere, but certainly Sioux Falls. There's there's certainly a ton of interest in technical fields, and we have a handful of you know, scaled tech companies here. There's an autonomous tractor company doing really cool things called called Raven, and some you know, some some cool businesses. So there's certainly plenty of like interest. But I think what's so interesting about where things have gone is that you could live here and work for work for anybody out of
anywhere. And I think that's more true in tech fields, specifically developers, et cetera, than it's than probably anywhere else. And so I think that really changes that dynamic that you can you can decouple your career choice from your
choice of where to live, for sure. Yeah, And that's a that's a very recent change, Like it certainly wasn't true when I started my career in the nineties, and then it sort of gained traction and then you know, Code, of course, I think was really like the theme that opened up that as a long term possibility. Yeah, I think, I mean we've been creeping that direction and then COVID fast forward to us a couple of decades or something, and you know, just by proving it can be done.
And yeah, I don't think the tech sectors broadly likely to go back. I mean, I know specific firms are doing whatever they're doing, but like I think, I think from a big get your perspective, the cat is out of the bag, right, Yeah, exactly, agreed. So
let's talk about SaaS is software as a solution. I would imagine everyone's had some experience with them, and like, sure, the big problem, I think, the one that you have focused on addressing is integrating with all of these different SaaS is because there's a there's a kind of like this theme in software development right now where a good portion of your application is likely powered by
bringing multiple SaaS vendors together to provide some of your back end. Would you say it's a fair statement, Yeah, I think so, I think, And I think it all stems from you know, customer, the customer need you know, any any software as a service, any SaaS company is delivering some domain specific thing to some customer, and I think increasingly, for a lot of reasons, those customers just expect that whatever solutions being delivered is just
in this like magical web where everything talks to every everything else, right, this like fully connected graph and and I think that's kind of been like creeping
toward true for a long time. But I think we've seen seen it happen in certain spaces and in consumer tech for example, and those expectations have broadened to the SMB space in B to B, the enterprise space even in B to B, and I think there's just more and more expectation that every point solution, every system of record just kind of like magically talks to each other. At the end of the day, guess where that burden got put. It got put on SaaS companies, on software vendors, you know. And
there are pros and cons to that whatever. We're not here to debate that. The fact is that's what customers want, and so you know, we're there. There are a lot of ways to skin that cat, but you know, somehow or another, you have to deliver that to your customer to stay competitive. There's an argument that the connecting of these integrations is the core value that businesses today are bringing, and that you can't be competitive by building
something. You've got to find the pieces out there. I mean, everything's been done before already for the most part, right, So the only value left is connecting them in interesting ways. And that's sort of like internal right in ways customers don't necessarily see. But then there's of course the external kind as well, where they're bringing their own sort of expectations on what their own system is using and wanting it to play ball with that. Yeah, I
think there are kind of two factors. I think the first is exactly what you said that, like, for a lot of solutions, a huge portion of the value is in their ability to connect other things. Secondly, I think customers are less and less willing to build those integrations themselves. You know, it used to be that in the small end of the market you'd use Zappier, in the big end of the market you'd use mules, Softom and everything in between. And if you're a big business, you have some it
group to do it. If you're a small business, maybe you're the one who connects things. But like that expectation was always put on customers, and I think customers are just back away from being willing to accept that to some extent, you know, and saying like, hey, you're you're the software people, go make it work and you know, And I think as a result, we're just seeing this huge trend or this huge just expectation of native
integrations. I think it may be a pendulum swinging the other way too, where sales is saying, hey, you know, of course we have integration with X, Y, Z other software, and then you turn around and be like, oh, we don't actually have that. What's the easiest way. Do we hire a team in some other country to build it for us? Or Oh, there's an automated solution that you know will come in and just connect this up for us. We don't even need an engineering department to
make that happen. Yeah, you know what I hear A lot is is a very similar, but it's often through the lens of like a product manager, where they're saying, I'm looking at our road or looking at our pipeline of deals over the next X number of months, and some percentage of them including integrations that we don't have today, and so the way I can unlock this pipeline as a product manager or an executive or whatever is to figure out, as you said, like how do we how do we get there?
And to a large extent, most most SaaS companies don't really care how to get there. They just need to get there in a you know, in a reliable way that that's actually tractable. And I think that has people looking at a lot of different ways of doing it right now, especially the ones that are VC funded, where speed is the only importance required it. Yeah, that's that is right. I think there's an interesting abstraction there, you
know, like when you're writing code hands on the keyboard. Part of the value that SaaS applications add is don't build something that is not unique to your product. You know, if somebody else has already built it, just buy that and focus on your core business. And I think making one SaaS talk to another is an extension of that. Like there's no need to have ten thousand people writing a you know, a salesforce to Google Drive integration. Let's
let those two guys go and battle it out. Or is that where you come in as Prismatic. Is that like your value add to the whole transaction? Yeah, so you know we are Prismatic is used by a SaaS company, whether that SaaS company is kind of on either end of that connection, whether you're the system of record that everybody's connecting to or whether you're a point solution connecting to the system of record, which is often kind of the dynamic
in a B to B environment. Regardless, we are a tool that can be embedded into a SaaS to make it as easy as possible to make those
connections. And the way that we always think about it is like, like you said, there's no reason for everybody to reinvent the wheel of the eighty percent of this that is the same no matter which industry or which toman you're in, Like, why in the world should every software company go rebuild the way to scale integrations, log integration, secure integrations, I mean, the
list goes on and on. Instead, we want folks to focus as much as possible blond the things that are actually unique in a domain, because a software company that sells software to egg tech is going to know tons and tons
and tons about ag tech. Put you know, ideally, they would put all of their effort, all of their energy into things that are unique to that because that's their deep experience, their deep domain knowledge that doesn't include, as it turns out, building yet another way to stand up in ELK stack to you know, to log integrations and some of the unique things related to it, right, And so I think wherever you can you can shove that
off, shove it, you know, into an ecosystem the better. That doesn't mean you can just offload your integrations completely, because it turns out integrations have a lot to do with the domain, but it does mean you can offload the infrastructure, the scaffolding, the tooling that it takes to go build the domain specific integration stuff. If that makes sense, Yeah, for sure.
And I don't I don't want to derail this, but I'm glad you brought up ag tech because my nephew is a farmer and like the amount of technology involved in farming. Like I hang out with him sometimes and he shows me like, oh yeah, this is our tractor and it's got GPS and it tracks how far you know, and at tracks where the next row of onions should be. Enough, Like I'm just completely geeking out over this because you think of farming and like, I don't think of farming as being like
a high tech industry, but it kind of is these days. Oh for sure. Yeah, I mean I think as we squeezed all the efficiency we can out of it, it's it's gotten bizarrely tech enabled in the best possible
way. There's some amazing things happening in eg tech today. Yeah, it's like the tractor tracks how many times you've lifted and lowered the bucket, and when you hit the maintenance threshold, it sends an SMS message out to the dealer and some guy shows up and say it's maintenance time for your tractor. I'm like, ah, yeah, okay, fair enough, I guess.
So. I'm always amazed when I see it, honestly, I mean, just the automation and the and the industry really does remind me of some sort of computer game, you know, Sims or Fell or something like that. It's just like, it literally seems like that from a you know, owner perspective. The number of actual people on staff at a farm is incredibly minimal. Yep. It's farming simulator, irl. We just connected it to the real world somehow. And now there's iron driving around out there. And you
make it a game and someone will pay actually to do that job. Right, They'll pay to drive your tractors for you. It might be hard on your fence lines, but they'll pay to do it. There's a new business here, I'm sure of it. Just you know, make the right interface right and chat dialogue on the right hand side. It's just you got a gold in there. I love it. I am curious about what the actual interface is for say Prismatic or some of the ones that you're actually integrating into
into your system. Is it providing a APIs that are somehow ubiquitous or you know, everything goes into Prismatic and there's some configuration there that has it redirected to the right integration and whatnot. You give me a good picture of that, I think, I'm sure people are interested in. Yeah. Yeah, So you know, we see a couple of different pieces of this equation. If you think about, hey, I'm a SaaS company and I need to
deliver native integrations to my customers in whatever industry they're in. The first is you have to somehow have the infrastructure to actually run those integrations. As you probably are aware, like integrations have kind of unique burstiness problems because of that
the nature of what they are. They're often scheduled run every fifteen minutes or at the top of the hour at midnight, and so like the first piece of Prismatic or something like it is just the infrastructure to run this stuff, and that includes security, and it's one of those things that like, the deeper you dig, the more you realize there's there's a lots of doing it well. And then on top of that, you have to have a way
to actually construct these integrations. And if an integration is you know, a bunch of business logic that is domain specific to what this integration needs to do, then you have to have ways to specify that. And at Prismatic we take the view that there are two distinct and both completely valid ways to do
it. One is by actually writing code, which in Prismatic land is just typescript using an SDK of ours that lets you, you know, kind of write the actual business logic pieces, but none of the stuff around it, right, Like, you want to just be contained to the part that's actually business logic actually domain specific. So code native is what we call that path, and we see that as I mean, just a natural way for software
companies to do some things. Then the other path is low code, which is the natural path for software companies to do some things depending on kind of which people inside of a software business are the closest to the domain specific stuff and are the ones who should be building and specifying these integrations. And so we see those as b basically equal but different paths to build the integration that can then run on top of that infrastructure that I that I talked about before.
So so what that gets you is a platform that can run integrations, monitor integrations, introspect integrations, alert on integrations, Uh, you know, all of that stuff. Then the then the then the third piece of all of this is what we call the marketplace, which is a actual like ux that you can put in your app. This is the only thing that a our customers, customers will see, and it's the ability for you know, to have a little like, hey, here's your marketplace of all the integrations
we offer. Go click connect on Google Drive or on you know, acme, ERP or whatever, putting your credentials and it'll turn on. And and that's another one of those things that like, I don't care which industry you're in, that looks substantially similar everywhere. It doesn't make sense for everybody to reinvent that the same way it doesn't make sense for everybody to reinvent authentication screens for example. And so you know, warrant you to to your to your
your ongoing concern. But uh, you know, we we we provide that such that it can be put into embedded in embedded you know, embedded inside of SaaS tools, and between those three components and all the things that support them, you have a pretty full featured way to provide native integrations. I
totally get the perspective here. I think our customers are similar, right, they want the Some of them, for sure, want the full integrated experience, hands off, like they don't even care if they're users see our interface for our stuff. But then there are for sure the other ones are like, we don't like what you did. We want to customize exactly how we want. I always hope that there's some sort of middle ground here where the
configuration makes sense. But then there is this sort of weird fine line of that's too specific for what we need. We need the code first approach for sure to make it happen. I mean it makes a lot of sense. Yeah, you know, we think a lot about the integration platform Space originated and and most of the you know classic ipass space, which is integration platform as a service. The Classic ipass space sells to it groups generally sells to
businesses for use internally inside that business. And you know, if that is your if that is your goal, if that's what you're doing, then you're going to have a certain outcome around. You know, low code is the thing that makes sense because we're dealing with you know it teams, et cetera,
et cetera. But if instead you're in the space that Prismatic is in, which is called embedded ipass and is a new category, and you are selling exclusively to SaaS companies or to software companies, you come to a pretty different conclusion on the kinds of tools that are going to enable them best. And sure low code is part of it, but every developer ever who has touched anything related to low code is terrified of painting themselves into a corner and
being stuck on the last five percent. Right, Hey, it was really easy for the first ninety five percent, and then it was impossible for the last five and guess what that rounds to zero. Now I'm going to just
build it myself. And so, you know, the way we always thought about this is like, if you're selling to SaaS businesses, if SaaS businesses are who you're serving, then you've got to always have an escape patch and about the best escape patches straight down to typescript, right, like just just let them, let them pull the rep cord and write typeescript where they need to, And that has served us very very well and I think has worked
very well for our customers. Yeah, I've definitely seen the concerns over the low code interfaces for a lot of things. I mean, even at the app level, they're out there, but yeah, like you said, if
you don't know what you're doing, they're great. But if you're anyone who has any experience of writing an integration using anything else that promises only low code and doesn't give you those options, it's just becomes a huge burden at some point when you realize, hey, our business logic has requirements here, and it like I need to do a thing and there's no documentation or no expectations about how that actually works for real in practice. But with like an SDK,
that's like a huge advantage. Yeah, and you know, what we see, really, what we've seen be really successful is businesses customers of ours that will that will use developers to essentially build like low code extensions or low
code blocks that can then be used by other folks. In their organization, and so you kind of have this thing where like developers can be the leverage to make the low code tool form to the business or form to the industry, and then you can use other people inside the business to build the you know, whether it's a custom specific integration or maybe you just need to build
a hundred because you're an integration heavy space. My last business built six hundred integrations in the public safety space, which is law enforcement and nine one one centers. So like, the way Prismatic came to be is that my co founders and myself spent I was there for sixteen years, beam my head against this integration wall and came out of it and said like, dang it, we're gonna go. We're just gonna go build the thing that we always wished
we had. So if you're in a space like that, you probably don't want developers to build six hundred integrations. You want to developers to build a set of tools. In my now biased view on top of Prismatic, but like, regardless of how you get there, somehow build a set of tools that enable other people in the organization to go build those six hundred domain specific
things. I really love that you're leaning into the marketplace, especially because one of the biggest problems I've had with other low code or even code as a platform tools has been that they care a lot about who their customers are, but they don't pay a lot attention to the success of the marketplace, which you really have to have to see a multi sided marketplace where there's the consumers and the people that are building the code and those building blocks and the If
you have a platform that's not attentive, like not attendive to that audience, you will not get high quality building blocks, which means your customers will all suffer. So really an attention there on doing that effectively, like you know, good, good job. Like that's not a there's not a trivial insight to have to really focus on that aspect because they're not your customers, you know, primary right, Yeah, it's interesting because a big chunk of our
solution actually serves our customer's customer. And you know, we we internally are really careful about talking about customers are our customers. Customers and organizations are our custom because otherwise nobody knows who you actually mean when you say customer. Which was one of the first problems that we like ran into in this business is Okay, apparently we have to invent a word for this because I knew that there are two very different things. I totally get you one hundred percent.
I think it's a you know general B to B T B problem or you know B to B B C. Like is this thing we went with, I think, uh, you know, fundamental end user and administrative user for the platform, you know, so like offer an end user and an end user, and we use that everywhere in our but yeah, it's it's not trivial to explain that. Yep. Yeah, it took us a little while to get our head wrapped around kind of all the different personas and where they
overlap and where they don't. And thankfully that was years ago now, but it was certainly a muddy time. So I think another one of the problems with building your own integration is keeping up to date. You know. It's one of those things where like you build this integration yourself and then the company wheny you're pulling that data from they change their API or they have a new feature, but it's only available in the new API and you're on two versions
back. So yeah, I'm assuming that y'all have like a process where you're continuously working closely with those those integration partners and getting updates for like when they're releasing new APIs, you're updating it so that in the Prismatic platform, your
customers customers automatically get those updates right away, right. Yeah, So we certainly that's part of what we manage is you know, on the things that we are in what we call our public component library, meaning those like connectors to common third parties, we take responsibility for upgrading those as necessary, and when Salesforce deprecates whatever, then we move, you know, move things forward.
What's what's interesting kind of around that though, is that, uh, you know, one of the insights we had fairly early on that has proved out is that, I don't care how big your library of connectors is, You're never going to have the thirty thousand SaaS companies that are in vertical markets in SaaS in you know, and that's just in the United States much less, you know, worldwide, and so many many, many of our customers build connectors that are not connectors that we built, and so you know,
we we can build to Salesforce and HubSpot and service now and you know, the list goes on and on, right, But it turns out an early conversation with a customer or prospect I guess you know, like four years ago where he was in the in the vertical markets from Australia, in the vertical market of liability waiver software for go karts. Okay, So like that is
about as narrow a vertical market as it gets. And it turns out he had competitors who are also in the liability waiver market, right, So, like, what what you realize is like there are so many vertical markets and they're getting narrower and narrower, in narrower as those solutions get better and better and better. One of the ways they get better is they get more domain
specific. And so you now have so many vertical markets that are so narrow that there is no vendor ever on the ipass side, in betded ipass side that is going to have every connector you could ever have. And so one of the things that we did, kind of to your point, is build a set of tools so that software companies can build their own connectors in a really nice way. Turns out it's the same set of tools we use to
build our public library. But that includes ways to deal with versioning, like you mentioned where like how do I deal with the fact that maybe salesforce updates to a new API version. I can't just make a change and magically have
three thousand of my customers get that updated. What if there's a problem, what if there's some nuance, What if I have SLAS with enterprise customers that say you can't update our software without notifying us, And so like, one of the values in one of those sneaky things that people don't think a lot about with integrations until they run into it head first, is how do you deploy integrations to three thousand customers, but then manage the rollout to those three
thousand customers in a way that actually serves your customer base, which is going to be different for every SaaS company, And so like to your point about versioning, Uh, It's it's true that connector is a version, but it's also true that then that causes all kinds of downstream versioning, and we thought
pretty deeply about how to handle that. It's never perfect, and I'm not going to say we have a silver bullet, because that's just a hard problem for sure, but I certainly we have a lot of tooling around it. So in your in your marketplace, you have the connectors that y'all have written, but then you are are the ones that other people right also available there, like for the company that has the go Kart liability insurance connector. Uh
yeah. So what's interesting is that you're right. We build this like library of connectors that we provide and everybody uses and we maintain, and it's you know, it's kind of the big SaaS apps that you'd expect. I think there's a couple hundred of them at this point in that library, maybe one hundred. As companies build their own connectors, they generally want to keep those
private because they generally see it as a competitive advantage. If you're that guy in the gopart car market and he goes and builds connectors to whoever he needs to build connectors to, he doesn't want to put them in the library and then turn around and have his competitors get them for free by just like becoming
a customer prismatic. And so we actually at this point we have hundreds and hundreds and hundreds of custom connectors as we call them, that have been built by our customers that are internal to their environments, and they put them in their own repositories, and they put them in their own CICD pipelines, and they release them to Prismatic as they would any other software, but they're they're private to them, and it turns out that's what people that's what people largely
want. Now. That said, if somebody goes and build something that's common and they're willing to share it, we'll often take that on and then we'll
take on responsibility for maintaining it going forward. And we've done some of that, but you'd be surprised just how many of these like niche custom connectors there are to systems that I have never heard of and we'll never hear of again that like that aren't in the public library because because there's a competitive advantage to keeping them private, and and I guess to kind of elaborate in the marketplace, the thing that that our embedded marketplace allows is for a soft customer of
ours, let's say it's like acme erp it lets. Acme erp deployed to their customers a marketplace that includes some things from us, some things that they built themselves, some integration workflows that they built that are domain specific. And then it just feels like, oh, well, this is the acme er pre P marketplace. It's not the Prismatic marketplace. It's not a generic integration
marketplace. This is the acme ERP marketplace. And there's a huge amount of power in that, like curated here are the thirty things you actually probably care about, customer, H got and and that's and that's a that's a big part of what Prismetic enables for our customers. AH got you? That makes sense? Yeah? Is acn ERP a real e r P? No, no up in the RP. It turns out here's here's another thing that I have learned. It turns out there are ERPs for every industry you could possibly
imagine. There are there are chiropractic ERPs. There are long mowing ERPs. There are like the list goes on and on and so like a big and and those tend to be the system of record in whichever customer uses that ARP. And so those ERPs tend to either be integrated to a lot or integrate to a lot of other things. And you know, in some ways, in my previous company, we were we were an ERP for law enforcement to some extent. They didn't call it an ARP, but that's kind of what
it was. That's why we had to integrate to so many things, and so many things that had to integrate to us. Is we were like the center of this elaborate hub of activity inside of you know, a police department or a nine one one center or whatever. I think, well, you may have fallen into that. This is a good cartoon out there where the characters were attempting to come up with a name for their company and everything was already taken. So you know, I imagine there is an acme ERP out
there. I could like, I would probably is. I wouldn't be surprised. Uh. I was just sorry, go ahead, I was just gonna say. You kept saying it, and I was like, dang, that is the coolest ERP name ever. It's much better than I saw in Microsoft's docs for the longest time Contoso dot com. Yeah, And I'm just like I remember as a very early on engineer being like, what is that? Like? Is that a real company that they're using as an example? Does
Microsoft? Is that actually what I'm supposed to put in? Uh? The integration for I mean, I think it was like authentication at the time. I'm just like I don't understand, like, could you not have pulled something? I think we use we literally use our company name in the example. I think it's like author is dot your domain dot com, like wherever. It is, like, there is no question that this is not a real
thing. So way back in the day. This is gonna date me, but Microsoft used to use north Wind the company and all of their examples. So, like anybody who was around software in the I guess it would have been the late nineties or something early two thousands, it was all like north Wind database, north Wind Trading Company, north Wind, this north Wind that I have the same thing where it's like, okay, tell me about this north Wind because it is ubiquitous somehow, and then it turns out Microsoft just
made it up. I probably still have the north Wind Microsoft access database. Yeah, exactly, exactly, because you didn't change the name. You know, when you were installing it the first time, you're like, oh, that's the depault. I'm going with that. We're like, that's what it was bost to name it, right. The field says enter name and the examples as literally northwest north Wind is the name. The doc said it.
Yeah, and there's some point in your career where we're like, you don't have the confidence to change it. You're like, I'm typing north Wind because I don't know where this is going to come back up. It works in
the example, so I'm gonna stick with it. I definitely turned into the domain name that's gonna get used, which you know ends up other places and then it becomes an internal company you know, secret nomenclature for that project that you're working on, will right, you know, just you know, you keep bringing this up. And I think, having built so many integrations in my past life, one of the things that always really bothered me was itempotency
of dealing with them. And I don't know how much you see this, but I can totally imagine that the it's not just the API format or schema like you mentioned will with the version ing. There is some really gnarly bits when it comes to just things that you would normally expect, even from very large companies, in how their API works. I think item bonzy and rate
limiting are huge ones. Any any like you know, secret sauce advice there that's just like you know, you definitely don't want to think about that. I mean, I don't know that I have any secret sauce. I think I think those problems and many other like others like them are the classic like everything is easy until you're six months into it, Yeah, for sure.
Like I think we all make the problem. Developers, engineers and just like people in general all make the problem that anything we haven't done ourselves, we just like consider much easier than it actually is, because what we see is the obvious surface level stuff and it's like, oh, well to integrate this and that it's two APIs, I just need like a lamb in between that talks to those two APIs. This is one hundred lines of JavaScript, and
I'm done. And then you realize, as you said Laurren, like item potency and pagination and rate limiting and rate limiting that is sometimes very complex. You know, it's not always like x per second. It's got burst limits
and it's got you know, different limits by time of day. And so I think at Prismatic, what we're essentially doing is just continuing to build scaffolding and tooling that solves those problems in ways that let developers or what we call technical non developers to kind of like use those tools to not have to reinvent the wheel. Now, can I make you not? Can I Can I keep you from having to ever think about item potency and and integration in a
B to B SaaS company? Probably not. Can I make tools to make it easier to implyor make it just like drag that thing on there, say that we want to store the you know whatever. Yeah, there are all kinds of ways that we can make that easier. And I think that's just a it's a perfect and classic example of this is all really easy until you're actually in the in the depths of it, and then you just keep keep
digging and digging and digging until you wish you hadn't started. You know, if you can make it so that I don't ever have to inspect an HTTP two hundred response to see if it's returning an error object instead of getting an HP four hundred back, it'd be great. Yeah, well you've worked with one of those. Yeah, And again, there are no silver bullets to these problems, right, like everybody dreams up their own craziness. We've seen
everything you can imagine. You know, a similar A similar vein is the number of ways that oh OFF two has been bastardized by APIs and by SaaS companies like I we may eight a standard. Guys, it even has like four different standards in the standard pick one. Uh, you know, but every everybody makes up their own stuff. Sometimes they expect an act pack. Sometimes they expect an act pack with a certain like hash in it, like
it's it's insane. And so at this point we have ANF two implementation that does o off too, but that's you know, one twentieth of what it does. It's all the bastardizations that are the hard part. You know. I love I love the brothers up. I mean, so I'm actually in the IF working group for for a lot, so you know that that's okay, that's one thing, and for sure they're like the implementations go go everywhere, like people say that their standard and they're realistically not not even clear it's
not just yeah, and then having to deal with that consequence. There's a lot there. I mean, we've built integrations for our customers in the same exact way, specifically just for the OAF, so I can imagine, I mean, just way more complex space to actually have to think about the whole
API and not just this small little off piece. Yeah, you know, the authentication piece is complex enough that there are players in this space, not prismatic, but other players that see authentication as most of the value that you can provide, and they'll like their connectors are basically just the authentication and then sling whatever you want at it. And for some kinds of problems, that probably is a pretty decent solution. It doesn't, in our view, solve
enough of the problem though. Sure it's complex in and of itself. No, I mean we actually went there. I mean, that's actually one of the things that we offer in our platform. It's not one hundred and fifty just because it's not that number. It's much less than that. But yeah, for sure, it wasn't one of the ones that we did recently.
But I do remember working for a company where it was for sure a two hundred response coming back, and the error whether or not was successful or not was there was a URL in the body which pointed to I kid you not a PNG on a website, and the color of a circle or the shape on there would tell you whether or not it was an error. Like sometimes it'd be text. But there's no way you're gonna ocr that to figure it out that that is. That is what I have not seen yet, Warren.
So, uh, congrats. I image recognition as air as air handling is something. He's laughing. I still I still get, you know, flashbacks to how how bad this was, and I'm just like, what do you want us to do? And this was like way after we've already moved to micro services as a company and gone much farther than that, and we still had teams that were building solutions that that had this stuff. And it's great to know that in a lot of cases there's a company out there that
would actually just you know, have to inspect those images for me. Yeah. I guess, uh, that's that's my lot in life at this point. So, I mean, you could use like Amazon Mechanical Turk and send the you are there, we go them and have somebody click the URL and then reply back with whether that was successful a sponsor and error response. Well, let's just let's take it all the way down. Let's just not even have APIs. We'll just have Mechanical Turk and and access database and they can
just they can just enter everything. Absolutely, we need to bring more aucrosoft access back. Is that even still any product? I honestly don't know. I'm sure, I'm sure it's one of those. Like it's probably still running power plants somewhere, you know, because that's how that that's how that works, right, Like, once the thing gets enough ubiquity. Uh, it's
it's pretty hard to ever deprecate it for real. That might be a state secret somewhere that they're actually using, you know, a legacy version of access database. You should not spill that information. Uh, that could be a supply chain attack coming in the future. Yeah, sorry, apparently. Yeah, So we are live streaming. So if you were watching the live stream and it suddenly got interrupted, it's because we stumbled across the topic we weren't
supposed to talk about. So whenever you're creating the public integrations that you have, what's the process of deciding who you're gonna who you're gonna integrate with. I mean, I think there's always a lot of nuance to it. But I think just broadly, we're looking for solutions that are that horizontally serve SaaS
companies or horizontally relevant. I guess to SaaS companies rather than some specific vertical so like we could chase let's we talked about Agitech before, we could chase the players in eg tech, and we could have one hundred and fifty or two hundred connectors just in ag tech if that's what we wanted to do. The problem, of course with that is, well, now you've built an embedded ipass for ag tech, and that's probably not a product that's gonna to
reach in US critical mass. And so we've always looked for the things that serve horizontally. There are some really obvious ones, like go look at the list of the biggest thirty software companies in the world or SaaS companies in the world, and you're going to find, you know, many of them that are on our connector list. Salesforce hubspots is now you know, the list goes on Oracle, et cetera, et cetera. I think from there, though, you can kind of take the like we want to we want to
serve folks horizontally. That doesn't necessarily mean the biggest ones. It sometimes means, you know, in integration heavy sub markets, which one seem to be the most horizontal. For example, UH and and you end up with things like the sales marketing category or the sales marketing vertical has a huge integration problem, you know, and there are solutions like segment that basically just do that.
They're a little more of an ETL, but it's similar. So we have a bunch of sales and marketing tools, some of which are much smaller than the service now is, et cetera. But because that space is so integration heavy, it makes sense. So I think, you know, we're weighing a bunch of different things. And this is the challenge of being a product manager is there's never a there's never an exact formula to spit out the
answer. I actually heard a different thing when you said that, which is, if you are planning on building a platform embedded ipass as a service for a specific market, you should consider trying to partner with prismatic and use it as your fundamental under under a layer because be generic and go specifically into ag techs or ed tech or you know, sales, et cetera. I think there is absolutely a future where a space like ours ends up with people who
pull it in. We always talk about it is like pull it into a domain like customize it for that domain and then have the you know, Prismatic, egg Tech or whatever. And I think, I think you're right that as platforms like Prismatic get better and better and better at being the being the guts. But we don't know any I don't know anything about egg tech aside from the tractor conversation we just had a half an hour ago. People who
understand those domains really could do interesting things. And we have a couple of partners doing things kind of like that in a couple of spaces, and I expect to see that pull up, right, Although we shouldn't talk about a tech because I'm totally excited about going and doing that now and just spending my day driving around fields to tractors to reboot them. Like that's a good time
waiting to happen for me. You actually want to become a tractor repair man and get the uh you know, your phone hooked up to the legacy SMS technology and get those messages. You may never see another human being the rest as long as you live, if that's your path, like you know, thrown me with a good time, So not seeing if another human may be a pro for some The con is I think we've now waited into the right to repair debate. Uh, you know, a huge, a huge seing
with tractors. Is that mostly not repaarable now, is the way I understand it. Uh. You know, they've gotten so technical and the such closed walls that I think you basically can't be a tech that just drives around and repairs tractors now, which legislation quite hot, But I don't know where. I don't know if the past or didn't pass. I just I remember the debate it very well did may have passed. I imagine it will take a
little while to filter through the industry. I mean, if you're if you're subscribed to like the the ag tech RSS feed, I'm sure you know the answer to that. But I remember that. I remember the conversation. Yeah, and I think that it went that they couldn't stop you from working on your own tractor. But like both of you, I don't know for certain that that was the answer. Yeah, And it's one of those things where you know that the skeptic in me wondering what does that? What does that
mean? In practice? Right? Like, I mean, you know as well as I do. You got a bunch of embedded micro controllers on a tractor with a bunch of like sea or rust or something built on them fifteen years ago. Okay, so I can. I can open the panel and poke at it, but what like, do I have a j tag programmer for this thing? Like it's uh, you know, it seems it seems like a stretch as technical as they've gotten. I mean, the old ones I think are easier. You know, you can try to find on eBay
some part that that exact thing and you throw it in there. I think the new ones are really the problematic. They're so well integrated that even if you have the right to do it, there's no expert out there outside of the company who actually even understands what that is. And have you tried to go through manuals on like how Windows ninety five was actually built and like read
through that. I mean, I'm sure some people have gone through that and be like, I know every single bit that's here and would be able to understand it. But it's it's its own sort of problematic situation of bean to try to fix a complicated machine. Yeah, and from that perspective, I can understand the manufacturer's desire to sort not. It's I don't feel like it's
a protection thing. It's like a maybe a self preservation thing, because they know what's going to happen is somebody's going to open it up, upload some rom that they got off of pirate Bay on there. It's going to brick it, and then they've got to do a warranty repair on this thing. I think part of it is definitely a mote around exposing it. I know part of it. It's definitely ip where if you expose that, there will be ten other companies who build that exact same thing, who promise that they
can connect to the ag tech network automatically and work exactly the same. So I can imagine, like all of the things happening here, I'm on the opposite side for sure, though I prefer open. I think there's a lot more benefit that comes from it. You know, I think we're building platforms
here. We tend to believe that in general, you don't have a competitive advantage just because you built it first, Right, it has to fundamentally be better, and having customers or users out there that are pushing you to get
better is for sure a better direction to go in. Yeah, it almost feels like they're still in the an environment similar to what we were in in the nineties, where closed loop competitive agreements and intellectual property was the defining factor in your business, not how much value you actually provided to your customers. Oh, we're going to get this all loop back around, and to do it today and deliver value, you need to have the most number of integrations.
Right there, you go full circle. Lauren, you're a geni, You're a podcast genius. So what does the future of Prismatic look like? Yeah, you know, I think we started with a really simple plan, which was we're going to build a thing that makes what we just finished doing at old company not insane. Uh you know, when I left there, sold sold it to a big investor. We had we had about one hundred folks in our engineering team, and about half of our resources were on integrations.
There's like no CEO or a product manager or anybody really who wants to see that on a slide and think like, yeah, that feels right. And so like, you know, we started out just to say we're gonna we're gonna solve as much of that problem as we can. And we didn't even start with a real opinion about what shape that solution would take. And you know, that was five years ago. Now we built, you know,
an early product, iterated with customers. We're now scaling the business and you know, are growing pretty quickly, and through that, I think our viewpoint on what shape that solution takes has continued to evolve. I think as you get more customers, I think is the category evolves. I mean, our category didn't even have a name until about three years ago, so it's
it's certainly a fast moving place. I think some of our original you know, ideas about what was important have turned out to be less important, and vice versa. You know. I think we will just continue iterating on that, like core belief that there has to be a solution to let software companies connect their products to the other products their customers use as easy as possible.
And I think we're mostly agnostic about the shape of that solution. I think we're mostly agnostic about whether it's more code or more low code or both or like you know, we see so many companies that get really opinionated about that, and we certainly have opinions about where different pieces of the solution make sense. But I think to some extent, we're just looking for a solution. We're just iterating toward a solution, and we're pretty willing to take that wherever
it goes. So I expect for the next few years we're going to keep with exactly that same mindset. We're going to keep building fast, We're going to keep working closely with customers. We're going to keep you know, iterating on the code native side, iterating on the low code side, continuing to scale the infrastructure because we keep getting bigger customers that keep inventing new ways to do crazy things with integrations, and I think all of that in and of
itself is going to keep us really busy, you know. So as long as all of that keeps serving customers better every day or at least every week, I think I think we'll absolutely be doing that. I think you did something with genius here. Actually going a little bit further, as companies have engineers on staff called integration engineer or like sometimes they're in the customer success role.
So I can imagine as long as people are hiring for that position, they're not necessarily utilizing this great resource that's out there instead right, you know, instead of hiring an engineer it's probably a lot cheaper to even go out in a lot faster to integrate Prismatic in the long term. Yeah, and a lot of the actual end users in the SaaS business of Prismatic are integration engineers or integration specialists or you know, they have a million different titles.
But you're exactly right, like we're we're a platform that can to a large extent, enable those teams independently so that they're not as reliant on DevOps for example. They're not as reliance on core developers, for example, and they have a platform that's kind of like their sandbox to go build their stuff in
and that has worked extremely well. Like we're, we can provide a huge amount of leverage in there for a huge amount of value for those teams, and sometimes let those teams get structured in different ways where you know, you'll you'll hire for a different profile than you otherwise would because it turns out they don't need to manage a Kubernetes cluster to you know, to deploy integrations, you know, and you can instead focus on more domain expertise or more like
API expertise or things like that. I like to hear that you're sticking with your core value proposition, because that's one of the things that you know, it's almost my entire career working with startups, and that's always been the big struggle is for those that actually make it to the part where they know what their core value is. After like achieving a moderate level of success there,
they tend to wander off somewhere else and do something else. And My Fitness Pal is my favorite example of this because you know, when they got started, it was all about just tracking your food, you know, put in your food and it gave you the stuff there and they were hugely successful at that. But today if you open the my fitness Pal app, you have to navigate through three different screens before you get to the to the screen where
you do the core thing that they do. So I'm excited to hear that you sticking with that and that you're not you know, you haven't gotten shiny objects syndrome and have gone off to chase something else. Yeah. I think
there are rational reasons at some scale to start diversifying a product line. I mean, at some point you've saturated a market, for example, and if you're going to keep growing, you have to you know, somehow diversify when when your target market is what prismatics target market is, which is essentially all software businesses worldwide, there is no risk of saturating that market anytime soon, right, So, like, I think, we know this is something that
we set out to do, we know that we're good at it, we know that we've thought really hard about it for years and years and years. Why would we spend our time on anything else? I think is basically the way that we see it here, and I think we will just keep doubling down on on that and keep serving a bigger and bigger chunk of that market every day. There's a it actually reminds me of a totally different vertical here
in the mutual fund and investment world finance. Okay, there's a writer Investors and Lynch who has a book one up on Wall Street and he calls it value based investing. But he actually coined a term here to mean that the the investors go out and they start to do extra things, or the companies that they're focused on actually do these things. His he coined it diversification. So you're you're diversifying what you're doing, but you know you're not good at
that next thing. You're not good at the next step, So you're really just making your whole portfolio worse in a way. I see you try if you're just not good at it, Well, I think, I mean, it's so hard to be good at one thing. Think of how hard it is to be good at four things, right, like, especially especially before you're at a scale where you can you know, bring in people to you know, to do some of that, and uh, you know, I would argue that that scale is pretty good sized. Yeah, I mean that's
a standard founder of mistake. I think that, Oh we were so survivorship buy us right. We were good one time. You know, if we just do the same thing again, we'll be successful a second time with a new thing. Realistically, it doesn't work that way. You got lucky. Maybe you know, you had help, you had backing, right, you had no need to do it. Your network was perfectly aligned for whatever whatever that is that made it happen. That's likely not the second true the second
time around. So you know, like like Will said, it's great to hear you know that the focus is there for Yeah, I'm I'm acutely dialed into the second founder thing. I you know, had a pretty good exit last time, and I was too young to retire, so I did this. But I went into this thinking like, oh my gosh, Like, I mean, so many things had to go right. I can look back over the sixteen years of my first thing and see all of the stars and
moons that had to align to make that happen. What are the chances that that happens you know again? And you know what, you realize it is going to be a very different path and it's gonna you know whatever. But yeah, I was I was terrified starting prismatic that like, you know, you had one good run and now you decided to just like do it one too many times and this one, this one blows up in your face. You know, you waste a bunch of years. But it's gone, okay,
I'm feeling better about it every day. And there's that paranoia that karma is going to go, look, we cut you some slack and now you're pushing your luck. We gotta put exactly And then there's I think there's a go ahead, Oh you go ahead. Well I was gonna say there's there's pressure there, you know, because like when you're a solo founder, like
ah, whatever, you know, it's just me. But then you start adding employees and oh yeah, and so now like you have like your employees, kids are essentially your kids because you're on the hook for making sure that they get provided for and that weighs heavily on your mind. Yeah, definitely
something you notice along the way. I remember I, you know, early in my career, and the last thing is we got to a decent size and it was a lot of young folks at the time, and they all started having kids and buying houses because that's what you do when you're you know, in your late twenties or early thirties or whatever, and things are going well. And I suddenly realized, like, oh my off, the amount of like capital outlay happening, you know, far flung from this organization is
kind of terrifying. We better not screw this up at this point. And that stuck in my brain for a long time as a I don't know, I was probably twenty four or something at the time, and that was a that was a grow up quick moment for me in a lot of ways. Hey, you're like, I'm twenty four and have fifteen mortgages. Yeah, exactly, exactly, so from a technical perspective, you know, whenever we talk about integrations, my mind instantly goes to calling HTTP APIs and getting a
payload. Hopefully it's a Jason payload. What is Is there a common pattern or is there do you have you done enough of these where you have like like just I guess, just some general advice on things about APIs or integrations that were surprising. I mean, I don't know that I was even surprised by this, because I'd seen enough pain along the way in my previous journey. But like there is every everything in the world is out there. You
know, there are still soap APIs. There are still soap APIs in giant applications, you know that are really important applications that run the world. And you know, there are plenty of rest APIs that don't give you JSON. Now there are of course some that do, but there are there are plenty that don't. There are also plenty of integrations that don't have anything to do
with httpa APIs. You know, it's like we're going to take a flat file and we're going to put it in ss FTP share somewhere, and we all laugh about that, and it does feel very antiquated, but like the huge amount of the world is run on things like that, and you know, I think, I think, uh, companies that really want to do integration as well can't just decide they're only going to integrate with things that happen
to have the most modern, most palatable API. I think instead you have to think about it from a customer perspective, and like, I don't care how we do it. What I know is that we need to do this for our customer. And if that means like reading some crazy, you know, flat file that's fixed with and you know, sticking it on an SFTP
share somewhere, then that's what we're going to do. There are also plenty of integrations that, you know, although many of the solutions may be in the cloud, some place that data has to end up is not in the cloud. You know, it's it's behind a firewall in a data center somewhere, or maybe behind a firewall in a Even if it's in a cloud,
it's like for some reason cordoned off from the public Internet. And so you know, something that Prismatic released relatively recently is on premise agent where you can run inside, you know, in doctor, you can run inside your environment something that we're remote tunnel to prismatic such that we can dump a flat file to your file share inside the thing, or maybe talk to an API that happens to be private behind a firewall. So I think the diversity of these
things is way more than most people give it credit for. We all think about the you know name hot SaaS app here that has a really cool graph q LAPI. That's what we think APIs are. The reality is some APIs or you know, APIs that maybe don't even meet the definition. Technically the word invented thirty years ago and are still really important parts of the world. So I think being flexible and finding tooling that lets you be flexible is maybe
the advice I would give. Yeah, I'm glad I asked that, because you know, I spend so much time in new tech startups that I just naturally think of Jason, APIs or graph ql or whatever. And You've got a great point. You know, like some of these legacy companies, their their footprint and their infrastructure is just so massive that I'm sure they would like to upgrade to something newer too, but the level of effort to do so
is just cost prohibitive, especially if what you currently have is working. And that is the truth of it. And I mean this is not always the most popular opinion among technical folks, but like, some of this stuff has worked for thirty years, don't I don't know that we really want to swap it out for a new thing. Like, you know, there kind of has to be this like barrier you cross for the things that you might get if the new thing works out well before you're willing to take on the risk
of a new thing. And do we all snicker and laugh at the flat file that gets put on an SFTP share every fifteen minutes around the clock that happens to run some mission critical thing at a power plants or whatever. Yes, we all sticker about that. Has it worked basically NonStop for thirty years? Yes, I can see, yeah exactly. So, like there are obviously really complex things to weigh there, and you know, obviously everybody's slowly
modernizing. That will go on forever, I imagine in technology, and so this stuff won't exist forever. But you aren't going to get you know, somebody to move that overnight because you thought it would be nicer if they hedographic QLAPI. It is that is, that is not how the world works, and so I think, I think again flexibility is really important. Yeah, for sure, Warren, do you see that a lot with was the authentication and authorization space. I didn't know which way to go with as honestly,
because I worked. I worked in a place where we were shipping around like gigabyte large doc files for customers manufacturing and so like. Yeah, for sure, anyone who's like, we were rest all the way until I got to this file and then you're not basically faring that and shipping it over an API, like, I'm just gonna laugh at you. I mean, realistically, how are you getting five gigs over the internet like that? For sure, you're compressing it it's some binary format and being sent like that. Yeah.
But on the off side, absolutely, for surely even these providers that say they're oh too compatible, they'll support XML and other ones. I mean AWS for instance a good example. Until recently, I think all their APIs were still fundamentally XML based. I mean the SDKs of course handled it appropriately,
but their XML requests and that's still fairly calm. The actually, interestingly enough, the default standard for OATH two, because of the legacy of how the Internet was built, supports URL encoded at www url encoded format, not JASON
by default, so that's the primary one that we have to support. I mean, by default we do Jason just because it looks nicer for everyone and debugging, but you get a lot of weird behavior, like if you don't specify the accept header, sometimes the docs will say, hey, we're XML, but the result will be some nonsensical other thing. So there is a lot of undefined behavior when not requesting explicit things. And a part of it
is, unfortunately, the legacy world that we're still using. Yes, the Internet is part of that legacy, unfortunately, so we're dealing with the consequences of that. I don't know if I have any particularly good stories because we're not shipping along a lot of data. But if you think anything related to a author open ideas bad, like, just take a look at the guts
of how SAMIL works. I mean, this is security over XML, and this is I mean, it's not the most shocking thing ever, but it gives you a good understanding that like literally every stas company out there that offers SSO as an option is doing XML in some way and you're not going to
get away from that. Yeah, I think that's right. The other thing I always think about is, like, you know, we talk about XML as this legacy thing, which at this point it is fifteen years ago it was the hot fangled whatever, right, and so like, I think what is often lost on us is we are building we're building legacy tech right now, and in ten or fifteen years we're going to dislike what we're building right now. Like that has proven to be true since the beginning of computing,
So I don't know why it wouldn't continue from here. There's always going to be legacy stuff. And I think, you know, a key belief that prismatic is that's the real world and we live in the real world. We're not making the nicest platform to make a really cool blog post to show that in two minutes you can connect this to this and move on with your life, because that is in the real world. The real world is all of
this complexity and all of this data and five gigabyte doc files. And you know, I mean like, because whether we like it or not, that's the real world. So the next time you're having a bad day, that's a thought to keep in mind. Just remember that if you're really lucky, ten years from now, someone's going to be looking at this code you're writing,
bitching about how it's legacy. Yep, they're going to be talking about this stupid graph ql thing where like there, you know, it's just I don't know what we'll do instead, but like graph ql will be will be chopped delivered, It'll be the worst thing ever and we'll all make fun of it. I'm sure the answer is there is going to be some sort of LM involved there, and I don't know I'm okay for that future yet. It's going to be an LM writing it back to an access database at the
bottom. It's always an access database. That's my new life. That's my new life. Theory awesome. What else should we talk about for integration's prismatic future goals? I think I think we I think we covered a lot of things. You know, if it's been really interesting to be at the beginning of a category. This certainly isn't the first time that that any company has
tried to build a tool to help companies provide native integrations. There have been kind of like several generations in the past of this, but none of them really got critical mass in any way. And I think, you know, we believed when we started this, and I believe, you know, tenfold that today that like the time is right for this category and these solutions.
And so it's been interesting to watch, like what didn't go right in some of the previous iterations of this ten years ago, eight years ago, whatever, why is now the time? And then just watching what it looks like when you start in a space and you don't know who your competitors are because they're not calling it the same thing you're calling it. Eventually people kind of
like consolidate around the name. In the case of our category, G two kind of like helped firm that up by deciding to call it embedded ipass, and several of us were using that term, and then they've used it and everybody kind of globbed on. But like just watching from from like goo, watching a category get firmed up has been really interesting and very different than my last experience. We were a disruptor in an industry that had been around since
the seventies. You know, there was no category to be formed there. We were we were like a better tool, we believed, but like we weren't. We weren't generating in a new space. And that's that's very much what's happening here. And you know, I think I think software companies, SaaS companies and developers are are well served to pay attention to the category.
Like even if there's some completely rational reason to keep this stuff in house for now, I think it's a category that is moving so fast and getting so much better all the time. Prismatic included in that that. I think we're seeing more and more people decide what people decided with authentication ten years ago, which is like can I build this? Yes? Do I want to build
this? Or is it the highest invest you yes? Probably not, I should probably focus on my core domain instead, right, And I think the same exact thing is happening in the integration space, and it's been fascinating to watch. I also think it's going to have a big impact on software companies because I think everything you can do to focus more of your energy, more of your R and D energy on core product, the more of that you
can do, the better you're going to serve your customers. And I think in a little way, this integration platform space and better integration platform space is a way is a way to do that, and I think software, because of this and a million other things, is just going to keep getting better and better and better at serving customers in their own niche and their own neurow verticals better and better all the time. For sure, what was the first
integration you built for Prismatic do you remember? Oh, that's a good question. Probably Salesforce, which to this day is our use connector. I mean it's I think last I heard they had ten percent of the revenue in SaaS worldwide, So like that's a that's a pretty major, pretty major player obvious.
But you know, some of the earliest ones that we watched our customers build and go to production were things that like I literally don't remember the name of it was crazy ERPs and vertical markets, it was you know, sales tools in big enterprise stuff that were really important to our customers customers and therefore were important to our customers. And really early on we had validated this idea that like it is one thing to have a marketplace or our library of connectors,
we're never going to have the thirty thousand you have to have. And you know, since then, I've just been I've just been amazed at the kinds of things that our customers connect to because that's what their customers need.
And I think that's what's often lost in these conversations, are lost in the you know, in the the tech Crunch article talking about whatever is the like, Yes, it is neat that in the sales marketing space, if you build one hundred connectors, you can connect you know, some large percentage of that ecosystem. But the long tail is where customers are actually well served. And software companies have to serve their customers well, and that means the long
tail. And I think as not sexy as it is to some extent prismatic as a tool that serves the horizontal stuff really well out of the box, but we have spent a lot of time getting really good at helping our customers in the long tail. And that is sexy. It's not what anybody wants to hear or talk about, but I can tell you it's what makes what makes it's what makes tools at the end of the day, serve their customers
best. Sure, yeah, and I agree with you. I think we should probably make a a decision based effort to talk about that more because that is important to keep in mind in technology. You know that it's the technology is cool, and that's why a lot of us are here geek out on that. But you've got to do something that generates value along the way.
Yeah, I think that's exactly right. And fortunately, customers are pretty good at reminding us all of that, and product managers are usually pretty good at consolidating that and communicating it, and so you know, I think I think good software companies have a million ways to hear that feedback and respond to it. But yeah, I mean, at the end of the day, all the matters is how we're serving customers. Everything else is just the path right on cool? Well, should we move on to some picks. Let's do
it all right own? All right? Picking on you, Warren, which get Yeah. Today, I'm going to go with the book The twenty one Irrefutable Laws of Leadership by John C. Maxwell. And I absolutely love this book. I think this was one of the first ones when I decided that maybe I can be a leader too. I picked up and read and I wouldn't have expected that it would have been that interesting for me. But there have been some that were really cornerstone to how I think about leadership now,
things like the law of succession and the law of incomplete data. I love to think that I I'm only going to be successful as a leader if I can point to someone and say that person will replace me when I leave. And honestly, every organization I've been to since reading that, I, you know, keep looking at this and be like, where is your replacement? Where is your replacement? Everywhere? And that, you know, was my thought when I joined this podcast. You know, Will is just looking for
his long term replacement. Absolutely, it's like the Roman Senate. Somebody's going to stick a knife in my back sooner or later. Oh hopefully it won't be like that. Will. I can't wait to hear six months from now that Warren has stabbed Will and taken the podcast, right, like going to live in the same country? Right? Fair enough? Awesome, Michael,
what'd you bring for a pick? Uh? So there's a company called McMaster Car and an associated catalog that is just like the coolest thing ever for anybody who's ever made anything physical. And I think it's not known enough about you know, it's it's anybody who has a shop or bit, you know, a commercial shop or whatever's gonna have a McMaster car those big yellow catalog somewhere, But I think more of the world needs to know about McMaster cars,
So go to their website. It's like the rare catalog that is as educational as it is a catalog. You can go to the section on like leveling feet for a table looking to my right here, and they will explain to you all the different kinds of leveling feet and the different ways they articulate, and the different kinds of materials and the advantages of that, and then they will show you all the ones you can buy. And they have absolutely everything
under the sun. It's it's just the coolest, coolest thing for anybody who makes anything. So do they still ship the physical catalog only to people who get to like a certain amount of spend, And it's it's kind of become this cult thing where like it's kind of unknown what the algorithm is to get yourself a catalog. But they they resell on eBay, So when people every year they put on a new catalog and it has this big green number on
the front. They're on like one and thirty something or one hundred and forty something or whatever. And every year it's a new one, or maybe it's even more often than that, and so the people who always get a new one will put the old one on eBay and they sometimes sell for like fifty one hundred dollars because it's kind of become a status symbol to like have a McMaster car catalog. They managed to make their catalog like an elite scarcity thing.
That is, that is some branding right there, right and and there's something about having the physical catalog that is so satisfying, Like this is an experience that you can't get from a website, having that catalog and just flipping through it, you know, and finding what you need and reading up on it. Like that's a tactle experience that can't be replicated. And mcmastercar has
definitely nailed that. It absolute nailed it. They also have about the lowest friction ordering experience that I've ever seen, and I'm including Amazon in that, which has a very low friction ordering experience, Like it just magically shows up and they don't ever show you they at least unless this has changed recently. They don't show you shipping costs. They don't calculate shipping. It just costs exactly what it costs to ship it to you, and everything ships to day.
I think you can get one day, but nothing ships slower than to day. And they just like you just push the button and then two days later it's at your door no matter what. Uh, And you get this little invoice and it's just like all handled on the back end. It's definitely set up for commercial use. But right it's it's just the coolest company. Yeah, good call. I hadn't thought about them in quite a long time, but as soon as you said the name, like the memories just came
flooding back. Not always the cheapest place to get things, but you can find anything anytime and get it two days later, which which is just pretty awesome. Yeah. And and based on my experience with them in the past, like you can depend on what you order from them as well. Yeah, yeah, I think that's I think their entire brand is built on the like it's gonna be of the highest quality, it's gonna be what you wanted. We're gonna educate you to make sure you get the right thing. I've
never had a problem with them. Awesome. Dang, that's going to be a hard pick to top because that just brought back a flood of memories for me. But my pick is also going way back. I'm going to pick for those of you who may not know, there's a band called led Zeppelin that was popular and started in the sixties, popular in the seventies up into the eighties, really key to defining heavy metal as we know it. But like the songs that they did are not what you would think of when it
comes to heavy metal. But go check out led Zeppelin. The Immigrant Song, And if you've seen Shrek three, you've already heard this song because it's the song used when snow White unleashes the animals to attack in the movie Shrek three. And the only reason I know all of this is because I was scrolling through YouTube one day a couple days ago, and there was this video a vocalist coach reacts to led Zeppelin. And it's this whole genre of YouTube
videos where people listen to music that's outside of their expertise. And so this lady, who's a professional opera singer, was going to evaluate Robert plant, the singer of led Zeppelin, his vocals in this song Immigrant Song, and the song starts and she immediately stops and She's like, wait, I've heard this before, and then goes and finds the YouTube video from Shrek three where snow White is singing the song and she was blown away because she thought that
the song was written for Shrek three, not realizing the Led Zeppelin song from the seventies. So that's my pick. I love it. Yeah, good times. Well Man, thank you so much for being on the show. This has been a really cool chat, fascinating, brought back some old memories. Thank you for it's been a pleasure. Yeah, it's been so much fun. Born thanks again for joining me on the show of course, and then to all the listeners out there, thank you all for listening. Appreciate
you being there and we will see everyone next week. M