Kickstarting a business without technical background - with Richard & Ben, Founders @MOHARA

Welcome, everyone, to another episode of the Product Bakery. As usually, I'm here with Christian. Hi, Alex. So today we had two co-founders sitting here with us. Actually, we know there is more and more non-technical founders popping up nowadays. I think it has become much easier compared to the past, where most people who actually founded some tech companies were the ones building it as well. And having more non-technical founders building products also comes with a lot of different challenges. And Richard Sams and Ben Blomerly founded Mohara. And they are an agency that helps founders build their companies. And one of the key aspects is helping also the founders to get from the why of what they want to build to actually the how to build it. Because this is something that's often skipped in this step. Christian, do you have any highlights from the session today? Absolutely. I think one of the highlights was the whole process around collaborating and communicating as an agency, as an external party with the founders. Because you have a different trust basis, you have a different timeframe to build trust, and you have also make them buy into an alternative way of thinking. Because founders sometimes tend to sticking to their ideas. And I like the examples on how to convince people with outcomes in short times that are data-driven and can change people's mind. Perfect. So let's not say too much. And before we start... As always, feel free to follow us on social media and share this episode if you liked it with your friends, family, and most important, with your colleagues. And as we have introduced in one of our last episodes, we added a small survey in our podcast description. So feel free to give us feedback and tell us how much you liked it and what we can do better or different next time. Let's get started. Hi, Richard. Hi, Ben. It's nice having you guys. Thanks for having us. So as always, I usually introduce our guests, but due to the fact that we have the first time guests who are founders, I think it would be really interesting if you could share your story and also introduce the topic a little bit, because your mission is to help people to build the products they believe in and to make the dream come true. So yeah, I leave it up to you to say hello and share us your amazing story. Okay. Hello, everyone. My name is Richard Sams. I'm CEO and co-founder of Mahara. I've been working with Ben for 10 glorious years, which has been fantastic from day one to glory. We run a business called Mahara and we work in two ways, mainly with startup founders who are looking to build out their idea. They typically come from a non-technical background. We look to complete that incomplete team and help them get their ideas to market. And we work on the corporate innovation agencies to build out ideas and opportunities that larger businesses may have and take their ideas to market as well. Yeah, so I'm the CEO and co-founder of Mahara. In terms of the backstory and how we got here, Rich says 10 years ago, I was finishing an MBA and I'd taken on an idea that a friend of mine had and I was like, I want to start a startup, I want to build a startup. And I'd had the idea with my friend and trying to get it actually built, so from a non-technical background. And I'd worked with an agency first and basically fallen out with them. And I had some sympathy for their position. I'd changed the scope around and move things around, as you do when you're trying to build a startup and you're getting more information about what it is that users actually want. But from the agency point of view, they wanted a fixed scope, they wanted to manage their risk. So I fell out with this agency and ended up with this half finished code and no idea about how to actually go and get it done. And then a friend of mine introduced me to this guy who'd been living in Thailand as a technology teacher and was setting up an offshore agency. And yeah, I met Rich in a pub in Brighton in 2011. And we worked together as kind of agency and client for three or four years, working on my startup. And we had some really tough times, but we had some really good times as well and just really got on well. And Rich understood what I was trying to do, understood how to build the product that I was trying to do. And more importantly, made some decisions that really hurt him and his agency in the short term, but for the longer term good. And it was from that really that Mahara was born. We were seeing more and more non-technical founders coming to us saying, look, I really want to do this thing, but I don't know how to get my product built. I don't know how to engage with somebody offshore. I don't know what to prioritize. I don't know if I'm going to miss something. And also I feel like that there's a disconnect between what they want as an agency and what I might need. How do I know that they're not going to be taking me for a ride or leading me down the wrong path? And so that's where we built Mahara from. Rich came to me in the cellar of a pub in London and described what it could be. Yeah, what it could be. And yeah, I brought in my startup, some other that I already had, and Rich brought his agency along and Mahara was born there. So is your startup still existing somewhere within Mahara? No, it died. The dream of it lives on in the marketplace ebook that I wrote, because it was an online gifts marketplace. And yeah, it's a classic adage that you learn more in failure. So I've talked about it a lot and I do a lot of presentations or webinars about that. And there's obviously the ebook, the startup itself is dead. In retrospect, it was never going to work really. But to be honest with you, the mistake you made back then is clear, right? So you didn't have the idea in the pub, I guess. That's why it wasn't working. Quite. It came out of a class at INSEAD, so maybe that was the problem. We should have just done more things in the pub. You're too sober. That was basically it. Ideas usually only work if you have them in a pub. Either you need to have something to drink or to eat, because the product bakery was born while we had lunch. There you go, you see? Yes, absolutely. Fantastic. But we need to host you on a web podcast at some point, to understand more about the background. It's fascinating. Fair point. I would be curious to dive a little bit into the whole topic of supporting startups, because it sounds like you are not a typical code-only agency. So there is more work that needs to be done to be able to build up a business and make your idea great. So how do I get started if I say, okay, I want to build an online shops for croissants and other things. How would I get started if I would need help and if I don't have a full-fledged team? So I think the challenge is, how much do you know about how to do what you're talking about? Because what you often find is, we see this all the time, non-technical founders really know why they want to do something. They know why they want to take that user or those set of users on that journey to make their life different in some way. It's some lived experience or an industry they've worked in or some research that they've been able to get hold of, but not activate in their current role. And so they're really strong on the why. But what they then struggle with is, maybe you're familiar with Simon Sinek's Golden Circle. They really struggle with the idea of, if you go from why, what about the how and the what? And people jump straight through to the what of how to do something. So I want to build a website. I want to build an e-commerce site. I want to build an app without thinking about how those things can get done. How will my user flow through this platform? How will my user actually interact with the data and all these kinds of things? And so what we come to is, okay, we can help you walk through that. How does the product actually work? Agnostic of the technology, agnostic of the platform. And then we can build the what for you. That's one key part of it. The other part, which I'll let Rich talk to, is more about the mindset, about how you approach working with a startup and what the challenges they may have. Yeah, I think it's a good lead. And actually one of the key things that we look for when we meet people and think about the kind of businesses that we want to build with them is very much around understanding what it's like to be a founder. And I think we're in a really good position as a business that Ben's founded a startup. I personally have been involved with building the technology alongside a number of founders. So we've got a real clear understanding of the pains and what's required of an individual who is founding a business and what we need to go through. To the point where on our website, Ben's even written a great post about what it's like to be a founder and thinking like a founder is an internal kind of thing that we have going on in the hire. But a lot of it's rooted around coachability. A lot of it's based down to that they've got to be open to suggestions with inside of it, kind of the early stages of that business. They may have a core, why they want to go and do it, but really digging in to understand how and listening to different opinions and listening to users. It doesn't have to be us going out and testing assumptions and throwing rocks at the idea and things like that. They've got to be open to that feedback to be able to break away from that clear piercing vision about what they want it to be and to really understand what it could be. I think being able to listen and that coachability is very key for us. And on our side, it's understanding what it's like for them to grow this baby and understand the things that they could be going through and the stresses and the strains and working with them to ensure that it's a harmonious relationship as best it can be. Sometimes it's not, but sometimes it can be. What would you say are like the traits in founders where we would say, okay, they will probably not be successful founders. And so this is like something where I keep my hands out of it. Cool. Yeah, on a very human level. Now, if I look on a very human level, I think one of the things that I had to teach myself before we started to get success was very much around focus. You can work incredibly hard, but you can work in the wrong way very easily. And I think in the early stages of what was the precursor to Sageforce, the agency that then worked alongside as a client, I was very scattergun in my kind of approach because I was ambitious to do many things, but that lack of focus really was detrimental to the growth of the business at that stage. So I know that I'm very aware of ensuring that people have got that kind of focus. They don't have to be like completely and utterly dedicated to it and they've got nothing else in their life, but they've got to be able to follow through. And you can tend to get a feel for that when you talk to them about their prior career and everything else that they've kind of gone through as to whether they've got that focus. And I think that trait for me is very important. I tend to look for whether they've got the capability to be a bit of a generalist, you know, because of the amount of hats that you have to wear when you're starting a new business and you're starting that new company. Because I did everything from finance through to marketing, through to design, through to tech. And I'm not necessarily great at any of them, but I was good enough at some of them to get us going. Then you bring specialists in as you go. And that's the important thing. I do think that focus and that awareness that you are going to have to wear many hats and having that capability to be a generalist. And if you're not comfortable in doing that finance piece, you've got that drive to go and learn enough to be able to get you through to where you need to get to before you can bring that specialist in. It's kind of like the three pillars. You've got sales and marketing, you've got finance, you've got ops. Covering enough and realize you've got to do enough to bring that up. Do they have the capability to do that? So the whole thing just doesn't tip over. So I think there's a couple of things that I would look at. That'd be where I would start, I think. Just to add to that, I think one thing that's important for me, I don't mind the specialist quite so much, but you have to have an eye or not more than an eye. You have to have a really good hand in what your product is. So we've worked in the past with people who don't really have a good grasp on that product. And then they just talk about selling or what have you and can't talk to people, can't feel the passion about what their product actually does, can't communicate that. And then from that, they don't understand the trade-offs that are required in building products. How with scarce resources, you can't build everything, nor should you try and build everything just because B2B sales that you had said, Oh, we would buy it if you added this feature on. I don't mind if you're more of a, I really know how to take this product to market. I really know how to sell it or what have you provided that you've got that solid grounding in understanding what the challenges and the trade-offs are in how to build a product. When I'm listening to these kind of traits and personalities that you're also describing, I almost also get a little bit like the feeling like non-technical founders could even be better founders than technical ones because they by nature somehow need to be open for, because they are not the ones that can build it. So they by nature need to be open for trusting others on the execution and so on. While I feel like if we look like in the past, most of the companies were founded by engineers because they were the ones that could build it themselves. And then a lot of the product of listening to the users, listening to other people, maybe it got a little bit like short tracked. I would say, I've not done an exhaustive study of this, but I would say actually in the founder team, maybe the second or third high, you will find very quickly a business person because engineers without stereotyping too much can get a bit siloed about how they're actually going to go build something and how cool it is and what features it has, and maybe aren't great at selling it. And as Rich was saying, we have a really simple rubric around what requires a business to succeed and somebody's got to build it, somebody's got to sell it, somebody's got to finance it. So for sure, very early on, you'll get a non-technical person taking that product to market. And I think you're right though. I think that there is a wide open space for non-technical founders because there's a lot of opportunity to innovate and create a startup. A lot of people want to. The challenge has always been that traditional capital will look at non-technical founders and an incomplete founding team and they'll say, that's not backable because nobody's going to be able to do it. And then the non-technical founder themselves, if they don't have that grasp of product, if they don't have that handle on, okay, I don't need to define to the other person what to go and build. I don't need to tell them to go to a website. I need somebody who can tell me how to actually translate my vision into reality. I think that's the key. That's the thing that we're trying to unlock. Are you currently working with more technical founders or non-technical founders? It's almost exclusively non-technical founders. For the larger businesses we're working with who have a core product that might be doing really well, we're coming in, building a non-core product, maybe in a technology area that they're not strong in. If they are hardcore RFID guys, they don't know how to build a consumer-facing product. And I think that's an interesting point you make because there is this line drawn between technical and non-technical founders. Whereas one of our startups is very technical, but in a banking product sense, they've got the FCA regulation and things like that. And we're building the technical, the technology side of it. Whereas in a business like that, you would need three prongs normally. You need your regulation person, your sales person, marketing person, and your technical person where we're filling one of those prongs. I would love to know how you get started once you, for example, helping a company that is very tech driven. So let's say a fintech company, they have the technical knowledge, but don't know how to market. So where do you start? Is it like that you and your team join them and you start building up new processes, rework the discovery process or implement HR best practices? How do you start? Ben can talk very much to how we start product onboarding and things like that. I just want to, I suppose I want to reference a methodology that we have. We have a, it's the acronym is SCUBA because every technology needs an acronym, right? Every technology company needs something. Ben and I felt very naked until we had that. The consulting context. Yeah, exactly. Me and Ben felt a bit cheap. We were like out of there. We haven't got an acronym. We need one buddy. So we came up with something called SCUBA, which stands for Surface, Conceive, Stand, Build, and Accelerate. And that basically is the methodology of how we look to take on businesses, how we look to build. Surface is very much understanding what it's about and how we go and do this. So surfacing the ideas. And that's, a lot of that's rooted in, in kind of service design, really, you know, kind of thinking about what the service is. And then we think about conceiving what this could be and understanding. And that's very much about design research, design sprints, and really getting to the bottom of what the users are and testing those assumptions and sometimes fighting those founders assumptions of what they want to do. And then build goes through a lot of design work and obviously engineering and then accelerate. It's like, how can we wrap a flexible team around to accelerate that business forward? So that's the, the overarching kind of methodology of how we tax stuff. And obviously service lines sit inside of each of those kinds of sectors. In terms of product onboarding, Ben's, Ben's designed a very slick process. I think. We have our internal software development lifecycle approach, but I think it's interesting to think about what is the type of customer. One project we worked on the, in the FinTech one, our team and our CTO have planned a lot what to actually go and build. And I was talking to one of our engagement leads today about actually for an MVP site build, agile is not always the best because often you're in a sort of semi waterfall world because you've got a fairly limited budget. And you know that in order to get to the next milestone, you really want to get something out that does something to prove to your investors or demonstrate to your users. And how you can then actually have a really good planning sprint or a couple of planning sprints, get a shared whiteboard going and really feed things into that, plan things out really well. Because I think a lot of people jump into these kinds of projects and think, Oh, I'm a startup. I must be acting in a really agile way when your runway doesn't get you that far. And you get to a point if you were doing that, where actually the set of features you've got, it's not a coherent product or coherent enough product. Many of the early builds we do actually tend to be a kind of quasi waterfall, which is a bit surprising to a lot of people, I think. But so you do stress test also the ideas at the beginning to like really see is the product really the right thing? So depending on the stage it's at, it might require us to be able to do a fuller service design, user research and what have you. And we always prefer to do that. And also we come from a background of having built many startups and lots of different places. So even from just an experience point of view, you can say, look, that business model is not going to work. How have you validated those assumptions about those customer acquisition costs or what work have you done about that? And our belief around that comes from quite a simple equation that we put together. And it says that on one side of the equation, your total lifetime value of your customer has to be bigger than your total cost to build, your total cost to acquire your customers and your total cost to serve your customers. But if you come to us and say, I want to build a really slick, fully functioning end-to-end minimal back office servicing product without validating your lifetime value of your customers, then you start in the wrong place. And so we always use a quite simple methodology to say, okay, how much work have you put in validating your lifetime value of your customers before you start then working on solving the equation for the different assumptions that you've got? And it's quite a straightforward process. It's the customers, it's the acquisition, and then it's the serving those customers because you can hack together serving your customers plastic, elastic bands and band-aids in the background. So when you start to scale, that starts to become a real problem. And then all the while holding down your build costs as best you can. So if somebody comes to us and they've not really thought about their assumptions that are making and what they're trying to solve for with the build in a fairly structured way, we'll definitely push back on that. What are regular obstacles or challenges you are facing with the founders team when you start collaborating? Good question. It really varies. This is the whole point around when we look to do an investment or we look to partner with somebody, the process of getting to know them is quite long. And we do stress that human capital relationship part of it quite a lot. And that's why we're very attuned to coachability and things like that. Are they the right type of person? Are the ideas that we're suggesting landing or is it just hitting a brick wall when it comes back? We've other common threads. I'm not sure if there are. I think sometimes founders have in the past got very stuck and set in their ways that this is the only way that this product can get to market. And I think it can be very hard also to then get them to invest in that design research path and to actually say that you need to go. You may have spoken to 50 of your friends. You may have spoken to your family. You've got, there's a bias coming through that. You need to go and actually expand as well. Sometimes it's very difficult to get them to buy into that piece. And we haven't necessarily got that across as effectively as we can do. Once we do get that feedback through and they can begin to see that there is value in understanding that user ahead of, oh, I'm going to go and build the full app and drop it on the app store and hope it becomes a lot easier process. So I think that's definitely one of the hurdles we struggled with because they're first time founders. They can see that investment in that yet they think they know the answer in some cases. And it's been validated down the pub or it's been validated from these people. And it's often, it's a process that needs to be done. And it sometimes can be really difficult to convince them that no matter whether we've got use cases and we can prove cases, it can be quite set in their mind. So that coachability, that can block that particularly important step of understanding that user base. Pre-design, pre-build. We don't want to spend any money on that until we know exactly what the user wants because it could just be a waste. One of the challenges I would say is that because we're outside of that founder team and it's external parties, and this goes for any time you're working with an external party, I think you've got a real trust deficit to get over. So some of the projects that we've worked on, we've kind of viewed at arm's length and they're outsourced or what have you. And one of the ones that I've worked on for now three years and we have a phenomenal relationship now. In the early days, this founder, he got another consultant really to check some of the work that we were doing. And this guy was feeding back to the founder and he's saying, oh, they're not doing this. They're not doing that. What have you? And I was like, why? What is the value you're getting from this? If he wants to throw rocks, tell him to throw rocks at us so we can fix what we're doing rather than you getting a bad impression of us. And it's all up to interpretation as well, situation. Like let's be in the same team about this and then we can work together and then we can solve it rather than somebody feeding into you and not telling us what he thinks that we're doing wrong and getting over that hump of actually, if we work together as a team and if you've got a problem or if you want to check something or what have you, let's get over that. And that's what you'd do if you were in a founder team together. You wouldn't be keeping secrets from each other or secretly checking up on people. You'd be like open and honest and these are the challenges. And I think that's something that we always try and get over as early as possible, but it's that natural kind of blocker that you have if you're working with an external or quasi external party. That's very good. I would like to double click a little bit like on the topic that Richard just mentioned when it comes to especially like getting the buy-in for research and going out and actually validating these ideas. Because I think it's something that I've seen as a challenge like when working in a consultancy and you try to get people to do it. But at the same time, I'm pretty sure like a lot of product managers or designers, researchers also sometimes have this problem in the companies. Like how do I advocate for the value of getting this data, of getting the user feedback early before even building something? So I would be curious to hear like how you are usually like, how you work in convincing the customers or to advocate for its importance. We have a very good design director. He does a fantastic job of going out and talking to them. I think it really comes down to trying to explain the impact of not doing it, the potential impact of not doing it. I can't remember off the top of my head, but there was a statistic that we talked to in that the savings of spending one pound at a design research stage can save X amount of pounds at the development stage. And I think when you extrapolate that out on how much that money that could save you in time and stress and everything else of doing this company, it does begin to land. But it's a real challenge because it's not something they can necessarily see. And it's just people's opinion. And people's opinions are very strong, particularly founders, or they trust the opinion of their friends. It is a very challenging thing. So we tend to put in the people into the conversations who are the ones doing the actual design research. We bring the expertise in. We say, look, you've got to advocate for what you guys believe in, what your career is about, and as to why you would go and do it. Ben and I can sit there and say that we need to go and test those assumptions. But Ben and I are not the design researchers. So we try to bring in the design team as quickly as we can into that so they can advocate the reasons as to why to do it. And then backing up to that is talk to case studies. We can talk to case studies where we haven't done design research, where a startup has failed. Now, that may not be completely tied into that. But we could probably pull out some feature sets where a significant amount of time was spent, and it just wasn't used. And we can probably talk to something where something is completely pivoted in the design research phase. And that does happen often, where people think they're going to go to market with this feature set and actually find out 90% of that's not needed. And the gem is in something they would have never even spoken about. So we try to bring together those case studies as well as best we can in a way that will relate to that founder. But I guess wrapping that up, I think it's about putting the right people in who can speak to it, and then backing it up with examples of where it hasn't been done that will relate, and then examples where it has been a success. I think on that one, things like the simple equation that we talked to are useful props to support that argument. Because if you're sitting there and you've only got four elements of your equation you're trying to control for, and you say, look, this left-hand side of the equation, the total lifetime value of the customer needs to be bigger than the rest. How well do you know the assumptions that underpin that? Then they're sometimes like, oh, yeah, okay, good point. And they might say, actually, you know what? I've got £20,000, I need to get something out in the market because I've got this gut feel about it, and I want to go and test it. And then you go and build an MVP and get something out there. And more often than not, they'll be like, yeah, okay, we should now need to spend the research, but we've time-boxed or resource-boxed how much we're going to put into that thing before we then look at a different part of the equation. I think generally the big challenge is just, and you touched on this at the very beginning, it's also the mindset, right? Because whenever you do this sort of research, it might mean that you're actually not going to build your initial idea because you have to pivot. And I think this is where people need to get comfortable with, to be like, okay, I have this idea, but if I validate it, it's better to know that I shouldn't build it at the beginning than investing all that money and all the time to build something that nobody will use afterwards. Once you have done your research and you know what you need to build and a team realizes while the process that they're running out of money or they're building an MVP to raise some money, how do you support them in the context of funding? In the context of raising capital? Yes. Yeah. So we've often sat, if it's a startup and we're going to be an investor inside that startup, we can get involved before kind of angel funding or friends and family funding has taken place and support them through the process of raising that capital. And I think the fact that we are involved is sometimes validating the idea and giving support that capital raising because of a business like ours that's seen so many startups has got that experience. If we're buying into and believing that this founder has got this concept that we think has got potential, that's really helped. And I think investors are looking to put capital in, do want to see a balanced team and they can see that passion and that sector knowledge out of that founder. But when they know they've also got the support of product people, designers, engineers, and people who've been in startups for a number of years, I think it just really gives them confidence that it can become a reality. And that the money's going to be spent well because of that alignment that we spoke about earlier, because we're aligned with them, we're not going to just go and spend money on engineering for spending money on engineering sake. So there's an element of safety to it. And we do get involved in pitches. We've been there numerous times with founders on their first run through with angel investors and sat there and said, yeah, we're an investor in this. We're going to be the technical arm of this business. And that does provide security and I believe a bit of validation, to be honest, at that stage. Also, by trying to provide rigor and pushback and saying, look, we don't think you should spend money on this. There are other things that you should be going and spending money on to achieve or validate the assumptions that you made in your first round of funding or what have you. Because going to the next round of funding is basically saying, this is what we said at the last one. These are the things that we said we were going to achieve or these are the metrics that we wanted to validate. Yes, now we've gone and done that. So getting them to go back to that and saying, actually, I don't think it's the right time for you to be spending the money on this because you need to focus more on understanding the customer or how much it costs to acquire those customers. The feature set is enough. And we've actually had situations where we've turned down build because it's not the right thing to be building. Yeah, I can also understand it. Sometimes you would just have to make the cut if you realize it doesn't make sense. As hard as it sounds, but that's also reality. How often does that happen? I think I see them smiling a little bit. Yeah, I'm looking back in my mind of like situations where we've said, look, we shouldn't be doing this. You know, so I was just thinking. I think it happens fairly often. It's not that they don't spend the money in the end. It's that we have proven to them that we're not there for the short term gain. And therefore, if they push something back, if we push something back, then we're doing it for a reason because we want them to be around in a year's time. So it does happen fairly often. How that is an actionable thing for your listeners, I'm not too sure. But the getting back to the focus on what are the biggest risks you're trying to validate and how are you trying to prove the things that you said in your last funding round to be able to get to the next one? Really keeping a laser focus on those things rather than getting distracted by somebody saying, oh, we would have bought this product if you'd had that feature and losing sight of your laser sharp focus on your product roadmap from it. Yeah, that does happen a fair bit. Actually, I've seen that over the years, we do tend to follow exactly what customers are asking for and lose that sight on what that solid roadmap is. It's easy to do. They're paying customers, oh, we need this feature, we need this feature, we need this feature. Before you know it, you really have deviated or you built this really vast product set, even though 20% of it may be only used by 10% of your user base and you've got to go and support all of that. I think the key thing, just thinking about the startups I've worked with in the last year, it's been really important for us to be really close to the business goals and understanding that business roadmap. Not necessarily the product roadmap, but what are you talking about with your investors? Where are you thinking about going? What's your market research telling you? What's the feedback from your users? So that we can then map what that product could be to that and think about the technology for that. So we could say, okay, we've got a business goal in three months time. We may want to dial back engineering because we don't want to go and invest in something until we've hit that milestone. So I think that the piece Ben mentioned earlier about trust, once we've got over that trust, we've got that trust capital and we're in the business and we're functioning with inside the commercial side and understanding what the business roadmap is. It makes it a lot, lot easier when you work collectively as a team. So it's not them and us and we're just responding to it. I just wanted to say that, but I missed the part to Ben, when it comes to the whole topic of trust. I think, especially as an agency or as an outsider, for example, I'm also as a coaching consultant. There are two types of trust. At the beginning, you have to trust, but later on you ideally want to trust someone. And especially as an outsider or as a company who provides services for other companies, it's a much bigger challenge to overcome this trust hurdle in a shorter timeframe because you have always less time than an usual employee has who works full-time there because you have a budget, you have a project deadline, et cetera. So I think finding that piece of trust to make this collaboration as great as possible is one of the biggest challenges, but can be also most rewarding in case you accept each other's trust. Yeah. And you build a great long-term relationship when you get there. And I don't think we've fully cracked it, but working out ways and things that give you that kind of trust. And actually, a really strong, clear process that doesn't leave any white space and doesn't leave any kind of uncertainty is actually a really good way of building trust. Because then there's no doubt about who's going to do what or when they're going to do it. And just being really transparent about how long things are taking and what you're going to deliver. We're big believers in weekly oversight meetings with our customers, as well as weekly demos of product in a stage. I call it as soon as something can be deployed on local and runs, then you should be demoing it to the customer. Whereas a classic agile would be like at the end of the sprint in as close to production as possible, because that's what you would expect to be delivering from a feature point of view. But if you're sitting there wondering what's happening with your product, with your baby, and you're not hearing anything for two weeks, and then you only get a demo of a small fraction of the overall product, because it's the ones that have gone through all the way through QA and everything, then that doesn't build trust. What builds trust is really early engagement and really early seeing what's happening. Yeah, absolutely. If we speak about long-term relationships, and this might a little bit be a more challenging question, because obviously as an agency, you want to build this long-term relationship and work with a client as long as possible. But purely from a product perspective, what's the point in time, if there is one, where I, for my company, should choose to try and build the capabilities in-house and really start building a strong in-house product and development team that can push this directly from inside without having to rely on external resources? Yeah, we absolutely know that's part of a company's journey. We have a little internal hashtag, which is precede to series A, and it's basically that represents the size of businesses that we typically work with or the type of investment that could come into that size of business. We foresee that within our startup space, it's a two to two and a half year relationship before you need to be bringing in the CTO, before you need to be bringing in and building out that internal function. We know we have a sweet spot for getting these businesses going, and we're fully aware that we want them to graduate, if you will. We want them to move on from us, and that would have been a great job done from us if that company's got through that first two to two and a half years, and they're in a position to grow and grow that internal teams. Well, what a fantastic thing we've managed to do to get that business through to that point, and it's absolutely of our roadmap. We've got one of our businesses at the moment, we're thinking about what that transition looks like. We're 18 months into that position, but they're growing at a pace where we recognize that the best step for them is to actually move their core strategic function inside and moving some execution, and we could be there to support that further execution for the next year or two to whenever it fits for the goodness of that business. Because on the startup side, we're an investor, and we're ultimately looking for the best of that business to grow. And if that's the case, if they want to put their internal team within eight months, then let's do that. It's what that company needs. So we're not precious about always having to put our resources in it. It's not that game for us at all. It's about building a great business and what that business needs when it needs it. Amazing. And the startups, if you're early stage, you may believe your equity is worth something, but somebody who's got a load of other competing offers or already working at a top technology company or anybody, really, from a tech standpoint, will view your equity differently. Our goal is to try and get those businesses to a position where their equity is worth a lot more and their funding opportunities are worth a lot more. And therefore, they can build that internal team and then hand it over, but not wash our hands and walk away. Often, we will continue providing resources while they've got their own CTO. And so there's a stage transition. I think it's just the right kinds of people for the right business. And we're not enterprise engineers either. We're not there building enterprise level systems. We're about the quick decisions and how you get things working with a scarce budget rather than that size of project as well. Awesome. I do have one final question, at least from my side. And I think especially when thinking also of companies that are considering to work with externals, maybe you can help me summarize a little bit. I think we touched on a couple of things. Is it the trust? Is it also the coaching mindset or being coachable? But what would you say, what should the mindset be when they want to start, for example, with you? Because I've seen in the past, oftentimes, people reach out to agencies, consultancies, because they want something to be executed. And they don't really get them in to listen to their opinion or something like that. So what would you say, should someone be prepared for when working with an agency? I think you do your view first now. I mean, I guess just one point is that if you're going to bring in a group of people who've got a tremendous amount of experience, and you've identified them because of their work, that they've done their case studies. If you're bringing them in, why would you not bring them in to listen to them? Why would you not bring them in to take all the learnings? So I'm a firm believer, and I know that's how we approach business. If we can find people who have got more experience than us that we can go and learn from, we're not just going to go and drive them to say execute. So I think if you're going to work with an outside partner like us, or like someone else, they will have gone through various experiences, which will put them in a unique position, which is different to the one that you're in. And that's why you need their service in the first place. So for me, it's very much about listening. It's very much about being humble and saying, okay, let's just understand it. Let's have a discussion. Let's see together if we can pull something fantastic out of the relationship that, after all, you are initiating. So that's what I think. Yeah. And on that, back to that idea of the why, how, what. If you're approaching something, a relationship like this, just really think about what you don't know and make sure that the stuff that you don't know, somebody's covering. So is the agency you are, the outside partner you're working with, leaving loads of gaps or white space that you're having to guess and fill in, whether that's about how they're actually running the software development lifecycle or the gaps in the product. And if you're having to define the product really detailed yourself, and you're defining in detail exactly the scope of what it's going to be, but you're not from a technical background and you're not from a background of building products, what are you missing? That idea of how the product works. If you know why you want to build it, and then you're defining yourself to how, and then somebody's going and building the what, you can be certain you're going to be missing some of that how as well. And therefore, how can you challenge the scoping that you've given to that external party if they're not going to fill in that gap? So I would look out for, back to what Rich said, this idea of humbleness of, okay, I've defined everything. This party's going building the app for me, but I've had to define everything and I'm not an expert at this. Therefore, I know for certain there's going to be a gap there. And how can I challenge that if they're not going to do it? Amazing. Yeah. I couldn't agree more with that. So to wrap up the conversation, there's two final questions, but the first one is the bigger one. So you are doing Mojara now for almost a decade, and you have seen many companies rising, falling, succeeding, failing. So I would like to know, including your own, you have maybe seen many pubs in between as well, but it would be interesting to me. Now, working for years with startups, what was, from each one of you, the biggest thing you have learned for yourself, for your personal growth by working with startups? I think I learned, working with startups, I think I learned the biggest thing I could have learned was working with Ben and working alongside him with a startup, a chap called Aaron, who Ben introduced me to, who's gone on to have a very successful startup. What I found was that you really, if you're going to build a startup, you often have to be in it with them. There was quite a lot of, like Ben said, there were some ups and downs. I remember November 2013. I remember that particularly. I remember preparing myself mentally for a conversation with Ben, where because of these two startups that were very draining on a very small team at that time, I was actually having to let Ben down, getting his product out for Christmas. I know that was going to be hugely detrimental to it. But I think the thing that I've learned is if you're going to go and build businesses with people, and you're going to go and do that, I know it's a bit cheesy, but it's a little bit like a marriage. Prepare yourself for that emotional feel that comes from it, because you do really become quite close with people. You do share what they're going through. And I think that period in time, I really recognized, crikey, this is wearing on me a little bit. I feel like Ben's co-founder in a sense, even though I wasn't, strictly. So I think the thing that I learned in the early days of working with startups is that it really can be a little bit consuming, from an hourly thing, but also from an emotional standpoint, because you're really pushed for success. And you really want to see people strive for what their goals are. And I think you go along with that story. It's not, you don't necessarily switch off. You don't switch off that easily. So I think that was one thing that I learned early on, that it can be emotionally incredibly rewarding, but it can also be quite stressful. I've become a bit of a straight line thinker, just in lines rather than in circles. And one thing I learned very early on in my startup is that I didn't have the skills to be able to do it. The idea, as I said before, of this, somebody needs to build, somebody needs to sell, somebody needs to finance. And if you're a single founder, doing all those things, either takes you a long time to learn it. And therefore you've got to need a much longer runway, or your runway is going to run out before you actually learn how to do it. So the idea of being a single founder, I found very difficult. And then when you are a multiple founder and the skills are distributed, that means that actually somebody can go out and do the selling and somebody can go out and do the building and what have you. But actually those skill sets are different. And it's a diversity in thinking type thing. If you're thinking, oh, I want somebody exactly like me, but can do things that are opposite to what I do, that's not going to work. And so that's where that kind of trust and relationship thing comes in is that Rich and I have had our kind of ups and downs, but our skills are very different and we drive each other mad at certain things. But if our skills weren't different, then we wouldn't be able to cover the ground. And if you can't cover the ground, then you're both doing the same thing. You're both looking at each other, why are you digging this hole? I'm digging in this hole. You should go and dig in a different hole, kind of thing. And that kind of realization that you need to divide and conquer or be covering different grounds, otherwise you're not going to succeed. But in order to be able to do that, you have to let go of yourself a bit and say, okay, I trust this person who's got different skills and does things in different ways to go and do his thing or her thing, because I can't do that. And that extends outside of startup life. That extends to other things like being able to trust other people who can do things differently to you in different ways and get on with it. Amazing. Thank you very much. That was a nice chat. And I think, yeah, it was a pleasure. Thank you. There's one last question I need to ask. I think I need to send my man today. And Alex, I just want to ask you, do you want to professionally marry me? You've been dating for a while now. It's time to make it real. All right, guys. Thank you very much. Bye-bye. Thank you. Bye-bye.