Studied computer engineering
Got his first job as a software developer at a broadcast technology company
Managed and built real-time graphics and production systems
Getting promoted and expatriated to Thailand
Has now lived in Thailand since 2010
Building and managing remote or extension teams
Some of the challenges and solutions when the head office is on another continent
Building FindYourSpace which morphed into Property Flow
Diving deep into Seven Peaks
The evolution of software development
Microservices and the Cloud
The validated learning loop Building great user experiences
Selling solutions to problems
I Want to Build a Website
Trying to Build What They Need, Not What They Want
The Commercial Model Is Not Agile
Don’t Spend Two Years Building a Product
Nobody Buys a Product
Read the best-effort transcript below (This technology is still not as good as they say it is…):
Michael Waitze 0:02
Michael Waitze Media…Telling Asia’s Stories.
Hi, this is Michael Waitze and welcome back to the Asia Tech Podcast. It’s harder doing this in person with someone staring there looking at exactly what are you doing. Today we are joined by us, Jostein Aksnes. Jostein is the CEO of Property Flow, and the CEO of Seven Peaks Software. How are you doing?
Jostein Aksnes 0:30
I’m doing great. Thank you very much for having me.
Michael Waitze 0:32
It seems my complete pleasure to have you on the show. I’ve been waiting for this for such a long time. Just to get some context. Can we let our listeners know a little bit of your background?
Jostein Aksnes 0:42
Yeah, sure. I’m from Norway. I’ve been living in Thailand since 2010. Uh, well, my background is in computer engineering. So I started my bachelor back in Norway, moved to Australia to do my master’s. And then move back to Norway started my first job as a software engineer in broadcast technology company.
Michael Waitze 0:59
What does that mean a broadcast technology company.
Jostein Aksnes 1:02
So this company is one of the I would say world’s leading in real time graphics for broadcast. So it’s a company that basically work with all the leading broadcasters doing real time graphic and production systems.
Michael Waitze 1:12
So what does that mean all the Chiron ‘s and stuff you see at the bottom? Or the what do they call them? Lower thirds and stuff like that? Excellent. Because any other kind of graphics that show up on television?
Jostein Aksnes 1:21
Exactly. So Chiron is the competitor. Okay, sorry. So I thought
Michael Waitze 1:25
that was a thing. I didn’t know that was a brand. Yeah. See, you learn something every day. Go ahead.
Jostein Aksnes 1:29
Exactly. So so. So I started as a developer working for that company. And after a few years, I was in charge of basically building up a product after three companies was acquired and merged. So I was in charge of basically combining these products and building a workflow for journalists, allowing the real time graphic and videos to be used in one system.
Michael Waitze 1:50
Wow, that’s gonna be a pretty non trivial project for somebody just starting, though.
Jostein Aksnes 1:56
Yeah, it was quite interesting, especially the fact of having different companies going through different aeronauts and different motivations to work together, while trying to build a good product. So um, so yeah, it was a very good and interesting learning experience. And after that kind of phase was over, got a promotion and was relocated as an expert to Thailand as head of r&d for this company.
Michael Waitze 2:16
And why was there stuff in Tyler? Was it there already? Or did they send you here to open up that office and then expand the business in Asia?
Jostein Aksnes 2:23
So the company was already here in Thailand, they already had a few developers working on some projects. Okay. But the company wanted to have a more focused development team on supporting more their international products as well. So um, so yeah, so I was in charge of basically building up a bigger development team and basically building products for our international offices.
Michael Waitze 2:45
Right. And does that mean that you had to be in constant contact with the team back in Norway?
Jostein Aksnes 2:50
Yeah, exactly. So so that’s kind of where I first got experience of, I would say, building remote teams, what we call them at that point extension team. So it’s a extension to your local team, following the same processes, working closely with basically the product owner back in Norway at that point,
Michael Waitze 3:05
was that hard at first? Yeah,
Jostein Aksnes 3:07
I think there was quite a lot of learnings, I would say, especially on on kind of getting these teams to work close together, as in getting the culture getting the working process, getting the buy in from the local team to work closely with with the overseas team. I guess the for the overseas teams, or have been origin team, I guess there was always a concern of Will this be a risk for their employment, or their outsourcing everything now to a lower cost country? What is the implication etc. Right?
Michael Waitze 3:32
So this is really interesting for me, because I was basically an expat my entire life. Right? I work in the New York office of a big investment bank, and that got sent to Tokyo in 1990. And I was constantly on the phone with my partners in London, because that was the center of basically finance in Europe. And in New York, constantly, right. And one of the things that was really interesting to me, was that the Tokyo people thought that the London people were idiots. The London people thought that the New York people were like, lazy. And then people thought that the Japanese people were dumped. You don’t I mean, because they just never got together and worked with each other. Where did you have the same dynamic where like one team thought that people in another country just didn’t have the same attributes? So I’m not saying that they were better or worse, but you know what? I mean, did you have to spend time convincing the guys in Norway? Like, no, no, we got this here kind of thing.
Jostein Aksnes 4:25
Yeah, of course. So there are of course, different, again, cultural differences in Thailand on how people behave and work. And again, very different from, I guess, in fact, in Norway, where people are maybe more direct and open and Okay, so of course, there was there was a transition phase there. But over time, we managed to hire very good developers here in Thailand. And we got the buy in from the from the teams back in Norway. And and we’ve got a very good working model. And also one of the things I think was very important is that we had some of the team team leads from Norway coming I was every three months to Thailand to work with the team closely building kind of that relationship. Such a great idea. Right. Yeah, exactly. So that’s one of the I would say the main, I would say, the most important part to building a remote team. It’s also having that proper kind of coordination and be able to actually build the team and work as one team.
Michael Waitze 5:11
We, I could not agree with you more. Every and it was funny that you say that, right? Because every time one of those guys from New York and it was mostly guys back then would come to Tokyo, they would meet the team and think, wow, they’re amazing. And then when the London guys would meet the New York team, they would think these guys are working really hard. Right? I’ve always called this sort of the other side of the mountain syndrome, where just if you just don’t meet them, they must be worse than you. Otherwise they’d be on your side of the mountain, kind of thing. Anyway, it’s true everywhere. were you always interested in media?
Jostein Aksnes 5:43
No, to be honest, I never had an interest in media. But I’ve always been interested in technology, right. So so from I was young, so everything from programming, programming, of course, and learning how things work and how to make things better, finding problems, solving problems. So that’s kind of been a passion from from day one. And the fact that I started in a broadcast technology company, it was more coincidence. When I came back from from university, basically,
Michael Waitze 6:08
What a great place to start.
Jostein Aksnes 6:09
Yeah, I’m very happy I started there. I was there for eight and a half years. And I learned a lot.
Michael Waitze 6:15
Were you excited at the beginning to come to Thailand or even just to leave Norway?
Jostein Aksnes 6:19
Did you be honest, I was, to be honest, not very interested in moving to Thailand at all when I when I got the offer? So I initially said no, really. I came as a tourist here, and back in 2004. And I was not very impressed. So and because of that I was not that interested in moving to Thailand, but you did it anyway. Yes, it was a very good opportunity, career wise, challenging, very interesting job tasks. So I told him, I, I go for a year. Now it’s 11 years later, still trying to move some of my equipment from Norway back to Thailand.
Michael Waitze 6:57
It doesn’t seem like you’re leaving soon. But you left them. And then did you found your own company first? So did you start the software company seven peaks. So
Jostein Aksnes 7:05
I basically at one end of 2013, I got an offer to go back to Norway? I had more than three years as my can expect. Deal was over. Right. And at that point, that was Yeah. To the benefits. I was not interested in leaving, leaving Thailand. Right. This is where my network was. I thought it was a lot of opportunities, the whole startup scene and started kind of taking taking shape now. It’s all entertaining. Exactly. Yeah. So it was a good time to stay here. And I decided basically, that I didn’t want to go back to Norway with a company and I, I left that company, right? And then what did you do? So at that point, I did apply for a few jobs. I got rejected as a CTO for a company because I didn’t have any lab experience. So because of that, I love it. Because of that, I decided I want to build websites. And I looked at Finland Oh, back in Norway, which is one of the ships that’s marketplaces like, Heidi here in Thailand, right. So at that point, I decided I wanted to get hands on again and start programming. And I started basically building at that point one was called Find your space as a real estate portal. So that was just before I guess hip flat, or in the same time he flat just started out, right. So quite early on. But then after what spending a year of just building things, we then started talking to the clients, we started understanding actually what they needed. And even if we want to promote, say, a real estate properties for free, nobody could give us these properties, because they did not really have any way to give us these properties. They were What do you mean? So they will work in Excel files, they will have their pictures on a hard drive or on Google Drive. They did not really have any platform any way to basically provide this content to us.
Michael Waitze 8:45
Ah, so the agent itself didn’t have any way for you to connect to their stuff and then feed it into your portal. Exactly. So what you decided to build that thing.
Jostein Aksnes 8:55
Exactly. So we basically then saw that this is a massive problem. And in the whole market here. And for being I would say, a technology company or an engineer, I rather wanted to solve that problem, then then building our lead generation platform. Yeah. So so we quite quickly decided then to basically change direction. We basically then spend another six months to kind of repackage the product. And then we went to market with our platform for real estate agents, allowing them to basically digitize their, their their
Michael Waitze 9:25
offerings, how hard is it to build a platform like
Jostein Aksnes 9:27
that? I would say took a lot of lessons learned that a lot of lessons learned being an engineer with the idea of I want to build a website to to I want to build a massive platform. Exactly. So So I think I think that that’s there’s a lot of learnings over obviously over the two years it took to just build that MVP, Bootstrap, sit at home working, traveling, that’s hard work enjoying life. Exactly. So So I think that also is one of the reasons we’re now also for seven peaks. We see that there’s a lot of lessons learned with how I built my previous kind of platform and Some of the things that we now see that we want to kind of pass on to our clients and ensure that they don’t do the same mistakes that we did.
Michael Waitze 10:07
Yeah, cuz it almost feels like, right if you use real estate agents as a proxy for the entire sort of Thai economy, but also for all of Southeast Asia, everybody’s trying to get digitized, right or digitalized, pick the word you like the best. And then everybody’s probably sitting on a Google Drive or a Google sheet or an Excel sheet or, or even a piece of paper. So they have no way to connect. So there’s so much of this back end platform stuff that has to get built. Is that fair?
Jostein Aksnes 10:37
Yeah, exactly. So that’s kind of the whole, I would say the industry 4.0 or Thailand 4.0, where now there’s a lot of efforts now put into kind of digitizing a lot of these processes,
Michael Waitze 10:47
right? So at seven peaks, are most of your clients here? Are they overseas? Is it split? Like how does that work?
Jostein Aksnes 10:53
So for seven peaks, now we have, I would say around 50% of our revenue from Norway and Scandinavia. And the remaining is primarily Thailand, but also have clients in Singapore and Malaysia, Indonesia, and Australia, etc.
Michael Waitze 11:05
But the reason why I asked that is because the state of digital transformation in Norway and in Scandinavia is very different than it is here. Right. I mean, I think that’s a fair statement. What are you seeing companies doing? Are you seeing this accelerate? Do you know what I mean?
Jostein Aksnes 11:20
Yeah, I think I think one thing, especially with COVID, is that the COVID has a really accelerated also transformation, because again, now a lot of businesses are forced to becoming digital much quicker than before as well. So for us as a business, of course, there’s been a massive demand over the last year, which is a direct result of COVID. So for sure, I think in Europe, a lot of things are more mature. And in many industries, and in Thailand, or in the whole Southeast Asia region. Of course, there are obviously a lot more opportunities of, of helping businesses go go digital, right?
Michael Waitze 11:54
Yeah, I would think so. Absolutely. I mean, I see that in the InsurTech space at scale. Like at massive scale, every insurance company wants to figure out a way how to digitally transform themselves. But I don’t see the type of stuff that you see, particularly from a software development standpoint, I think that most people think that software development is kind of like a static thing, where it’s just, it is the same, it will be the same, it has been the same forever. What do you see from your side, though?
Jostein Aksnes 12:20
I think, again, for software, again, I think one of the biggest problems we see, especially with softer hair in the region, is that it following more the old fashion waterfall way of running software projects. So
Michael Waitze 12:32
what does it what does that mean waterfall for people that don’t know? It,
Jostein Aksnes 12:35
basically, you you try to come up with all the requirements upfront, you might come up with requirements for a massive big platform, you talk to all your different departments, your sales, your marketing operations, you get all the requirements from everyone, then you try to combine all of these requirements into one sort of requirements document, you get some sort of a board approval for a certain budget, they set a date and a timeline for for your release. And you go out to a vendor and try to get them to build it within the budget and time that was sets.
Michael Waitze 13:04
That almost seems like an impossible task. Exactly. Like it almost seems impossible to know what you’re gonna need to build even three months out as opposed to six months or a year out for an entire thing.
Jostein Aksnes 13:13
Yeah, exactly. And that’s also why if you look at, I would say like online surveys and statistics on software projects, I think the bigger the projects get, the more likely is that they will fail as well. Right. So I think there’s more than 50% of bigger waterfall projects are failing in one way or the other, just because of the complexity and the difficulties of running this.
Michael Waitze 13:34
Yeah, I mean, they almost have to fail, because from the get go, the planning sounds completely wrong. Yes, exactly. I had this discussion with somebody else as well. Software development, and the services that software provides was just becoming so complex, like so complex, almost unthinkably complex, right? But also very interrelated. Which wasn’t always true. If you go back 20 years, you could write this standalone piece of software, it didn’t have to interact all the time with other pieces of software. It just kind of did its own thing. But today, it’s so complicated, right? How do you disintermediate that complexity, maybe break it down into smaller pieces that are more easier handled? Like what is software development looking like today? And where’s it going?
Jostein Aksnes 14:17
Yeah, exactly. So I think again, that was a that was a most businesses back in the good old days started in a garage and having your own service and you’re at home, right? Isn’t gone a long way with we do that. Exactly. So so that means again, of course, at that point, it was much more difficult to build solutions. Of course now with Cloud public cloud available AWS, Asher, etc. On roll, you have so many services available that allow any type of company now to build products at scale, right. That also means that there is a lot of additional services available online to interact with and to provide additional services. So you don’t have to build everything from scratch. So that means that you will have a lot more components and moving parts Then then typically a standard desktop application you would maybe 10 years ago.
Michael Waitze 15:04
Can you just explain to me what a microservice is?
Jostein Aksnes 15:07
so it’s a microservices architecture is is a way where you are isolating, I would say, the specific business logic in one certain module, which then is built independently of others, allowing that to be easily reused across different systems. And basically allowing different modules to interact with each other through some sort of a messaging kind of infrastructure. And is that normally an API or so so of course, so each of these modules will potentially now in many modern software, architecture now be deployed in some sort of a container like Docker or similar, each of these will have their kind of isolated kind of responsibility with a clear API that you could interface to. And then, of course, the challenge, of course, with micro services, as well as that the more of these services you have, the more complicated it also becomes on orchestrating your your kind of deployment. So again, there is kind of pros and cons, going from a monolith to one big system to becoming a very distributed kind of micro services architectures. So there is that there is reasons for both. But I think the most important is to understand what is your what is your pain point? What are you trying to solve and find the right solution to solve it, because now the toolbox is getting so big, there’s so many different ways of solving the same problem. And it’s very important important for the customer to understand what they’re actually trying to solve and find the right tools, and not just follow the bus.
Michael Waitze 16:31
Right, exactly. So tell me now, if before, you used to have like a meeting and had to go up to the board, and you had this, like 75 page document about what this piece of software was actually never going to be gone in the future, right? What do you do now?
Jostein Aksnes 16:46
So so there was still a lot of these, these projects out there, right. And it just that we are trying to avoid getting too many on these, right, because we don’t feel that’s necessarily the way we want to go. So for us, when we get these opportunities, we are we are trying to kind of meet with a client and try to really understand what they are trying to do, what is kind of the pain points they have and understand what they need, not necessarily what they want. Right. Right. Right. And, and basically, based on that, trying to kind of flip this upside down, and instead of of kind of having a long list of features, trying to look at kind of what is the problem statement? Who will be who will have this pain that you’re trying to solve? And what can you build, say within three months?
Michael Waitze 17:26
Who are you normally dealing with? Right? In other words, are you dealing with another CTO? Are you dealing with a business head, the business team is going to know what they want. They really are. They’re like, we’ve been trying to do X for a long time. We can’t do it. But we want to digitalize this whole process. So help us do that. They won’t understand the difference between waterfall on microservices and the Mac Alliance and API first and cloud all this kind of they have no idea they just want to get from A to B. Can you get them to do it your way as well, like who are you first of all, who you normally dealing with? And can you convince them that your way is the better way as opposed to that 75 page document we were joking about before,
Jostein Aksnes 18:03
right? So I think for seven years, I’ve been trying to sell this idea. I’ve been doing it in different ways. So I would say over the last two years, we started getting a lot more traction with this. And we do have a lot of clients now understanding that, again, the old fashioned kind of waterfall way is not necessarily the ideal way for for all kinds of projects. Of course, for some projects, it might be the suitable if you have enough requirements up front, and you actually don’t expect any moving parts. But the problem now is that most clients, older working teams, they don’t know all the requirements upfront, they know that they need to have a preparation phase, they know that they need to still define the features, and it’s not set in stone. But they still the costs of again, how corporates work here is that the board has given some sort of an approval, there is a timeline and a budget and a budget. So that means that basically that even if the working team has now gone through agile training, they want to be agile, the commercial model is not agile. So that means it’s it’s even more difficult for us as a as a vendor or partner to work within that. Because now you have a team that is very interested in working in the modern, agile way to…
Michael Waitze 19:15
Right, for a business. It’s not working in a modern agile way. So it’s like trying to put us What do you say, like a square peg in a round hole in a way even though both want to do it?
Jostein Aksnes 19:23
Exactly. Yeah. So the challenges then is, of course, that is the working team. We want to work closely with them. We want to kind of help them kind of define the product, you want to change the requirements. We want to learn. We want to iterate. But then from a commercial standpoint, we are kind of getting forced to sign a contract for a fixed price with a fixed deadline with potentially even penalties if we don’t hit that. So that means that from from a vendor or partner perspective, it’s very difficult to have an agile working model with a fixed price. commercial deal.
Michael Waitze 19:53
Yeah, because they’re just incongruent, except they don’t equal each other at all. Exactly. And and this must happen a lot too. I won’t wait You’ve finished that thought in a second. But let’s say you’re literally just trying to digitalize a form like in its simplest in its simplest form, right? You have input questions, and then maybe all of that stuff then goes into a database, right? But maybe if it’s a handwritten form, or even a typewritten form, right, if you give it to me for like, like an insurance contract or something, you restrict the you naturally restrict just because you want it to be on two pages or three pages. And because it doesn’t connect to anything else, it’s an actually restrictive. But once you figure out and let’s say you’re working with a team in the insurance industry, they figure out Wait a second, if it’s digital, I can connect it to all these other things that they didn’t think about beforehand. So by definition, this is not what I would call scope creep. This is called like just rethinking the process, but they don’t know that. Do you know what I mean, until they start building next segment. So all these new things come up that have nothing to do with the development team not hitting their KPIs? But it almost makes that fixed pricing? An anomaly? Yep. And anathema. Yeah, sorry. Go ahead.
Jostein Aksnes 21:07
All right, exactly. So the thing here is that what you want is a two pages for, but what you need is not a two pages four, that’s the
Michael Waitze 21:16
point I was trying to like, right? It’s like, the only reason why you had it was because nobody wants to do more than a two page one with the writing it out. But now you have access to all these other micro services and databases and stuff like that. Why not do it in a completely different way?
Jostein Aksnes 21:29
Exactly. And that’s also why we always ask, what are you trying to solve? What is your problem? Who hasn’t? For example, in this case, as in, say, if you have two pages for them, because you want to get some sort of an NPS score for your, for your services, right? Maybe a net promoter score? Exactly. So maybe a two pager form is not what you want, maybe you need a scale for one to 10 and one button. Right? Right, exactly. So it’s we need to understand what you’re trying to achieve, then we will help and work on suggesting the best way to solve it, it might not be a form, it might be something totally different.
Michael Waitze 21:56
It could be completely, but that’s the whole point of this idea is that if you’re working in a waterfall way, you’re never gonna even get to that point. And once you do, you’ll just realize internally, we’ve already spent like, 50% of our budget.
Jostein Aksnes 22:10
Thanks. And if you look at a bigger project, like I said, 1218 months projects, there’s 1000s of these decisions already made before you start the project, right 1000s of assumptions that was made without any testing without any validation at all. And 1000s of ways you potentially take the wrong turn,
Michael Waitze 22:26
do you think because I know the way big corporates look at software development, but basically, because I’ve existed inside them for years, right. And I worked with what we used to call it to build trading systems and a whole bunch of other very non trivial systems. And the more than I did that, the better I got at telling them what the requirements were. Because you could then figure out what you really needed. Do you see that as well with your own clients? You don’t mean that the more you’re just with them? In a way, wouldn’t it be better to have like software development, and I’m just freelancing here, right? Like almost like a SaaS product. You just hire us? Not outsourcing per se, right. But we just work on all your stuff with you. Because the more we know about you, and the more you know about the way we work, maybe the more efficient and the faster we’ll be like, Is that happening already? You know what I mean? Yeah, exactly.
Jostein Aksnes 23:17
So I think I think one thing is at least as you said, the more you talk to the client, the more you understand what they need as well, right? So for us, we have kind of different few different ways of doing this, right. So one is, for example, if we get this kind of say an RFP for a big project, we try to at least be able to have a meeting with the client and really do what we call a scoping workshop, where we really try to understand again, what’s your pain point? What’s the problem statement? Who will be using this? How do we how do we somehow shape this. And then of course, try to kind of go in and sell kind of our, I would say way of working, which is more where we do a discovery project where we go in and help and really scope that say MVP, and then going into an agile kind of as a development phase, right? And that’s exactly what your what we refer to as, let’s say, the SaaS model here is that we would typically then provide as a cross functional product team, what does that mean? So basically, again, there’s two ways of obviously, developing software one is, again, if you look at this, you look at as a project, right? So it’s a start, and there’s an end, right? You start building it based on requirements, you cannot you launch it, you do a user acceptance testing and go in production. But the problem with that is that once you launch it, what happens then what then what do you do what when is the next phase who is looking at there is no end? Exactly, exactly. So so the way we’re trying to do this now is in having it instead of having a straight line that’s in we’re trying to make this more into a circle where again, that you, you launch the first version, but then you iterate on it, you learn you measure. So it’s basically the whole validated learning loop from say, the lean startup. So it’s more about how can you have that kind of experience also for a bigger bigger product for big enterprise right as in how can we launch something over three to six months after that’s been launched? How do we then look at the data? How are people using the platform? How are they engaging based on feedback, we get that learning how do we then Now shape the product to further improve and increase your conversion or engagement? Right? Right? Because that’s when devalue, you really start getting value of that investment you put in for your software. Because if you put in a million dollar for building a project, you launch it and forget about it. And then later on management, or the board is complaining, why is nobody using the software? Why is this not showing any results on on what happened on the revenue? Exactly, this was a bad investment, right? And it might not be a bad investment, it’s just that you did it halfway, you did not finish it, right? Because once you launch it, that’s when it starts. That’s when you start the learning, that’s when you start basically learning and iterating and improving. And it’s the same as you look at all ecommerce, everything else, you have AV testing you have endless of experiments that people are doing all the time to really iterate and improve. So how can you get into a bigger I would say Enterprise Project,
Michael Waitze 25:49
right? So if you look at this in reverse, we talk a lot in the startup world about building that minimum viable product. I’m kind of anti buzzword, but I know what that means, right? But the reason for building that MVP is not just to throw something out into the market, it’s really to see like, what do I really need to build? I want to get you to use something. So if I don’t have anything, it’s not even just the chitchat between two people on what to build doesn’t really matter. Here’s a here’s a product. Second, now tell me what you really need, are you and that’s the way software kind of needs to get developed inside of big corporates as well. I’m curious if you see the types of products that they’re building, also changing? Do you know what I mean? Like as they look around in the rest of the startup world and see all these other kind of unique things, distribution channels changing? We talked about Microsoft’s as well? Are they changing the way they look at the products they’re building based on their new understanding of how software gets built? Does that make sense?
Jostein Aksnes 26:44
Yeah, for sure, I think, again, just just the fact that there is a lot of available services online. Now again, like again, talking about buzzwords AI, right as in you have vision API’s for doing image recognition, you have sentiment analyzers for text, you have text to speech you have, there’s endless of different online services. Now, that’s if you as a startup or company we would build from scratch, it will be years of years of research and development, right. But now everybody can use this, you just use that service, you now can give a sentiment on every review that you got on your product and run natural sentiment analysis to see if this was positive or negative. And now you have some added value to your product that you
Michael Waitze 27:26
Right and in a way reminds me of the iPhone. Apple didn’t invent capacitive touchscreens, right? They didn’t invent like visual sliding software. They didn’t invent like having Wi Fi inside of a phone. Exactly. But they combined all these things together to provide a unified service that didn’t that hadn’t existed prior.
Jostein Aksnes 27:48
Oh, better user experience right?
Michael Waitze 27:51
Way better user. So sorry. Go ahead.
Jostein Aksnes 27:51
No, right, exactly. So that’s again, back also to again, products, right? And then if you’re going to build a good user experience, you need to understand what people need, what’s their what’s the pain point the friction they have? And how do you build a user experience for them to be able to solve that as best as possible? Right. So as I said, iPhone is a great example of that, but they actually did it right. If you look at some of the other older phones, it’s some of the very difficult to use it against mobile screen. So it’s, again, not usable for a lot of different things. So I’d better gloss over again, iPhone and the big screen and application support, etc. Now, suddenly, you can use this for so many other things. Right.
Michael Waitze 28:24
Right. And that was the whole key to the software keyboard. Right, was that you could make it anything? Is that fair? Yeah, exactly. Yeah. And I just lost the thought I had a really good thought to say something. I was joking at the beginning of this right that you were the CEO of two companies at once. But in a way, they’re mirrors at some level, they’re mirrors of each other, right? One’s a software development company. And one is a company that uses the development of software to attack a particular problem. So in a way, if you go back to when you started property flow, what was the original name and find your space, find your space, right? Property flow, much better name, by the way? I write, in my humble opinion, but the point is that you should understand based on building that, how the development of software is changing over time, and then be able to apply some of that to your software building at scale for your clients. Is that Is that fair? as well?
Jostein Aksnes 29:22
Yeah, exactly. So I think I think by having two companies one is again as a service company, like it says, having big software right, so we are we are a team of 100 people now. We do end to end everything 100 people Yeah, exactly. That’s a lot of people. Sorry, go ahead. So so everything basically from from ideation, helping with again, discovery, workshops, UX, UI design, architecture, implementation, development, etc. So we are now helping companies end to end and I would say the learning experience we had now with with property flow as well is that we have hands on been building a product right? I have hands on been building a product for two years investing my own money. for two years before I sold the first client, so there’s a lot of things that I personally learned there. And also that I always tried to tell the clients or startups that we talk to. So don’t spend two years building a product start selling, sell from day one, as an even if you don’t have a product, make a mock up, test your price test your problem statement, you can sell, you can sell to your friends, you’ve held your family, you don’t need a product, you don’t need to have a finished product before you start selling. Right. So that is, again, is back to again, testing, validating the market and focusing on what is your MVP? Because if you don’t know what your MVP is, as well, it’s difficult to build it right. But if you start talking with clients, you start understanding what’s the pain point? What is what is people worth willing to pay for?
Michael Waitze 30:45
Right? So this is one of the biggest things that I’ve learned in the past few years. And I always say this when I came to Thailand in 2011, you know, it’s coming from the investment trade, the investment banking, but really like the trading side of that business, right? And selling was easy, because the product was already there. And there was this massive infrastructure of information distribution that came with the product. So going out and selling it was just really like, come on, you’re gonna deal with Goldman Sachs, right? Well, you just wasn’t that hard. You don’t know that when you’re there. You think I’m a genius? You’re not. Anyway, I don’t mean to you. I mean, I. But the point is, you learn in the startup world, in a way, you don’t even need to have a product. Just like you have to have a product idea. You can’t just go out and sell nothing. Well, I remember once I was in the middle of a conversation, so I was me, a buddy of mine talking to an entrepreneur. And the guy said to the other to the other entrepreneur, why don’t you have any clients? And it sounded really obnoxious to me. I love telling the story. And I realized it wasn’t meant to be obnoxious. It was meant to be like, no, no, I really want to know, you’ve probably tried to get a client. And they’ve said no. So what are the reasons why address that? And then you can get a client. But once my mindset around, that changed, everything looked different. Right? And I think that’s what you’re saying as well. On the software side, you have to build the end product.
Jostein Aksnes 32:14
Yeah. So the thing is, nobody buys products, people buy a solution to a problem you have. Right. So if you don’t have a problem be
Michael Waitze 32:22
the title, I think of this episode, people buy a solution to the problem you have. Go ahead and second.
Jostein Aksnes 32:27
So I think, again, if you don’t resonate with the problem, you cannot buy anything as a nobody will buy anything from you if they don’t realize they have a problem, right. So again, that’s again, back to the whole sales pitch, right as in one is, again, make sure that you make sure they resonate with the problem that you’re trying to solve, identify the problem, once they know that, yes, I have this problem, then you present a solution to that problem, which is say your product. Yeah. And the same goes for again, building a bigger enterprise product as well, is that what is the problem they have? How do we solve that problem by solving that problem to get adoption for the users internally in the company, or then customers etc. But if you don’t solve a problem, you’re just building yet another super app that is not necessarily providing that much additional value, right? And who needs that? Exactly?
Michael Waitze 33:12
Exactly. Do you have a sales team at seven peaks? I know it sounds like a dumb question. But do you? And if you do, how do you train like the new person to come in to have that kind of mindset?
Jostein Aksnes 33:25
Yes, so so we have, we have what two business developers in the team now. Okay, so So, of course, it takes some time to go. And I would say, to preach our way to explain that, again, we’re not trying to do any hard sell. We’re not trying to do any quick wins. No, we’re looking at the long term. And again, if somebody comes in and says, I want to do a one year project, I’d rather want to take a three month project and build the right thing. And and try to focus on actually solving that that problem well. And by doing that, instead of having the next whatever nine months having them for next 24 months. Right? Exactly. Right. So try to make it right. Because it’s very difficult to once you close a deal for, say 12 months, and then if it’s not a good experience for either for for us or for the client, that relationship is over. And ever forever. Right? Right. So again, either we were not happy because again on the commercial terms and be overrun and be lost money, or the clients felt they either overpaid or or didn’t get exactly what they wanted. Right. So it’s very difficult to have that perfect balance where both parties are happy. So for us, one of the most important things that we cannot tell our sales or business development team is again that we are looking for Win win. We’re looking for long term partnerships,
Michael Waitze 34:37
right? You saw me turn around and look up at the board, right, because I wanted to make sure it was still there. And I think you can see, like four lines down it says build for the long term. Exactly. These are things that we like and on on that side of things that we don’t like, which is like hype and buzzwords and stuff like that. Yeah. But sometimes building for the long term does require you and again this gets back to the difference between the waterfall type of business And the new type of development that you’re doing, which is like let’s do something quickly get it out, figured out kind of build around that, as opposed to having this monolithic document. And it’s the same thing with relationships. One of my bosses once said, you don’t have to marry the first person you dance with sign. But you should be dancing.
Jostein Aksnes 35:20
Exactly. So I think, if I was in from a pure business perspective, if we wanted to just monetize as much as we wanted, we could take all these projects, yeah, but deliver that project, regardless of results, move on to the next client, then nobody wants to do that. Exactly, there is more enough clients in the world, we can probably build a very good business based on that. But again, for us, it’s more of a again, if we do what we like to call more like an agile product team, right as in, we have to work on a month by month basis to prove our worth, if we are not delivering, they’re free to terminate engagement with us, or build a team in house or move to another vendor, we are we are proving ourselves every month, by giving them our consulting on the direction of the product, to build a good product to be able to launch the product on time to ensure we can help and scope the product and rightway to be able to measure and kind of improve their whatever conversions or right so we are always proving ourselves versus you have 12 months, you will now we’re in bed with that guy or that company for whatever, 12 months regardless of the outcome, right? You don’t know if that’s going to be good or bad. And at the end, if that was bad, okay, you both both parties leave, not happy, very unhappy.
Michael Waitze 36:29
And I was trying to think of this thing that I heard recently. And I think it goes something like this. And if it’s not right, I’ll take it out. But I think it said, the man that tries to be everybody’s friend, is his own enemy. And I think that’s the philosophy, you have at least something like that for your clients, like you could be everybody’s practitioner. But then you’re not doing a great job for you. And you’re not building those long term relationships in a way you’d rather just have like five clients or six clients that you work for forever. Yep. And build killer stuff for them. Yes, I do have 1000 clients. Sorry, go ahead.
Jostein Aksnes 37:01
No exactly. So so this was back to the end of the sales, right, as we’re now talking about, okay, what is our dream client? Right? So again, when we we doing prospecting now, or when we are talking with with clients about proposals? So one thing is, of course, that client, we see that there’s a long term horizon that, okay, they have money as an it’s a bigger company, that they can actually be able to afford our services for longer term, right. But but the other one that is, I think, is more important is the working model, is this a company that have a mindset that is aligned to how we want to work, right, that we can bring the value that we believe in as a partner, not as a vendor?
Michael Waitze 37:34
Nobody, yeah, because otherwise, you’re starting off behind the eight ball, as we would say, next time, it’s never gonna work. And you know that, because that’s not the way you want to work. That’s not gonna happen.
Jostein Aksnes 37:44
Yeah. And then again, then again, we don’t provide as much value as we could always we want to write as, again, say, development now is, in one way, becoming more commodity as if you want to go now you can find a random vendor and say, Okay, I want to have 10 developers doing this, please do this. We’re not in our business, we want to be able to provide more value than that. Right? So that’s, again, back to providing full squads, or development teams and designers, QA, product managers, product owners, that all working closely together to deliver that product for the client.
Michael Waitze 38:13
And is that embedded in the client? Or is that in your office? Or, you know, remote work? Like, how does that or some combination of those three things?
Jostein Aksnes 38:20
So we do work primarily from our office, but of course, with with kind of close contact with with clients in Thailand or in the region? Right. Okay. But it’s, again, a lot of our clients also are overseas. And then of course, the majority of the work is remote. And and I think also the there is, again, over discussion as you want to have people sitting in your office. And if you ask the client, why main reason is because I want to see that they’re working
Michael Waitze 38:45
And the reality is they don’t want them because they’re taking up space, exactly, resources, etc.
Jostein Aksnes 38:48
So I think I think it’s back to again, the type of clients we want to work with, right as in one, we need to be able to trust each other, right? We need to be able to kind of have a partnership and work towards a common goal. If we deliver, and they are successful, they will extend and we will continue working together. If we don’t deliver, then they’ll get products irrelevant. So for us again, back to prove ourselves, right. So again, we want to have clients that we can work with on a trusted basis where we can actually help the client actually achieve their business goals, where we are just helping to enable them to do that.
Michael Waitze 39:21
That is the perfect way to end on friends. Again, I like to think use them often. The CEO of property flowed and the CO seven software for calling into the studio. That was very much Michael