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