Verena: Simon, good seeing you first of all. Are still feeling a little bit jet-lagged? Or at least judging by how you look? ⁓ you. well, think one of the biggest learnings I took away from the conversation was the importance of really slowing down during the early build phase. So Charlie mentioned how his team spent a lot of time actually mapping user journeys on whiteboards, using sticky nodes and really finding out what do they need for their operation, before jumping into development. this really helped them to you know, reach their long-term Today I'm joined by Charlie, who has helped build and grow multiple ventures. One of those is Mission, Inc. An AI powered platform to design, help leaders identify performance gaps and turn insights into real impacts. Welcome to the podcast, Charlie. It's awesome to have you.
Simon: Thanks. Yeah, a little always hard coming back from ⁓ Mexico, time difference kills
Verena: But yeah, maybe to give our listeners a bit of context. we usually meet on quarterly base just to review our strategy, define what we do next, et cetera. I think that's always better in although we love working remotely, but talking strategy is just better with cup of tea or strong coffee. And time we also met with one of our advisors in Mexico. So also quick shout out to Jason Long. Thanks again for your time.
Charlie Addison: Thank you, good to be here.
Simon: next episode.
Verena: could you tell us a little bit when Mission Inc. was founded and how the idea first came about? target. So my takeaway for founders is just building doesn't bring you closer to the end result. You need to spend a lot of time understanding the problem and ⁓ being really patient, right? Because it can be really rewarding later on.
Charlie Addison: Mission Inc. an idea was ⁓ formed by our founder CEO, Andrew Pooley. And that was to kind of crystallize a mission intent driven leadership. What that is you want all your people in the organization to know ⁓ not just your mission and what part it.
Verena: super, super valuable lesson we had with you.
Simon: when we come away from those sort of things, usually it's just you and I catching up with you and I and some of the other members of the team. But when you bring in an external founder or an external mentor who happens to be a founder as well, you get that opportunity to get an external view of your business. And I think that's really valuable because you can go and get stuck in the weeds yourself, not really see the view and somebody to come in and say, yep, that's right or no, what are you thinking? That's madness. It's really super helpful.
Charlie Addison: delivering it is, we also want to delegate as far as possible down the hierarchy the ability to affect change. The philosophy behind that, and there's been quite a lot of research on this, but philosophy is the people who are actually best placed to make critical decisions are the people at the of the spear in military ethos, the people
Simon: If you're not doing it as a founder, really suggest you find somebody or some people that you can that kind of bounce off with, even if it's once a quarter or once month, even better.
Charlie Addison: at the coal face who are doing the work. So if you move that decision making away from the people who have the most information, then you degrade the quality of decision that comes back down. So what we've built with support Million Labs is a dashboard, a tool that will both push the information down the hierarchy
Verena: don't have to sign up for a coaching program, right? Just go through your network, ⁓ look for people LinkedIn who's done something similar, right? And just reach out to them and ask them for a paid hour to challenge your idea. I think you will be surprised to see how many people accept and how much value you get out of that.
Simon: Yeah, you've got nothing to lose. You can ask the question. There's lots of founders out there that are kind of one or two steps ahead of you and they're brilliant because they've kind of been through it and they're not Richard Branson or Elon Musk or whatever who went through it 10 years ago and don't really remember what the pain felt like and what they did in those circumstances. Of course things change, but the guys and girls that are just a couple of steps ahead of you, they're really valuable. So yeah, reach out, find them
Charlie Addison: mission ⁓ what the organization leaders require their people. And also back up the real performance against those metrics. plug AI into and you can get some real fascinating insights.
Verena: Yeah.
Simon: So are we going to get into this topic? Should we do this?
Verena: Yeah. Yeah. Let's dive into today's episode. Yeah. web versus native apps. And probably it makes sense to quickly clarify the terms because is where we get a lot of confusion. Right? So many people think a web app can only be used on a desktop, but that's not true. So a web-built app can be fully mobile responsive and work perfectly on your phone.
Charlie Addison: about data, especially big data sets that perhaps aren't evidently available to you if you're just looking with your own eyes.
Verena: Who's your main target customer?
Charlie Addison: we are targeting businesses are problem aware. So they recognize the ⁓ value, and developing their leaders. And they would this tool to help deliver embed that mission focused ethos throughout the business.
Verena: just through your browser, And the key difference here is that a native app is something you've downloaded from the App Store and our Google Play versus a web app runs in your browser. It doesn't require this installation, but you can still open it from your phone.
Simon: I think that's a small difference and it might sound small, but it has a really big impact on a whole bunch of things, particularly development, because you're developing for, let's say the two major ones, which is Apple and Google. And you've also to test in those two environments as well. So you've got to test all the models of iPhone. You've got to test the literally thousands of Android type devices as your problem, you're testing for like, say three or four different browser types. Chrome, Safari, Firefox, whatever, to now testing for literally thousands of devices. Does it work on a Samsung 170i that came out in 2016, or does it work on the latest iPhone? You've suddenly got this much bigger problem to deal with.
Verena: you know, our start phase is all about validating demand before building the main platform. You've already mentioned Andrew, the founder, was obviously very close to the pain points and he observed that. Could you walk the listeners a little bit through how the validation process looked like for Mission, Inc.? Yeah, and I mean, even if you just break it down into Android and iOS, it requires a significant amount of time. mean, significant, not in the sense of what it meant in the old days, but when you now can build stuff very quickly. Suddenly, if are talking about an additional three or four weeks, matters, because that's a time when you could have gone out and ⁓ already talked to customers. you go native,
Charlie Addison: in terms validating philosophy, we ⁓ knew that that ⁓ valid Andrew and other members the senior leadership team in his past businesses had used this philosophy to turn around struggling businesses to make them profitable. But in terms ⁓ validating how that works in a platform,
Verena: our experience is that it can easily take around like a month ⁓ just you're kind reliant on their process, right? So Apple releasing a new version or Google, changing a policy or, know, there's a constant back and forth and it goes all right, But in the majority of the there's always a bit of a back and forth. it's just to account for that when you make the
Charlie Addison: how the market reacts to that. That a process that took a little bit more time. We needed understand the platform and where it fits into our business first, I think. ⁓ understanding has evolved we've grown the platform and we've learned more about what it can deliver for us. That then changes our of how we go out to market and, you
Simon: And I think it also changes the cost as well. It doesn't massively increase it, but it increases it enough, know, maybe ⁓ one to thousand pounds, two and a half thousand dollars, something like that. And that's just extra effort it takes to make it mobile ready and get it mobile ready. As you said, like the app stores can be an absolute nightmare. It could be one day or it could be one week it takes. And it's just an unknown. It's out of your hands. And anybody that's been through that experience is that, Apple, they're pretty brutal. It's either it passes or it fails.
Charlie Addison: what we can sell this on as a ⁓ tool for developing ⁓
Verena: So if I understand you correctly, the business model itself was already proven before, right? Because it was part of an ⁓ business, it was part of an infrastructure, but you basically took that and just applied it to niche,
Simon: And it's sometimes quite hard to figure out why it fails and what you need to change to do it. And that could take days to then try and figure that process. and money, definitely an impact there.
Verena: we look at our data, we see that the of founders, they tend to overbuild their MVP, right? They spend three times more ⁓ than their initial budget and it them like six months or longer to launch. And obviously there are several reasons, but ⁓ one of them is also, know, do go native too early when it's not needed? it can, you know, add or be one of the reasons why you just...
Charlie Addison: Yes, exactly. And as I said, I think the, kind ⁓ while were building it, we started to understand more and more, especially the value of that AI driven insight. it, sounds like a, maybe a minor value add, you know, that we, we have the platform. ⁓ and there's an AI plugged into it when really data about data is, or can be so valuable.
Verena: again and again. And early on, really, your main goal should be speed, Getting something in front of users, learning and iterating. We probably repeat ourselves, Simon, by it again and again. But oftentimes, in entrepreneurship, it's like you do the obvious, right? And you do it again and again. And so we probably sound like parents,
Charlie Addison: that having that AI into an interrogation engine that can give us insight and surface insight we didn't know we had. That's really powerful tool.
Verena: ⁓ now with wipe coding low code back then, It's almost building almost becomes part of did that like for you? What did your ⁓ version look like?
Simon: record, we would say in English. We sound like a stuck record repeating the same bit. But yeah, whenever speak to founders, we always say start with a web app. That's our go-to advice because of those problems of cost, complication, ⁓ maintenance of ⁓ a app, ⁓ requirements, all of things that we just talked about. Those all ⁓ slow you down and you more money before you can even speak to a user.
Charlie Addison: there was a lot of, a lot of head scratching, you know, lot of planning out user journeys. I think we use, you know, we use everything from Figma to, you know, sticky notes to having it up on a, on a big whiteboard. vibe as you say, it's, it's such a, such a big thing now, such an upcoming thing, but I actually think we benefited from.
Simon: And I know everybody wants an app in the app store. Like it feels cooler. It feels like you've a proper startup. You've got an app in the app store. I get it. as we said, it's probably not the right thing to do. the only reason that you say go from mobile app first, so into the app stores is where you absolutely need mobile specific features. Now that might be GPS. It might be something to do with the camera that's completely native. It might be ⁓
Charlie Addison: going back to basics almost and really thinking through the problem rather than diving straight in with a prompt and then you don't know where you're going to end up if you do things that way.
Simon: movement, the gyroscope that sits in most smartphones, et cetera. So if it is an app like that, sure, you've got to go mobile. But for everything else, I think as a question mark is, back to our previous episode about minimum viable products, is this requirement for the value to prove the value? And if it's not, then go web first.
Verena: ⁓ we see it the time that it's so easy to, ⁓ you know, get distracted with the details of the build, And it's almost, it's really easy then to forget why you are doing it in first instance. ⁓ So, ⁓ yeah. ⁓
Charlie Addison: Yeah. Yeah, absolutely. Absolutely. It's, um, if, if I can use an analogy, it's, it's like when, you when you're young and you want to, you want to start a band, everybody focuses on the band name, but maybe not so much on the, the music, you know, it's the same here. We want to dive in, you know, we want to be, we want to be building and it's so easy to do that just with a, you know, with vibe coding prompt, but actually that's, that's not really perhaps the best way to go about it.
Verena: Do it. What would you say, when you back, like what were some of the ⁓ key learnings ⁓ you had from launching application? Maybe some things surprised you.
Charlie Addison: I'd say the, importance of, really planning what you're to do before you do it, because even ⁓ planning in as detail I think we did, we got to phases where, you know, you go through user testing and something, something happens, you see something and you're like, this isn't right. And then you look back and like, but that's exactly what we asked for. So, you know, you, you, those
Verena: So what did we learn, Simon? Going native to early often leads to more complexity, higher costs and slower progress. ⁓ you have a very clear reason to go native from day one, starting with a web app is usually a better choice for early stage founders. This just allows you to move faster, test your idea and iterate quickly.
Simon: Exactly. So, Farina, let's hear your conversation with Charles.
Charlie Addison: of no way in which you can over plan this I think you have to be very very clear about what you want to happen and what you don't want to happen and somewhere in between those things going to be the truth I think.
Verena: did you do in terms of user testing?
Charlie Addison: I had done a bit of user testing myself before we, before we came development. so, I took all the testing myself in-house ⁓ spun up various different user with different roles just, went through the process in excruciating detail. Yeah, it was definitely a very valuable process with the trying to break the build.
Verena: 100%. And I mean, there are always a of edge cases, right? Like also, you know, and you have to at some point also decide, you know, what, know, is really needed, ⁓ right, now and what, could we do later?
Charlie Addison: Yeah, that's a really interesting point actually, because you can get so hung up on edge cases and treatment of these edge cases and the edge of the edge. you say, there comes a point where you just need to draw a line and say that, you know, this is it and we're going to move on.
Verena: What happened once you it and ⁓ first customers were it?
Charlie Addison: feedback, very positive, start with. And I'm quite glad that they were, they were able give us kind of useful feedback ⁓ instead of kind of say, ⁓ yeah, we don't like this. We don't like that. You ⁓ know, instead of having a negative mindset, were very much understanding that, you know, they were, early birds. were first customers. ⁓ they were getting a product that is is powerful, also not yet polished. So they were critical in helping us really put that last layer of polish on, ⁓ from the ⁓ point of view, because a lot of ⁓ we were doing to get into production was simple functionality. You know, if it works, ship it. Whereas, you you come across a user who's never used the platform before. And they'll have a completely different set of eyes from me who's, you know, who's I see it in my sleep, you know, I see it in my dreams. I've been I've been testing it so much over the last days and weeks.
Verena: Do you have any recommendation for founders out there, like how to get your customers spend time with you and kind of be part working on the version two of your product?
Charlie Addison: Yeah. think that, honesty, very important because, know, ⁓ if you say to someone that this, this is in production, but it's not polished, you are early to this platform and we value your feedback, then they, they become, they're not just a revenue stream for you they are a partner and they, they will see the value in that as well. You know, they will understand that they're getting access perhaps a good rate to an early product and in return, what they have to do is maybe be a bit patient about some things that might not work how they'd want them to and engage with us and give us that feedback.
Verena: ⁓ it's lot also about expectation management, isn't it?
Charlie Addison: everybody kind of, I falls into the of thinking that you have to almost show this, this final version and actually it's think to, to have something that is, that is functional, but not yet the final product and be honest about it. I think maybe one of the biggest ⁓ across the whole product life cycle very early on, was deciding particular directions that the product going to take.
Verena: question from my side, Charlie. obviously not only build Inc., but also ⁓ other ventures, as know, right, especially in the medical space. What are some of key lessons you've learned for that experience of building multiple businesses? is a piece of advice you can share with listeners out there?
Charlie Addison: you're working across multiple businesses, you just have to be flexible. You you can't plan your week or maybe even your day because there are so many different competing priorities. So you've got to be able to ⁓ prioritize and think your feet and just handle different situations because no day is probably to go how you thought it was going to. You just need ⁓ to adapt and keep going.
Verena: And I guess enjoy the process. Thank so much, Charlie, for being our guest today. ⁓ Really conversation
Charlie Addison: Yes. Yeah, thanks for having me.