Hi, everyone. My name is Patrick Akio.
And if you're interested in Big Picture thinking product
organizations, as well as laser focus in adding value than this
episode is for you. Joining me today is Andres
Prince is the chief product officer stack State and final
tip that he's addicted to mid-journey.
He showed me some of those images and they look insane.
I'll put all is links to socials in description below.
Check that out. And with that being said, enjoy
the episode, like, what's your day-to-day like nowadays?
Days because you're in a product Market, fit phase, I guess or
what's it like? Yeah.
So really focused on product Market fit and that's ultimately
a mixture of product, right? What are we building?
And but now the question is, if you're in product Market, fit
is, how do you feed the debate on?
What is it that you need to build?
So a lot of the day is spent on Research.
What another, its actual research calls with prospects or
just experts in the market. Yeah, or research being desk
research. How's the market evolving?
Body others doing and then a little bit of competition.
And then a lot of products debate internally, if you have a
lot of data, right? Then you need to structure that
really derive results conclusions out of the analysis
that you do. Yeah.
And I hear a lot of people say market research but like what is
that until for you or how do you even do that?
It's a good question. It's somewhere.
I kind of got feeling right? You're just you're just going
with the flow but what we did is we changed our Thinking by
coming up with low Fidelity, High Fidelity designs and really
running all these research calls with prospects, okay?
The dating the screens, the ideas that we're doing but that
was starting with more problem Discovery.
A so if you talk about research, there's a lot of problem
Discovery. What is it actually that we need
to solve? What is the problem in the
market? Followed then more by solution,
Discovery and solution investigation?
That's one part. Other part is really
understanding, how do competitors solve the issue,
right? Because by understanding how the
competitive things you actually discover yeah, in a better way,
the problem that the market is facing.
And then funny enough looking a lot in the open source
Community, because there is where the people iterate, the
fastest it not necessarily all comes to the really to the
market. But some of the times these
really small open source Frameworks can inspire you quite
a bit and then you take learnings, and lessons and feed
it into the product. T', very interesting.
I like the looking at Open Source Products, like, have you
do you have an example of that like an an open source solution
that inspire you to change something or adopt something?
Yeah, there's for example, s over in the in the in the Cuban
at these troubleshooting space and there's Robusta which is why
I would say kind of a small open source framework.
But what I've built really nicely isn't good integration
with slack and then almost an engineer Q aying in slack.
Kind of the Robusta framework or the bolt will provide them with
answers so that inspired Dash to think about.
Hey, but what is not necessarily the AI, or the algorithms, under
the hood, that do the magic. But what is the interaction
pattern that we would like to give our Engineers with our
system? And that's now a sparking a doll
debate around event, handlers. Yeah, and it's actually this
text a DUI more important versus is a deep integration in slack
or teams, more important so that you kind of more.
Yeah, ideation type of thinking but where you can really good
inspiration from open source framework.
Work. Whereas the data they have and a
couple other elements are absolutely not what we do.
So you can take a broader look and then take the principles the
concept into your own offering. Yeah.
Still maintain that Focus that
your organization is for right? Yeah, exactly.
I mean I can assume that figuring out what problems there
are and then how you can solve them with the thing that you're
creating. I think that's the most complex
part, right? Because a lot of people have a
lot of ideas but if they don't actually solve a problem and
people are willing to pay for it then it's never gonna like take
off. Off as a lot of companies need
to. Yeah.
And that's also probably why 90% of the startups fail eventually.
Yeah. But let's start with kind of
what problem you think there is and then how you're trying to
solve it as well to give the audience an idea.
Yeah, so state is really focused on helping out software
Engineers, who deploy applications to kubernetes to
let them troubleshoot their application.
And why is that important? Because there's a lot of Cuban
at these experts. They really focus on the Cuban
at this layer and there are many tools and Frameworks that have
solved. A kind of the lower-level Cuban
Nettie's. Yeah, but now there are many,
many engineering teams deploying to Cuban artists and they don't
have the Deep knowledge of kubernetes itself, but they
still need to troubleshoot their interaction between the
application and the Cuban at is layer.
And we really ask yourself the question So that problem is
heard from s res. From platform teams, who are
bothered time after Times, by the regular Engineers.
Can you look into this? Can you solve that for me?
So, that's a trend that is spotted in the market.
Then if you take a look at how the markets all shit that's
primarily to dashboards and we seek ravana, we see low key and
then all the at the bigger, a p.m. type of tools that also do
observability But they all only provide dashboards, right?
And that then means that it's up to the human interpretation, to
read the dashboard, read the signals, and come to
conclusions. What's actually wrong?
Hmm? And that sparked, that
understanding that, aha moment that's parked on a deeper
research to really identify okay?
If the current way of solving it is true, dashboards are than
better ways, right? Where the other teams become
more autonomous, more powerful in doing the troubleshooting the
remediation Shelf. Yeah so that's how we how we try
to discover is there is the problem actually solved and it
solved effectively and efficiently.
Then we concluded. The answer is no and then we
started to think, okay but how could we, how might we solve it
in a different way? Do we have different answers to
the fact that we have different data Etc?
Yeah, so yeah, that was that was really first.
Is there a problem? That's one.
And then you can help work towards initial Solutions.
And the question is, are people willing to pay?
A at that standard, kind of the the seconds.
Yeah, so interesting stage but that can only come second.
If you have a really clearly articulated problem and a
solution and that's the next iteration.
Yeah. I like that.
You also look at like I mean if there's an existing problem then
there's also Solutions towards that problem.
But if they are most effective right?
That's kind of subjective. If you believe that your
solution can do better or can iterate faster or can deliver
value in a different way, in a more effective way, then you
might have a product on your hand which can add value to That
space. Yeah, exactly.
I think that's very cool but that's not.
So I know sex tape from years and years ago, but that's not
what stack State started off with, right?
That's kind of how it is now, but what did it do?
Previously, and then even more importantly, why you have you
pivoted, I guess. So if you take a look at stack
State as a platform, yeah, I would argue.
It's a kind of a toolbox. So it's super powerful szostak.
State was technology agnostic. Which effectively means you can
observe and monitor everything. That was floating around in your
large Enterprise from modern tech.
To the more traditional Technologies out there and it
was really up to the human, to the user to, yeah, to Define its
use and to set the right thresholds and to set the right
alert. So there's very manual.
And if you do it in a larger Enterprise, where you rely on
multiple data sources that resides in multiple silos in
your organization, it can take quite a while before the tool
becomes effective a because you need all the data to become yet
to become effective. Yeah.
So the fact that was a tool box and it reaches I it relied on
multiple Organizational units to have value that started our
thinking, is there another way that stack State can become
powerful straight out of the box?
So, rather than weeks, or probably even months in some
organizations, just go to five minutes and there you go.
So we said, what is done the technology that is super
standardized? The provides a repetitive data
stream. That's easy to consume.
Yeah, so whenever you switch that on, at least the data is
in, and then stack State can do its magic of structuring the
data. So our desire was to go to a
situation where it's easier to get started and see the value
faster. That's one then the second
obviously, is the entire move to add to Cloud native where the
trend is around for quite a while.
But larger Enterprises adopting, it and struggling with many
engineering teams to make that to make that work.
Yeah that was kind of the second movement that made us think is
also from our solution. Can we provide not only fast
time to Value but also out of the box value at these two.
I always separate from each other and Devil.
We should we not only need to ingest the data but we also want
to as soon as we ingest tell the user, what's a configured
correctly? What's running, smooth?
And what's failing. Actually in your landscape, your
community landscape where you need to act upon?
Yeah, so that's first time to value.
And then whenever we understood that, that is indeed a way
forward. Then we ask ourselves questions
about other than the real problem.
And that's troubleshooting so, for many people they say.
Yeah, it's reliability. Correct.
That's the underlying needs. But what is most painful?
That's the process of troubleshooting.
Where people, struggle understanding what's going
wrong, one hand and knowing how to remediate what's out there.
So bringing the azeri practices into our product.
Yeah. That is a kind of the yeah, the
third angle that we applied. So from an empty toolbox that
took months towards a yeah solution that works within 5
minutes as soon as the data is in interesting.
Yeah. Interesting.
I mean building that toolbox and getting to that point where You
have kind of your customer base and you can see the problems
with that toolbox, right? Getting up and running with
weeks, or even months in some complex, organizations, getting
all the data in. I think that required a lot of
time, right? And a lot of, like, customer
interviews, probably really getting to know what the problem
is. They're facing with the solution
you've built. Because the toolbox is really
good if it works for whatever you need to, but if it takes you
a while, to get up and running like that can be challenging and
I'm assuming, especially for the people that created that
toolbox, that must have been hard.
Right? Because if you're in a product
building phase you think you have a problem defined and then
you're building that solution towards it, right?
But if in practicality turns out it's it's a bit different than
you expect it, right? Reality can be different in
actuality then at some point, you have to acknowledge that,
okay, the solution that we've built might not be a perfect
solution, right? It's rarely perfect solution,
which is why you have to keep iterating.
But at some point that acknowledgement needs to happen
that is like, okay, this might not be the right way for us, but
we Might find Value in this way. Like how, how was that if it
within the organization stuff? Well, the interesting part is
The platform itself is a powerful platform and if you go
to our individual customers, they would all answer that.
Because if you take a look at how they get end-to-end change
inside and when Jane Eyre with 10 15, 20 different engineering
teams, all being built up in the same.
Topology, stre, how we call it older components connected?
That's super powerful. But if you then open that box
and ask the customers that are existing customers but what is
it that you do with our solution in then you find almost twenty
different use cases and That in particular is a sign that you
need to ask yourself. Is it then repetitive right?
If you want to move more towards a faster growth or then,
repetition is super important because one customer almost need
to be the same otherwise you start adding capability after
capability in your platform becomes super broad rather than
hyper-focused on a super clear program.
So the fact that they were solving so many problems that to
me was a sign, okay. But is it actually a healthy
model for faster growth because then you need to maintain all
these capabilities. Ability to make them better and
make them better and Devils. You kind of the AHA for us from
a product perspective to say, hey, the platform is powerful
and because taken to 20 different things, but is that
sparking fast and rapid growth that we had that we planned for?
And that was the kind of the main reason to start thinking
differently and to almost narrow down the toolbox and say, hey,
but let's make two books. Super deep, right?
Really into a product on this narrow capability set, and then
we can Start widening again into other Technologies and other
other patterns. If you like, yeah, it's compared
to Old comparable to like a personal skill set.
I feel like like if, you know, a little bit about a lot of things
then are you still being very effective in a few things now,
you still need kind of a depth in a few areas, right?
People talk about t-shaped profiles or pie-shaped profiles
or what have you cone-shaped, nowadays?
But it's similar to the product that you're describing, right?
And I'm assuming that or one of the questions.
Had was like, I have a friend that is building a code,
automation tool, and this called automation tool.
He describes it to me as if an organization adopts her and uses
it effectively, then their developers are going to be
faster just by code automation standards, right?
We're playing around with Chad GPT now and it spits out a lot
of generated code which means developers can be more
productive. But the most challenging part
there, I see, is that an organization needs to really
invest in this kind of adoption of a code automation tool and he
Don't have an open-source variant.
Yes kind of a free license model but I really see a lot of
challenges in organizations adopting software in that way
because it's a big stepping stone for them.
It's a big hurdle to adopt it within an organization or
development unit if I'm in a development unit and my manager
says listen we're going to use this and only this nowadays
after we think of, okay. Do I want to invest my skill
set? Also in using this tool, I'm
going to be bound to this, or do I value like, All these skills
more and more like have you seen kind of a challenge in
organizations adopting stack stay early on versus how it is
now or how did that go? Yeah definitely so if you have a
toolbox you need a lot of knowledge on the inner workings
of the toolbox itself to become effective.
Are how do you create whatever your data streams your monitors,
and all these type of Ed Tech stay technicalities but sure
individual building blocks you need to have a deep knowledge
because you need to configure it as a user, your self purchase
today. Where you switch?
It on and the platform does it for you as so the burden that
the level of knowledge that you need to build up to become
effective. Yeah, reduce probably with 99%.
Yeah moving from an impromptu ass ass, right?
So all these movements that go hand in hand that really lowered
lower the burden as such. Yeah.
But interesting, you're talking about the open source, the other
interesting learning that I of the yeah the the challenge I
would say that. That then commercial players
face is for open-source. There's often a super narrow
problem with a narrow small problem with the super narrow
solution, right? So that there's a problem and a
solution. They go hand in hand because
there's often a developer that has a frustration or he sees a
problem and that sparks then an open source project development.
Yeah. Whereas if you think about what
we want to put it commercially in the market, what is that?
It kind of the broader the broader play that you need to
play as so you need to To go a little wider.
Take the big trouble shooting area.
Yeah. And then the pitfall straight
away is. But what fits the
troubleshooting boxer? Because we've now customers say,
hey, this is amazing but can I create my eye?
My own as allies and as allows yeah, technically it's pretty
easy because we are a platform but is that in our main focus
and that's now the the next the next challenge wave I feel we
need to go through. Is how close do you need to
stick a kind of to your core Mission?
Yeah. And not start to widen to Early
and under the answer yet, but that's the kind of the next the
next challenge that were that were facing.
Because so many people asking, hey can you also do this and
that and the most time the answer is yes because there's a
powerful tool box. But the question is does the
derail you as a product from becoming really good at
troubleshooting before you move to the next?
Yeah, the idea - yeah, exactly. Do you think that happened early
on as well? Because you said like a kind of
grew in breath. Yeah, definitely definitely.
This is definitely a pattern which is which is not that bad
turn. If you're providing a toolbox
but if you think about who you are, yeah.
What is it really that you would like to achieve?
Then if I would do it over again at the journey, then I would
definitely stick to a smaller features at first become really
good at that before before widening, and I can really
recommend every company to do that and if you feel
difficulties there, I think my hypothesis right now with the
Lessons Learned is that you don't know enough of your
problem and the market that you're targeting.
As soon as you feel hey I need to do this and that and that and
that they're my main question would be but are you clear
enough on the problem and is it in real existing problem that
people are willing to pay for? Yeah because it's often a sign.
Yeah. And this and a little bit of
that but then hey this is my problem.
This is very focused on. Yeah because you're like trying
to add things on top of the or next to it to add value but if
it doesn't have that depth to kind of keep you going, then it
might not be a good idea to do so I feel like yeah, exactly.
Exactly thing. And the and the other part is if
you need six website pages to explain what you're doing, then
you might want to ask yourself the question.
Yeah. Right.
Is it clear enough and I my targeting a single use case or
IMA just identifying what to do. So we also radically simplified
our homepage right, took off every use case, that was on
there and just one single use case and as resonating yeah
because there's a clear audience and a clear problem and a clear
solution. I mean, I like I like that.
It's resonating now but it to get to that point must have had
a lot of like discussions. Conversations.
And some people also disagreeing with you saying, like, no, no,
no. If we do that, then all of the
use cases go out of the window, right?
Because it's still a toolbox. Like how did you navigate that
to a point where it is effective now in having those
conversations? Obviously it's a lot of it's a
lot of data gathering night, and that's primarily qualitative
data. So having interviews and coming
up with results there. Yeah.
Sparked conversation. Show the trends in the market.
Let more people talk to the customers but also yeah, take a
look further. What is what's happening in the
cloud native? And it's TGIF community and it
landed computer Foundation Community what's happening there
and what are kind of the underlying deeper trends?
Plus what we did is we look back and said, what are kind of
technologies that evolved F 5 10 15 years ago and a really good
learning that you can take from the test automation, right?
Which started pretty Technical and now move to the UI.
We're also the non-technical people can do test automation.
Yeah, similar to see ICD. It started with Jenkins and and
the command line driven tools, and now you have all these nice
UI based tools. And we honestly think that that
there's the same Evolution going on in the in monitoring and
troubleshooting Market where It's now still super technical
oriented but what if you want to bring that to the big groups of
people to audiences then the UI again is needed.
So what are similar patterns that that happened and repeated
in history that say something about where this Market is going
as well. Yeah, That's one.
Yeah, and the other is finding in your existing customer base
successful examples of that the narrow.
Well, smaller product you want to further develop first
because, also, in our existing, customers were a lot of
customers troubleshooting. Cuba, Nettie's through the help
of Sac State. Yeah.
So taking these lessons showing how happy they are.
That is super important. And and just a factual numbers
are from gardening from Forrester.
How is the market evolving? From from a money perspective
and word, what does it go? What are the competitors doing
Etc? Like the like the data-driven
approach, right? Because then you kind of take
the gut feeling or a lot of assumptions people have you try
and take that out of the room? Because if it's a discussion
like that then it might not be towards something Progressive.
Especially if people are kind of hard-headed, like they tend to
be in the tech space, but still I was wondering because you
said, you talked to customers, who's in that room when they
talk to customers, are we talking software engineers?
You're talking product like who is in that conversation and who
does that conversation as well? Yes, tax it has to beauty or
very technical product managers and because we're in a super
product technical space. So you cannot, I do believe you
cannot build a product in this space without knowing what
kubernetes is without knowing what coding is, what software
Engineers go through? Yeah, so a big portion of our
product team is super technical, having an engineering background
themself and that's that's super helpful to 11 and assess at the
technical. Things in, at the same time to
understand the more product management oriented questions of
problem and Market Etc. Yeah.
So that's one of them. The other thing, what we did is
we started to listen more to our own Engineers are, which is
often a good sign. If you say, hey, we want to
build a product that we not only sell to larger Enterprises, but
that should be so powerful. That even we ourselves would
say, hey, I want to use this day to day, and that means all of a
sudden you have F 15 20, 30 engineer, super close by
ancient. Iran engineering teams.
That provide feedback. Yeah, and that change that.
It's so many things. I can imagine, the one edit the
passion from your own Engineers. How they contribute to the
product, the feedback cycle that we started to build up.
But also the fact that they're more hurt ever then have them
before. Yeah.
It's super helpful to make to make better and more accurate
decisions. Yeah, that's really cool.
I mean, from a I'm a person that also on this podcast.
I've said I'd like to start my own company at some point.
Like, I think now, Still early on and I'm trying to have
conversations about a lot of avenues with regards to building
something to gain as much knowledge.
They have the confidence to even do that but for me one of the
questions I have is like I'm going to be probably one of the
technical Founders, right? And I can see if you're
developing a sauce or an open source kind of product that it
can be very valuable to have that technical knowledge but I'm
wondering what the pitfalls are. You're saying like the founders
are very technical like what were some of the pitfalls you
saw with regards to that as As well.
Well one of the pitfalls. Sorry Mark Lowe do I complain?
He's listening sorry I know it's strength and the pitfall there
is is that you focus too much on technology, right?
And the focus on product Market fit.
What is the what is the need for the ask behind the question?
Yeah that is that is something that requires slightly slightly
different skills. I would say truly understanding
hey the deeper problem and can you productized that into
repetitive play? I do think that's Tech.
State, picked up a little later into the journey rather than the
technology Focus. The other Pitfall I do think is
that you focus too much on the vision which can become almost a
fairy tale rather than hey. But where based on what data
where do we see just exit relatively late start off with
product measurements, collecting the data?
What are the features people are using?
How are they using it? And honestly, yeah, you needed
qualitative but also that quantitative data to make to
make judgments on our dish features you Used to need to
switch them, off position, them differently.
And then, the other thing is, what are the, how can you build
customer intimacy or loyalty without having conversations
with all of your customers? So the fact we started too much
more user guidance in our product and through whatever
tools at the do it for you, even if you're not guiding the user
yourself. That was also another way of
thinking that we brought in that is changing how How people
interact? Linda, the final BJ's sometimes
having a technical having a feature that can do the job.
It's not an it's not exactly the same as will.
It do the job for the user rights are saying yeah.
But from a technical perspective, it works.
It's not the same as hey, but the user is super easy and happy
with how you use it, he knows where to find it, he knows how
to configure it, right? So that distinction, from a
technical perspective, you can earlier say, hey, it works,
right? And then me as a product manager
Injure or Side Sales engineer. They can demo it because they
know where to click, they know what to do and if you have the
voiceover that works but if the user in the world needs to use
it, then that's that that can require different.
Yeah thinking so that would be another one.
What you needs a little more business or customer oriented
type of product. Next to the technical roles
interesting? Because from a technical point
of view, I can see how that happens, right?
Because you're like okay, we're going to build this feature, the
features live, but if people are not using it then, Wrong right?
It's not really finished. You can say well we offer the
functionality but yeah, if you can't find it or you can even
use it then what's the point right?
It hasn't deliver that value like it should.
Yeah, exactly. Exactly.
And then moving from a big broad platform, toolbox into a narrow
super-focused out-of-the-box solution.
Yeah, that's also a thinking that you need to go through,
right? Because the goal initially was
to provide a platform versus now.
No, it needs to work within five minutes, right?
There's no Debate about that. So that's also an entire
different mindset and it goes from documentation to the flows
to the UI to the text, to the Highlight icons to literally
everything to guide, the user towards that moment of value and
a ha in the product. Now, that's a, but that's also a
complete shift in the new species, right?
Because if you're saying no, it has to get up and running within
five minutes, like that wasn't there before.
So you have to get used to that way of thinking, as well.
If it kind of takes away from that then has it really offering
the value as a Chair. Or is it take away from that
experience? And therefore we shouldn't do
it. Yeah.
And the beauty to go there
little deeper the beauty. Is that in the past we had a lot
of feature development by different teams.
So focusing on multiple areas of the product we're now super
focused, we have a single demo our single demo flow in the in
the spring demos. We've run Sprint of two weeks.
Yeah and then everything the entire company comes together
and it's a single demo where the business comment on it were
engineering comments on it and the fact that it's so focused,
you get also very small Subtle elements of feedback.
Say, hey, this is a link everywhere.
It's underlined and here we go, add to a component page, but
it's not underlined, right? And you can say, yeah, that's
minor. But if you think about usability
perspective, the pattern is everything.
That's underlined is a link. So let's make this one as well.
As I hated this takes three clicks before you get to panel
B. Why not making that one click?
Now as so everyone becomes more passionate about, what are we
building? What is the feedback, what can
improve it rather than a feedback cycle?
Sometimes three months or even six months before, the user is
using it, right? So you're also reducing that
that feedback time, much more, and doing that together,
technical business engineering product sales.
Yeah, that's that's, that's amazing to see that changing.
Yeah, I like that a lot. I mean, I've been at demos and a
lot of people are invited, but they don't show up.
And I don't know how you got that engagement because from
your perspective, like the way you described, it sounds like a
very engaging audience. Right?
If they're saying listen, that takes three, clicks and it It'd
be one, click. Then that means they care and
they see Improvement that that's needed there.
And they add value by being in those demos and seeing what's
being delivered. But, not out of a lot of demos
become like that out of the box. Like, how have you gotten that
engagement to that point that people actually care and show
up? Good question.
Well, yeah, I got a couple things so one is just just start
doing it right, and it sounds super easy, but that's one.
Second is myself. I'm somewhere in between, I'm
not technical but I but I understand what we're doing.
Obviously you need to end, absolutely.
And I Repent, I pretend to be the stupid Watcher also often
when engineer start to demo and it said, hey, we have a 500
error over here and we need to do blah, blah blah.
I said, hey what is your 500 error?
I know what a 500 errors but in my team, right in the sales or
whatever, there are people who don't know.
Yeah, right. So, just asking the stupid
question. People start to open up as well
and think. Oh, if on the a.s. is asking
this question, I can also ask another question, which is
probably absolutely non-technical.
So it's the behavior. I think that you need to change
in your organization as Leaders to just be open.
Yeah, the second is, we changed a so there's a demo their
feedback and then some of the Engineers organized, the
meeting, thank you Brom to do straight after the demo harvest.
The feedback prioritize it, put it on the roadmap on the
backlog. So all of a sudden, many sales
engineer was providing feedback on for now, it's within a week,
it's back into Master. It's processed and they see the
results are so we park the behavior to provide feedback and
yeah, rewarded. With picking it up and doing it,
furthers. Yeah.
I've listed the feature requests and in Months or years, we can
work on it. And it's now possible because we
have such a narrow Focus because everything suits, that, that
thing, the other one really important is take a scenario
that real rather than say I have some code and it works I
validate something yeah show some see allies what not have a
real working problem and focus with your demo on that.
So everyone who's watching the demo.
They can start to repeat that message.
In the sales Demos in the pitches that we do towards our
prospects and whatnot. So yeah, it becomes really
integrated. What we're working on in
engineering and demoing is the same.
As we show on the playground is the same as we do in sales
meetings. Yeah, that's awesome.
And it's really awesome. Yeah.
Actually imagine. Yeah.
I mean the feedback and the reward, right?
If you miss a demo and you had feedback and therefore a feature
doesn't like is not being developed and doesn't add the
value that I think it should. Like, I think that, like, fear
of missing out. That's a, that's a pretty
interesting one. Yeah.
Do you also Get feedback where you're like, okay, that's
valuable feedback. But we might not pick it up and
we do push it to the long-term I'm assuming so.
Yeah. Absolutely.
Absolutely mad because we have such a high focus on our first.
Our first part of the journey we said, hey, this doesn't fit a so
we often get the question and we're now focused on Cuba,
Nettie's text a really good at any technology.
So when do we widen to are here to AWS?
Because that is that is our power to do the full full stack.
Observability, sure. And that is it.
That is a choice. We should we not going to do it
now obviously, right, in three months or four.
Four months down the line that will be a feature will pick up.
So yes that's happening a lot and just by explaining it and
saying, hey but where do we focus on, what's our next kind
of big thing? Yeah, we can easily push push
things back the other element which I didn't reply or that
answer yet but I realized is we also Focus really almost on.
It's almost a new product that we're building.
So also almost a new launch that we're doing.
Okay. So we're really thinking through
okay, what is the Engagement level people come in on the
website and we want to push them into the playground.
Hey, there's only a button at the menu, at the top export
playground. Let's change the homepage right?
With the big image. You scroll over, you get the
button, explore playground. Okay, then they are in the
playground. What's the next yet that user
guide? And so it's not only that
Engineers focus on engineering the product or developing the
product, but we also try to involve mache.
But if the website is now the most important thing, let's just
make that little website pivot or if the playground is most
important and We need to start measuring what people do in the
playground. Let's start a wedding events as
a rather than saying, hey, but the main goal is to develop a
strong product. Now, the main goal is to start
building an end-to-end process right, where you start yielding
results. And that pivoting thinking I do
think is super important as well for companies who go through a
stage like this. And yeah, it's not only about
the product know, right? It's the entire funnel that goes
before and straight after they use and utilize your product,
it's a whole, it's a whole journey, right?
It's interesting because if you optimize a new really make a
performant kind of end station but people don't get to it.
What's the point, right? Have to optimize the whole flow
and that takes, as you mentioned Gathering data, even testing and
see what works most effectively. And then really showing where it
shines, right, because it's kind of a route to get to where you
want them to go and that route needs to be optimized are all.
Yeah, yeah, I mean you touched on it earlier as well but you
don't have a technical background yet.
You're in a very technical space.
Nowadays like what were some of the challenges in getting there
Because from this conversation, I can see where your value is
rights. Optimizing that change its
giving those insights. It's keeping that focus and
maintaining kind of laser focus and the engagement within the
organization. But from a technical point of
view, you do need to know your stuff before you can do that as
well. All right.
Thank you answer the question yourself already.
My focus of my quality and strength is in the big picture,
understanding the big picture and then knowing just enough I
had to yeah to help out with the details.
Two people. Yeah, so funny enough early in
my career although I studied human kinetics, which is really
focused on developing medical tools and devices for people who
are missing arms or legs or maybe something else leave.
Yes, I've been in welding making stuff from Plastics from Woods
and not go out. Not so super nice.
I do think one of the most practical university studies
available in the Netherlands, but I never worked in that
space. I jumped straight into it
started as a test engineer. Our and then started rather
quickly to develop new services for capgemini sogeti which I
liked. So what I like there is the
thinking on new products, new offerings and putting them into
the market. So you need to know just a
little enough, do the analysis and then often whenever it was
developed, I moved on to the next to the next challenge
because that is that is what I like thinking through new stuff.
At any moment, I started the entire agile movement Devils
movements came about and then I moved closer to engineering
teams again, the more from a change perspective.
So how can you utilize technology?
She ICD pipelines release automation deployment,
automation. How can you use that to become a
more effective engineering teams.
And that's where the law of of management leading engineering
team started to, to happen and there again, knowing why you're
doing stuff is probably more important than implementing a
Jenkins pipeline, or, and as your Hopes pipeline worker or
such. Yeah.
So again the big picture, why do we do stuff?
And then I work for ING at that moment.
I really challenge the status quo, from a security perspective
with all these paperwork's, right?
That you need to put signature of paper to get to production.
I said, hey, the tools can do that much better.
So that's where I dived more into the technicalities.
How can we build pipelines that really do this and then,
ultimately, Yeah. All these experiences in
whatever, 1517 years, helped me to focus on this, i-i'm self
educated person. That's, that's how I learned
just do it. Push yourself to the limits and
then and then discover stuff is going.
And then the big picture thinking.
Sometimes I wonder my, as should, I become really good at
something, but then I realize, yeah, but probably heard that
something is is indeed the y-yeah, that's the skill.
Yeah, I can imagine. I mean a lot of people I meet
being involved. Volved in creating products,
right? If it's from a technical point
of view or from a big picture point of thinking, if they're
very entrepreneurial, I wonder, like, do you have or do you
think of going out and on your own Venture, as well, like, in
the future stuff like that because it feels like, okay?
You can probably figure out a problem laser focus on it,
incrementally, create a solution towards that and bring that out
in the market, right? That's what you've been doing
your past, that's what you're doing now as well.
And kind of Journey is obviously a journey.
So, you're We're in that Journey.
Do you want to do it from end to end with your own kind of baby
as well in the future for 15 years in a row?
I would have said, yes, I will go that one day.
Yeah. But then I recall an assessment
I did that the university and just in my final year and that
was a pretty intense assessment. And then the guy he came with
the conclusion, he said on the rez.
I don't know why I came to this conclusion.
He said you're very enterpreneur.
Oh, but you will never become an entrepreneur and I started
laughing. I said well you're lying because
I will start my company two months because I was partying
with someone and that never happened.
And then about eight years ago, I started my own company.
Again, I was about to start as an independent Management
Consultant and two weeks before I would start my first
assignment. I got pulled into a product
company. And again, I was, I was working
for someone else. Yeah, rather than starting
myself. So, I don't know if it will ever
happen. I really enjoy hell.
Leading leading a company and what are not.
My own or not. It doesn't matter too much to me
as long as I can just contribute.
So I do think you can have a lot of entrepreneurial skills
without running an ad without being an entrepreneur yourself.
And yeah, that's 10 for the benefit of us, probably.
I don't know, it just thing and that's okay.
It's a it's interesting that they said that and then actually
happen like that. It's an interesting one, but
when it comes to then the the environments, you either have
operated in or you operate in now.
Like obviously the environment needs to be In such a way that
you can be entrepreneurial, right?
If you think there's value in a certain direction.
But that wasn't really the direction.
You came into this organization for you, advocate for that and
you go for the value, right? If your organization is like no
no no you need to be focused on this little tiny thing then
you're probably be going to. This is not for me.
Yeah basically yeah yeah definitely and I've been in a
company before and people can check out which is that right
why was it? So I operate the best if I
report straight into the CEO. Okay.
All right. Because then you there's not too
much in between you and the decision making and the
direction. Yeah, I form a product, if you
work for product companies, that super important, right?
Because product is the direction that the company is taking
because your product company. Yeah, and I struggled quite a
bit being a bit more on the distance from the real decision
making powers in the company. So, I discovered myself in the
last five, six, seven years that smaller companies and then being
at that position, leading the product is The best way I
operate, having a lot of interaction with marketing,
which seals, and with engineering kind of that
triangle feels feels the best to me.
That's also. And then it's also like more so
on an earlier start of a product phase.
Yeah. So you have to start, you have a
scale kind of ramped up and then I don't know what the third
phase is, but that's also for like a different skill set.
I feel like, yeah, definitely definitely, yeah.
So the first part of company I joined was another gbi company
called GB elapsed. That was a lie.
A scale-up stage and I like that very much because it was my
first experience with with product, with product companies,
how do you operate the product team, what matters?
So there's quite a bit of established processes and
practices already and so that was nice as a learning and now
it's text date. And in particular if we start
pivoting are thinking towards more product LED growth.
We almost start from scratch again.
Yeah. Which is nice because then you
can you can figure out that first part at the start up
towards Caleb stage over then you have the full spectrum and
Let's go quickly to chain up and then enjoy.
What's after that, as well. Yeah, exactly Joy.
The launch basically exactly. I can imagine I mean a trend
I've been seeing and also with regards to conversations I've
had on this show is like an open core business model where part
of like the product that you're building is open source and then
exactly as you saying getting something up and running as fast
as possible and that real user experience, that's then where
the added value of a company is right.
Like I It's not a secret. Sometimes I applied a jobs and
one of them was a developer advocacy role and it was around
this open tool an open source tool that they've created, right
was about database management and then something else was
about like, schema-less changes to give you very narrow and you
can't really figure out what that is.
But their idea was okay, we have these open tool or Open Source
Products. The maintainer is one of the
founders of this company. And we're going to create a
product around this to get everything up and running faster
and to make a seamless user experience.
Experience is going to be running on the cloud.
You don't need to deploy yourself.
Maintaining yourself that's going to be a service, right?
That's going to be the software as a service, but then still,
the core of their business is open source.
And the value of that is that everyone can contribute.
The features can be added on top as well.
And the value for them as a company is more.
So that user experience, right? Reducing the maintainability and
kind of total cost of ownership of a team that uses not tool in
using their sauce offering basically, with the Will that
you're building. Have you had those
considerations and going open source as well with the regards
to the tool you're creating because the way you describe the
tool is more, saw the open source part and in the laser
focused kind of user experience part, that's more.
So the product of on top of that I would, I would say we're
taking a slightly different approach to.
This is what we see a lot right there isn't successful open
source product and then all of a sudden you how can we monetize,
right? Because it's ultimately the
desire to monetize that's out there for good reasons, right?
Because you need to maintain it. And make it better.
And if you take a look at OPA, open policy agents.
Yeah. Headers, their companies around
it, there like steerer and others that then build a shell.
You II what? Not a platform underneath and
around it. So that's that's that's a really
nice model. Sac State has a slightly
different model so we utilize a lot of Open Source components
are like Victoria metrics, for example to store our our metrics
because they provide amazing from ql capabilities and a
couple other under the hood, open source components.
But then, the core itself I would say is, Is closed, right?
Yes, its own proprietary solution how we would go to the
market is really true. Okay, we provide let's say 10 or
15 out-of-the-box monitors at these out-of-the-box,
validations that look at your data, mmm.
And that is the open part where people the community can start
contributing more monitors and then ultimately, if other start
using it, you just got a broader coverage of all policies that
you would like to apply to given that he's running apps on Cuban.
At ease. So we take, we take a different
approach. We don't have what we discussed
it a couple times, but there's so much proprietary magic and
through our well for people who knows text Data as a lot of
topology, that we that we get. And that we create, that's our
unique Source, right? So open sourcing, that would be,
would be a mistake, I think, but using open source, and then, at
the same time, building a community.
That's where we believe we should.
We should push text date. Yeah, yeah, I've seen it from
from both ways, right? That people have an open source.
Lucian and they build a product on top of that.
Yeah. And people that have some
product in their head, they're creating a solution.
And at some point, they open source part of that.
Exactly. And then the you, the community
can leverage that to create as you're saying, more solutions
towards specific problems that they have and then the core is
then still kind of close. So I feel ya.
Yeah, and if you think about the audience that the developers,
you need to think about this very well, right?
So it's and it's not only what all this commercial open source,
it's all the way. Also, So about how open is your
platform and so whatever have a year ago or three quarters of a
year ago, we did an entire rebuild over CLI.
Right. And a lot of people would say
half I would you do show right using the CLI about the main
interaction to configure a product.
These days is to the she like so not thinking that true if you
pivot the product from a broad platform to a narrow developer
tool yeah would be a mistake a show.
It's it's also about the openness here we moved or moving
away towards or more towards yellow based monitoring
configuration why Because the entire space from Covell, right?
Rather than having our own query language.
Hey, we're standardizing around from ql, let's Embrace and let's
add it to the product. Yeah.
So that is also, if you think about Mass adoption, you also
need think about these type of things, and probably more than,
than open source for his commercial.
Because if you think about the freemium model or an extensive
free trial or a playground, these are ways where people can
easily experience your product as well.
So, Yeah. I mean I'm a software engineer,
right? So I know the tools that I use
and I only mostly use the tools that are that have the least
hurdles to get up and running right if I'm trying to do a
proof of concept and I'm trying to build a feature and we have
certain solutions that are out of the box or even open source
variance. Then I want to try those out if
I have to pay to even try out your solution like it's, it's
never going to fly. It's never going to get adopted,
I think, as most of the open stuff is, right?
So you want to if your customer base.
Software Engineers. You want to make it as seamless
as possible for them to get up and running and to actually do
multiple proof of concepts with whatever you want them to do.
I feel like yeah definitely. Otherwise you're out of the
running before you even begin. Yeah but I do like this kind of
open core model. I see a lot of benefits with it.
Like an older variant would be like licensing and stuff like
that and even then you have kind of more of a freemium model by
Adam. The reality.
I feel like a product space might be shifting towards more,
so open and The building as well.
Yeah which I think is an interesting one.
I've really enjoyed this conversation.
Man. It when when a bit differently
than I thought it would but still very enjoyable.
It's there. It's there anything you still
want to share before we leave off?
I always throw this curveball, what to do.
Well, probably more personal I do think no one, no matter in
what role you are, should accept the status quo where we're if
you're a software development or in the space, that we are Beyond
coding, there's so much changing at the moment, right?
And that entire Cloud but then also, the addition of product
growth, how people experience your product.
That's that really big in the space and how is that big is in
the past? And some people might think,
yes, some of the listeners might think, hey, but that's already 5
years ago, the decision making is changing entirely different
in. In larger Enterprises, we're
still other Architects and the senior decision-makers these
days, it's all happening in engineering teams.
Yeah. Right.
The evaluate. And if even possible they would
purchase or one level up, they would purchase the solution
directly. And that's something.
If you're if you're in a product company think through how for
your product, that is pivoting and probably more rapidly
pivoting than you think. And that's that's an area that a
lot of companies have you underestimate, where is the
buying power moving towards and how do I How do I deal with that
movement? What does it mean for my product
my positioning which are the conference's you go to Etc.
So that was a big learning for me and enjoy life.
That's a that's also and I really like that one.
Cool. We're gonna round it off here
everyone. Thank you so much for listening
Andreas Prince. I'm going to put all his socials
as well as some other links in the description below.
Check those out. And with that being said, thank
you for listening. We'll see you on the next one.