Unknown 0:00 So, Unknown 0:04 I feel free to free to give me more details, if you think of any point. I also give you some hints from a previous interviews whatever heard, so that you can also think about those answers and Kimmy. Unknown 0:16 In your opinion, are the correct. Unknown 0:19 So what is your current role here, and since then. So I'm here at sleep since about three years now. Unknown 0:28 And my main role is product owner and business developer. Unknown 0:36 What does it mean business developer, so it's it's a mix of extending the business activities as well as regular sale. Okay. So you have to talk to customers. Yeah. Unknown 0:47 And we and we like to, not everybody does it but we like to mix both roles, so that you don't have this typical scenario where the salesperson doesn't make some promises and then pass it over to the project team and it's not his problem and then watch them. So yeah. Unknown 1:06 How many years of experience you have a software development or mobile development, I have well software development as as a product owner Product Manager, I have 10 years. Unknown 1:17 But I've only done no bad since I'm here at leaps of mobile specifically would be three years. Yes. Unknown 1:25 And how many years of experience you have with this kind of gathering requirements from clients, and so I would say, Well, I think that extends, more than 10 years actually. Yeah, I've been working as as project manager and then, and things like that was previously. So, yeah, I have to say it hard but. Unknown 1:52 Yeah. Unknown 1:54 What's the academic background so you come from software engineering or. Unknown 1:58 Yeah, what I would say I come more from the technical side, even if I broke up my studies so I started. It doesn't but I didn't finish, and then I just started working but you have that background. Yeah, exactly. Unknown 2:15 Okay. Unknown 2:17 Whatever techniques you must be using with your clients workshops okay what. How did you learn those, or is it to experience self taught. Unknown 2:27 Yeah, mostly. Unknown 2:29 But not only it's it's it's it's through working experience actually mostly and reading and reading so what do you read exactly do you read online blogs. Yes, yeah exactly I mostly read your blogs testimonials from scientific publication so John's, not, not regarding Requirements Engineering. Unknown 2:55 Let's talk about your company a little bit. How many employees do you have here, so we have 180 days. Unknown 3:04 And they don't all do. Mobile right but these are all the strength of the company. So all the people. Unknown 3:29 Because we like to have the proximity, when the customer customers. Yes. Unknown 3:12 And, which are the geographical markets you build for you as, Switzerland, Switzerland, Switzerland, but not the of course the market of the app itself can be clients. The clients are Swiss. Yeah, exactly. I suppose you have other offices also in three public and what we do is on calendars and so we have offices in and what are the purposes so they are development centers, or send sentence or you know they're they're all generalists so to say. Unknown 3:52 The purpose of having five locations and this one is not an economical one because it's less efficient economically is really to have proximity with the clients, because we like to. I mean we do video conferencing and stuff like that, when we need to but we like to have have an onsite presence. And so it's important for us. That's the reason why do you have any number of how many mobile apps are you built so far. No, I would say, good question. I guess I guess about 20 to 20 ish Yeah, we only do mobile app. So really native mobile app development at least since four, maybe 554 or five years it's quite new for leap actually. Unknown 4:33 And I would have this 20 apps on a enterprise apps are on the public apps. It's a mix of both, I would say mostly public apps. And, yeah, just a couple of enterprise apps and the public apps all day free. Unknown 4:51 Yeah, I think there is none that is that is paying I think they're all free. Unknown 4:56 They are available on Play Store see. Okay. Unknown 5:03 Can you tell me, roughly, average users your apps might have number of users can also tell me like this so which has the least number of users which has the most lovely also yeah well. Unknown 5:19 I would say probably the least amount of users would be like 200 years or something like that and that would be an enterprise, that's contained into the enterprise. Unknown 5:35 And the most stupid question and something between 10 or 20,000 10,000. Unknown 5:49 So I suppose, which officials would be different in different regions right i mean officers and communication within the teams yes like this was storage of meditation is actually going to ruin your recording. Unknown 6:03 Yeah, exactly. It depends what it is not only depends on the location, it depends on the composition of the team also because you might have people teams in Zurich where some people are not not German speaking so they would then speak English, but it's. Unknown 6:18 We tend to speak a lot of English. Unknown 6:22 But when we can we speak the local languages. Unknown 6:27 I suppose you don't just build mobile apps you also build software center. Unknown 6:32 And we as we build Well, not, not really. We don't build software in the sense of Java. Java apps or things like that we really were coming from the world of web development, and that's really where leaves to get started. And then extended to mobile apps but also other services like service design or general user experience. Unknown 6:54 Services data. Data Services, things like that or extended. Unknown 7:00 Could you tell me which platforms to support, iOS, Android, both in both. Yeah, exactly. So, I'm struggling. Yeah, I think we have one app, which we have only been playing only for one platform but all other apps, we can always build for both Android and iOS, Windows phones or stuff like next season, is it you or the client. Well it's it's much the client of course because the client is the one deciding what he finally wants to build. Unknown 7:31 But it's not really a really big question most of times because, as most apps or public and consumer focused you need to address both platforms. Unknown 7:44 But do you suggest them platform, which they can use if they do not have any idea. Yeah, we would get we would do that too. Unknown 7:53 Well it depends on on what what the app is intended for and what's the audience. Unknown 8:00 But I don't really see a case here at least in Switzerland where we would have a consumer app which would say, you would only built for one of the two platforms. I've hard time imagining right what would you build for the both platforms at the same time, or one comes first, we have done both we mostly doing the same time but we have done a couple of times building, I think it was an iOS first and then you know to to just invest that efforts before really testing it on users properly, and then build on Android we've done that also a couple of times but most times we build, both at the same time, could you please estimation for distribution which is more straightforward which is by the users are you meeting or other clients as well. But by the clients I can't really tell it's really because as I said no to say they want that phone so there's no preference there. And what by the users it's the typical mixing Switzerland is quite iOS have, I have the same great Unknown 9:09 economical factors to go with only one platform at the beginning and then add another. Unknown 9:15 It doesn't really matter for your clients, it's often a sort of investing. Because when when they are aware that you don't just build software and then it comes out exactly as intended to addresses the public exactly as intended, and that awareness is there. That's the driver for for that wish to build on one platform first kind of. Unknown 9:37 They think it's half the effort and then you can test the correct and then once you know exactly what what works, you will do it for the other platform so it's an economical driver for. Unknown 9:48 Yeah, thanks bearings bearing development so if you aren't offering the same application on what platforms. Unknown 9:57 Would it be a case that you offer different features on different platforms, not No, not different just because just because the platform offers you some technical advantages over the other. I can't see any case where we're done that, of course, the usability of the UX can be a bit different, because we will try to stay with a with a non predicaments from each platform which may differ, but feature wise, I'll give you an example. Unknown 10:24 So one of the companies I interviewed. He said, they are building an app for virtual reality related things. And they just realize that the libraries for iOS. I think which is beyond kid was not so adequately developed. All mature as compared to what is available for Android, they decided to go for that Apple Android is dependent on certain other factors, the capability want to that. Unknown 10:51 We haven't been encountered. Unknown 10:58 So, are you a product oriented company or are you service, a service based business right. So in that case. Unknown 11:06 Imagine the moment when you have a customer Unknown 11:12 starts giving you ideas, until you have your first product release. Unknown 11:17 How much time does it take so it will depend of course on the projects. But on an average like what is the least. Unknown 11:26 The question is from the time with first have contact with the customer or from the time you really have had to kick off with maybe let's say kickoff. Yeah, because you have the lead time that a contract so I don't think that's what's point. So, supposing that we would start working directly and we don't have any other, you know, external constraints that it can go quite fast. Usually we, we have the sprint of that we do two weeks prints close attention usually we have the first sprint country let's say you have deliverable that you could push to users even for testing at that point is most times you need to Spencer, after month after month you you start having things that you can really test on one call to include gathering requirements that will be really be that would be really just developing and the point is often we have customers who come to us and they come too late in my, in my opinion. Unknown 12:23 So they come in they already have preconceived ideas of what they want and they and, you know, I want an apple or the red button in the corner and not your opinions because i know i think it's a bad for that. Yeah. Because it's the requirement engineering part is quite lacking the customer into the whole marketing part is also quite lacking so they probably don't really know who their customers are no I want to ask you, until this day so when it format or, in this case, if the client has some technical background. Unknown 12:53 Anything comes with an idea, compared to like my idea. I mean, have no technical background. It comes with an idea. So it's not the technical part. That's the problem. It's the knowing the customer part that's the problem. Okay, so they do not know the end users. Unknown 13:16 So how typically things in your company look like mobile development. So we typically have a smaller development team we won't have like 10 mobile network importance because the code base is usually smaller so you really don't want to step on the feet of each other so we usually have maybe two developers like typically an iOS and Android development and then maybe a back end developer, two or three developers. Sometimes we have for developers when we have to get going a bit. And we have a UX designer UX designer. Okay. Unknown 13:51 And the UX designer, as well as the product owner of course, the team and Scrum Master product owner and UX designer are the ones involved three in the requirements part told our testers, you have no we don't have a dedicated test. Testing department or things like that to outsource testing on quality word, you know it's it's done by the developers, so when the developers are the definition of done is is that it's quality testing as well. Okay, how about deployments. Do you have any deployment engineers, not really, we have developers can take care of. Yeah, exactly. So we have the whole pipeline. Unknown 14:30 So do not offer any design work. You have everything in house. Unknown 14:35 So I would say, a typical team would look like. 346 275 six people on another. Yeah. Yeah, something like that, probably more on five and six and it's pretty it's and it's mostly smaller teams, right. Unknown 14:52 So, in which phases of your project, other customers involved as a two hour, as it in the beginning, it's, it's mostly as well. The customers. So the end customers the users of the product you mean not our customers because that's the crux. Our customers are most times. If it's not, if it's not an internal or not the users of the. Unknown 15:19 And so we have really lacking contacts with the end users. Unknown 15:24 And we're in good cases where we where the customer is open to the idea that we need to do proper requirements engineering and and all that we, we might have contacts sporadic contacts with users in the beginning, when we talk about user journeys and certain things like that. Unknown 15:49 And then we would love to have you know a user test group, looking at every release after each sprint and really testing and testing, but sadly that doesn't happen. Unknown 16:03 Mostly never happens. So, even we do agile development. Unknown 16:09 We don't submit the releases to the, to the real users, just to the beta users. Yeah, well, that would be good, but but that doesn't happen on the beta users mostly are the real users mostly our that our customer and think when people ask our customers which are already having this tunnel vision because they're thinking about you've been working on the project, very long time. So that's, that's a problem we would like to, to solve, but it's it's hard thing to do. So most of the times, it's only when we then have had a public non beta release that the custom the real users will get in touch with it and even then, it's hard to convince the customers that we need to do. User richer research or user testing or things like that, interviewing, or whatever to really get some feedback from the real users. So there is a lot to do in that area. Unknown 17:06 So if your client has some expertise with software development, some experience. What do you think that once you're in a good or bad. Unknown 17:16 It probably will not really I don't know if your question is still focused around requirements gathering. Well, yeah, they were they really depends on what that experience is if it's, you know, the classical waterfall experience, then that might not help because they might think that's the way to go because they've done that for 20 years. If it's experience involving you know really user centric approaches then when of course that would help, but it's as if the customer is coming from a technical background, it is easier to communicate the communication also takes less time in. Unknown 17:57 We, as we really try to stay user centric as much as we can. The communication with the customer is mostly based around what the what the user wants and what we think he wants and all that. And the customer doesn't really have to bother that much with the technical details that's our job. Right. So, no we don't Unknown 18:23 have two questions about security and legal things, but I think we can talk to them afterwards. Unknown 18:31 So, if you consider the project, lifespan of the project. Unknown 18:36 What percentage of it in terms of time and cost would you spend on Requirements Engineering activities, Unknown 18:44 but also less than we want. Unknown 18:47 And let me think here. I think it's it's maybe around. Unknown 18:54 15 20% something like that, I would say. And could you say, Tell me, why does it happen. Why it's so low, or why we do it at all. I wouldn't say, necessarily, but what are the challenges in that context, for instance what I've heard from other people is the customers usually do not want to pay for these things, that's definitely one one challenge. Exactly. The customers, even though it often turns out they didn't really know what their customers wanted exactly as they, they usually think they do. so they're not really open to being challenged often because they think they're coming to a company like leap or another one for the really technical expertise on how to build the software. And so, and that's what I said before they often come with too late so decisions have already been made, they have already thought about it internally and might they do some sort of requirement engineering. Yes, not really the the new way of doing things really testing you know beforehand with, it's easier to convince them about this new ways that you try. Yeah, every time. Yeah. Unknown 20:09 And you know it's it's it's it's really a tough process, I guess. Unknown 20:18 Could you describe me how the process look like. Unknown 20:21 So what we would like to do or what we finally end up doing finally a dumpling perhaps, so that's what you can talk afterwards what we would like to do in that. So typically, we start of it depends if we did in early, we can already do workshops where we discussed the vision, and you know, the vision can be really rough and it can end up just you know we have a workshop with a couple of brainstorming sessions where we formulate something like for this in that group, we would like to achieve this in that business goal, and therefore we will build a mobile app in our case, or maybe not, which should, and then you have some key points are really something really rough and and then, but that we don't do very often because that would be very rare. During brainstorming, which platform you want to call it web or mobile. Yeah, exactly. And maybe maybe the outcome could even be they want, they need to do a marketing advertisement campaign and exactly but all I mean that could correct, not necessarily enough in us having any word for the customer in the end. Right, that's okay. Unknown 21:29 And, but yeah, but mostly they come to us because they already sense they need, they need something so that doesn't happen very often, often the first point is, we will define personas. So the customer would come and would already have a you know a business case in mind or use case in mind. And so then we would define personas, and we would do that together with the customer who knows this customer better than we do of course, that we would love to do it. And then, yeah, exactly, but but we most of times, it's out of the imagination of the customer. Unknown 22:02 We then proceed to discuss and and elaborate the user journey. Unknown 22:07 And it does that talk to you or do you want me to explain a bit what I understand by user journey, maybe you can talk about it. So I have no idea. Okay, so I think every company does it exactly so so well, a clip you would we don't just suffer for, for you to understand we were self organized completely we don't have any management and. and so it might be that we, in my circle as we call it, do things differently than maybe here or. Unknown 22:37 But yeah, user journey well as we understand it is really the steps that the user has to take, for one of the use cases one of the business goals to achieve what the person one so let's say we have a web and e commerce or something and so we would imagine you know user journey like okay I can start but how do I find, you know the site and I'm googling it and stuff like that and I want to buy a pair of trousers or something like that and so imagine a complete scenario. Exactly. And the steps that you really have to take you and some point you have to decide but color at some point you have to, you know, decide about size at some point the price may be important, maybe the brand and stuff like that. So we reflect on those steps and we're that's not technical at all at that point that's really what the user needs to do. Maybe if it's if it's in a physical store or on the internet, and that's really what we focus on and then. Unknown 23:33 So we have a combination of the user story user journey with the persona, how do you record these things. So most of times we do it's on the wall somewhere with posted somebody writes on walls and stuff like that because we like to have really as less constraints as possible, to let the imagination flow. So that's where typically it's important that we meet with the customer and we have physical physically the customer. Here we are at the customer. Unknown 24:02 And then that's also something that's up to it because most times you end up with a wall full of post its and stuff like that and then you're taking picture. Or maybe you're put up some big paper sheets and you stick the poster so and then you have to road that stuff up and then you can imagine that it's hard to maintain, that's the problem, right, it's really a great way to to be free and express the ideas but then it's really hard to maintain that documentation. So that's a big problem we have, but that's the way we do it now, until you have that and then we would, of course this doesn't happen in one session of the all of this, because it would be too much. And then at some point we do as user story mapping. So that's when we start to reflect about okay for this in that step and they use journey, what features right into technical details. Yeah. Unknown 24:49 Not Not Not Not really, really yeah more design is exactly, but that's where the user stories pop up. So that's what I would describe okay the user needs to be able to this and that and then how do we facilitate to enable these activities. Unknown 25:06 And then it's it flows from there and and and at some point in the combination of the user journeys and user stories from the mapping where we also decide what's the you know the VP, and what is refinement, the UX designer would then make mockups and you know, maybe I clicked a clickable prototype if it's needed. Unknown 25:31 So we can quickly test the ideas, then we would test them. And again, that's where it would be really nice to have contact with a real end users. We don't. So, but I mean if it's if it's a to consumer app we can pick people you know we know and but the problem is we're Of course here all bias towards right technologically savvy person so that's not really representative but, you know, yes, it's better than nothing. Anyway, so we do your UX critique and we test those things out, and of course always in discussion with the customer. And then, and then we develop and also what's a bit hard is the Agile development, together with this UX process because that's quite a waterfall ish. Look at the whole process you try to think fits coherence, but then you want to develop magical way and not already be set on exactly what you're going to do so that's still a bit of a challenge, and we try to not go too far into details, and we usually have the UX designer working a sprint ahead of the development team. Unknown 26:33 So we do like small increments on the UX part as well. And then it's agile classical agile development, how many. Unknown 26:42 Let's say your customers, participate in these activities are in these courses. So, so it's mostly the product owner on the side of the customer and maybe somebody from marketing if that's the product owner himself or herself. And, and, eventually if the customer has a designer in house which is also involved in. So it's one, two or three people, not the problem is offered you have hidden stakeholders, which are really hard to get out of the woods, which then kind of influence the whole design, without having been in the workshops and that's that's problematic. Have you ever noticed that their customers, they face some challenges with this process. Unknown 27:25 But for the most of them it's really new to think of it that way and to use these tools. Unknown 27:31 So, but they often actually really appreciate it and they like it when they come out of it and they thank us for that and didn't expect all of that. So, it's mostly positive actually and but it's hard for them because they're not used to doing the US Open the time perspective demands more time. Yes, but that we tell them at the start right away that the way we work is going to be more time consuming for them then they would just put, you know, a list of features to develop and say come back in six months, but I think it's clear for them that it's not the way to go anymore, because they have no control they're worried about, if it's going to be good or not so. Right, but they know that from the start. How do you communicate with them. Unknown 28:16 As a digital music based, and you said you already like to be close to your customers. Yeah, exactly, as much as possible we like to, to meet in person in person but of course you will do that for a daily stand right. It depends on also how involved the customer is, some are really participated in everyday life, and some are not. So we use slack a lot of customers. Yeah. Okay, so we have them as external users in our slack most of the time so so they will integrate into an open because that's our main communication tool internally for direct messages slack. We have a high five that's a video conferencing solution which we use quite a lot. And that's quite a good one, really accessible to people who are don't have it. Unknown 29:02 And, yeah, that's the phone, of course but you see any challenges with communication. Unknown 29:09 Yeah. Unknown 29:11 It's well it's the language is one of them. Unknown 29:15 It's not necessarily we're often people are communicating in English and it's not the native language of any of the participants. Unknown 29:22 But why does it happen because you asked this. Yeah, well they have because we have the team and feeble we might still, even though we want to have proximity we might still work with dancing in Zurich which which are German speaking and those are not really so. Okay, so that's Switzerland you know we're all languages but nobody really speaks four languages. Unknown 29:41 So if any of us with customers you're talking in English. That's how does happen. Yeah, exactly. With love to talk to customers. Everybody, everybody and we actually we try to keep the way short, the balance to find his short communication ways so developers talking to the, to the customer for your directly, but still having the leap to involved so that he doesn't you know so that the information is not a symmetrical. So that's a bit of the challenge but mostly we want to keep the weight short. Even the developers, they are allowed to talk to customers. Yeah. Unknown 30:17 Do you think it's a positive thing it's, it has some negative aspects as well. I think it's 99% positive. Yeah, because I heard from the people that said, we like developers to really focus on their work and not get distracted by unnecessary communication, but you don't see any such know because that depends on what the customer wants to communicate and that's also a bit of a learning for the team, including the customer is included in the team. That's the way we work so the customer to is really part of the team. And, and when it's you know when it's technical stuff, or maybe minor changes in the requirements we used to do something that then there is no reason for the, for the customer to go by the. Unknown 31:09 Yeah, exactly. Because it just makes stuff hard, but when it's, you know, discussing priorities in the backlog and stuff like that the customer returned to me as a PO and not bother the, the depth. And, I mean, we really respect the sprint so we don't mess up the sprint one sprint to started the backlog is set and they sprint. Unknown 31:32 That's why it's called sprinting. Unknown 31:35 So that doesn't really, we don't really have that problem. And the positives are are overwhelming and the impact that I mean, who is responsible for doing user research and market research, is it true or is it the customer. Unknown 31:50 Well, responsible, that's a good question. Unknown 31:55 I mean user research, most of the times the customer doesn't have the skills to do that so it's most of the time it's us doing that so the UX designer, we're in, In collaboration with a product owner with Tony, that we, at some point we have actually done outsourcing, now that you talked about it before, for user testing you know really in a kind of a lab setting on an existing app or we wanted to figure out what's what's to be improved economically and stuff like that but you know, they found the dress pants and all that stuff. So there we used a company that was an aspect that just happened one time else we do the visibility. Unknown 32:38 It's a very specific point I mean, not necessarily the developers, you will have an understanding of the users, or how to do research in that area so yeah that's so that's why it's the UX designers to do that. So I maybe the term UX designer is encompassing more athlete than it is at other companies, I don't know, but UX designer is not only here for designing and user interface elements and things like that and then the design itself, they do that as well, of course, but they also work on on your end user research on on the vision and things like that. Unknown 33:13 So do you have in the end users of your apps are there globally distributed or limited duties with, you have to take care of it. I think. Unknown 33:26 No Sleeves with me. It's mostly Swiss I we have done a couple of apps which aren't necessarily limited to do this with market but it starts into this market. Unknown 33:41 The next question may not be no related or relevant for you, but how do you make assumptions about end users considering they are distributed. Unknown 33:51 I don't think it was a from Geneva would be different than a user from three. But, I don't know, but definitely a user from Japan in a different space user. Unknown 34:04 Yeah, we, as I said, we are our customers come to us mostly I have through sorry to think through the apps we've done here scanning through, but so my feeling is the customers we have had at least 10 come to us to build an international app let's call it that way right from the start. Mostly it's it's with folks like, I don't know if you know fantastic that's thing to for the bus tickets are you can you can just check game okay and attracts you and then it dies the correct. Unknown 34:35 So that's, they have the ambition of going international but they've started in Switzerland, so our customers were Swiss at that point, and they still are, or. Unknown 34:45 Yeah, urban connectors and things like that. Unknown 34:48 So we haven't we haven't been faced with a problem of the Japanese or the African collect user at this point in time in the challenges wouldn't be different in that case right yeah and assuming what are their preferences. Unknown 35:01 How do we do that, however, how would you end up doing that so that's why I say it may not be relevant at the moment. Yeah, exactly. That's why I probably can't really tell you I mean, but there will be some differences. Yeah, you would have to tackle. Exactly. Absolutely. And, and I guess we would try to really at that point say sorry we can't know, start as Swiss persons and start to imagine what the Japanese how he thinks and reacts we really did we I guess we would really really insist on having contacts and having really users involved, right at that point, I don't really see a way around. So, but that's HIPAA hypothetical. Unknown 35:42 Do you also collect non functional requirements from the clans. Yeah, not really in a formal way of course they expect performance they expect security. Unknown 35:51 But that's kind of a given. Unknown 35:54 Yeah. Do you think they have enough knowledge about these things or its smallest years. Yeah. Yeah, it's our that's, yeah, that's totally, I mean we come across some customers who initially come in they have really unrealistic expectations about non functional requirements, can it be an example. Well, like, you know, response times and so you have to build an app and it has to have one millisecond response time for every screen and things like that but it says server good client server and so then you have to explain to the customers needs to, there's just no way you can guarantee that, I mean there is but that's a whole other world. Yeah. And so yeah, it's mostly response times I guess where were they at some points are not realistic but that's rather an exception. Unknown 36:43 I think there's just an expectation you know as it's so it's such a part of our daily life these mobile apps. People just expect that they were like the other apps. Unknown 36:58 This is usually and this is more or less about experience so I mean the non functional requirements you don't have it so it's it's more or less it now subconscious thing that you do by experience, because you have done similar projects before and you know the loopholes, where certain things speed. Yeah, exactly. Unknown 37:17 You already said you're doing prototypes and MVP. So I want to know what is your impression about them, how do you do it will talk about both of them differently because I got mixed reactions about MVP. Unknown 37:30 But you do prototyping, how does it mean do you do paper prototypes, or he will do really pixel perfect mockups and so on. With a kid that can depend on the project but we I don't think we do pixel perfect prototypes that often. It's more it can be paper prototypes we've done that, where the problem of course is you have to you know manually simulate what's happening so that's bit of a hassle so it doesn't really scale when they want to test them and. Unknown 37:59 And we did most of times we do clickable prototypes with the invasion or Unknown 38:07 is it economical to build them. Does the customer pay for these things, or is they do pay often we don't really ask them if we should do that way we just do it like that and that's just, yeah, it's kind of imposed because I know the discussions, would be can be a bit hard. Unknown 38:26 But I think it's economical I'd say I'd say it's a good question. Is it really economical or should want to really go you know, old school agile and say no you develop and then you test to develop product and. And then you redevelop because mobile app native mobile app development as we do is quite expensive compared to do web development the way if you do a website or something it's much faster to, to bring out something than in a native app, where it's really yeah it's quite costly, every time you develop something so that's why we in this domain stick to to clickable prototypes, as first step to just validate ideas, and we wouldn't do it for you know for the whole thing we do it, where we see complexity in the usability. Unknown 39:14 Right. Unknown 39:16 About MVP. Do you do every piece. Yeah. What is the impression about them, are they, useful, are they, do they sell their purpose. Unknown 39:27 Yes, I think, Well, that depends on what do you mean by their purpose. So if the purpose. For me, the purpose of an MVP, is to minimize risk, very fast in the in the project. Unknown 39:42 So, you have, you really focus on going into and as fast as possible, or as quickly as soon as possible, so that you know that whatever happens in the worst case, you will have a product that fulfills the the intention of the product, you won't have something that's really nice from A to B but doesn't doesn't come to A to Zed. Unknown 40:05 So that's for me is the purpose is to is to really instill the mindset of agile development in the whole team including customer and and you add the definition of MVP can also vary a bit. What do you mean by minimum viable product, and then one should maybe talk about minimum marketable product that can be a variant of an MVP. Unknown 40:27 So, Nicholas I'll do some of the reactions which I bought some people said it depends where you release your MVP. Unknown 40:37 They said usually customers are very skeptical about me is because they see that the product is not done in, and they're very skeptical to release it for the users, because it gives the wrong impression of the product. Yeah. Unknown 40:51 But if you're releasing only for the beta users. Perhaps it is good. Yeah, that's me and that's absolutely true. They're very wary of the image that the outcome is because it's their brand image. So that's why they most of times they wouldn't release a really a really, you know, hard MVP to really stick to MTV as as as as you intend to, then it's probably not good enough for for public release because it's it's Minimum Viable in the sense of fulfilling the process, but it's not minimum viable, if you take into account all the other stuff, the branding the image and everything that's why sometimes talk about the minimum marketable product, which then adds a couple of those things which you could do without actually if you just want to do what the thing is intended to do, but which the company couldn't release with Alice, but and so one of the companies they said MVP is more of a startup thing. Unknown 41:47 It's cooling startups. For them, because they are in business for 10 years they say we don't do this anymore. Unknown 41:54 It just kills the spirit of the team, because you get kind of negative reactions from the customer okay. Unknown 42:05 No haven't had that and and and again it's, it's important to be able to use the product as soon as possible, because often that's where you find out Oh, we didn't think about this but in thinking about that during Requirements Engineering. And oh, there was a stair to climb, and I felt the car groups, you know, your other your other rather see there is a stair to climb have to build a skateboard then once you finish the cart. So it comes back to me for me it's an integral part of the Agile development, because it's often misunderstood, how that works. And what's the what's the benefits of doing so it sounds like you have prototypes. And you have entities, and you have the end product prototype prototypes will then become part of the system but Mbps will much more be the end systems, or they will evolve into the end systems. Right. Yeah. Unknown 43:01 I think that's already covered. So, could you give me a couple of examples which tools you use in general in the company for different purposes like communication you said slack Ok I will communications. Unknown 43:14 Then the typical, you know Scrum tools we have the attraction tools. So we're conference in JIRA. Yeah, we and we share the so for every customer and project we have a shared conference space. Okay. and are they comfortable using JIRA Confluence conference, not so much but JIRA JIRA. Yeah, but it's easy to get. Quickly messy because the end up opening lot of tickets or anything like that. No, actually not because we really have to have this pair of the leap to and the customer to working together. And now that doesn't really happen. Okay, because I heard it from couple of companies that their customers had access to JIRA and they just opened up and lots of tickets which are not relevant, or tact strongly and so on actually now because we really a company that customer and the learning of Scrum and agile development sitting and that's also really fun to do. Unknown 44:15 So, and one thing I really emphasize on it's not to pump the backlog because having a backlog is just unmanageable. So as I really that's one real strong focus I said, with the customers and keeping it needs. Unknown 44:29 And you also mentioned invasion for design, yeah invasion and settling for the innovation for the prototyping and Zeppelin for the, for the design, so that it can transfer to the developers in a good way. And then you can do it really well with, etc. And then we have our, our own homebrew tool, which is really central here at lips called the zebra but it sits for at the moment it's not open source where it will do that at some point. And that's ranging that's really extremely broad that's ranging from our internal peer reviews more salary determination to project budget management and all that stuff but that's in the in the custom projects we use that for tracking so we don't use the gyro sprint tracking, we have our own sprint tracking of it communicates with JIRA. And so it's it's it's completely integrated with the budget tracking awesome. Okay. Unknown 45:27 What tools do we use as well as that, because I think it's a good enough. Unknown 45:33 Um, do you collect privacy requirements or security requirements as well. What security requirements, not so much as what we do our most of the apps in the app store and stuff like that so that's not really an issue there. I mean security on the back end side is given, and we know we have to do you have any exports. Unknown 45:57 Well, the people doing back ends they already know. Yeah. Unknown 46:03 And but we have we have actually we have we have experts in the company which we can, we can draw on if we really need people who have expertise in many different domains before since security. Unknown 46:16 And what would they say privacy privacy privacy is something we on every kickoff we mentioned it. We remind the customer about the privacy, we have to think about it and even more now. Unknown 46:31 Dr. Yeah, it's, it's, yeah, I think it's gotten more prominent since GDPR and the funny thing is now customers are told me about it as if no Swiss slow would exist, prior to GDP. Unknown 46:43 And they only focus on GDPR that's interesting. Also, they don't care at all about the Swiss law. The only person GDPR now it's okay because GDPR is more stringent than this, we still at the moment but that might change. Unknown 46:56 But it mostly leads to just having you know a section with some legal documentation and things, how do you how do you handle these situations they go Do you have any legal experts within the company or the outside the legal work with the legal work is actually that's up to the customer to if they want to do, they're like terms and conditions and all that stuff and privacy statements and stuff like that, then that's, that's actually there there. Unknown 47:20 We have legal counsel here in them. Who is part time working as product owner and part time as legal is just the name of his role, but that's mostly regarding contracts. Unknown 47:34 So, we also observe, anything like the customer, wanting to sign a nondisclosure lot for out this way, this was very interesting for me so those guys listen. Unknown 47:51 Customers are kind of, sometimes they have this feeling of urgency, or they have this feeling that the company will steal their idea, the super awesome idea. Unknown 48:01 And the first thing they want to do is sign India. Unknown 48:05 Yeah, we'll have really both experiences we have exactly that blends with the consequences. They are not willing to give out the details. Yeah. So do you observe that happens and and well we're at the point we have signed the NDA we're required little assigning engage we don't really have a problem with it. So, if the customer wants to sign an NDA, and that's okay. But that really happens because he doesn't want to tell us like anything before we signed an NDA that's the most extreme that doesn't happen that's maybe that's maybe two or 5% of times, and then maybe 30% of times at some point they say they want an NDA. They tell us a bit about it and then they say so now would be the time to sign an NDA. Unknown 48:48 And then we have the opposites. Customers who really are really open and even if it's novel ideas, they openly talk with us about it and they don't care about India is so that that's the best case, you have yeah well actually I don't really have a problem with me. Because it's not the problem with India's itself not it's the fact that customers are not open to giving you important details, which are helpful for the government. Yeah. Actually Actually we, I don't know why but that kind of doesn't happen. Unknown 49:22 We really have a very transparent way of communicating with our customers and I guess that kind of reflects in the other way back, and they appreciate that we really try to understand their business center. First of all, before we do anything else. So, we haven't had that actually what what I'm aware about might be that we had and other parts of the company. Unknown 49:47 So now we'll try to see and discuss more about how mobile development is or is at all different and software development in general. Unknown 49:58 So do you think, are there any major differences between mobile development and software development. So you said one is, it's costly. Unknown 50:07 Well I mean if you develop a business Java for enterprise app then it's also costly, that's it's it's it's as much costly or even more than a native mobile app native mobile app is more costly to develop PR features you want them a JavaScript application web application. So it's somewhere in between but it's not more costly than any other customer application development. Unknown 50:37 So do you see any other differences. Unknown 50:41 Well the code base as I said is mostly smaller on the smaller side because you mostly don't want to have a mobile app which just thousands of different things mostly it's it's really specific for a couple of tasks. So that makes the code base, much smaller you don't have these millions of lines of code code basis in one. So that's the difference. So the code ownership is easier to to maintain and and also would be easy to transfer rates, that's not really something we do we try to keep the same teams on the same project so for many, many years. Unknown 51:19 And yeah, different in the sense of. Unknown 51:23 I'll also give you a couple of examples what I've heard. Unknown 51:26 The prototype itself is much more extensive because you have different platforms, which have different designs. Unknown 51:35 So you have to do the prototypes, if you're doing pixel for pixel perfect prototypes, it's double work. Yeah, that would be true but as I said we don't, you don't do the other thing is testing is quite much more extensive and mobile apps in the problem is you have to do it on real devices. And you have to test it on multiple devices. Also multiple operating systems. Unknown 51:58 So, and it has to be done manually, because there is not much automation. Yeah. So the testing itself is also quite extensive in case of mobile apps do. Yeah, that's true. Unknown 52:09 Other point which I heard is when it comes to web applications. Unknown 52:16 You can just deploy, any hot fixes, or any bug fixes multiple times a day with mobile apps, you're kind of limited by our stores because they have their own workflows they have their own checks. Yeah, that's too bad it's gotten easier and faster, the the main bottleneck that was actually the Apple store more than the Google Play store where you had you know sometimes that to wait for more than a week for an app to be to be rented released, but that's so true anymore since they don't do it only in Cupertino anymore they have outsourced to India. And Unknown 52:50 so that's true. And also, the thing is, with a web app you access the front end code you, you download basically the front end code every time you access it so it's much easier to roll out changes you could do that very, very often. Unknown 53:05 As if I would have to updates. If I don't have to do something manually, a mobile app, a couple of times a week, it would annoy me installed by some kind of funny reflex because I always see this app again that annoys me. Unknown 53:20 And also you have this problem of. Unknown 53:23 You might be out of sync between back end and mobile app, which is because the user did not install the update. Exactly. So that's a challenge, which you don't have on on the web app where you always are in sync actually. Unknown 53:38 Yeah, that's true. Do you think non functional requirements, play different roles in case of mobile apps and web apps, Unknown 53:50 play different roles i don't know i don't really think so well yeah I got funny reaction, I'm not sure. So people contracted with this also in the original opinion what he said is, when it comes to web applications, and if it is slow. Unknown 54:05 The user, usually ends up blaming the browser or a zoom, or whatever the connection. But when it comes to mobile apps things. It's the developers fault or the it's the app which is not performing well, that, that might be very true, I don't know, but it sounds it sounds sound very realistic, it sounds like I would, I might think that as well. Unknown 54:27 Even though I think. And, yeah, and also the, but I guess it comes from the expectations which have been set. So your mobile apps are mostly very wonder. Unknown 54:39 done well, they're very reactive and very quick and things like that. And, and in the web, you come from this other side where you it's actually always getting faster in the I don't know if you remember the beginnings, where you had to look at the pictures loading like this, right? So that's where we come from, on the web. And on the mobile apps, we come from, you know, snappy apps. So that's the expectation is a different one. And, and people think it's a program on their phone, and they don't really realize that there is back and communication going on. Yeah, so that is that, Unknown 55:08 but on the web, you know, it's that that's waiting. So I think that's kind of intuition. I think. So Unknown 55:17 do you think the solicitation process the gathering process and differs for mobile apps? 10 minutes? It might be not because of technological aspects, but because what they web app or website is most of times the things we do with the mobile apps is much more custom functional app developer. Unknown 55:39 Whereas what we do with the website, even if we do web apps, we don't only do like display web websites, displaying stuff, but also really interactive surface, it's still more standardized. It's still more, you know, having your content and maybe some functional aspects. But we don't build things like like the clash and tools would be a good counter example that legend tools or web apps. But actually, they're much more akin to mobile applications or any business application because they're really 100% functional. So the websites, areas of the websites, but we have websites which also have functionality, but it's not the dominant part of the website. And the website is mostly standardized, because you have the the information architecture is is is different one because, again, on a mobile app, you don't try to do enormous things with a lot of navigation, lot of information. That's probably not what you will have on the mobile app. Whereas on the web side, you will have lots more of that. Unknown 56:39 So I think that's why it differs a bit Unknown 56:46 what in your opinion are the biggest challenges with the gathering requirements for mobile apps? it I don't know, if it's for mobile apps, I think it's a general thing. It's, it's really getting access to the, to the end users. Exactly. And, Unknown 57:05 and really, really developing agile in an agile way that one should do, which means Unknown 57:11 really having the users given feedback on using the software Unknown 57:16 deal to see any patterns that the customers they focus on more sensitive about the design of the app, then Unknown 57:33 they maybe that's because of our image but I think they expect I mean when you said design Do you think Unknown 57:39 The looks and feels because I heard that they are really sensitive about these things they don't get really about functionality as such on the web or Unknown 57:50 innocence what they give you opinions Unknown 57:54 about design because what they see and that's what they can understand Unknown 57:59 agree on the dance extra even though that happens as well you know you have important things and you have something in the workflow which doesn't make sense and you want to discuss about that to the customer talks about the color of the button or something that does happen but it's not that's that's what predominant I think our customers there they managed to focus on Unknown 58:22 we talked about it briefly but as those who can play or Apple App Store they have their own checks for security they have go and check for Unknown 58:32 design Apple more than morning Vincent does it affect your gathering requirements. Unknown 58:39 Process Monitor. Unknown 58:42 So in essence, the question was something like this. So you're doing a giant, Unknown 58:48 the idea is that you are flexible to do for changes Unknown 58:53 because Unknown 58:55 at stores have certain policies. So you are careful volcanic certain requirements, why it doesn't have no, no, doesn't happen. It's more it's more than when when we engineer the solution or designed the solution, maybe at some points that we have to take that into consideration, but not where we gather requirements because they are familiar requirements, they really need to be decoupled from the from the solutions. Unknown 59:20 That's, you know, the typical thing is you you don't want to go to the users and asked him what do you need, and then you expect that they tell you about functionality, I mean, can be okay, but but most of times they they will come up with the optimal solution. And what we really need to understand is what what is the problem we try to solve for the user, that's what we want to know. Unknown 59:40 Any decisions you make, Unknown 59:42 do they depend on external factors such as Operating System version is external libraries, their versions Unknown 59:51 sometimes on operating system versions, because it's their requirement from the one non functional requirement from from a customer would be it has to be really backwards compatible on Android news really far, far back then that might impose some constraints please at least certain role while getting requirements Unknown 1:00:12 again, again, I don't think it's while gathering requirements. I think it's once you have the requirements and then you say okay, now how do we how do we respond to those requirements? That's when it plays out but not during the requirements gather customer they will say I want to support last three Morton Salt operating system or Oh, yeah, sure. He can say okay, well, maybe it's our definition of requirements gathering because I would think Unknown 1:00:39 about the process where He then said, Okay, what does the US want to do? What's his problem? What What do you want to sell the kid? What's the context? And how does it do it? And there, Unknown 1:00:50 that's not the point where the customer would tell us, but hey, think about the customer might might have an old Android version, that that sort of things only happens like on a general level for some reason, I think that it's important that that everybody can use the app. And then sometimes you have to give the numbers and say, hey, look, that's like 1% of the users to really think we need to put in all this effort to support Android for Unknown 1:01:18 my thing, which I forgot when we are talking about the differences. So do you see in mobile apps, it is much more prevalent that you cannot really forcing all the situations in which the app will be used because you have external factors such as network drugs and offline continue to different locations and so on. Unknown 1:01:40 While we're kind of we're kind of used to that sort this point has evolved through Expedia exactly had initially initially is true. Unknown 1:01:52 Do you ever consider troubles that might be faced by special users? such as old people? Yes. So do you make any conscious decision? Yeah. But it's, it's, it's it depending on the persona. So if we would identify that, well, discussing the main persona, yep. Then typically, we would add something in my, in my memories, I don't remember which app it was, but where, where it's addressed older people more than younger people. So the, you know, the size of the display and things like that would would match right. I also heard for this, it was quite surprising. So he said, it's a budgeting issue. Unknown 1:02:29 In the sense the customer knows that there will be 1% of the users with the old people and he doesn't want to be easy for these people 1% of his users. Unknown 1:02:39 extra money for designing Well, I mean, it's an economical choice. Unknown 1:02:47 They use very strange constraints, Unknown 1:02:50 such as Unknown 1:02:52 the number of methods you can have. So Android had this limit that you cannot have more than 60,000 minutes Unknown 1:02:59 your Unknown 1:03:00 website's continue get published as external continue for additional content. Unknown 1:03:07 Have you ever made any such constraints Unknown 1:03:11 that hasn't impacted our requirements engineering or design process at all? Have you made this constant cyclist that app was rejected by I will have to ask the developers and Unknown 1:03:26 so we are almost towards the end. Now this is not like some rapid fire questions. So I'll give you one keyword. You tell me if it is important for an app okay. Yeah, for consumption. Unknown 1:03:40 Yeah, yes, Unknown 1:03:43 I think you already said but different mobile devices and different operating systems you can display Unknown 1:03:50 third party libraries and their versions you use Yes. But less less less than the other two Unknown 1:04:00 mobile advertisements and revenue generation through them. You know, in other cases, not in the case was given for free apps. Yeah, great. Unknown 1:04:09 This was this was interesting because I interviewed one indian guy, they are providing services to us customers and so on. They said, for free apps that is very much important for the customers. But in Switzerland, I heard it from nobody, Unknown 1:04:22 nobody actually advertisements, I think annoying Unknown 1:04:26 and the business models work differently. Executives don't rely on Unknown 1:04:32 Oh, he was a feedback on app stores or any social media platforms. Unknown 1:04:40 Not enough if, if it plays a role, that's a question Unknown 1:04:47 user feedback on that source. Do you ever go and check? Yeah, sure. Because we're curious, you know, but But Unknown 1:04:54 how? Yeah, well, no. Okay. Let's say I mean, it plays a role when when suddenly you have a one star of somebody screaming out or the app doesn't work I'm on I'm skiing on the top of the mountain and doesn't work. Yeah, sure. It doesn't work. Unknown 1:05:08 You know, that's, that's when it gets important suddenly for the customer. But else I don't think it's such relevance. Unknown 1:05:16 And probably it's more relevant than once you you you have, you know, maybe an app with 100,000 or million users then apps that we have like were smaller user base because most of you don't have that much reviews and you know that first five or the or the team anyway, on the customer. Unknown 1:05:39 One thing which I missed before, do you do analytics as well as for the ads? Yeah. Not Not as much as we would like to. That's, again, something we talk to customers say, hey, it's important to build in analytics at the beginning. So we have the data and can make decisions based on and it's always dropping down in the backlog. They always prioritize, you know, functional stuff before, so we don't do as much as we'd like, but you, you have, I mean, the analytics of installations and all that stuff from the store. But then the internal analytics, like, how does the user use the app? We don't do as much as we would like to right. We would like to do much more of that. Unknown 1:06:18 I had some questions regarding that, but I forgot. Anyway, Unknown 1:06:22 last two questions. So I want to reflect you on these. So what are the implications about hybrid apps Unknown 1:06:28 we have with with abandons hybrid apps. Could you give me reasons right Unknown 1:06:36 quality of the products so I don't Unknown 1:06:39 I'll give you a had very interesting discussions about these things both opinion. Unknown 1:06:45 But you First tell me like, what are your thoughts? Well, as I said that if you really want to polish it up, then then you can't really Unknown 1:06:54 get that with a hybrid app as good as with native and hybrid apps might be a bit cheaper to develop. But that's an impression more than a reality. I think. Unknown 1:07:06 So often people come to us and say why we want to do a hybrid app, they have no technical expertise, but they they think they need to do that because it costs but it's not really always true. And another factor driving us is the skills of the team from it's much more important to that the development team uses the environment language tools, whatever they know, and that they're proficient in rather than somebody that the customers want to developing web applications. So Unknown 1:07:35 but the developers we have in the mobile teams Unknown 1:07:39 They are all developers with, you know, Java backgrounds and things like that. So they, and they like that environment. And they like, you know, the, the language is to be a bit more strict than, than JavaScript. They're not the JavaScript boys fanboys. And so, this hybrid of React Native or all those things are really good for people with web background, which one to step into mobile application development. But that's not the case of our developers. They come from the other side, they already like the district language and the and the tooling, the patterning is much better also for continuous integration. And, and the case of native native. Yeah, Unknown 1:08:24 so that's, it's the environment. It's the IDS Unknown 1:08:28 which are also preferred and the Polish you can get and I mean, less and less of the technical Unknown 1:08:39 possibilities would be an argument for for native apps, that was an argument for you, oh, you cannot do geolocation you can do this, you can do that. But as the browser's extend their capabilities to talk to the operating system that fades away more and more accurately. So. So it's it's sometimes hard to argue for the case of performance. One of the companies I interviewed. Unknown 1:09:05 Yeah, so they said they do exclusively the abundant native apps. And he said, performance, Unknown 1:09:14 it's just different. It's not necessarily worse. Unknown 1:09:18 And usually the discussion about performance is done by thing guys, end users are not most of the time sophisticated to notice differences. So how would you react to that Unknown 1:09:31 that's not our experience experts in performance is not necessarily You know, when when you have to load data from the server will that will be that won't be more performance with Unknown 1:09:39 data that it's really, you know, you click in the millisecond, the reactive ness of the interface Unknown 1:09:48 is better experience not the same with hybrid apps as with mobile native apps. And I mean, you're probably right, because I'm thinking of it right now, the developers, they see an app and there's Oh, that's a hybrid. And I couldn't tell, I wouldn't know hybrid, but they somehow see, oh, that's a hybrid app because they know some details that I don't know. But I think you might be right there. I don't notice it. Unknown 1:10:13 But it's an interesting point because we really have a different view on it because we see things differently than really the people on the street. He Unknown 1:10:22 other point was Unknown 1:10:26 the point was you already when you do web development, we are kind of open to use anything you want with it when it comes to mobile. And you're kind of limited by two guys which is Apple and Google so you're already kind of debate Unknown 1:10:39 On these two guys, the link hybrid means you add one more layer of dependency on some of the framework like ionic or Facebook react. So that plays a role that probably plays a role. And yeah, exactly. I mean maybe way if you want to use some SDK, which maybe maybe that's not available through those frameworks and things like that. So yeah, that's true. We also by the way, we sometimes do examiner and developments as well but also less now than we used to. And that's also the same problem you have one more constraint and you have a lag of not being able to use the newest of the new which would be a good point for native app is that as soon as a feature functionality or hardware feature is available, you can access it while these other tools I only can encode they need to catch up so they always lagging behind but how often do you really need the newest thing because Unknown 1:11:39 That awesome actually. Also, one thing is Unknown 1:11:43 it depends on the use cases. So if the app is just showing some information, it doesn't need any native features. But that would in that case, would it be economical and cheaper and practical to go for hybrid apps and stuff but really need an app? And that's more the question or can you have a reactive responsive websites which is really done well, that it really looks good. And my next question comes to what is your impression about progressive web apps but that's that's yet another thing I was saying. When I was saying Unknown 1:12:17 reactive reactive website website I mean really something that displays well on the mobile phone and if you're talking about your display information then do you really need and that that all and then progressive web apps with that might be interesting. And again, this is the promise you develop once it works everywhere, but that's not true at all. You have some Well, it's true. Unknown 1:12:39 It's true. But then when you practice it, you have to tweak endlessly, and you have to test an hour and then suddenly you've made changes and suddenly doesn't work on iOS anymore. And it's really a has left the moment that way does not get back. Sure. So it is not so much. No, I don't think it's it's exactly I think it's still immature and the games promise in terms of development time or nuts. Do you think in certain cases, it can be useful considering that you can very much bypass the app stores and their workflows? Yeah, even though I we don't have that much of problems with the app stores. So especially since Apple got foster that was actually the main problem at sometimes you have it it's not that problematic, you know, Google change some policy at some point. Sadly, we have a lot of apps where we, we had rejections because of the advertisement it was something and we actually we didn't use it but by default, it was activities you know. Unknown 1:13:39 Stuff like that. But you that's it quicker actually republishing. It's done. So Unknown 1:13:44 now I don't think that's a big issue. I don't think that's a big win for the for the Progressive Web Apps would you compare with progressive web apps with hybrid app? So would Unknown 1:13:58 for certain cases where you're going for hybrid apps, because it's not using my two features, and it's just information displaying all there was a newspaper, kind of Unknown 1:14:08 do a progressive web app, right? Yeah. So in that case, it is more practical to go with Unknown 1:14:14 it's probably even more practical to just have your website responding well, to to Unknown 1:14:20 to a mobile display, and then maybe, you know, putting in a link or something to put the I can Unknown 1:14:28 do that. I think the reason behind Unknown 1:14:31 not having a website is responsive is very less times I think users go to mobile browsers to open a website. Unknown 1:14:40 The owner just just not used to it, they just prefer an icon click on something different. But you can do that where the website Unknown 1:14:48 I mean, you can you can put an icon of any website you can have a URL link and as an icon on your homepage, it doesn't have to be a progressive web apps, how many people are aware of nobody knows that but you can that you can use JavaScript to to Unknown 1:15:03 to make a call for action on your websites. But you have to be have been on that website of course personally but the same is true with a progressive web so and the arguments about the web Unknown 1:15:15 stores you know it's marketing channel to be on the stores is I guess less and less true because it was true I was bring up the story The fourth one of the four first apps that ever came out for iOS was Unknown 1:15:29 a completely useless app you would see a pond from from above that was really nice looking and you could you could bother the fishes with your fingers in the water would react to it. Unknown 1:15:39 would get all messed up. But that was all it was doing. So it had no news. And the guys made a million dollars worth it. Because it costs I think, $1 to buy. And it was one of the four first app you could ever install on your phone, right? So then it was really a major advantage to be on the store. Now, you have millions and millions of apps. And you have the same problem as on the web. Discover is the problem now. So just being on the store is not an argument anymore for doing an app instead of having a website because you're completely lost in the store. So I have some statistics here, because you said back so Apple App Store or Google Play, they came into existence around 2007 in about 10 years. Around 2017, there were 2 million apps on App Store Yeah, Unknown 1:16:29 and the second figure was around 170 billion apps were downloaded from different platforms in the same year second figure seems a bit fishy Yeah, but the site Unknown 1:16:39 The triggers of constructing it is true. So you have already in 10 years you have billions of apps. And if you ask a common person on the street, how many apps do you have any will work, it wouldn't be accepted. 20. Yeah. So what happens to these buildings so that you have exactly the same problem. So before you become an icon on the home screen or This transcript was generated by https://otter.ai