205 - Everyone Says They’re the Missing Layer in Enterprise AI, So I Asked Solid’s CEO How He Proves That in a POC

WEBVTT
00:00.258 --> 00:04.062
Hi, this is Yoni Leidersdorf, co-founder and CEO at Solid, and you're
00:04.562 --> 00:07.089
listening to Experiencing Data with Brian T. O'Neill.
00:09.740 --> 00:13.645
Welcome to Experiencing Data. I'm Brian T. O'Neill, a design-powered
00:14.145 --> 00:16.792
product consultant and founder of Designing for Analytics.
00:17.373 --> 00:20.710
Since 2018, I've interviewed over 150 founders,
00:21.226 --> 00:24.609
product and AI leaders, and VCs working on the next
00:25.109 --> 00:27.879
generation of B2B analytics and automated intelligence products.
00:29.033 --> 00:32.626
Unlike many technology podcasts, my show looks at the human side
00:33.126 --> 00:36.667
of data-driven products, how buyers evaluate them, how users
00:37.167 --> 00:40.917
experience them, and how to avoid the trap of building a technically right
00:41.222 --> 00:44.670
but effectively wrong solution. Every 2 weeks or so,
00:44.927 --> 00:49.112
I'll dive into the UX design and product strategy challenges that
00:49.225 --> 00:53.122
come with building complex intelligent software and the changing role
00:53.170 --> 00:56.907
of product strategy at a time when engineering is getting faster and
00:57.003 --> 01:00.440
cheaper. If you want to turn your analytical sophistication
01:00.954 --> 01:04.651
into a human-centered product that people can actually use, trust,
01:04.812 --> 01:07.634
and buy, this is Experiencing Data.
01:15.350 --> 01:19.217
Welcome back to Experiencing Data. This is Brian T. O'Neill. Today I have Yoni
01:19.314 --> 01:22.762
Leidersdorf on the call from Solid, the founder and CEO.
01:22.810 --> 01:23.616
How's it going? Hey, Brian.
01:24.259 --> 01:26.434
Hey, great, Brian. How are you? Thanks for having me.
01:26.986 --> 01:30.606
I'm good. What the heck is Solid?
01:30.655 --> 01:33.033
What is the missing layer in enterprise AI?
01:34.371 --> 01:35.323
Everyone says that.
01:35.984 --> 01:37.645
Yeah, everybody's the missing
01:37.742 --> 01:41.692
layer, but we are actually, we're truly, truly the missing layer. We're the missing layer.
01:43.224 --> 01:46.545
Not a missing layer. Not a missing layer. We're the
01:47.045 --> 01:50.273
missing layer. So basically enterprises want to do AI.
01:50.354 --> 01:52.425
Everybody wants to do AI. Some just want to do AI because it's cool,
01:52.441 --> 01:56.057
but some want to do AI because actually
01:56.557 --> 01:59.526
it's gonna give them real value. And when you kind of look at the real
02:00.026 --> 02:03.910
value in AI today, the real value lies in agents
02:04.328 --> 02:07.958
that are actually doing work. So agents that are taking work that maybe
02:08.458 --> 02:11.459
is done by humans today and maybe is not, but they're actually,
02:11.893 --> 02:15.747
they're actually doing that work. They're actually automating it. Now for agents to be
02:16.247 --> 02:19.441
able to do their job, in most cases they need to use data.
02:19.602 --> 02:22.798
They need to use the organization's data. So imagine you're an insurance company and you've
02:23.298 --> 02:27.354
been around for, call it 100 years. At this point, you have a massive
02:27.386 --> 02:30.673
data estate that contains all of the policies to the,
02:30.897 --> 02:34.311
the current ones and historical. It contains a full ledger of all
02:34.424 --> 02:38.046
of your customers and, and many, many other pieces of information. And you
02:38.546 --> 02:41.605
want agents to leverage that. The thing is, at this point,
02:41.797 --> 02:44.186
your data is big. Part of it is messy.
02:45.404 --> 02:48.787
It's sometimes hard to understand. Different people have different
02:49.287 --> 02:52.971
perspectives on it. And so agents struggle to navigate your data.
02:53.131 --> 02:56.369
So if you're that insurance company and you want to build an agent that is
02:56.401 --> 02:59.990
actually actually doing work and doing real things for you, that agent
03:00.490 --> 03:03.740
is going to struggle to understand the organization's data. Now, at this point,
03:03.932 --> 03:07.778
everybody knows it, and everybody knows that in order to solve that struggle,
03:07.842 --> 03:11.383
that challenge, you need what's called a semantic layer. And so everybody in the,
03:11.527 --> 03:15.517
in the world right now is looking for semantic layers, and there are probably
03:16.017 --> 03:19.844
100 different semantic layers you can choose from. But what they realize very
03:19.860 --> 03:23.529
quickly is that constructing that semantic layer
03:24.026 --> 03:28.182
is a massive undertaking, a massive effort, because somebody needs
03:28.294 --> 03:32.370
to sit there and explain to the AI what
03:32.450 --> 03:36.076
each piece of data means and how to correctly use it. That's essentially
03:36.140 --> 03:39.237
built into the semantic layer. And since it takes
03:39.365 --> 03:42.558
so much work to do that, AI initiatives get
03:43.058 --> 03:46.489
delayed. AI initiatives don't take off the way that they should. And so what
03:46.989 --> 03:50.485
Solid is doing is we basically automate that process
03:50.741 --> 03:54.109
of constructing the semantic layer. Solid offers a semantic layer. We are
03:54.609 --> 03:58.421
a semantic layer, but different to our competitors, we automatically
03:58.453 --> 04:02.798
construct all the semantics that are in there, and we can do it across
04:03.022 --> 04:07.158
a variety of data estates. So instead of being,
04:07.510 --> 04:11.197
let's say Snowflake has a semantic layer, and if all your data's in Snowflake,
04:11.213 --> 04:14.564
then you can use that. But if you are a big insurance company and your
04:15.064 --> 04:18.459
data is spread across Snowflake and Databricks and Oracle and other systems,
04:19.214 --> 04:22.971
You need a semantic layer that can span all of that and can self-construct
04:23.471 --> 04:27.017
itself and self-test and self-maintain. And that's Solid for you. Solid is that
04:27.517 --> 04:27.579
solution for you.
04:28.687 --> 04:31.320
Got it. So putting my product hat
04:31.820 --> 04:35.238
on here for a second, um, the semantic layer, this is
04:35.286 --> 04:38.995
invisible in a lot of ways, right? You can't see this.
04:39.107 --> 04:43.908
It's a concept. How do you make something like this valuable
04:44.005 --> 04:47.632
enough to pay for? And especially because The way I
04:48.132 --> 04:51.526
would see this is you can get better over time. It's not binary,
04:51.558 --> 04:54.522
like you either have a layer or you don't. It's like, well, how comprehensive is
04:54.586 --> 04:58.014
it? And it gets customer questions right, but it's not so good at
04:58.848 --> 05:02.709
procurement questions or finance questions because we haven't done that part.
05:02.757 --> 05:06.138
So it's not binary. So how do you— is there
05:06.638 --> 05:10.111
enough market knowledge that people like data leaders just know that
05:10.464 --> 05:13.860
we're missing this? And generally speaking, we need to have one
05:14.293 --> 05:17.834
and it's kind of vague whether it's good enough,
05:17.979 --> 05:21.793
or is it— have you made it so obvious that
05:22.146 --> 05:25.047
you have— you have— there's a problem here, there's a lack of this, is a
05:25.547 --> 05:28.798
significant problem, customers can see and feel the pain? How do you do this
05:29.298 --> 05:31.972
with an invisible kind of middleware solution like this?
05:32.645 --> 05:32.725
Yeah,
05:32.885 --> 05:36.027
infrastructure has that problem sometimes, right? Um, you know, nobody,
05:36.107 --> 05:39.201
nobody thinks about their electricity until, uh, the power
05:39.233 --> 05:43.208
company shuts it off, right? Um, and so yeah, this is, this is infrastructure
05:43.240 --> 05:46.835
at this point. All the data leaders in the world know that
05:47.335 --> 05:50.850
they need a semantic layer. It's— we don't even need to do that education at
05:51.350 --> 05:55.169
this point. Everybody knows. Thankfully, even bigger players than us have done the education.
05:55.218 --> 05:58.782
Snowflake, Databricks, Microsoft, all the big players have educated their customers on
05:58.831 --> 06:02.283
this. At this point, every single data leader knows they need a semantic layer.
06:02.684 --> 06:06.330
Some business leaders know, by the way, some business leaders at this point who've been—
06:06.362 --> 06:10.071
business leaders who've been driving AI initiatives have now learned that they need
06:10.571 --> 06:13.907
a semantic layer, which is interesting because To them, a semantic layer is a very
06:14.051 --> 06:17.902
boring piece of infrastructure. Usually if you go to, let's say, a marketing leader and
06:18.402 --> 06:21.431
you start talking to them about semantics, you see that they fall asleep or start
06:21.931 --> 06:25.715
checking their phone. It's not interesting to them. But business
06:25.763 --> 06:29.277
leaders have also learned that for AI to understand the data, there is
06:29.325 --> 06:31.763
something called a semantic layer that needs to happen.
06:32.213 --> 06:35.726
So it feels like at this point there's very broad knowledge
06:35.790 --> 06:39.000
that semantic layers are necessary. The challenges we
06:39.017 --> 06:43.176
usually find are a few. The first one is data
06:43.676 --> 06:46.710
leaders who come to us and look at semantic layer as the goal.
06:47.288 --> 06:50.661
They say, I need a semantic layer. Say, okay, but why do you need a
06:51.161 --> 06:53.183
semantic layer? What, what made you think that you need one?
06:54.018 --> 06:57.086
And you find that the— it's not,
06:57.230 --> 06:59.640
it's not the correct way to look at it. It's not the right thing to
07:00.140 --> 07:03.639
do to look at a semantic layer as your destination. Your destination is
07:04.056 --> 07:07.678
taking real work and AI-fying it, using AI
07:08.178 --> 07:11.718
agents to replace human labor in some places or to accelerate human labor in
07:11.766 --> 07:15.853
specific processes. And a semantic layer is necessary for that. But a semantic
07:16.353 --> 07:19.459
layer as a goal is not the right goal. And so a lot of times
07:19.959 --> 07:22.264
when we get on calls with people and they say, hey, I need a semantic
07:22.764 --> 07:25.310
layer, we ask them, okay, why do you need it? And we encourage them to
07:25.374 --> 07:28.660
think about it in a bit of a different way. Think about the business use
07:29.160 --> 07:33.579
cases, what you're actually going to deliver to the business versus buying the infrastructure
07:34.079 --> 07:37.179
of semantic layer. That's the first thing that we find. The second thing
07:37.243 --> 07:40.875
is that if they haven't tried building
07:40.923 --> 07:44.367
anything yet, often they don't know how time
07:44.399 --> 07:47.956
intensive and how much work it requires to build a semantic
07:48.456 --> 07:51.027
layer. And so sometimes they'll come to us and say, okay, there's all these different
07:51.527 --> 07:54.730
options of semantic layers. What's the difference between them? And we ask them,
07:54.746 --> 07:57.893
hey, have you tried building something? Have you tried building
07:57.958 --> 08:01.056
an agent, building a mini semantic layer that the agent will
08:01.105 --> 08:04.701
use with your data? Have you seen what works, what doesn't?
08:04.942 --> 08:07.736
You know, have you seen the promise of it, but also the challenges?
08:08.490 --> 08:11.461
And if their answer is no, then we usually say, okay, this is what you're
08:11.961 --> 08:14.238
going to run up against. But we do recommend that you get your hands dirty
08:14.656 --> 08:19.135
before you start exploring semantic layers, because otherwise
08:19.408 --> 08:22.941
we— our experience is that they're not looking at it necessarily in the right way.
08:23.342 --> 08:26.603
And so if to summarize those 2 points, semantic layer is not the destination.
08:27.342 --> 08:29.783
And before you go and buy a semantic layer,
08:30.570 --> 08:33.782
build stuff on your own. Just get your hands dirty, see what's working,
08:33.798 --> 08:37.011
see what's not, because that will help you determine what
08:37.059 --> 08:40.271
you want. And then another related thing is
08:40.771 --> 08:42.857
that a lot of people come to us and say, well, I need a semantic
08:43.357 --> 08:46.872
layer because I want to enable chat with your data or talk with your data.
08:47.418 --> 08:51.417
Why? Because the CEO. of a 100,000-person
08:51.433 --> 08:54.627
company wants to chat with their organization's
08:54.659 --> 08:58.592
data. And while that's a very cool thing to think about,
08:59.620 --> 09:03.007
we find that it's not very useful because it's, it does great in
09:03.507 --> 09:07.421
demos and people are excited about it and projects
09:07.921 --> 09:11.482
are opened and funded to do that. But really the real
09:11.595 --> 09:15.287
true ROI doesn't come from chat with your data, doesn't come
09:15.787 --> 09:19.591
from letting your CEO chat with the data. The true ROI comes
09:19.607 --> 09:23.078
from AI agents actually doing work. Chat with your data is maybe a step
09:23.158 --> 09:26.419
in that direction. So I know it's a long-winded answer to your question,
09:26.757 --> 09:30.355
Brian, but basically at this point everybody knows they need a semantic layer.
09:30.773 --> 09:34.259
The challenge that we find is that they're not necessarily thinking
09:34.759 --> 09:38.003
about it the right way, and we find that we need to educate them what
09:38.503 --> 09:41.312
is the right way to think about it and what are the, what are the,
09:41.874 --> 09:45.485
the, the good drivers for for getting a semantic layer
09:45.985 --> 09:49.236
versus what are ones, what are maybe bad drivers or, you know, things you need
09:49.736 --> 09:49.830
to think about more?
09:50.599 --> 09:53.276
Yeah. So several things to unpack here.
09:53.340 --> 09:56.996
Thank you for sharing that. The first thing that comes to mind is,
09:58.054 --> 10:01.340
and as you said, there's a lot of competing solutions. Some of them are
10:01.840 --> 10:05.524
built into the store, you know, your database layer, your Databricks
10:06.024 --> 10:09.660
and this kind of thing. There's third-party solutions. To me, that raises
10:09.692 --> 10:13.444
the bar on the commodity challenge. Like why you, how are you different and
10:13.684 --> 10:17.065
all of that. But the second thing is, you talked about the
10:17.145 --> 10:20.847
difference between buying a tool, an output, a piece
10:21.347 --> 10:24.821
of technology versus a benefit, which is some change in the real world
10:25.321 --> 10:28.041
that we can see as a result of this thing that we bought.
10:28.682 --> 10:32.143
So what does an ideal customer
10:33.072 --> 10:36.982
look like in terms of when they come in and they're evaluating
10:37.014 --> 10:40.267
a solution and you're like, wow, you know exactly how to properly
10:40.299 --> 10:44.178
evaluate us, because I would think that better answers from AI
10:44.531 --> 10:47.946
or more better work from AI agents is still
10:48.139 --> 10:51.442
really broad. So is this usually like, we've tried
10:51.942 --> 10:55.803
to deploy an agent to like accelerate the claims process and it keeps
10:56.108 --> 10:59.973
screwing up. So we want to do a targeted deployment of your solution
11:00.486 --> 11:03.548
just on claims processing and we want to move like
11:03.564 --> 11:06.788
XYZ metrics and see less failures or
11:06.980 --> 11:10.636
automations that are running off the rails or like Talk to me about
11:10.684 --> 11:14.069
like, how would someone better deploy a solution
11:14.133 --> 11:17.903
like this and know that it's working beyond just generally the
11:18.403 --> 11:21.801
numbers seem better? Because I would think it's hard to measure this when you're talking
11:21.833 --> 11:25.443
about like, it's going to make it smarter. It's so vague.
11:25.828 --> 11:29.100
How do you make it? Tell me how did SurveyMonkey— like SurveyMonkey,
11:29.196 --> 11:31.234
I think is one of your customers, am I correct?
11:31.522 --> 11:31.683
Yeah.
11:31.763 --> 11:32.260
Did they do a
11:32.325 --> 11:36.126
point deployment or did they have a very specific way to measure
11:36.175 --> 11:39.705
that? Hey, afterwards it's better, and here's what better means.
11:40.282 --> 11:41.181
Talk to me about that.
11:41.887 --> 11:44.069
Yep. So actually you gave 2 really good examples.
11:44.150 --> 11:47.311
I'll start with the claims one that you mentioned, uh, because actually we do have
11:47.343 --> 11:51.178
projects around those things. Um, so the way
11:51.194 --> 11:54.869
you, you, you, you laid it out is they basically built
11:55.369 --> 11:58.928
something without a semantic layer and they looked at it and then they measured how
11:59.201 --> 12:02.908
correct it was, how accurate it was. Um, you know, was it reliable,
12:02.988 --> 12:06.408
the agent that was doing the work? And so what usually happens in these POCs
12:06.665 --> 12:09.814
is that they see promise, but they also
12:10.314 --> 12:13.572
see a lot of mistakes. They also see the agent misunderstanding the data,
12:13.910 --> 12:16.978
pulling the data incorrectly, making the wrong decisions.
12:17.668 --> 12:21.186
And so they say, okay, there's promise, but this is not reliable. This is
12:21.218 --> 12:24.720
not something we can roll into production. We need something that will help the agent
12:25.234 --> 12:28.976
be a lot more precise in the data that it's pulling and how it's using
12:29.089 --> 12:32.220
it, et cetera. So that's a great driver, by the way. If somebody comes to
12:32.720 --> 12:35.420
us and says, hey, we built something, has a business, has a business use case,
12:35.920 --> 12:39.510
is gonna process claims, and it's gonna save us a ton of money and labor,
12:39.740 --> 12:43.310
and it's gonna accelerate claim processing. So our customers are gonna be a lot happier.
12:44.080 --> 12:47.400
But the only thing is the agent is struggling to understand the data. Great.
12:47.900 --> 12:51.580
Amazing use case. This is, that's exactly where we want to fit into. Second example
12:52.080 --> 12:53.720
you gave was around SurveyMonkey. So SurveyMonkey—
12:53.720 --> 12:55.020
Wait, wait, let, let, actually, can I pick
12:55.520 --> 12:57.980
apart? Let me, I, I really want people to understand this. So let's go back
12:58.480 --> 13:02.396
to your claims processing thing. Is the issue here that when we
13:02.896 --> 13:06.162
try to, like, ultimately we want customers to get a result
13:06.662 --> 13:10.248
faster on their claims, they get a first contact from the insurance adjuster,
13:10.489 --> 13:13.790
you know, 50% faster than before, whatever it is, right?
13:14.319 --> 13:17.908
Is the issue here that there are so many different
13:18.165 --> 13:21.306
errors? It's a wide number of errors all over the place
13:21.806 --> 13:24.911
that's happening. If it's a car crash, then we see random stuff like this.
13:25.392 --> 13:28.744
If it's a tree branch that fell on a car, it's this. If it's
13:29.244 --> 13:32.946
a failed battery, blah, blah, blah, then this. There's so
13:33.446 --> 13:37.917
many different things happening. Or no, every time we have a car
13:38.046 --> 13:41.830
crash that involves body damage, that it always gets this problem
13:42.330 --> 13:46.240
wrong. And we tried to build our own small semantic layer to force
13:46.740 --> 13:49.929
it to use the right stuff, and it still doesn't get it right. And we
13:50.429 --> 13:53.156
don't know how to do it. Because those are 2 different— one's like, we have
13:53.656 --> 13:57.380
a million small problems because it doesn't fetch the right data versus like,
13:57.396 --> 13:59.372
we can't get it right ourselves.
14:00.432 --> 14:03.757
What are you— what is the— are you solving both of these? Or like,
14:03.805 --> 14:04.720
tell me about that side.
14:05.283 --> 14:07.178
So we're focused
14:07.678 --> 14:11.418
on the agent's understanding of the underlying data. So for example, let's say
14:11.434 --> 14:15.289
when you're processing a claim, you're not just looking at the claim itself,
14:15.466 --> 14:18.550
you're looking at other data. around that claim. So let's say your,
14:19.321 --> 14:23.448
your business is home insurance, okay? And a homeowner submits
14:23.641 --> 14:27.350
a claim, a tree fell on their house. Okay? Now there's a
14:27.415 --> 14:30.177
lot of data that you need to go through in order to decide what to
14:30.241 --> 14:33.052
do with that claim. For example, you need to look at this person's policy,
14:33.453 --> 14:36.970
right? That's the easiest one. You might want to look at past
14:37.470 --> 14:40.744
claim information, you know, for the same home. You may
14:41.244 --> 14:45.161
want to look at data in the area, other insurers that
14:45.661 --> 14:49.400
you have in the same neighborhood. Maybe even weather information and
14:49.576 --> 14:52.675
external information that you're trying to pull that you pull into your,
14:52.867 --> 14:56.142
let's say, data warehouse. So the, in the process
14:56.640 --> 15:00.493
of responding to a claim, there are multiple different datasets that
15:00.993 --> 15:04.811
you want the agent to pull and to look at before saying, this is
15:04.908 --> 15:07.428
what I want to do with this claim. Obviously, there's the merits of the claim
15:07.928 --> 15:11.169
itself, and obviously there is the logic. You were talking about the logic, you know,
15:11.185 --> 15:15.406
if it's a tree falling down and it's this, If it's a flooding,
15:15.518 --> 15:19.160
then it's some other logic. So we focus on
15:19.192 --> 15:22.850
the data piece. You will still need to codify
15:23.363 --> 15:27.053
your logic of how to process different claims of
15:27.553 --> 15:30.695
different natures. You still need to codify that. And usually you have that as an
15:31.195 --> 15:34.850
insurer, you already have your own internal policy documents. So the agent can
15:34.914 --> 15:38.588
use that to understand this is what I should follow when I'm processing
15:38.685 --> 15:42.074
these. But in those, in those, let's say,
15:42.412 --> 15:45.994
SOPs, standard operating procedures that you have, you say,
15:46.010 --> 15:49.400
okay, but when you're processing, don't just look at the claim itself. Look at
15:49.900 --> 15:53.401
the history, the policy, the area that the house is at, et cetera.
15:53.963 --> 15:57.337
And that's where the agent is going to struggle pulling the right data. And that's
15:57.401 --> 16:00.952
where we help the agent pull the right data because our focus is on helping
16:01.452 --> 16:04.165
the agent get the data that it should get. We don't focus on the SOP
16:04.665 --> 16:07.697
or something like that. That is still— codified elsewhere in a,
16:08.082 --> 16:11.515
you know, let's say a knowledge repository that the agent uses. The thing
16:11.611 --> 16:14.162
we tackle is making sure that the agent is pulling the right data.
16:14.819 --> 16:15.092
Right.
16:15.156 --> 16:18.846
But is the, is the insurer's problem that we're
16:19.346 --> 16:22.872
seeing repetition of the same kind of problem, which is like it keeps
16:22.937 --> 16:26.594
pulling the person's auto policy on a flooding situation,
16:26.867 --> 16:30.396
which is totally irrelevant information here, or it's,
16:30.541 --> 16:33.670
it, it, it pulls other people's flood problem,
16:33.686 --> 16:37.266
flood insurance claims, and it's using that to, to make a decision
16:37.314 --> 16:40.589
and we don't want it to do that. Or it's all these different
16:41.089 --> 16:44.297
prob— there's, there's hundreds of different small problems where it's doing the
16:44.361 --> 16:47.845
work, quote, incorrectly, almost like an image, like an early career
16:48.070 --> 16:50.751
insurance adjuster not doing their job correctly.
16:51.505 --> 16:55.406
What I'm trying to understand is like, how does the, what is the pain
16:55.438 --> 16:59.018
that the buyer is feeling? Is it a repeating targeted kind of thing?
16:59.452 --> 17:03.748
Or is it a general sense that like claims are not being
17:03.780 --> 17:07.324
processed correctly or we're giving the wrong, we're paying out too
17:07.824 --> 17:10.979
much or we're not paying enough and people are angry? Like that, I'm trying to
17:11.479 --> 17:11.732
get at that a little bit.
17:11.781 --> 17:15.901
Yeah. So usually, usually, and luckily they identify
17:16.401 --> 17:20.069
the issues before it goes into production. So it's not yet that you have a
17:20.569 --> 17:24.094
situation where claims are being paid that they shouldn't be paid. Usually it's in,
17:24.526 --> 17:27.957
in the evaluation process, they're seeing that the agent is making the wrong
17:28.005 --> 17:31.746
determination. too often for this to be reliable. That's ideally
17:32.246 --> 17:36.180
the situation. You don't roll it out into production unless you're very confident that
17:36.680 --> 17:39.280
it's doing the right thing, right? So you're seeing this in the evaluation phase.
17:39.633 --> 17:41.930
That's the point where you're like, okay, this is a problem. This is not good.
17:42.444 --> 17:45.978
Now, if you look at the data, so imagine that,
17:46.540 --> 17:50.540
let's say the flooding example. So imagine that now the agent
17:51.040 --> 17:54.491
needs to pull all flooding claims in the area.
17:54.828 --> 17:58.371
So it needs to go to the database or the data warehouse and pull
17:58.871 --> 18:02.058
that information. Now, if it doesn't have a semantic layer,
18:02.410 --> 18:05.697
what the agent is going to do is going to go to the warehouse and
18:05.729 --> 18:09.223
it's going to look for datasets that it thinks is
18:09.723 --> 18:11.708
going to, are going to answer the question. So it's going to look for dataset
18:12.208 --> 18:15.860
that says, this is historical claim information.
18:15.988 --> 18:19.162
And it'll say, okay, that looks relevant. And then
18:19.662 --> 18:22.578
let's say that in that dataset there's a column. that is claim type, and it's
18:23.078 --> 18:26.300
going to say, oh, okay, this probably I can look for any claim
18:26.316 --> 18:28.835
that says flooding or flood or something like that.
18:29.428 --> 18:32.942
And then let's say there's a column for zip code. And so it'll say,
18:33.038 --> 18:35.845
okay, this is, this is the column that I need to filter by for the
18:35.926 --> 18:39.872
area that's in. And what's going to happen is that every time the agent
18:40.372 --> 18:44.444
processes a claim, it's going to try to understand the data on its own and
18:44.944 --> 18:48.344
take a guess and pull data accordingly. And what you'll find
18:48.682 --> 18:52.536
is that you can run the same claim 10 times through the same process.
18:53.741 --> 18:57.017
And every single time the agent is going to pull data a bit differently
18:57.756 --> 19:00.502
and may have different conclusions as a result.
19:00.904 --> 19:04.292
So maybe in some cases it will fail to pull any flooding data
19:04.517 --> 19:07.424
at all. It'll say, oh, there's no— there are no flooding claims in the area.
19:07.794 --> 19:10.813
This is a unique claim. This is very weird. I think it's suspicious.
19:11.182 --> 19:14.281
We should not pay it out. Let's, let's have a human involvement. And then in
19:14.458 --> 19:17.971
other cases where it's running on the same claim, the agent
19:17.987 --> 19:21.532
will successfully pull 10 other flooding claims in the area and say, oh,
19:21.596 --> 19:24.885
it looks like there's some rampant issue here. You know, let's process
19:25.385 --> 19:28.783
it a different way. So that lack of consistency of how
19:28.895 --> 19:32.617
the agent is pulling the data is going to be sort of your first
19:32.665 --> 19:35.023
red flag that you're going to say, okay, this is, this is a problem.
19:35.151 --> 19:37.188
I can't let this thing process claims for real.
19:37.975 --> 19:38.857
Got it. Is it safe
19:39.357 --> 19:43.157
to say then that the, The buying trigger for your solution has
19:43.189 --> 19:47.089
to do with, we're trying to use Agentic AI to
19:47.105 --> 19:50.251
do work. We have evals set up. The evals are
19:50.751 --> 19:54.841
failing. It's not because the SOP is wrong. It's that the work's not being executed
19:54.905 --> 19:58.757
properly on the data side. Answer is we
19:59.257 --> 20:00.025
need a semantic layer for this.
20:00.763 --> 20:03.299
Yeah, that's the ideal one. The not ideal
20:03.331 --> 20:05.754
one is the reverse where they come to us and say, we know we need
20:06.254 --> 20:07.006
a semantic layer.
20:07.343 --> 20:07.407
And
20:07.728 --> 20:08.884
say, okay, why?
20:10.216 --> 20:13.508
Right. And is that because you're worried they're— you're going to buy this tool,
20:13.749 --> 20:16.815
it's really good, but it's expensive, and then you're not going to know whether
20:17.315 --> 20:19.111
it's doing anything for you, and then you're going to be unhappy?
20:19.866 --> 20:20.685
Yeah. Yeah.
20:20.813 --> 20:23.912
And also, even before the buying of the tool,
20:24.603 --> 20:28.810
we see a remarkable difference in
20:29.179 --> 20:33.000
the process and like the process through, you know, the pilot
20:33.033 --> 20:37.092
procurement, all that stuff, the speed And, and conversion
20:37.124 --> 20:40.344
rates. Conversion rates is basically, you know, do we move to the next stage kind
20:40.844 --> 20:44.542
of thing at what rate? So the speed and conversion rate of these processes
20:44.878 --> 20:48.355
are remarkably different between the cases where somebody
20:48.855 --> 20:52.713
says, I need a semantic layer and is looking to buy a technology versus cases
20:52.729 --> 20:56.447
where somebody says, I have a real business need at origin, it's funded,
20:57.055 --> 20:58.898
you know, the CEO cares about it.
20:59.074 --> 20:59.331
Right.
20:59.459 --> 21:00.180
Uh, we need to get this thing
21:00.276 --> 21:00.404
done.
21:01.061 --> 21:03.801
Got it. Got it. Let's talk about a little bit about
21:04.301 --> 21:07.811
like, So proving this out to the buyer. So I'm assuming you're
21:08.311 --> 21:11.774
selling in chief data officer, VP of data, this kind of role.
21:11.982 --> 21:12.832
Is that kind of— okay.
21:13.185 --> 21:13.330
Yeah.
21:13.506 --> 21:15.110
So if they have to justify paying for
21:15.610 --> 21:17.902
this, I got to get procurement to believe it and finance to believe it.
21:18.223 --> 21:22.474
Is the AI like more accurate now? What is the moment
21:22.974 --> 21:26.308
in the POC that facilitates them saying, there it is,
21:27.126 --> 21:30.158
I have my ammunition to go and get this deal done?
21:30.608 --> 21:34.344
so we can move this thing forward. Where is that breakpoint
21:34.844 --> 21:38.881
where either it happens or it doesn't? Is it really like we have these clear
21:39.154 --> 21:42.778
evals, the eval is here it is, and we can score it and you can
21:42.842 --> 21:46.386
see the score is better? Is it that quantifiable? Is it
21:46.886 --> 21:50.186
something else? But talk to me about that moment where the buyer can see or
21:50.218 --> 21:53.665
can't see the impact to justify
21:54.165 --> 21:56.872
it to the person who doesn't understand any of this and glazes over and checks
21:57.372 --> 21:57.257
their phone.
21:58.829 --> 22:00.564
So, um, we're data
22:01.064 --> 22:03.969
people, right? So it's all about the data. So when we, before we go into
22:04.017 --> 22:06.683
a pilot, we define the success metrics,
22:07.229 --> 22:11.245
um, the success criteria first, and then the success metrics themselves. So, you know,
22:11.325 --> 22:14.618
what are we testing for? And then how do we measure? For example,
22:15.292 --> 22:20.030
measuring accuracy and consistency of response for
22:20.530 --> 22:24.512
certain questions. So if we take the, the claim process we were talking about,
22:24.913 --> 22:28.014
imagine the agent basically needs to ask 50 different questions.
22:28.544 --> 22:31.677
Okay. When it's pulling data, it's, you know, I need to pull all the flood
22:31.726 --> 22:34.570
claims in the area, yada, yada, yada, right? All, all these questions.
22:35.357 --> 22:39.197
So they have these questions mapped out
22:39.697 --> 22:43.681
usually, and if not, we can help them. And then they say, okay, we want
22:43.793 --> 22:47.859
to get the questions correct at least
22:47.955 --> 22:52.117
95% of the time. And we want to get the same
22:52.165 --> 22:56.124
answer To a given question that was run 5 times,
22:56.941 --> 22:59.970
we need at least 4 out of the 5. Or maybe they'll say we need
23:00.082 --> 23:02.774
at least 9 out of the 10 times that we, that we run the question.
23:03.911 --> 23:07.660
And so what you're doing here is you're proving accuracy
23:08.317 --> 23:11.858
and consistency in responding to the questions that
23:12.358 --> 23:15.784
the agent is asking. That is what you're proving at that business
23:16.284 --> 23:19.693
level. Now, also, you do get the business users involved
23:19.709 --> 23:23.159
early before pilot starts. And when you come to the point
23:23.659 --> 23:27.320
of measurement, you have the business users also evaluate, is the system
23:27.820 --> 23:31.288
answering the questions in the way that it should? So essentially on the
23:31.788 --> 23:34.067
business side, there are people who know the data, the claims data in this case,
23:34.710 --> 23:37.858
and they want to see that Solid is answering the questions in the
23:38.358 --> 23:41.666
right way. So you have metrics and you have the business feel.
23:42.035 --> 23:44.413
So that's at the top level. Below that,
23:44.927 --> 23:48.670
what we need to prove at Solid is that building the semantics
23:48.686 --> 23:52.311
is easy, is fast, highly accurate,
23:52.552 --> 23:56.113
it gets tested well, et cetera. So there are also technical criteria
23:56.643 --> 24:00.942
that the data team evaluates to make sure that Solid is delivering
24:01.038 --> 24:04.230
on its promise. Okay, so 2 sections. One is,
24:04.808 --> 24:08.658
are we delivering on the accuracy, consistency, et cetera, for the business
24:09.158 --> 24:12.893
questions? And below that, are we delivering on the ease of creation,
24:13.406 --> 24:17.178
testing, maintenance of semantic models? So all that criteria
24:17.678 --> 24:20.710
is set up at the beginning of the pilot, and then it's evaluated
24:21.210 --> 24:24.564
throughout the pilot. And if we get high scores on all of that, then the
24:25.064 --> 24:26.298
customer says, okay, great, we can move forward.
24:27.197 --> 24:27.422
Got it.
24:28.273 --> 24:32.239
Just briefly, how good are these data buyers at eating
24:32.271 --> 24:35.868
their own dog food and coming in with nice quantifiable success
24:36.368 --> 24:39.063
metrics? Or is this a whole journey that you drag them through the mud and
24:39.079 --> 24:40.107
it's like eating your own?
24:43.410 --> 24:46.563
Yeah. Are they really good at this? I have a pet peeve. I have a
24:47.063 --> 24:50.005
pet peeve, and I'm sorry for all the data leaders who are listening. And do
24:50.505 --> 24:52.336
know that I say this with a lot of love and a bit of a
24:52.836 --> 24:53.792
tongue-in-cheek because I know—
24:53.792 --> 24:54.132
Here
24:54.197 --> 24:56.382
it comes, folks. I ask
24:56.882 --> 25:00.173
data people, what are your KPIs? What are you measured on?
25:02.458 --> 25:02.668
And—
25:02.668 --> 25:03.717
Value from data.
25:04.604 --> 25:06.589
And it's
25:06.638 --> 25:09.254
terrible. I'm sorry, but as an industry,
25:10.312 --> 25:13.182
data people are not measured in an objective way.
25:14.642 --> 25:18.394
They usually are measured on user satisfaction.
25:18.811 --> 25:22.724
Is the business happy with me? But not really,
25:23.558 --> 25:28.016
how much business impact am I delivering? And it's
25:28.048 --> 25:31.191
weird, right? I think it's very wrong and I think the industry needs to change
25:31.691 --> 25:34.271
it. So first of all, it's a bit of a pet peeve and And sorry
25:34.367 --> 25:37.838
to all the data leaders there, but, you know, I think data
25:38.338 --> 25:41.388
leaders are not measured in an objective way. And it's a weird failure.
25:41.453 --> 25:45.196
It's like the shoemaker walking barefoot, as you would
25:45.212 --> 25:48.892
say. And so, and back to your question,
25:49.325 --> 25:52.426
a lot of times we need to educate them on this.
25:52.700 --> 25:55.158
A lot of times they come to us and say, well, what have you seen
25:55.174 --> 25:58.339
elsewhere as success criteria and metrics and so forth? And we
25:58.839 --> 26:02.112
share those and then they align on it. Even yesterday we had a call,
26:02.241 --> 26:05.626
one of our pilots that just started. Um, we asked
26:06.126 --> 26:08.563
them, there was a specific thing we asked them, how would you measure this?
26:08.659 --> 26:11.932
How would you know that this is correct? And they said,
26:12.205 --> 26:16.024
we don't know, you tell us. And so
26:16.281 --> 26:19.570
it's, that's, that's the situation. It happens a lot. And it's, you know, we,
26:19.650 --> 26:21.319
we, we find that we need to do that education.
26:22.378 --> 26:23.758
I think it's to,
26:23.822 --> 26:27.112
to all the listeners' credit out there, I think those are fair points. And I
26:27.612 --> 26:30.992
think it's always hard to, do this with your own work. It's so
26:31.492 --> 26:34.294
much easier to do it with someone else's, like when you're outside the jar.
26:34.823 --> 26:38.494
So I love what you're saying. I do the same thing
26:38.591 --> 26:41.748
with my own clients. And a lot of times, they're asking how to measure the
26:41.861 --> 26:44.858
impact of the work that I would do with them. And I think they're fair
26:44.922 --> 26:48.834
questions. And if you don't have that outside perspective, it can
26:48.850 --> 26:51.928
be difficult. But yes, thank you for sharing that.
26:52.216 --> 26:55.615
Just thinking about moats here, I'm thinking about this
26:55.727 --> 26:59.077
a lot for analytics and data products in
26:59.125 --> 27:02.953
the B2B space right now. when engineering is just no longer the bottleneck that
27:03.453 --> 27:07.529
it used to be. Another founder told me he recently
27:07.561 --> 27:10.762
lost a design partner and an executive said,
27:10.778 --> 27:13.973
hey man, I committed to Databricks and Anthropic.
27:14.200 --> 27:17.601
Why do I need you guys? I think we're just going to
27:17.682 --> 27:21.272
wait it out here because they're just creeping into
27:21.321 --> 27:24.604
the stack more and more all the time. What do you say to
27:25.364 --> 27:28.836
a buyer like that? What's your answer for Solid if you were to hear the
27:29.336 --> 27:29.117
same thing?
27:30.450 --> 27:32.363
Oh, we hear it all the time.
27:33.198 --> 27:37.231
So this is my second startup. My first startup I built before
27:37.697 --> 27:41.281
the AI craze, the GenAI craze. And back then
27:41.377 --> 27:45.137
customers couldn't build their own solutions and big vendors
27:45.876 --> 27:49.813
moved very, very slowly. Like the Microsofts of the world moved
27:50.313 --> 27:54.023
very, very slowly. So as a startup, you're like, well, my claim to fame is
27:54.071 --> 27:57.347
I can run faster I can get stuff done faster. And,
27:57.764 --> 28:00.059
you know, whatever you need on the roadmap, I can commit to and make happen.
28:00.428 --> 28:03.895
Right. And so that was like the big, the big
28:03.943 --> 28:06.752
differentiator of startups building faster, running faster, et cetera.
28:07.875 --> 28:11.486
That is gone. You know, at this point,
28:11.583 --> 28:15.210
Microsoft is shipping features at a much higher clip
28:15.418 --> 28:17.730
that, you know, makes you look at it and say, wow, this is amazing.
28:18.227 --> 28:22.063
Databricks and Snowflake, they're shipping features all the time
28:22.336 --> 28:25.756
in capabilities. And they're really good. If you think about the
28:25.773 --> 28:28.502
world of semantics, Snowflake has their Semantic Studio.
28:29.144 --> 28:32.436
It's good stuff. It's really good. And it's
28:32.452 --> 28:36.209
built by very talented people that I've met. Same, by the way, on Databricks,
28:36.225 --> 28:40.288
the Genie Ontology, et cetera. Talented people. They're using cloud
28:40.320 --> 28:43.627
code to build their stuff just like we are. They're running at a
28:44.127 --> 28:47.652
speed, in some cases, a speed of startup. So you
28:47.749 --> 28:51.649
look at it and you as a startup, you don't have that moat
28:52.149 --> 28:55.906
anymore. The fact that you can run faster is nice, but how much
28:55.938 --> 28:59.063
faster can you run versus a Databricks that is using the same tools
28:59.160 --> 29:00.924
you're using? And there are people that are very,
29:02.721 --> 29:06.497
very incentivized to run quickly there. So you have
29:06.529 --> 29:10.275
to look for where your moat is in the area of
29:10.307 --> 29:13.409
where these big companies are not looking to compete.
29:13.772 --> 29:17.331
right now. So to explain, if all
29:17.459 --> 29:21.019
of your data sits in Databricks or all of your data sits
29:21.067 --> 29:25.075
in Snowflake, you are going to select their solution over
29:25.575 --> 29:29.388
ours. And rightfully so, because, you know, your data's
29:29.888 --> 29:33.397
already there, so why not use it? Now you can, you know,
29:33.477 --> 29:37.068
you can start splitting hairs and say, well, their cost structure is very prohibitive.
29:37.117 --> 29:40.516
It gets very expensive. You know, our cost structure doesn't, et cetera,
29:40.532 --> 29:44.061
et cetera. Like you can, you can pick at that. and find places where Solid
29:44.561 --> 29:48.172
is the better solution versus just using the Databricks solution for yourself.
29:48.894 --> 29:52.073
But the reality is that if all your data is in Databricks, use the Databricks
29:52.089 --> 29:56.167
solution. Where we come into the picture is for enterprises
29:56.504 --> 30:00.647
where their data, analytical and operational, is spread across
30:00.759 --> 30:04.195
a bunch of technologies. Some of them call it ancient.
30:04.452 --> 30:08.225
So for example, one of our customers, they have data in Snowflake,
30:08.867 --> 30:11.128
And they have a lot, it's an insurance company, and they have a lot of
30:11.628 --> 30:14.544
data in Oracle, in a version of Oracle from 2016,
30:14.720 --> 30:18.521
by the way. And so for them to use the Snowflake
30:19.021 --> 30:22.322
technology with that old Oracle is virtually impossible.
30:23.075 --> 30:26.507
They need a layer that can run across all these
30:27.007 --> 30:31.126
different data warehouses, some of them on-prem, some of them built 10+ years
30:31.190 --> 30:35.215
ago, and provide a consistent experience
30:35.744 --> 30:38.758
across all of that. And that's why they come to us.
30:39.031 --> 30:41.243
So essentially my point to your question is,
30:42.397 --> 30:45.651
at, you know, at a rate where Snowflake can develop as fast as
30:45.828 --> 30:49.964
you can, you need to find the areas that Snowflake is not in and
30:50.012 --> 30:53.314
won't be in for the next maybe year or two. God knows
30:53.362 --> 30:56.649
what happens after that, right? But for the next year or two,
30:56.665 --> 30:59.486
they're not going to be in that space. And then you can claim a stake
30:59.986 --> 30:59.999
in that space.
31:01.153 --> 31:03.524
If I'm a smart founder though, I can
31:03.556 --> 31:07.097
go pick off your top engineers, a couple of the top semantic engineers
31:07.597 --> 31:11.711
at these companies, and I can now do multi-stack semantic
31:12.211 --> 31:16.197
layer. Like, it sounds like an engineering advantage, but what's
31:16.697 --> 31:19.593
to stop me from coming and copying what you're doing and saying, we're going to
31:20.138 --> 31:24.367
learn from what you did wrong and we'll do multi-stack semantic
31:24.867 --> 31:28.068
layer as well? Like that, like, how do you compete with that when I can
31:28.568 --> 31:30.407
just code my way to that with the right brains?
31:31.740 --> 31:32.574
Can I catch up to you?
31:33.827 --> 31:35.497
So am
31:35.529 --> 31:36.862
I allowed to use profanity?
31:37.456 --> 31:37.809
Sure.
31:39.126 --> 31:41.470
Okay. So
31:42.353 --> 31:42.754
is it
31:43.254 --> 31:44.777
going to be used at me for this question?
31:45.002 --> 31:45.950
No, no, no, no,
31:46.560 --> 31:50.397
no. Um, the truth of the matter
31:50.897 --> 31:53.962
is that auto-generating, auto-building,
31:54.058 --> 31:57.822
auto-creating semantics off of technologies
31:58.257 --> 32:01.965
that have been around for a decade plus, whether it's like an old Oracle data
32:02.465 --> 32:06.975
warehouse or some SAP data or Power BI semantics,
32:06.992 --> 32:10.824
which we know how to extract, is the equivalent of
32:10.857 --> 32:12.684
shoveling through a mountain of shit.
32:14.318 --> 32:17.666
And it's very, very hard.
32:17.714 --> 32:21.882
Like you can't just throw Claude code at it. We tried and
32:22.382 --> 32:26.417
Claude code will understand some of it, But there is a massive,
32:26.562 --> 32:29.836
massive, massive amount of effort that is required in
32:29.932 --> 32:33.832
order to sort of pry out the value
32:34.024 --> 32:37.892
out of an organization's data stack. So typical
32:38.392 --> 32:41.615
enterprise has some kind of cloud data warehouse called Databricks,
32:42.530 --> 32:46.478
a few on-prem data warehouses like SQL Server, Oracle, et cetera.
32:46.863 --> 32:50.619
They have 4 different BI systems, some Power BI, some Tableau,
32:50.940 --> 32:54.336
Some click, right? Because, you know, people made different decisions along the way,
32:54.897 --> 32:58.390
different business units, et cetera. They have all the complexity of being an enterprise,
32:58.807 --> 33:02.028
which beyond just going through the security process, you also need
33:02.528 --> 33:06.226
to deploy in a certain way so that it meets their data
33:06.274 --> 33:10.199
protection requirements and cloud security requirements, but also their cloud data,
33:10.440 --> 33:14.253
their cloud ops requirements. And so these
33:14.301 --> 33:17.730
are challenges that you can't just throw cloud code at. These are challenges that
33:18.230 --> 33:21.807
require a lot more creative thinking, a lot of that
33:22.307 --> 33:26.270
shoveling that I was talking about earlier, and the willingness to do it, the willingness
33:26.319 --> 33:29.080
to go through these complicated enterprise deployments.
33:29.626 --> 33:33.367
So another founder can pick our top people off
33:33.624 --> 33:36.466
and can pick people from Snowflake and try to,
33:36.675 --> 33:39.806
you know, put a team together. They're going to have a
33:40.306 --> 33:43.563
massive gap that they need to close. Everything we've built over the past couple of
33:44.063 --> 33:46.898
years, that you can't just throw cloud code at.
33:47.811 --> 33:51.962
Now, on top of that, you gotta remember that customers
33:51.994 --> 33:55.552
are not just buying a technology, they're buying the people, the service
33:55.840 --> 33:59.237
that are involved in it. And what they're getting from us
33:59.911 --> 34:03.885
is a level of commitment, commando style, that they're
34:04.385 --> 34:07.987
not gonna get from the big vendors. So being
34:08.084 --> 34:11.641
able to actually cater to their needs, build customizations that
34:12.141 --> 34:15.952
are very weird but are very specific to their cloud environment or to their just
34:16.452 --> 34:19.751
general environment, deploying FDEs that are
34:19.960 --> 34:23.374
just gonna work days and nights and weekends
34:23.791 --> 34:27.590
to make the project successful. Those are things that startups
34:27.735 --> 34:31.502
can offer and solid offers that you wouldn't get from
34:32.002 --> 34:35.029
the large vendors. And so whoever decides to copy us would need to copy that
34:35.529 --> 34:35.349
as well.
34:36.311 --> 34:39.565
Got it. So you're saying the engineering
34:39.998 --> 34:43.493
line is not straight you don't know what you don't know until
34:43.589 --> 34:46.634
you try to do it. And then you're going to find out that there's all
34:47.134 --> 34:50.658
kinds of weeds in here that you have no idea. So you have some domain
34:51.158 --> 34:54.312
knowledge here, experience having gone through that, you know where the dead bodies are buried,
34:54.424 --> 34:57.999
where to stay out of, and clod— you can't clod your
34:58.031 --> 35:01.733
way out of this kind of stuff. So you have an engineering— you do believe
35:02.233 --> 35:05.148
you have an engineering moat, so to speak, here. Hard to catch up.
35:05.949 --> 35:07.071
Yeah.
35:07.311 --> 35:10.677
Got it. Tell me about the You
35:11.177 --> 35:14.059
talked a little bit about user experience. So the people that are actually going to
35:14.204 --> 35:17.682
either approve the automated building of this semantic layer,
35:17.778 --> 35:21.272
I'm sure there's some human touchpoints in this. There's an interface
35:21.772 --> 35:25.631
to the solution. Tell me how teams, if at all,
35:25.824 --> 35:29.398
are evaluating that part. Like, do those people have a voice,
35:29.510 --> 35:33.133
the actual end users here? And do they have a process for
35:33.633 --> 35:36.194
measuring that, hey, this tool is easy to use, it's not going to take a
35:36.694 --> 35:39.993
lot of effort, we're not going to spend all day in here. I don't know
35:40.041 --> 35:43.697
what the measurements are there. I tend to find, especially in the
35:44.197 --> 35:47.321
data place, beyond adoption, like counting usage of the
35:47.821 --> 35:51.779
solution, they don't know how to measure whether something
35:51.827 --> 35:55.868
is useful, usable, and delightful. They just don't know how to measure it beyond counting
35:55.980 --> 35:59.812
analytics things, which is not right in my opinion. I won't get on that soapbox,
35:59.828 --> 36:03.292
but tell me about how they— if you think they're doing it or how they
36:03.792 --> 36:05.825
said— maybe they have a structured way they're doing it. I don't know.
36:06.403 --> 36:06.548
Yeah,
36:06.580 --> 36:10.225
so there's what we tell them to do, and usually they align with it,
36:10.257 --> 36:13.982
and what they do in general is, is pretty similar. So remember,
36:14.126 --> 36:17.530
somebody came to us after they tried something.
36:17.643 --> 36:21.416
They built a little agent, they tried to get it to understand their data.
36:21.817 --> 36:25.767
They probably spent time teaching that agent
36:25.815 --> 36:29.219
the semantics of the data. Okay, so they
36:29.719 --> 36:33.002
know how much time they spent to do that. Usually people quantify
36:33.067 --> 36:37.463
it at 2 to 3 weeks
36:37.673 --> 36:40.930
of work for one semantic model. So one
36:40.978 --> 36:45.463
semantic model will usually be a mini dataset
36:45.963 --> 36:48.212
that is focused on a specific use case. That's the easiest way to think about
36:48.712 --> 36:52.007
it. So they spent 2 to 3 weeks. Now, 2 to 3 weeks sounds
36:52.507 --> 36:55.610
like a long time. So, you know, what did you do for 2 and 3
36:56.110 --> 37:00.433
weeks? And really the vast majority of the time is spent On
37:00.770 --> 37:04.255
actually the testing and fixing of the semantic model. So you start with
37:04.755 --> 37:08.077
something and then you iterate. You say, okay, I started something, it's very nice.
37:08.559 --> 37:12.719
Um, now let me see, can it pull all the flood claims in
37:13.056 --> 37:16.701
this area? Um, and it got it right. Great, good.
37:17.151 --> 37:20.524
And then I would say, okay, can it pull, uh, the weather information? And it
37:21.024 --> 37:23.302
got it wrong. Okay, let me go fix that. And after you fix that,
37:23.591 --> 37:26.257
you go back and say, okay, can it pull all the flood information from that?
37:26.787 --> 37:30.481
Area. Same question. And now I got it wrong. And so what you find
37:30.981 --> 37:33.694
is that you're iterating. Welcome home. And you're in this annoying loop of like,
37:33.710 --> 37:35.476
okay, I need to fix it and fix it, but I also need to get
37:35.976 --> 37:39.845
consistency, et cetera. And LLMs can be annoying sometimes where,
37:40.375 --> 37:42.945
you know, they'll, they'll get it right, then they'll get it wrong, then they'll get
37:43.445 --> 37:45.113
it right and they'll get it right and they'll get it wrong. And you're just
37:45.613 --> 37:48.872
gonna pull hair. So that usually is the 2
37:49.372 --> 37:52.293
to 3 week process that an analyst goes through.
37:52.903 --> 37:56.257
building one semantic model. So usually they know this. If they don't,
37:56.273 --> 37:59.853
we tell them, but usually they know this. I say, okay, with Solid,
38:00.591 --> 38:03.897
you're gonna get that down to 2 days and your experience
38:04.042 --> 38:06.561
is gonna be much more enjoyable, much less frustrating.
38:07.268 --> 38:10.269
So to your question of the end users of evaluating, so first of all,
38:10.301 --> 38:13.607
let's define the end user. In this case is not the business user. The end
38:14.107 --> 38:17.154
user in this case is what we call a semantic engineer,
38:17.219 --> 38:21.103
but usually is a business analyst who is responsible for
38:21.698 --> 38:25.659
a set of semantic models. And what they're measuring is how
38:26.159 --> 38:28.896
much time does it take me to build a reliable semantic model in Solid?
38:29.218 --> 38:32.562
So 2 days instead of 2 to 3 weeks. And am I
38:32.595 --> 38:35.653
enjoying the process? And do I feel I can rely on this thing?
38:36.360 --> 38:41.502
So that's usually the way that they measure the
38:41.566 --> 38:44.606
system and whether it's good for— it's a fit for their use.
38:45.720 --> 38:49.527
Got it. Got it. Was it hard To beyond the cutting
38:49.639 --> 38:53.043
the time down, was it hard to get it to the point where
38:53.637 --> 38:57.860
the hair pulling out experience was reduced to something that's either just
38:58.310 --> 39:02.067
like oxygen, it's just fine to even possibly delightful, some somewhere
39:02.567 --> 39:05.519
between satisfactory and delightful. Was it hard to get to that?
39:06.081 --> 39:06.274
Yeah,
39:06.643 --> 39:09.951
it, it was. And I'll be honest, we're in a journey of always making it
39:10.451 --> 39:13.788
better. Um, you know, there are, we can
39:14.288 --> 39:18.236
talk a lot about how the dynamics of building a startup in this world with
39:18.284 --> 39:22.357
AI. But one of them is the user expectation
39:22.854 --> 39:26.124
of user experience is changing. So,
39:26.861 --> 39:30.516
you know, a year ago everybody had a chat interface and
39:30.549 --> 39:33.915
at some point it got really annoying that everybody had a chat interface because you're
39:34.415 --> 39:37.506
like, hey, people are making things chat where they shouldn't be chat, where they should
39:37.538 --> 39:41.033
be like a different interface, maybe even, you know, a normal older interface.
39:41.867 --> 39:45.556
But what's been happening over the, over this time is that People are used
39:46.056 --> 39:50.180
to different experiences. ChatGPT, Claude Desktop, you know,
39:50.276 --> 39:52.749
all these different systems, Muse, Meta Muse.
39:53.327 --> 39:57.117
We're, we're, we're getting used to different user experiences that are
39:57.617 --> 39:59.959
evolving at a pace that we've never seen before.
40:01.115 --> 40:04.840
And so what that means for us as a startup is that we
40:05.340 --> 40:09.288
need to advance our user experience, the user experience we provide along
40:09.320 --> 40:12.852
the same lines, because people are expecting different things than they did before. And I'll
40:13.352 --> 40:15.724
give you a very easy example. A year ago,
40:16.382 --> 40:20.441
people were happy using our user interface for 99%
40:20.489 --> 40:24.692
of what they needed to do with Solid. Over time, what happened is they asked
40:25.510 --> 40:29.056
that we expose more and more of our capabilities over MCP.
40:29.698 --> 40:33.660
And what we noticed is that in many cases, people are not
40:33.709 --> 40:37.447
going into our user interface. They're connecting Cloud Desktop to
40:37.543 --> 40:41.169
us over MCP. and doing most of the semantic modeling through
40:41.234 --> 40:44.620
Cloud Desktop because that's where they live anywhere anyway.
40:45.743 --> 40:49.257
And so that, that has changed. And, and, you know, we're very MCP
40:49.757 --> 40:52.627
oriented and, and, uh, you know, MCP first and building MCP,
40:52.804 --> 40:56.270
but like the way the users are consuming our system has evolved.
40:56.495 --> 40:59.319
And so going back to your question, it's an ongoing journey.
41:00.105 --> 41:03.587
It's possible that 3 months from now or 6 months from
41:03.636 --> 41:06.797
now, yet again, their expectations of how
41:06.845 --> 41:10.213
to interact with the system will again evolve. And we will need
41:10.713 --> 41:13.498
to evolve with it. So it's an ongoing journey. It's, it's not, it's not a
41:13.998 --> 41:14.027
trivial thing.
41:14.924 --> 41:17.376
Yeah. Yeah. No, thanks for, for sharing that. I think those
41:17.424 --> 41:20.997
are all really, really good points and a lot of people are on similar journeys
41:21.093 --> 41:24.570
right now, uh, understanding this. The, uh, I just wanted to kind of give you,
41:24.634 --> 41:27.839
this has been super great. Thank you for being so candid. Like, kind of wanted
41:28.339 --> 41:31.284
to give you the last word on a reflection. I, I know when we first
41:31.524 --> 41:34.745
met on email, what, about 2 years ago or something like that, you had said
41:35.245 --> 41:39.029
that you had talked to like 140 VPs of data and chief data officers
41:39.061 --> 41:42.515
before building. I find that's rare. I know that number
41:43.015 --> 41:46.420
is up in the high hundreds now of people that you've talked to. Would you
41:46.436 --> 41:50.276
keep doing that formula again if you're starting a third company?
41:50.372 --> 41:53.875
Is there anything that you'd change now as a two— you're now a two-time founder,
41:54.646 --> 41:57.377
or is that like, no, I'm doubling down on that, that's why the number keeps
41:57.877 --> 41:58.775
growing? Like, talk to me about that.
41:58.904 --> 42:00.639
Doubling, doubling down. Actually,
42:01.298 --> 42:04.718
the beauty of today's technology is that you can actually have way
42:04.782 --> 42:08.039
more conversations than you could ever before. You know, first of
42:08.539 --> 42:10.382
all, you've got Zoom and everything, so it's easy to get on a call with
42:10.882 --> 42:13.880
someone and people are very receptive to talking to you, which is amazing. Really,
42:13.912 --> 42:17.491
we've had, you know, if I, if I had to thank every single person that
42:17.507 --> 42:20.571
helped us on the journey, we would be spending hours here.
42:21.839 --> 42:25.273
And so people are very forthcoming. People are very helpful. They're amazing.
42:26.011 --> 42:28.867
And you can get on a Zoom call with someone 30 minutes, an hour,
42:29.300 --> 42:32.413
you know, at a time that is easy for them. But also with
42:32.446 --> 42:36.233
today's technology, all of these calls are recorded, transcribed.
42:36.939 --> 42:40.148
We analyze them horizontally all the time. Even today,
42:40.533 --> 42:43.871
we look at all our customer calls and we look at calls within customers and
42:43.903 --> 42:47.080
so forth. We analyze them horizontally. You take chat, you take
42:47.128 --> 42:50.177
Claude, it runs through it. It does an amazing job.
42:50.899 --> 42:54.189
And so today I, I would say
42:54.689 --> 42:57.414
the bar's even higher if I said 140 in the first year, cuz what you're
42:57.914 --> 43:00.143
talking about, it was the first year of of Solid. If I said 140,
43:00.533 --> 43:04.105
then in my next startup, it would be 500 in the first year. That's what
43:04.605 --> 43:07.880
I would want to see. Because customers,
43:08.862 --> 43:12.083
they might not know what solution they need. You know,
43:12.099 --> 43:15.464
there's the whole Innovator's Dilemma, the book from the '90s, et cetera. I think
43:15.964 --> 43:19.202
some of it still applies. So they might
43:19.702 --> 43:23.749
not know exactly what they need, but they can articulate their problems to
43:24.249 --> 43:27.317
you and priorities and what bothers them and what keeps them up at night.
43:27.746 --> 43:31.054
It's your job to synthesize that into, okay, this is the trend I'm seeing and
43:31.554 --> 43:34.281
this is what I think the solution would be. And then you show them mockups
43:34.781 --> 43:37.315
of the solution, which by the way, is even easier to do today than ever
43:37.815 --> 43:41.923
before. You can now show a full end-to-end solution to a
43:41.971 --> 43:45.487
person and get their feedback. And you can build that end-to-end
43:45.987 --> 43:48.811
solution in a week, you know, not the full product, but like the experience.
43:49.662 --> 43:52.905
And so, yeah, completely double,
43:52.953 --> 43:56.084
triple, quadruple down on that approach. Yeah. Every single
43:56.100 --> 43:57.689
startup founder should do that.
43:58.893 --> 44:02.247
Awesome. Yoni, thank you so much for coming on here. I know the URL is
44:02.359 --> 44:05.665
getsolid.ai. Where can people be in touch with you if
44:05.714 --> 44:07.046
they want to reach out?
44:08.378 --> 44:10.127
So you can
44:10.627 --> 44:14.557
either find me on LinkedIn, right? Yoni Leidersdorf. There's only
44:15.057 --> 44:18.649
one. And the other option
44:19.149 --> 44:24.690
is you can email me directly. Yoni, Y-O-N-I-L That's
44:25.190 --> 44:28.410
the other option. Um, I do have a lot of spam filters, so you need
44:28.910 --> 44:30.520
to do a good job of getting through them.
44:32.810 --> 44:36.150
I made it very hard to get in touch. Yeah. Don't we all
44:36.650 --> 44:36.920
right now?
44:36.990 --> 44:40.050
It's just a box and this spam stuff's like, oh,
44:40.550 --> 44:43.560
sign me up. Yeah. So if you're gonna offer me cleaning services in our office,
44:43.570 --> 44:46.810
then please don't. But if you're, if, if I can help you in
44:47.310 --> 44:49.686
any way, in any real way, helping other startup founders,
44:49.959 --> 44:53.284
helping data people, helping business leaders. I'm always up for that.
44:53.413 --> 44:57.398
So yeah, just, just make sure it's not a generic sounding
44:57.414 --> 44:57.767
message.
45:00.315 --> 45:00.526
Awesome.
45:00.575 --> 45:03.044
Well, thank you, Yoni, for coming on Experiencing Data. Appreciate it.
45:04.003 --> 45:05.595
Thank you for having me. Thanks. Have a good day.