Egil Østhus is based out of Norway - which obviously means he loves skiing. But outside of this, he loves to run outdoors, through the woods and on the streets. He has not done a full marathon yet, but dreams of doing the New York marathon someday. He's a family man, married, with 2 boys - none of which like to run with him, but they all enjoy being active and hiking.In a past role, Egil's co-founder (and brother, FYI) was looking for a tool that would help him release code into the wild, in a rapid - yet safe - manner. He couldn't find anything to meet his high standards - so he built his own. When the open source version started to get a lot of attention, Egil joined his brother to bring the solution to the enterprise.This is the creation story of Unleash.LinksWebsite: https://www.getunleash.io/LinkedIn: https://www.linkedin.com/in/egilconr/Our Sponsors:* Check out Vanta and use my code CODESTORY for a great deal: https://www.vanta.comSupport this podcast at — https://redcircle.com/code-story/donationsAdvertising Inquiries: https://redcircle.com/brandsPrivacy & Opt-Out: https://redcircle.com/privacy
One of the first, let's say, assumptions we had were that we didn't really want to go to the U.S. market because it was already two major competitors in that market. That was their home market, well established. So there is no reason for us to go there. Why should we go and compete where there's already kind of a big player? So let's go to Asia. That was our initial thought.
So we were really focused on let's go there and just make this thing happen. And you know what? We didn't understand the culture. We didn't know how to sell. We didn't know how to speak with them. We didn't know how to engage with them. I think everything you would read in a book, we failed on all of them. I'm Engel Östers. I'm the co-founder and CEO of a company called Unleash.
This is CodeStory. A podcast bringing you interviews with tech visionaries. Six months moonlighting. Who share what it takes to change an industry.
I don't exactly know what to do next.
It took many goes to get right. Who built the teams that have their back.
The company is its people. The teams help each other achieve. I'm most proud of our team.
Keeping scalability top of mind. The stories you don't read in the headlines. To ride the ups and downs of the startup life. All this and more on CodeStory. I'm your host, Noah Lapart, and today I'll help Egil Ursus create the open source solution to enable your team to ship code to production safely and at incredible speed.
Egil Ursus is based out of Norway, which obviously means he loves skiing. But outside of this, he loves to run outdoors through the woods and on the streets. He's not at a full marathon yet, but dreams of doing the New York Marathon someday. He's a family man married with two boys, none of which like to run with him, but they all enjoy being active and hiking.
In a past role, Egel's co-founder and brother, FYI, was looking for a tool that would help him release code into the wild in a rapid yet safe manner. He couldn't find anything to meet his high standards, so he built his own. When the open source version started to get a lot of attention, Egel joined his brother to bring the solution to the enterprise. This is the creation story of Unleash.
Unleash is an open source, what is called a feature management tooling. It's a tool that allows developers to release software in a less risky way, meaning you put your software out there. You can imagine the Uber or the Netflix or the Facebooks whenever they push something to production. If there's issues there, there's a ton of millions of people being pushed. seeing that issue.
And of course, that is causing some kind of risk to everybody. So that's basically what we do. We take away that risk and allows developers to do this. It's available, freely available. The source code is also available. And really what we sell is basically an enterprise version on top of the open source course.
So a developer, a software developer out there can really take downloads, get started with our open source version of Unleash, And whenever they start to see that, OK, this is really valuable for my team, for my company, it starts moving into more kind of compliance requirements. You need to have proper single sign on capabilities or you need to have proper role based access control.
And this is starts where you need to kind of move from an open source version into kind of the more enterprise version.
Basically what we do, we give developers back time to really focus more on being creative and doing what they love the most, solving complex problems rather than spending time managing and dealing with kind of post-production or post-release issues that tends to be taking quite a bit of time for a lot of software companies. It was actually created back in 2014, 15, actually.
This was back in the days where this type of tooling wasn't really available. So what happened, it was actually my co-founder and my brother actually that was working for a company and was looking for this type of tooling. So there was a few options available, but not really anything that fit his need. And of course, he has a very high bar.
Nothing he could find existing at the time didn't really meet his criteria. you know, engineers, we tend to kind of go away. And if we don't find a tool we like, we just create it. And the fun part there, Noah, is that it was never created to be a commercial product. It was never created to kind of go there and saying, this is where we're going to make a lot of money.
It was sort of, this is a real pain that we face. This is a real pain that Eva had. And let's make a great, great solution for that problem. Fast forwarding to when I was introduced to this project and this product, it was in 2019. So It was a few years later, so it was sort of growing organically as an open source project.
And Evo came to me one day and said, well, I have this open source project. This is something you probably want to kind of look into because it starts to get a lot of attention out there. So when Evo kind of brought this nice tooling to my attention, it was like, wow, this is actually very applicable also to this type of large organization.
It really caught my interest and we decided to let's put our heads together and then really see where we can take this opportunity. And then we spent about a year as a side gig, just exploring what is the product market fit? How does the competitive landscape look like?
And when we started to see that and actually spending a full year of every night and weekend to work on this project, we spoke to a lot of customers. That was basically what we did every minute, just talking to customers, understanding the pain, understanding if this was something that was what we experienced was similar to what they experienced and could this tool also be applicable to them?
Truth was, yes, it was definitely so. And also starting to understand how did we differ from the other players in the category. And that was a very, very important part of this journey because it allowed us to really validate what is the willingness to pay, what is sort of this position, or where does this product fit in next to the competitor that was already in there in the category, you know.
Okay, let's dive into the MVP then. So the first product you built. You've had lots of conversations, and then you went about building the first product. product. How long did it take you to build and what sort of tools did you use to bring it to life?
This is a Node.js application. It's built on top of a Postgres database. It was built in a few weeks. It was sort of just solving the most simple kind of use case you can imagine. And from there on, it was sort of kept like side project for quite some time, some weeks more active, some weeks less active. The beauty about an open source, there is a big community.
If there is some success, there is some community and there is some interest. And you start getting some feedback from others that is also using this open source and what they really need. I think the interesting part of the MVP is basically more than anything, we should as product people look at what is the minimum lovable product or usable product maybe, because that's what we're looking for.
Getting into a position where there is other users than yourself that really want to start using this product and invest in understanding this product. So the first version, a few weeks, and then it's slowly growing in feature set and kind of complexity from 15 to 2019. And then some quite extensive usage research.
And then we spent about a year to build kind of the next like really, really core, let's say, feature parity that is needed in order to kind of go and compete for large contracts.
So during that time, and maybe a little bit in that year, you've got to make certain decisions and trade-offs around feature cut, tech debt, things like that that you're building. Tell me about some of those decisions that you had to make and how you coped with those decisions.
Oh, I love this question. This is so difficult for everybody in product. I think we have, we spent quite a bit of time putting on kind of how do we kind of deal with that, this question, because this was one of the questions or trade-offs we sort of was starting to focus on early on. So in our case, I would say there is a few dimensions there because you bring in the kind of the technical depth.
Technical depth is very important to don't lose track of, obviously. But it's also what is the next feature you want to add to the product, right? Because Because eventually you want to gain more adoption to the product. And how do you kind of value that? So more than anything, we spent quite a bit of time deciding what is really the vision? Where do we want to take this product?
And why does this product exist, right? You need to understand what they're trying to solve, right? So more than anything, starting to really get the proper vision. So what we are focusing on, we are focusing on Making sure that developers have as much time as possible to do kind of what they love the most, solving difficult problems.
And secondly, we also started to evolve into saying, okay, when you create a software product, that is a team effort. So it's not like one single individual that is creating the great products. Great products is built by teams. At some point, I would imagine that you want to start monetizing on a product, right? So you need to have some thought around where and how do I monetize?
There is an open source version of the product, but it's also an enterprise version of the product. So how do we balance those two? We defined, then again, who is the user or the persona, the decision maker or the
key persona that is interacting with the open source versus the enterprise, and what is really the needs of this person for us to make this very, very attractive product for that persona. So when we have a feature request from a customer, does that feature request move the product towards the vision of where we want it to be? Does it really allow the developer to be more efficient?
Does it allow the developer to work more efficiently together with others? And secondly, also, it's about the commercial thinking. So does this really fit into the open source part or does it fit more into kind of the enterprise part? Is this something we should bundle this as a value add? So that's more the commercial conversation of everything.
And when it comes to technical depth, it's sort of you need to trust the developers. You need to trust your engineering acumen. It's just saying you are going to take shortcuts along the way. Technical depth might be okay. But you also need to allow and make sure that you continue to have a clean code or as clean as possible.
It's really important also to involve the developers into the prioritization, saying, OK, this is what we're thinking we need to build next. What else is there? Does this make sense? Is there anything that you think is more important? So we have actually had a few releases also of Unleash where it was really hard to see the difference.
But down there in the code, we know that we clean up quite a bit in order for us to kind of make sure that when we continue to develop the product, it It's still healthy. It's still good. So I'm not sure. It's not an easy answer as a product person or kind of developing a great product for yourself. You need to kind of set the direction of how do you want to make those prioritizations.
And of course, more than anything, you need to be true to them because as soon as you start having paying customers and the bigger the contracts and the bigger the clients, the more leverage they will have in order to kind of, we really, really need this. If you have a really good direction of the product, it's also easier to kind of push back and say, yeah, I hear you.
Let's focus on does this really bring the value that you're really solving for?
Let's switch to team then. So tell me about how you built your team and what did you look for in those people to indicate that they were the winning horses to join you?
I think we're looking for a healthy balance of experience and hunger or ambition. you need to have experience on a team, right? You need to have somebody that know the ins and outs and the playbooks, but also you're looking for people that is super eager to join you.
And initially we were also looking for individuals that was sort of open for just come and build, because one thing is to come and build the product, but also part of that is also how do we build the product? Meaning we don't have every process defined, obviously we don't have everything sorted. So it's sort of a different kind of state of mind or a species actually that, that,
that that really are happy in that environment because it is a quite hectic environment there is a lot of stuff that is not there you just need to figure out as long as we go but i think talent ambitions meaning ambitious not ambitious when i say ambitious is more towards you want to get somewhere you want to have an impact you want to do something you want to kind of put up your sleeves and just get it done type of mentality
but also experiences really undervalued. I mean, bringing experienced people into the, that has gone through this process before, or at least has seen what, or been part of what does a great team look like. And you know what, it's sort of when you start getting those and attracting those really, really strong people together, they tend to attract more strong people.
So I think the few critical hires is the first one when you've put the first core team. If you're If you don't get really, really strong people there, you will struggle to get strong people. But when you start having a few strong people, they tend to be magnets and attracting other strong people. And just keep the bar high.
Really expect a lot of your people or expect a lot from everybody, including yourself. And I think that pays back big time.
Let's flip to scalability. And this will be interesting, you know, given the product that you're building and how you've gone about it in the story so far, tell me about scalability and how you approached it from the beginning. Was it built with scale in mind from day one, or did you fight this as you grew and gained traction?
So for a product point of view, initially it was created for an organization that was really a B2C type of company. So it was built and designed with scalability, meaning resilience and performance in mind from day one. And I think for a particular in a software business, that is really something that you need to design for. But then again, you'd iterate and improve this as you go.
And from the organization point of view, it goes through phases, I would say. I think one of the challenges that we are facing and I think that most people is facing in kind of a startup world is what is important now and what is going to be, where will we mature into later, right? Because there is certain stuff that if you don't get this right, it will just fail immediately.
as you grow the company, as you grow the product, you will build a stronger and stronger foundation and it will start tackling in the next challenge and the next challenge. But I think it's important to really have in mind that there is something that we just need to accept. It's not there. It's not good enough.
I would love it to be better, but it's just not time and place to really go by and fix those challenges. And there are certain things that really needs to be done. And we decided very early to focus on, okay, we need to have a proper process on how we design, kind of what features do we put into the product and how do we do that?
Because we think that's going to be fundamental to how we are creating a successful product. that was the number one and then we started to move into okay how do we sell this product because for us we are here for business obviously so to really understand the commercial side of of the open source model and really how do we kind of monetize the product that was very very big
You know, it's this interesting balance between you want the structure, but you also want it to be unstructured because you want to be lean and you want to move quickly. I don't think there is an easy answer to this. I think most people with struggle, you just need to kind of go along the way and sort of balance this.
Sometimes you need to be very focused and sometimes you need to put down the structure and sometimes you need to allow, I wouldn't say chaos, but sort of unstructured and a bit more hectic type of environment.
Okay, so as you step out on the balcony and you look across all that you've built, what are you most proud of?
What I'm really, really, really proud of is the fact that we are a very small company. We are already competing with our major guerrilla competitors and we are winning deals with all of them. That is so cool. And that comes because we have an amazing team. We have an amazing product. We have customers coming back and saying, this is so beautiful, so easy to use.
It really solves this and that pain. And that makes me very proud. It makes me proud that there is like so 30 of us coming to work every day and they're working so hard. They're working extra hours. They're really so obsessed of really making this happen.
And honestly, that is making me proud that I'm allowed to be part of this fantastic team that is really pulling this together and completing it this way.
Let's flip the script a little bit. Tell me about a mistake you made and how you and your team responded to it.
One of the first, let's say, assumptions we had were that we didn't really want to go to the US market because it was already two major competitors in that market. That was their home market, well established. So there is no reason for us to go there. Why should we go and compete where there's already kind of a big player? So let's go to Asia. That was our initial thought.
Asia is booming and there is so much software development happening out down there in Asia Pacific. So we were really focused on let's go there and just make this thing happen. And you know what? We didn't understand the culture. We didn't know how to sell. We didn't know how to speak with them. We didn't know how to engage with them.
I think everything you would read in a book, we failed on all of them. And we also quite early spotted the fact that there was a lot of interest in traffic inbound coming from the, guess what, the U.S. market. So so after a few weeks and months, we just said, OK, let's just drop everything in Asia and just go for a U.S. market. This is where it is. This is where it happens.
We just need to be there. So so that I think was the first mistake. I can think of so many. I mean, initially when you start going, you are sort of just going for building business. You're going for building business. You need to hunt the next customer. You really want to close the next deal and really making sure that the product is getting out there.
Maybe you're doing a bit of forgetting to kind of document and build a structure. So I think in some areas we were... a bit on having a bit blind spots on when did we need to really start building some of the structures.
So I think that this is also where we are now kind of coming back and saying, let's not just let's get the heads together and just do some very focused work on rewiring and getting some of these key structures up where we can document how we can really coach to where we can really document and really make it more than tribal knowledge, because there's a lot of tribal knowledge in any startup.
And I think that we are not better than any. And I think The amount of tribal knowledge is really, really hard to get into for when we start onboarding more employees. So I think those are two obvious mistakes.
Okay, this will be fun to ask. What's the future look like for the product and for your team?
You know, we are building a great product that our customers love and we want to continue doing so. And for us, really, we are on a mission to remove stress from developers and making developers being able to spend more time on what they love most, which is fixing or solving difficult problems. So where will that take us? I think that there are so many ways where we can take this.
So feature management is a stepping stone, obviously, to support that. But there is also other challenges that we are looking into solving at some point. We are not there yet. So that is for future. I think that this company has the potential to go big, big, big. So I'm here for the long run, to be honest. And I don't really have any exit plan other than saying this is a great opportunity. And then
We are here just to create a great product that customers love, and that's where we want to take it.
Well, let's switch to you, Igor. Who influences the way that you work? Name a person or many persons or something you look up to and why.
I would say one of the first that comes to mind actually outside of our business. I'm not sure if you're aware of how up to speed you are in skiing, but there is an Olympic gold medalist called Axel Lundsvindal. He is a fantastic type of person. So why do I look up to him? Well, You know, he is the winner mindset like nobody else. He's like crazy about winning.
He is obsessed about taking the next gold medal. And really, he was, you know, really on the top of downhill skiing. And why I admire him is not necessarily the fact that he is a winner, that he's really kind of been on top of his trade. But he was – and this is really a nice movie. If you haven't seen it, there's a movie on Netflix called Axel.
You should go and see it because it really demonstrates this perfectly well. So he's individual. He's like one winner. You know, it's him or nothing. It's like if he'd make it, he'd make it. If he doesn't, he fails. But he's also part of a team, and this is really interesting. So there is a few kind of scenes there or kind of moments in the movie where you see him going downhill.
He's in the Olympics. He's in the final. He is on the top. And the first thing you do is calls back his pals up on the top, and he says – this is what I learned going downhill. This is where you should think of. This is how the snow is now. This is where the ice is. This is where, what you should pay attention to. So giving away all of the insights to his pals, they are major competitors.
They are in the team, but they're still, they are still competing. So they can beat him and take the gold medal from him, but he still does it because he believes in a team and he believes that we are better together as a team. If we are really transparent and honest, like openly sharing all of this. And that's, It's a mentality that is something I've never seen before.
It's like, this is really, really something I look up to. And I think that there is this great person that is so, so amazingly good, but also so humble and sharing openly, transparently everything he learned for everybody to be equally good or even better than himself because he thinks that's the better for the team. That is something I really, really admire.
We talked about a mistake earlier, but this is a little different spin. If you could go back to the beginning, what would you do different? Where would you consider taking a different approach? And I heard part of your answer, you're like, if I could go back, I would do that differently. But perhaps this one is something that maybe worked, but you'd tweak it a little bit.
More than anything, I have a lot of respect for time and place, meaning you will never, ever find exactly the same journey. So every run is different, right? But there is some learning points. So I think one of the things that I would do even more of is to be really, really focused on getting people on the team that have...
the experience and have gone through some of the challenges we are now facing. And some of those challenges we were and I were able to kind of predict were going to happen. But also some of them I weren't. So, of course, some of those challenges I've learned along the way.
And looking back, I would say if I knew that I had this and that type of personality or if I were hiring for this and that kind of capability or experience, we would have a kind of smoother ride.
Okay, last question. So you're getting on a plane and you're sitting next to a young entrepreneur who's built the next big thing. They're jazzed about it. They can't wait to show it off to the world. Can't wait to show it off to you right there on the plane. What advice do you give that person having gone down this road a bit?
More than anything, make sure you are getting complementary skills to your team. If you are good in marketing, make sure you get some good product people onto the team or a very strong product person. Get a strong marketing person or a salesperson on the team. And basically, I think one of my learnings was as a product person, I'm very much a product person, as you can tell.
Make sure you bring a salesperson. I think we onboarded a salesperson quite early in our ride. That was very smart because salesperson, they might not be the perfect product person, but what they do, they are really looking to sell. If they're really good salespeople, they can almost sell anything.
And how they do that, they do that by understanding what are the value for the customers that your product brings, right? What is the real value of your product? So if this young entrepreneur, if she or he didn't already have a strong salesperson, or isn't there already a strong salesperson himself or herself, make sure to team up with one. That is going to make a ton of difference.
Even though any founder can probably sell the product better than anybody else, but getting that second person doing sales on your behalf, diving into the value of the product, really diving into the problems of the of the customers or the users and really putting a price tag on that. That's going to be a make or break, I would say, for any startup or any kind of entrepreneur.
That's great advice. Miguel, thank you for being on the show today. And thank you for telling the creation story of Unleash.
So great to be here now. It was a fantastic conversation. I loved it all along the way.
And this concludes another chapter of Code Stories. Code Story is hosted and produced by Noah Laphart. Be sure to subscribe on Apple Podcasts, Spotify, or the podcasting app of your choice. And when you get a chance, leave us a review. Both things help us out tremendously. And thanks again for listening.