How to Build a Product Company with Andreas Prins

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.

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. 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.