Healthy mobile application growth

00:00 → 00:00

Hello!

00:00 → 00:03

Welcome to Merixstudio's webinar about healthy mobile

00:03 → 00:04

application growth.

00:04 → 00:07

I'm Aleksandra and I'll be your host today.

00:07 → 00:11

Joining me are Ayidin Guven and Jakub Kośla from Merixstudio.

00:11 → 00:11

Hi guys!

00:11 → 00:13

Hi! Hi!

00:13 → 00:17

Our goal for today is to guide you through the challenges,

00:17 → 00:20

risks and opportunities of scaling a mobile application

00:20 → 00:24

from a developer's and a designer's perspective.

00:24 → 00:27

But before we move on, I think it's time for introductions.

00:27 → 00:30

So guys, could you tell us a few words about who you are,

00:30 → 00:33

what you do and about your experience with mobile app

00:33 → 00:35

development and design in general?

00:35 → 00:37

Aydin, could you begin?

00:37 → 00:41

Sure. I'm a Senior Mobile Developer at Merixstudio.

00:42 → 00:44

Currently working with Flutter,

00:44 → 00:47

doing some cross platform mobile applications.

00:47 → 00:52

Prior to that, I worked on the back end as a back end software engineer.

00:52 → 00:55

Also did some team leading at some point.

00:57 → 01:00

Worked on various projects, big ones, small ones,

01:00 → 01:04

microservices, monolith apps, APIs, whole bunch of

01:04 → 01:06

different things.

01:07 → 01:10

Generally, I I work as a software developer for eight plus years,

01:10 → 01:14

five of it, almost five of it with Merixstudio.

01:14 → 01:15

Happy to be here.

01:15 → 01:18

Thank you. Kuba?

01:18 → 01:20

So I'm a Product Design Manager here at Merixstudio.

01:20 → 01:23

Prior to that I was a team leader and UI designer.

01:23 → 01:27

And before that I worked as a UX slash UI designer in

01:27 → 01:30

different companies before Merixstudio.

01:30 → 01:33

As a designer I worked for twelve plus years

01:34 → 01:38

on multiple different projects, most of them actually mobile

01:38 → 01:42

on different stages of development including scale up

01:42 → 01:44

which we will be focusing on today.

01:44 → 01:45

Thank you guys for the introductions.

01:45 → 01:47

I'm really excited to have you here.

01:47 → 01:50

Thank you for accepting my invitation.

01:50 → 01:54

As I said, today's topic are mobile scale challenges,

01:54 → 01:57

but before our audience faces them they need to build a

01:57 → 02:00

mobile application in the first place.

02:00 → 02:03

And for many this begins with an MVP that's functional yet

02:03 → 02:07

somehow truncated and there are numerous limitations be it in a

02:07 → 02:10

team count or budget and so on.

02:10 → 02:12

And with that being said, I'd like to first ask you,

02:12 → 02:15

do you think it's even possible to lay grounds for future

02:15 → 02:18

scalability from your point of view?

02:18 → 02:19

Sure.

02:19 → 02:21

So the process starts usually from design,

02:21 → 02:23

so maybe let's start from If

02:24 → 02:26

you want your mobile to be scalable in the future,

02:26 → 02:30

I think you should put in your priorities or or let's say

02:30 → 02:32

design principles two things.

02:32 → 02:35

It's consistency and modularity.

02:35 → 02:40

Consistency means that every element of the interface is

02:41 → 02:46

uniform and behaves and looks similarly across the app.

02:46 → 02:50

So that you create this sense of familiarity and control

02:50 → 02:51

for the user.

02:51 → 02:54

And because of that, they can feel

02:54 → 02:56

comfortable using the app, whatever they are doing,

02:56 → 02:57

wherever they are.

02:57 → 03:00

And the second thing is modularity,

03:00 → 03:03

which is based on the atomic design methodology.

03:03 → 03:05

It basically means that the app,

03:05 → 03:09

the screens are break into smaller pieces,

03:09 → 03:13

sections and modules or even atoms.

03:13 → 03:17

And because of having those bricks,

03:17 → 03:19

we can reuse them in the whole application.

03:19 → 03:21

We can add them, remove them with ease,

03:21 → 03:23

with little or no customization.

03:23 → 03:26

To accomplish that, we also work with documentations.

03:26 → 03:30

We create style guides, we work with design systems and so on.

03:30 → 03:32

But those I think we will be discussing a little bit later today.

03:32 → 03:33

Yeah.

03:33 → 03:36

Definitely, because there is so much to talk about in this case.

03:36 → 03:36

Yeah.

03:36 → 03:40

Maybe I can add a few few more things from the technical perspective.

03:40 → 03:43

Of course, we acknowledge that MEPs have a bunch of limitations about

03:43 → 03:48

time, budgets, human resources, nerves sometimes.

03:48 → 03:49

But as a developer,

03:49 → 03:53

you can of course put some kind of fundamental things into it,

03:53 → 03:57

like you can already start with the supporting multiple

03:57 → 04:00

languages, currencies, different time zones,

04:00 → 04:01

different time formats.

04:01 → 04:04

You can already include them in the system,

04:04 → 04:07

so you don't need to add them later after the MEP,

04:07 → 04:10

which can be quite a quite a headache.

04:10 → 04:11

Also,

04:12 → 04:15

I recommend having a mobile first approach whenever you

04:15 → 04:18

develop something or even design something.

04:18 → 04:22

So this is this is because mobile applications have bunch

04:22 → 04:25

of whole different set of limitations

04:25 → 04:29

and possibilities like different resources that you you use.

04:29 → 04:31

So you have to deal with different set

04:31 → 04:35

of problems in order to achieve this kind of mobile applications,

04:35 → 04:39

which is different than different than a simple website in this case.

04:40 → 04:43

So I recommend dealing with those problems in before you

04:43 → 04:47

you deal with, let's say before the MVP so that you will

04:47 → 04:51

save up valuable development time.

04:51 → 04:55

Also you can already more or less know what kind of

04:55 → 04:56

platforms you support.

04:56 → 04:59

Are you really planning to support mobile applications or

04:59 → 05:01

if you support which ones?

05:01 → 05:05

Are you supporting iOS and Android or vice versa?

05:05 → 05:09

Or are you supporting Linux apps or whatever you wanna support?

05:09 → 05:12

You have to decide in this first first phase.

05:12 → 05:15

That also leads to roadmap, basically having a roadmap.

05:15 → 05:20

So if you already have a more or less a roadmap and you

05:20 → 05:22

can base bunch of assumptions to it,

05:22 → 05:24

it's very useful for developers.

05:24 → 05:27

Also, I think for designers as well, it's very useful.

05:28 → 05:31

So that we can have more accurate assumptions.

05:31 → 05:32

We can use this as a guide.

05:32 → 05:36

We can craft better better systems right from the beginning.

05:36 → 05:38

And how about the tech backbone?

05:38 → 05:41

Because if you browse the scalability,

05:41 → 05:44

then you'll probably find loads of content about, you know,

05:44 → 05:48

bulletproof, tech stack, languages, libraries, and so on.

05:48 → 05:50

Is this really a thing from your perspective?

05:50 → 05:52

So about the technical backbone, of course,

05:52 → 05:54

in my opinion, it should come from after the design phase.

05:54 → 05:57

So you more or less know what kind of

05:57 → 06:01

tech stack or infrastructure you will need for this system.

06:01 → 06:05

Also, CICD pipelines and test plans according to what kind of tech

06:05 → 06:07

stack that you wanna have in this case.

06:08 → 06:11

Also, you can more or less decide what kind of third parties that

06:11 → 06:14

you wanna include or services you wanna include in your in

06:14 → 06:17

your system right at the beginning.

06:17 → 06:21

I recommend spending additional time in those in in in

06:21 → 06:26

this, make additional research in order to find a much better fit.

06:26 → 06:29

Because if you already have more or less a plan how the

06:29 → 06:33

system will develop over time and you find a

06:33 → 06:39

better fit in terms of in terms of tech stack or let's say third parties,

06:39 → 06:42

you will save a bunch of technical debt in this case in

06:42 → 06:44

the later periods of

06:45 → 06:46

this project.

06:47 → 06:49

Afterwards you go on with creating a navigation map,

06:49 → 06:53

you think about an architecture and maybe

06:53 → 06:58

add error reporting tools and that's that's pretty much how it works.

06:58 → 06:59

So that all makes sense.

06:59 → 07:03

I'm glad that you mentioned reporting tools because that's

07:03 → 07:06

also quite a crucial thing, right?

07:06 → 07:10

Starting tracking things that are going well and the

07:10 → 07:13

things that are not going so well and that you should focus

07:13 → 07:15

on in the later phases.

07:15 → 07:17

Could you tell us a bit more about these?

07:17 → 07:20

I mean, the ones that you enjoy using or maybe the ones that

07:20 → 07:24

our audience should use if they want to keep their mobile

07:24 → 07:26

application healthy?

07:26 → 07:31

In my opinion, it's gonna be wrong to recommend one brand or the other.

07:31 → 07:32

These tools are quite

07:33 → 07:35

they are quite different from each other and they offer

07:35 → 07:39

different services, different features and so on.

07:39 → 07:42

You just need to gather a list of needs

07:42 → 07:44

that you you you need

07:44 → 07:45

you need basically.

07:45 → 07:48

Gather your needs and check if those needs are matching

07:48 → 07:52

whatever this this error reporting tool is providing.

07:52 → 07:55

In my case, in my development journey,

07:55 → 07:57

used mainly two tools.

07:57 → 07:59

One is Sentry.

08:00 → 08:04

I used it for mainly for back end projects because of its

08:04 → 08:08

easiness to integrate, ability to manage

08:08 → 08:11

issues, manage your teams.

08:11 → 08:15

So if you work on multiple people development themes,

08:16 → 08:18

you can somehow manage this easily.

08:18 → 08:20

Otherwise, you don't know who takes care of what,

08:20 → 08:22

who is taking care of which bug, and so on.

08:22 → 08:24

So it gets kind of lost.

08:24 → 08:27

About mobile projects, I used Crushlytics,

08:27 → 08:29

is actually from Google.

08:29 → 08:32

And for mobile projects, because I'm a Flutter

08:32 → 08:36

developer, so I use Google services heavily including

08:36 → 08:37

Firebase.

08:37 → 08:41

And Crushlytics is basically a service of Firebase.

08:41 → 08:45

So it's very very easy to integrate because you more or less

08:46 → 08:50

heavily or almost all projects you use Firebase services.

08:50 → 08:51

And you just include one thing,

08:51 → 08:56

use also Crashlytics or cloud messaging, whatever you need.

08:56 → 08:58

And it's it's very

08:58 → 09:01

very, how to say, small small footprint.

09:01 → 09:05

It it gives a small footprint in your in your system.

09:05 → 09:08

And how about the design tools in this case?

09:08 → 09:12

I absolutely agree that you need to use analytics tools in

09:12 → 09:16

in your app if you want to adapt a product oriented approach.

09:16 → 09:20

It's crucial to introduce analytics from day one, basically.

09:20 → 09:22

And they give you a lot of insights,

09:22 → 09:25

not only about crashes and errors, like I didn't said,

09:25 → 09:28

but also the information about where the users basically

09:28 → 09:31

abandon the app, where are their issues,

09:31 → 09:33

what takes them too much time and so on.

09:33 → 09:37

So you can measure a lot of things that can basically be

09:37 → 09:41

base for your scale up or any other investment for that matter.

09:41 → 09:43

So look for the pain points, look for the blockers,

09:43 → 09:44

things like that.

09:44 → 09:45

But you know,

09:45 → 09:48

introduce those analytics as soon as possible so that you

09:48 → 09:53

can draw conclusions as soon as possible basically.

09:53 → 09:55

And not regret it later, right?

09:55 → 09:56

Exactly.

09:56 → 09:57

Yeah.

09:57 → 10:01

So say we follow your advice and we try to future proof the

10:01 → 10:03

mobile application.

10:03 → 10:07

I feel that jumping straight into the scale up phase sounds

10:07 → 10:11

almost too easy because from our experience we know

10:11 → 10:14

that most successful projects start with the thorough

10:14 → 10:19

discovery and the analysis of the SS state because this

10:19 → 10:22

gives us greater insight into what we're dealing with.

10:23 → 10:27

So from your perspective what things should we try to

10:27 → 10:32

analyse to make sure that we are ready for scale up?

10:32 → 10:34

So let's start with this.

10:34 → 10:38

If you want, before any scaling going straight away into investment

10:38 → 10:41

and so on, make sure that you have a good reason for it.

10:41 → 10:44

And I think the best way to

10:44 → 10:49

recognize the moment when you need to scale your app or to invest

10:50 → 10:52

any way is to listen to your users.

10:52 → 10:55

And you can do it both actively and passively.

10:55 → 10:58

By passively I mean just give them an option to send you a

10:58 → 11:02

feedback or see what are the reviews in App Store or on

11:02 → 11:03

Google Play, right?

11:03 → 11:07

But if you want to do it more actively then conduct user research.

11:07 → 11:10

And there are many techniques how you can do this,

11:10 → 11:15

but basically using those observation techniques and

11:15 → 11:17

feedback methodologies you can

11:18 → 11:21

gather the information, what are the, like we said before,

11:21 → 11:23

pain points or blockers or habits,

11:23 → 11:27

needs that they are driving the users, right?

11:27 → 11:31

And the type of the research you will conduct is based on

11:31 → 11:34

the type of the product you have, the budget, timeline,

11:34 → 11:35

target audience,

11:35 → 11:38

and even environment that they are using the app.

11:40 → 11:42

The other

11:42 → 11:47

tool that can bring you closer to the healthy scale up is UX audit.

11:47 → 11:49

That helps you to

11:49 → 11:53

avoid legacy issues before introducing new features,

11:53 → 11:58

helps you to find out what are the quick wins and

11:58 → 12:01

even chip improvements that you can do for your app.

12:01 → 12:05

What's cool about UX Audit is that it's not necessarily

12:05 → 12:09

expensive process, so it's cheap to conduct and can give

12:09 → 12:12

you a lot of good insights what to do next.

12:12 → 12:13

Okay.

12:13 → 12:16

Maybe I can also add a few things to it.

12:16 → 12:20

Once basically everybody wants their product to grow and scale up.

12:20 → 12:22

That's quite natural.

12:22 → 12:25

But from the developer's perspective, you

12:26 → 12:29

also need to pay attention what kind of what kind of technical

12:29 → 12:32

problems you will be facing during this process.

12:33 → 12:36

So you need to also gather some data about what what can

12:36 → 12:39

potentially happen in the background in the system.

12:39 → 12:41

So how do you gather this information is also very

12:41 → 12:45

similar to these analytic tools or UX audit.

12:45 → 12:50

It's just on the code or on the on the internal part.

12:50 → 12:52

So you gather data from analytics and other reporting

12:52 → 12:54

tools like existing issues.

12:54 → 12:58

You check the backlog for existing bugs that you just

12:58 → 12:59

didn't resolve.

13:00 → 13:03

You can also take care take a look at the user reviews in the

13:03 → 13:07

market or that things you get from the

13:07 → 13:10

support to the support emails.

13:11 → 13:15

Also, you can conduct some kind of code audit for the existing

13:15 → 13:18

status of the application or the API.

13:19 → 13:23

Just to understand where are we right now and what

13:23 → 13:25

will be the cost of building on this.

13:25 → 13:28

And once you collect all these points, all these tasks,

13:28 → 13:32

just categorize them, you can prioritize them, sort them,

13:32 → 13:34

and take some action, like what are we fixing,

13:34 → 13:37

what's the cost of fixing them in order to healthily

13:37 → 13:40

move move on with the with the with the project.

13:40 → 13:41

Okay.

13:41 → 13:43

So from what you're saying,

13:43 → 13:46

I guess that the key takeaway would be that it's never a one

13:46 → 13:47

size fits all.

13:47 → 13:49

And it's you have many options,

13:49 → 13:52

so you need to pick them carefully.

13:53 → 13:54

It's true.

13:54 → 13:58

I mean, it's usually not like business decides something and

13:58 → 14:00

it just right away pops magically appears.

14:00 → 14:02

No. There are a bunch of people working on it.

14:02 → 14:08

Not only business decision is is is is not the only

14:08 → 14:10

deciding factor here.

14:11 → 14:14

And you also need to listen to cooks in this case,

14:14 → 14:18

and they are they are doing this food for you.

14:18 → 14:23

Actually, both of you mentioned one thing, that's reviews,

14:23 → 14:26

and I want us to discuss it in a bit more detail because I

14:26 → 14:30

feel that it's also quite an affordable and accessible

14:30 → 14:31

source of feedback.

14:32 → 14:34

From my own experience I can tell you that's how I spill my

14:34 → 14:38

guts if I dislike something about any kind of solution.

14:38 → 14:40

So what do you think about those?

14:40 → 14:43

So in practice, a lot of reviews are actually not that

14:43 → 14:47

valuable as we would like to them to be because of the

14:47 → 14:52

plague of fake reviews and also the fact that we tend to give

14:53 → 14:54

extremes.

14:54 → 14:54

Yeah.

14:54 → 14:58

Your rate is very low or very high and you rarely land in the middle.

14:58 → 15:02

That said, like you said, it's something that is affordable.

15:02 → 15:03

It's also passive,

15:03 → 15:05

so you don't have to do anything to just review not You

15:05 → 15:06

have to review them.

15:06 → 15:10

Right? But it takes a little or no time.

15:10 → 15:12

And analyze those because people

15:12 → 15:17

sometimes do give some sort of feedback,

15:17 → 15:20

interesting ideas or even just report it back in the app.

15:20 → 15:22

And this is still a user voice.

15:22 → 15:25

So you should hear it, you should consider it,

15:25 → 15:26

and if you see a pattern,

15:26 → 15:29

then absolutely it's worth to explore it.

15:29 → 15:30

I agree on that.

15:30 → 15:32

I mean, market reviews are

15:32 → 15:36

for sure relative like their user usually users' opinion.

15:36 → 15:41

So approach it with a grain of salt with a cold glass of water.

15:41 → 15:44

But these are just let's say,

15:44 → 15:46

are complementary to what you already gathered from analytics

15:46 → 15:48

and error reporting tools.

15:48 → 15:50

So it shouldn't be the only thing you rely on,

15:52 → 15:56

There is one more thing I need to ask you about before we move on.

15:56 → 16:00

And I think you saw that coming, and that's tech debt.

16:00 → 16:04

During our modernisation lives so many people told me

16:04 → 16:08

that it's scary, it's frustrating and it can

16:08 → 16:11

be very dangerous to the project.

16:11 → 16:15

So what's its role in the mobile scale up?

16:15 → 16:17

What's its place in the whole landscape?

16:20 → 16:21

A small metaphor here.

16:21 → 16:24

For me technical depth is like vegetables in your plate that

16:24 → 16:29

your parents tell you to eat and you avoid them until the last moment.

16:30 → 16:33

Please don't be that kiddo and just

16:34 → 16:36

deal with this technical debt early on.

16:36 → 16:39

Because building anything on top of a technical debt will

16:39 → 16:41

only aggravate the existing issues.

16:42 → 16:46

That means it will get harder and harder to fix,

16:46 → 16:47

maintain the codes,

16:47 → 16:50

bunch of people will not know how the system really works,

16:50 → 16:51

so they will find workarounds.

16:51 → 16:56

So it will get quite messy in a very very short time.

16:56 → 17:01

That means your system will get will attract fewer and fewer users.

17:01 → 17:04

That means less revenue for you.

17:05 → 17:07

But in in in general, it's a business decision.

17:07 → 17:12

I mean, we developers do not really we don't really have a saying in that.

17:12 → 17:16

So we are really relying on what a client or in this case

17:16 → 17:19

project a product owner will say.

17:19 → 17:22

If they say that, nope, we are carrying on with the plan,

17:22 → 17:25

no bug fixing, no refactoring,

17:25 → 17:28

This is basically on their heads,

17:28 → 17:32

not not not their responsibility and they are to

17:32 → 17:34

blame not the developer in this case.

17:34 → 17:34

Yeah.

17:34 → 17:38

I mean, what else can you do if you are not told to to deal with it.

17:38 → 17:38

Right?

17:38 → 17:42

Just they have to remember that once you carry on with that the

17:42 → 17:46

severity of the future problems will be much much much worse.

17:46 → 17:47

Yep. True.

17:47 → 17:51

So that's a good tip to remember

17:51 → 17:53

when dealing with a mobile scale up.

17:53 → 17:57

Okay, I think we've done with the preparation and we can move on

17:57 → 17:59

to the very core of our webinar,

17:59 → 18:02

so with these mobile scale up challenges.

18:02 → 18:05

And I'd like us to discuss three areas:

18:05 → 18:07

one that will be product growth two,

18:07 → 18:10

performance and stability and three,

18:10 → 18:12

mindset and team related stuff.

18:12 → 18:16

Maybe let's tackle them one by one starting with

18:16 → 18:18

product growth.

18:18 → 18:22

And my first question actually would be kind of simple but maybe tricky.

18:23 → 18:27

So what do you understand as healthy product growth?

18:27 → 18:30

After all I feel that it's a big term and it can mean

18:30 → 18:32

different things to different people.

18:32 → 18:35

So I'm curious what's your take on this?

18:36 → 18:40

So maybe let's start with distinguishing which growth we

18:40 → 18:41

are interested in.

18:41 → 18:44

So we know there's vertical growth and horizontal growth.

18:44 → 18:48

The vertical growth means that you take your service

18:48 → 18:53

and scale it in the line of business that you are in right now.

18:53 → 18:56

So the example could be for example Netflix, right?

18:56 → 18:59

They started as a streaming service but at one point they

18:59 → 19:02

entered the production business and started

19:02 → 19:04

creating their own content.

19:04 → 19:08

And horizontal growth on the other hand means that you scale

19:08 → 19:11

into different markets, new markets.

19:11 → 19:13

So another example for Netflix,

19:13 → 19:16

they started in few countries and then grew to one hundred

19:16 → 19:19

fifty countries I think in two thousand sixteen or something like that.

19:19 → 19:22

And the vertical growth is actually more traditional way

19:22 → 19:26

for startups to grow and we see it more often.

19:27 → 19:28

Okay.

19:29 → 19:30

From the project perspective,

19:31 → 19:35

I agree with Kuba and on the code you will see that if

19:35 → 19:39

it's about horizontal growth, will see that

19:39 → 19:42

system will support new users,

19:42 → 19:45

more more like higher amount of users,

19:46 → 19:47

as well as different currencies,

19:47 → 19:52

different languages, new time zones, maybe

19:52 → 19:57

maybe new regions that your application is available to download.

19:57 → 19:59

But if it's about vertical growth,

19:59 → 20:03

it's more of a new feature that you add to the system.

20:03 → 20:05

For example, new payment method that you support.

20:05 → 20:09

You pay for example, add Google Pay or different

20:09 → 20:14

different payment gateway that's that enables users to actually

20:15 → 20:19

attach new ways of paying your system.

20:19 → 20:23

So let's focus on the one that you've just discussed on

20:23 → 20:25

vertical growth.

20:25 → 20:29

So it's it's not really a rule that more features mean

20:29 → 20:31

more troubles.

20:32 → 20:33

However, it can be so,

20:33 → 20:36

especially from the usability standpoint.

20:36 → 20:40

Right? Why is that? What can go wrong with adding new features?

20:40 → 20:43

So, first of all, history knows

20:43 → 20:46

many apps and services that basically got out of hand in

20:46 → 20:49

terms of what is a good and healthy grow.

20:49 → 20:49

Right?

20:49 → 20:50

Yeah.

20:50 → 20:51

And we all know Facebook.

20:51 → 20:55

This is a great example of a service that started very simple.

20:55 → 20:58

The idea was to put new connections and help people with that.

20:58 → 21:01

Now it's this huge over complicated service that

21:01 → 21:04

actually people are avoiding right now,

21:04 → 21:06

trying to avoid at least.

21:06 → 21:09

This increase of product requirements

21:09 → 21:13

beyond original ones is known as feature creep.

21:13 → 21:17

And it's something that we see all over the place and we

21:17 → 21:21

see that it actually can be very expensive for the business.

21:21 → 21:26

And I love the Uber case study that they shared a couple years ago.

21:26 → 21:30

Basically, they start as a transport service

21:30 → 21:34

operating in growing sharing economy industry.

21:35 → 21:38

But at one point they grew to such extent that the

21:38 → 21:42

map that you use in the app as a main feature was barely

21:42 → 21:45

visible underneath the multitude of features and

21:45 → 21:47

additional informations.

21:47 → 21:51

And the management of Uber saw the risks of staying

21:51 → 21:55

that way and decided that it need to change.

21:55 → 21:59

Their design team come up with the new look based on a

21:59 → 22:03

custom design system that they created for the Uber brand.

22:03 → 22:06

And their development team as a result had to basically create

22:06 → 22:07

the whole product from scratch.

22:07 → 22:08

So

22:09 → 22:12

I imagine it wasn't It was quite stressful for them.

22:12 → 22:13

You must have.

22:13 → 22:13

But, yeah.

22:13 → 22:17

And I think that what we see right now in Uber is that they

22:17 → 22:18

still are growing.

22:18 → 22:18

Right?

22:18 → 22:22

They have introducing us the new features like package

22:22 → 22:24

delivery or food delivery.

22:24 → 22:25

Right?

22:25 → 22:28

But they scale right now in more controlled manner,

22:28 → 22:29

I think.

22:29 → 22:33

And the lesson from here is that you

22:33 → 22:36

should focus on some sort of simplicity and your core of

22:36 → 22:40

your business and be sure that every new feature that you

22:40 → 22:43

introduce to your users is absolutely necessary and that

22:43 → 22:47

there's a value for them and not just something that can

22:47 → 22:50

bring your revenue about one percent or something like that.

22:50 → 22:51

Right?

22:52 → 22:54

Users, like one one was fault.

22:54 → 22:56

Users, if they have a choice,

22:56 → 23:01

would go towards the apps that give you a better user experience.

23:01 → 23:04

And this is something that we see all over the market,

23:04 → 23:06

so bear that in mind.

23:06 → 23:07

Yeah.

23:07 → 23:10

So even if it seems quite counterintuitive, right,

23:10 → 23:12

because the stakeholders want to pack the app with Yeah.

23:12 → 23:15

More and more features, thinking that it will make them

23:15 → 23:18

more competitive and it actually may backfire.

23:18 → 23:19

Exactly.

23:19 → 23:20

Yeah.

23:20 → 23:23

How does it relate to to road map?

23:23 → 23:24

Because you mentioned it at the beginning,

23:24 → 23:28

and I suppose that you shouldn't really stick too close to it.

23:28 → 23:29

Right?

23:30 → 23:32

Technically, no.

23:32 → 23:35

Because the road map is just a prognosis of what can happen

23:35 → 23:39

or what your application will become eventually.

23:39 → 23:44

But it's so so attractive to drop a new feature so

23:44 → 23:46

that your users will enjoy it and then you will get more

23:46 → 23:48

users and revenue etcetera.

23:48 → 23:50

It's quite natural to think about it.

23:50 → 23:51

But

23:52 → 23:55

it's not so easy as as it looks as we talk right now

23:55 → 23:58

because developers or designers base a bunch of

23:58 → 24:00

things, a bunch of their assumptions,

24:00 → 24:02

like basing on that roadmap.

24:02 → 24:05

So even though it's not set in stone,

24:05 → 24:08

any kind of change will have cost.

24:08 → 24:10

So that means

24:11 → 24:13

whenever you develop as a software software engineer,

24:13 → 24:16

whenever you develop a certain part of the application,

24:16 → 24:19

you you need to find the balance.

24:19 → 24:22

Is this architect architecture or or should this

24:22 → 24:26

block be flexible enough for specific future growth or

24:26 → 24:29

should be quite minimal only for that specific purpose?

24:29 → 24:32

Like you have to find a middle middle ground for that so that

24:32 → 24:35

you won't exceed the development time.

24:35 → 24:38

And if a roadmap keeps changing,

24:39 → 24:41

which does which does change,

24:42 → 24:46

it brings additional cost but client or in this case product

24:46 → 24:51

owner should be very well aware of that additional cost that it will bring.

24:51 → 24:55

And it should it should it should be accepted as a as a

24:55 → 24:56

potential cost.

24:56 → 24:57

Yeah.

24:57 → 25:00

Like that's an essential thing to bear in mind With any

25:00 → 25:01

software project, I guess.

25:01 → 25:02

Yeah.

25:03 → 25:08

So I get the feeling that there are quite a few things that can go wrong.

25:08 → 25:11

For example, the thing that you mentioned that stakeholders are not that

25:11 → 25:14

flexible as we would like them to be.

25:14 → 25:17

So what can we do to ensure that our mobile application as

25:17 → 25:21

it grows is going in the right direction and that we are not

25:21 → 25:24

really gilding the lily with unnecessary features?

25:24 → 25:25

So

25:26 → 25:28

back to the user research.

25:28 → 25:29

Take

25:30 → 25:32

a closer look where are you at now,

25:32 → 25:36

what is the state of things, how people are,

25:36 → 25:38

how your users are seeing your product,

25:38 → 25:41

where is it right now and so on.

25:41 → 25:44

Do the research to find their habits, their needs,

25:44 → 25:47

and what they actually like in your app so that you don't

25:47 → 25:52

change it and you lose the core thing that actually keep them in your service.

25:52 → 25:53

Right?

25:53 → 25:57

Before you add any new feature, feature plan,

25:57 → 26:01

how and when you will test it with the users,

26:01 → 26:04

there are multiple of different research techniques like

26:05 → 26:07

surveys, field studies, focus groups.

26:07 → 26:12

So many to choose from that you can actually find one

26:12 → 26:14

that is more suitable for your needs, your budget,

26:14 → 26:16

for your timeline.

26:16 → 26:19

And if you can't go with

26:20 → 26:23

tests with users, go with the desk research instead.

26:23 → 26:27

So go through the industry reports and do your

26:27 → 26:29

competition analysis

26:30 → 26:33

and see what are the new mobile solutions.

26:33 → 26:37

All of those can give you a lot of insights to what to do next

26:37 → 26:41

and where to go with your product.

26:41 → 26:44

And when you gather all of this data,

26:45 → 26:50

work smart with it because prioritizing work into a

26:50 → 26:52

road map can be a daunting job.

26:52 → 26:56

And fortunately, there are multiple techniques,

26:56 → 27:01

including Moscow or EIC model that can help you to decide

27:01 → 27:04

on what you should focus on first.

27:05 → 27:08

Okay. Maybe I can also add a few things.

27:08 → 27:11

Like, even though this is a question for management

27:12 → 27:15

There are also a few things that developers may realize over time.

27:15 → 27:17

Like,

27:17 → 27:21

they may even tell you tell to the executives.

27:21 → 27:25

Like, if you start spending more time on per task in

27:25 → 27:27

order to achieve that task,

27:28 → 27:31

most likely you you are having some kind of a technical debt

27:31 → 27:33

and it's much harder for you to

27:34 → 27:37

produce a value with a given time.

27:37 → 27:39

Also, you will over time,

27:39 → 27:42

you will see that frequency of updates may may get lower,

27:42 → 27:44

may may reduce.

27:44 → 27:47

That also means that you are producing

27:47 → 27:50

less value over a given time.

27:51 → 27:54

Also, things can be picked up in regression tests

27:54 → 27:57

that in order to fix one problem,

27:57 → 28:01

you therefore break another thing in the system.

28:01 → 28:05

These things can be caught up in the in the regression tests.

28:05 → 28:09

Also, as a developer, stereotypical developer,

28:09 → 28:12

you will realize then the amount of coffee you drink per day.

28:12 → 28:16

I personally try to drink one cup of coffee every morning,

28:16 → 28:20

but sometimes it gets stressful and annoying that I switch

28:20 → 28:22

to two or three cups a day,

28:22 → 28:25

which is an indication for me that things are not going so well.

28:25 → 28:28

Yes, a normal amount. Okay.

28:30 → 28:32

The coffee. This brings me to performance.

28:32 → 28:36

I think that it's quite a nice transition.

28:36 → 28:40

So the issues with performance and stability can occur at any

28:40 → 28:41

stage of the product life cycle.

28:41 → 28:44

But if you are a scale up business,

28:44 → 28:48

then you have definitely much to lose.

28:48 → 28:50

Definitely more than if you are a start up.

28:50 → 28:53

So my question will be what performance issues are

28:53 → 28:57

most common during the mobile scale up phase?

28:57 → 29:00

And what do these stem from?

29:00 → 29:05

Maybe I'll start from backwards From the from the reasons.

29:05 → 29:10

As your project grows and becomes huge in terms

29:10 → 29:11

of, let's say,

29:12 → 29:16

description, that means there are too many things that can go wrong.

29:16 → 29:20

That means there are too many things to process and display to the user.

29:20 → 29:24

That exponentially increases the edge cases for you to deal with.

29:26 → 29:29

If especially if your system has payment methods and deals

29:29 → 29:31

with, let's say, different APIs,

29:31 → 29:33

different third party integrations,

29:33 → 29:35

a lot of things can go wrong.

29:36 → 29:39

Included with the lack of documentation,

29:39 → 29:42

because if you in a fast paced develop something,

29:42 → 29:45

you probably don't have much time to document documentate

29:45 → 29:49

everything that you do and system does in in this case.

29:51 → 29:53

That also can be

29:54 → 29:56

aggravated with additional dependencies.

29:56 → 29:59

The more dependency you have in the system,

29:59 → 30:04

less scalable it will get in my experience because then

30:04 → 30:08

as a whole scaling up as a whole with together with the

30:08 → 30:11

dependencies will be harder because all

30:11 → 30:15

dependencies, previous ones may not support certain behavior,

30:16 → 30:18

may not support certain I don't know.

30:18 → 30:22

Even regions, different different different

30:22 → 30:24

different specific cases.

30:24 → 30:26

Like a lot of things can go wrong.

30:26 → 30:28

So you have to like I said in the beginning,

30:28 → 30:31

you have to pay special care what you're including in the

30:31 → 30:35

system to make sure it's scalable enough and frequently

30:35 → 30:39

updated and actual.

30:39 → 30:42

And all these things are basically

30:43 → 30:46

like under the hood of rushed development.

30:46 → 30:49

So if you're rushing it, a lot of things are going wrong.

30:49 → 30:52

So with the time pressure you include a lot of bad practices.

30:52 → 30:54

A lot of people does it.

30:54 → 30:58

I'm I'm not gonna say that we all work quite meticulously.

30:58 → 31:00

If you're under pressure, you make mistakes.

31:00 → 31:02

Yeah. That's just the way it goes. Right?

31:02 → 31:03

Yeah. Exactly.

31:03 → 31:07

And all these things basically most commonly lead to

31:08 → 31:11

length lengthy contents that you your application basically

31:11 → 31:12

load each time.

31:12 → 31:16

That means starting an application takes much longer.

31:18 → 31:20

Things that you scroll easily in the previous update,

31:20 → 31:24

this time you wait one or two seconds in order for it to show

31:24 → 31:28

something or your application is taking much more resource,

31:28 → 31:32

much more disk space or consuming a lot of CPU power,

31:32 → 31:35

these things can happen because you process more data.

31:35 → 31:38

These are the most common things that I observe in the in

31:38 → 31:40

this kind of apps.

31:40 → 31:43

And then users get frustrated and there are more bad reviews

31:43 → 31:46

and It's like a spiral basically.

31:46 → 31:49

Yeah. And a never ending story about performance. Yeah.

31:49 → 31:53

So performance issues should not be left unattended.

31:53 → 31:54

Period.

31:55 → 31:59

But I guess there might be still some skeptics among our audience.

31:59 → 32:02

But I believe there is at least one thing that will convince

32:02 → 32:06

them it's worth taking care of the stability issues,

32:06 → 32:08

and that's money and hard data Yeah.

32:08 → 32:09

On its loss.

32:09 → 32:12

Yeah. So exactly.

32:12 → 32:16

So now we go to the usability actually.

32:16 → 32:19

Because the bad experience can damage your business a lot.

32:19 → 32:19

Right?

32:19 → 32:22

You can create an app that is able to handle even one million

32:22 → 32:25

users, but if you if you sacrifice the

32:25 → 32:28

experience, it won't be enough to to succeed.

32:28 → 32:29

Right?

32:29 → 32:33

Because it's very hard to get users in the mobile

32:33 → 32:36

industry and it's very easy to lose them altogether.

32:37 → 32:42

First of all, the competition is huge and like popular apps rise and fall

32:42 → 32:46

in a heartbeat and we just see one name that is very popular right now.

32:46 → 32:47

Tomorrow, everyone will forget about it.

32:47 → 32:53

And those statistics were were harsh, are harsh.

32:53 → 32:54

That's true.

32:54 → 32:58

Ninety nine percent of consumer apps actually fail on the market.

32:58 → 33:02

And I think only seven percent live longer than three months.

33:02 → 33:03

So

33:04 → 33:08

Basically, you need to be sure that you prioritize your

33:08 → 33:13

user and the quality to succeed in this hard environment.

33:13 → 33:17

And it's because users are basically unforgiving.

33:17 → 33:21

I think more than fifty percent claim that they won't give you

33:21 → 33:24

another chance if they meet with bad experience in your app.

33:24 → 33:29

So they remember the brand and they just won't trust you anymore.

33:29 → 33:32

So can't stress it enough, prioritize quality,

33:32 → 33:37

prioritize your users and make sure that you create something

33:37 → 33:40

that is important for them and works well.

33:40 → 33:42

So there will be no second chance in the mobile world?

33:42 → 33:43

Probably no.

33:44 → 33:45

Okay.

33:45 → 33:50

All these numbers sound may sound quite scary, I guess.

33:50 → 33:54

So what can we do to ensure that the performance and

33:54 → 33:56

stability issues

33:57 → 34:01

do not harm our mobile application as it grows.

34:01 → 34:05

I know that I already asked you about the things that we can do

34:05 → 34:08

at the launch stage when the app is still small,

34:08 → 34:12

but I guess there are some measures and steps that we can

34:12 → 34:14

take at the scale up stage as well.

34:14 → 34:16

So it starts with a good design, of course,

34:16 → 34:19

with major process during the design phase.

34:19 → 34:23

So if you create a design with performance and scalability in

34:23 → 34:26

mind, that means that you create not only the designs,

34:26 → 34:28

but also the good documentation for it.

34:28 → 34:31

So let's say you create a style guide, change log,

34:31 → 34:32

or even a design system.

34:32 → 34:36

Style guide is basically this living organism that you create

34:36 → 34:39

alongside the designs that contains all of the components

34:39 → 34:43

and atoms for little from little things like icons to

34:43 → 34:46

huge ones like layout tables and so on.

34:46 → 34:49

And that lets developers to stay consistent

34:49 → 34:53

to standardize code to make it tidy and quick to load.

34:53 → 34:54

Also

34:55 → 34:58

creating those repetitive components, optimizing styles

34:58 → 35:00

and using

35:01 → 35:05

native assets will let you to that will

35:05 → 35:08

positively influence your performance of the app.

35:08 → 35:10

And regarding the design system,

35:11 → 35:14

apart from having the guidelines for the visuals,

35:14 → 35:17

it also contains components libraries,

35:17 → 35:20

which is basically a reusable code for the developers.

35:20 → 35:23

So that also brings the app closer to

35:23 → 35:26

consistency and better performance.

35:26 → 35:29

That being said, and I think it's worth to mention here,

35:29 → 35:34

creating a custom design system for your app is a

35:34 → 35:37

quite expensive thing, but you don't have to do it.

35:37 → 35:38

Fortunately, almost never.

35:38 → 35:39

It's

35:39 → 35:41

For the bigger players.

35:41 → 35:46

And there are multitude of multiple of open source solutions.

35:46 → 35:49

For example, material design, is based on Flutter libraries.

35:49 → 35:54

So you don't have to spend a lot of money to basically stay consistent.

35:54 → 35:56

That's definitely good news. Yeah. Okay.

35:56 → 35:58

What about the code?

35:58 → 36:01

Of course, there are a lot of stuff that you can do.

36:02 → 36:06

But I I think I will start with with our cooperation with the

36:06 → 36:07

product design team.

36:07 → 36:09

At the beginning of each project,

36:09 → 36:11

we heavily cooperate together because this is the moment we

36:11 → 36:14

create meaningful user flows.

36:14 → 36:17

And that is because

36:18 → 36:23

we are developers and we are living in our specific specific ways.

36:23 → 36:26

So usually we tend to miss how

36:26 → 36:28

things should work.

36:28 → 36:31

So cooperating with the product design team,

36:31 → 36:34

cooperating with the UX designer will help us seeing

36:34 → 36:39

the big picture how a regular user would expect things to work for us.

36:39 → 36:41

Also,

36:41 → 36:44

for us having a consistent design,

36:45 → 36:49

a very well crafted design is really helpful because as an

36:49 → 36:53

end result we also create reusable components, consistent

36:54 → 36:57

and visuals in the application.

36:57 → 37:01

So it's a better performing app and it's much easier for

37:01 → 37:05

user to use this app, have a better user experience.

37:06 → 37:10

There are are also some processes that actually helps

37:10 → 37:11

developers,

37:11 → 37:16

therefore indirectly affects the performance of your of your application.

37:16 → 37:17

For example,

37:17 → 37:21

traditional thing, giving a regular code review for

37:21 → 37:26

whatever you are adding into the application.

37:27 → 37:32

Or peer programming sessions or giving your developer some

37:32 → 37:35

coding guidelines, like having them

37:35 → 37:39

somehow more homogeneous experience

37:39 → 37:43

with the coding, with the project that they are preparing.

37:44 → 37:48

Also clear acceptance criteria that doesn't

37:48 → 37:53

let your developers to go wild with their decisions.

37:53 → 37:55

So this is also important.

37:56 → 38:00

Also, think some amount of time dedicated for refactoring the

38:00 → 38:04

existing system will also help your product to

38:04 → 38:06

become better over time.

38:06 → 38:07

Because

38:08 → 38:11

it's it's it's the case that I keep seeing.

38:11 → 38:15

Developers see some mistakes and that's getting ignored.

38:15 → 38:20

Like, because there is no time to basically go and fix that.

38:20 → 38:23

But if you provide them this time,

38:23 → 38:27

this small slot that they can just go and fix that,

38:27 → 38:31

they are more than more than happy to basically go ahead and do it.

38:31 → 38:34

So I find it quite useful.

38:34 → 38:37

Because leaving it as it is will have its consequences.

38:38 → 38:38

Yes.

38:38 → 38:43

And it's basically not visible until you address it.

38:43 → 38:47

So giving it time or at least creating a ticket in the

38:47 → 38:50

backlog for that will will definitely help.

38:50 → 38:53

So that sounds like the reasonable

38:53 → 38:55

best practices to follow.

38:55 → 38:56

It's pretty universal,

38:56 → 38:59

but it will work in the mobile scalar project.

38:59 → 39:00

I think so. Yeah.

39:00 → 39:02

Okay.

39:02 → 39:04

And now that you mentioned processes,

39:04 → 39:08

I think we are ready to move on to the last topic.

39:08 → 39:12

That's the mindset and team related things.

39:13 → 39:15

So as you said at the beginning,

39:15 → 39:18

there are some tales of success that we've all heard of,

39:18 → 39:22

but there are just as many or I think even many more of

39:22 → 39:26

businesses that failed during the scale up stage for whatever reasons.

39:27 → 39:31

And how can we ensure that our organization is not one of them

39:31 → 39:35

and that we are actually ready to scale our mobile product?

39:35 → 39:40

So I would say that this product mindset is a must.

39:40 → 39:43

So what you want to do is to focus

39:43 → 39:47

on the business and end product instead of temporary

39:47 → 39:48

challenges and milestones.

39:48 → 39:54

So thinking more in terms of outcomes instead of the outputs.

39:54 → 39:58

So measure those with metrics like retention and user

39:58 → 40:00

adoption and now with, I don't know,

40:00 → 40:05

trends and things that you think are cool to code with.

40:05 → 40:07

I'm sure I did understand that.

40:07 → 40:11

So that's the idea is to have the team like business

40:11 → 40:14

design, development, infrastructure, QA, all of

40:14 → 40:17

those to work as a one team from day one.

40:17 → 40:20

So that they create the experience and the product

40:20 → 40:23

together with their knowledge and

40:23 → 40:24

experience.

40:24 → 40:28

And the decisions you made should be you make should be

40:28 → 40:32

should be driven by the users and the business and that's the

40:32 → 40:34

core of the mindset I think.

40:35 → 40:38

When it comes to product based approach,

40:38 → 40:41

I I think it's also important, like I mentioned earlier,

40:41 → 40:43

having a mobile strategy.

40:43 → 40:47

Either mobile first or mobile early because that will lead

40:47 → 40:50

you to tackle certain specific problems that's

40:50 → 40:54

only for mobile applications early on so that you

40:54 → 40:58

won't postpone some some potential issues that will

40:58 → 41:01

prevent your application or project from scaling up.

41:02 → 41:02

Okay.

41:02 → 41:08

And Kuba, you actually mentioned all members of the team working hand in hand.

41:08 → 41:10

And we shouldn't forget really

41:10 → 41:14

about these people behind the project and the processes.

41:14 → 41:17

What skills, speaking from your own experience,

41:17 → 41:21

should they possess to make a mobile scale up project a success?

41:21 → 41:23

Maybe we could start with designers.

41:23 → 41:23

Sure.

41:23 → 41:26

So for sure you should look for

41:26 → 41:29

people that are experienced in creating mobile experience in

41:29 → 41:34

particular, that know the common mobile patterns,

41:34 → 41:36

that understands the characteristics of Android and

41:36 → 41:39

iOS, and also the characteristics of the

41:39 → 41:43

smartphones, their possibilities and limitations.

41:43 → 41:47

I think people like that will work a little bit faster and more efficient.

41:47 → 41:51

To addition to that, you should look for people that have this

41:51 → 41:56

user centric attitude, that are creative and focused on problem solving.

41:56 → 41:58

People that are definitely product oriented,

41:58 → 42:02

as we mentioned, and that also requires from them high skills

42:02 → 42:04

in teamwork.

42:05 → 42:06

And last but not the least,

42:06 → 42:09

I would look for people that are good with documentation of

42:09 → 42:12

their work, that work well with style guides, design systems,

42:12 → 42:16

that create change logs, that prepare working

42:16 → 42:20

files as tidy as possible so that you can go back to them

42:20 → 42:22

and reuse them if you need to.

42:23 → 42:25

Basically, you need to find people that not only create pretty things,

42:25 → 42:27

but also things that work.

42:27 → 42:30

Yeah. Sounds reasonable. Yeah.

42:30 → 42:32

And what about mobile developers?

42:32 → 42:34

There are a bunch of technical things that

42:35 → 42:37

probably they will be quite different for different

42:37 → 42:40

technologies that company is working on.

42:40 → 42:42

But I would like to talk about few, like,

42:42 → 42:46

gentler things in this case that you can look for in a in a

42:46 → 42:48

good developer, like,

42:49 → 42:53

of course, the capability or capacity to tackling difficult problems.

42:53 → 42:57

That's I think the base of being a developer.

42:59 → 43:02

Having or at at least practicing everyday these

43:02 → 43:06

main principles, solid principles, dry or keeping

43:06 → 43:09

thing keeping things stupidly simple in this case.

43:10 → 43:15

I can also recommend developers to swallow five books about

43:16 → 43:17

design patterns.

43:17 → 43:22

It might help in their later career.

43:22 → 43:25

And I I think it's it's also important if a if a developer

43:25 → 43:30

cares about test coverage Which which eventually saves

43:30 → 43:32

bunch of headache over over longer periods

43:32 → 43:36

of working in the same project.

43:37 → 43:37

What else?

43:37 → 43:41

I I think there are also some sort of soft skills that that's

43:41 → 43:43

soft or additional things to that,

43:43 → 43:48

like communicating clearly and openly talking about the facts,

43:48 → 43:50

not like emotions.

43:50 → 43:53

I'm not saying emotion doesn't have a space in that place,

43:53 → 43:57

but if if you talk about the product then you have to talk

43:57 → 43:59

about the facts and objective things.

44:00 → 44:02

Knowledge of the platform.

44:02 → 44:05

So if you are a cross platform mobile developer,

44:05 → 44:09

then you have to have the knowledge of knowing iOS,

44:09 → 44:12

Android, or other things that you may

44:12 → 44:15

potentially develop on, like native,

44:15 → 44:17

how things natively work.

44:17 → 44:21

Because eventually you may need to integrate or at least

44:21 → 44:23

develop something in the native,

44:23 → 44:25

not like all the time in the cross platform.

44:25 → 44:27

And for mobile developers,

44:27 → 44:30

it's also important about of this design systems.

44:30 → 44:34

Either it's material design or it's Apple human interface.

44:34 → 44:37

Knowing those things is going to help as well as knowledge of

44:37 → 44:42

design tools like Figma most often used.

44:42 → 44:45

Because if you're cooperating with the designer,

44:45 → 44:50

product design team, they I'm guessing that most of

44:50 → 44:53

the time they are just sending a Figma file just to or at

44:53 → 44:55

least sharing it.

44:55 → 44:57

Correct me if I'm wrong.

44:57 → 44:57

They do share it.

44:57 → 44:58

Yeah. They do share it.

44:58 → 44:59

So

45:00 → 45:04

ability to use this kind of tools without the need of help

45:04 → 45:08

will definitely definitely make their life easier.

45:09 → 45:12

Care the developer also should care

45:12 → 45:16

about the adaptiveness because we talked about platforms and how they work.

45:16 → 45:17

Knowledge about it is important,

45:17 → 45:22

but caring about adaptiveness is also important because that

45:22 → 45:25

means you are also caring about providing a native like or at

45:25 → 45:29

least high quality perform experience for your users.

45:31 → 45:34

And additionally, I think this is the last one.

45:34 → 45:36

They should be open for new challenges,

45:36 → 45:38

not like stay in their own shell and just

45:38 → 45:41

don't leave the comfort zone.

45:41 → 45:44

It's also it's also something for a plus.

45:44 → 45:44

Okay.

45:44 → 45:47

So it sounds like it's all about cooperation You know?

45:47 → 45:48

Yeah.

45:48 → 45:48

Yeah.

45:48 → 45:52

Just trying to make each other's It's not working in silos.

45:52 → 45:53

Never.

45:53 → 45:54

Yeah.

45:55 → 45:59

I mean, I think it would be great if

45:59 → 46:02

all the clients who are building mobile applications

46:02 → 46:07

were able to to hire great talent that you've just talked about.

46:07 → 46:10

But sometimes it's not possible for whatever reasons.

46:10 → 46:12

It can be the time restrictions,

46:12 → 46:15

the budget limitations, it doesn't really matter.

46:15 → 46:20

What I'm driving at is that in this case you need to outsource.

46:20 → 46:22

And it can go both ways actually.

46:22 → 46:26

And the trick to do good outsourcing is I

46:26 → 46:30

believe finding a good reliable tech partner.

46:30 → 46:31

Speaking from your own experience,

46:31 → 46:35

what would you say makes a perfect tech partner for a

46:35 → 46:37

mobile scale up project?

46:37 → 46:41

I think you should look for a company that has mature,

46:41 → 46:45

well tested processes, that are flexible enough and

46:45 → 46:49

that you can or the company you find will tailor them to your

46:49 → 46:54

needs, but never at the cost of under delivering, right?

46:54 → 46:58

Good development process is a key for working in scale up,

46:58 → 47:01

for scale up projects and scale up environment,

47:01 → 47:05

especially if you have if you started with something that was

47:05 → 47:06

maybe not perfect.

47:06 → 47:06

Right?

47:06 → 47:08

And here at Merixstudio,

47:08 → 47:11

we believe that one of the most important stages is discovery

47:11 → 47:15

stage, which is a key to productive productive deep dive

47:15 → 47:19

into the project, the client's needs, the vision and so on.

47:20 → 47:20

Yeah.

47:21 → 47:22

Okay.

47:22 → 47:25

I actually talked about processes a couple of questions ago.

47:25 → 47:28

And I believe a product success is not about

47:28 → 47:32

individual talents or very good single

47:32 → 47:34

developer that does all.

47:34 → 47:38

It's more about how your development team or how

47:38 → 47:41

your development partner is basically

47:42 → 47:45

making providing you with the whole whole development

47:45 → 47:47

process, basically.

47:48 → 47:51

Speaking from my own experience,

47:51 → 47:55

solid development process is about is also is about

47:55 → 47:58

cooperating with the client as well as taking responsibilities

47:58 → 48:00

of the project.

48:01 → 48:05

But this also doesn't mean that product just we develop product

48:05 → 48:11

in our own way without with by ignoring what client is needing.

48:12 → 48:16

But it's it's also about how we focus on development,

48:16 → 48:19

how we manage the risk in the development,

48:19 → 48:22

how do we ensure the quality quality basically with

48:22 → 48:25

our QA processes.

48:25 → 48:30

It's like a whole whole thing circling around

48:30 → 48:34

development team, product design team that that a good

48:34 → 48:37

reliable development partner would provide you in this case?

48:37 → 48:41

So there is also a subject of the form of the cooperation.

48:41 → 48:45

You can go with dedicated team or with the team augmentation model.

48:45 → 48:49

If you decide to hire a dedicated team for a software

48:49 → 48:52

house like from, for example, from Marix Studio, right?

48:52 → 48:55

It's basically creating this remote department

48:55 → 48:59

that is built from a blend of qualified professionals from

48:59 → 49:00

different fields.

49:00 → 49:03

And what you can rely on what what you can

49:04 → 49:07

count on is that they are focused on your product,

49:07 → 49:08

are focused on the problem,

49:08 → 49:10

technical choices and the scope of the product.

49:10 → 49:13

And they can also take a lot of ownership for the decisions

49:13 → 49:16

they made which basically means that you will have this

49:16 → 49:19

dedicated team that works well together.

49:19 → 49:21

They have the experience to work together.

49:21 → 49:24

That's also something that is an advantage of hiring a

49:24 → 49:25

dedicated team from one company.

49:25 → 49:29

The other model would be a team augmentation which basically

49:29 → 49:30

allows you to

49:31 → 49:35

add talented people and add

49:35 → 49:37

them to your in house team to work faster,

49:37 → 49:40

to work better or to work in technologies that you can't

49:40 → 49:41

cover with your own team.

49:41 → 49:42

Right?

49:42 → 49:44

The thing that is more the most

49:44 → 49:47

important regardless the model you will

49:47 → 49:49

choose is to find a tech partner,

49:49 → 49:51

tech partner that will be reliable,

49:51 → 49:54

that will have the ability to advise you and guide you

49:54 → 49:55

through the whole process.

49:56 → 49:58

And that's how we do it here in my studio.

49:59 → 50:03

Our teams are engaged, present, are motivated,

50:03 → 50:06

and this is something that pays off for our clients.

50:06 → 50:09

And I feel that one thing that we could add to the list of

50:09 → 50:14

qualities that you just gave us is transparency in

50:14 → 50:16

communication and processes.

50:16 → 50:16

How about that?

50:16 → 50:18

From the development team's perspective,

50:18 → 50:22

it's transparency is one of the crucial things because

50:22 → 50:25

daily basis we are almost daily basis, let's say,

50:25 → 50:27

we are contacting

50:27 → 50:28

client.

50:28 → 50:33

We are including him in in our process of development.

50:33 → 50:34

So any kind of risk,

50:34 → 50:38

any kind of potential problems that application may face in

50:38 → 50:42

the future is directly directly conducted,

50:42 → 50:44

directly basically reported to the client.

50:44 → 50:48

So additional measures can be taken in this case.

50:48 → 50:51

And I see a huge benefit in that because

50:52 → 50:57

everything is clear and you don't really

50:57 → 51:02

put additional pressure to hide or or basically ignore

51:02 → 51:03

certain things.

51:03 → 51:07

And we that means we are taking the ownership of the project

51:07 → 51:08

product and then

51:09 → 51:14

doing our best to give as realist as realistic

51:14 → 51:16

feedback or as realistic

51:17 → 51:20

screen display of the of the current status as possible with

51:20 → 51:22

the with the development.

51:22 → 51:25

So I believe that we are slowly heading towards the end of this

51:25 → 51:29

webinar, but I will have one more question to you guys.

51:29 → 51:33

So imagine our audience can remember only two things from

51:33 → 51:35

this entire hour of us talking.

51:35 → 51:38

What would you like them to remember?

51:38 → 51:42

Two things from the design and two things from the mobile

51:42 → 51:45

development domain.

51:46 → 51:48

So from the design perspective,

51:48 → 51:51

I would say those two takeaways would be

51:51 → 51:55

first, don't forget about your users.

51:55 → 51:57

You think you know everything,

51:57 → 52:00

you think you know what is the best for your app,

52:00 → 52:04

but the truth is that what you should focus is what your users

52:04 → 52:07

needs, what they know and what they want.

52:07 → 52:10

So don't be afraid to listen to them,

52:10 → 52:12

to use your analytical tools,

52:12 → 52:15

to conduct research surveys, things like that,

52:15 → 52:21

and ask them what they need and make your decisions based on that.

52:21 → 52:25

And the second thing would be design with the scalability

52:25 → 52:28

as a principle for the designers.

52:29 → 52:33

Well thought out design will be based on good practices, common patterns,

52:33 → 52:37

native solutions And all of this will help you in the

52:37 → 52:40

future when you will scale up, basically.

52:40 → 52:42

And how about the development?

52:42 → 52:44

Actually, wanted to talk about the same thing.

52:44 → 52:48

Scalability mindset is quite crucial for developers.

52:48 → 52:53

So have a scalability mindset whenever you develop things.

52:53 → 52:58

And second of all would be be open and don't hesitate

52:58 → 52:59

taking initiative.

53:01 → 53:05

That also includes talking about issues and risks in the project.

53:05 → 53:08

And this is the reason is that you

53:08 → 53:11

are the one that actually does all these things and you you

53:11 → 53:13

know what's going on internally.

53:13 → 53:14

So

53:14 → 53:18

make sure you you don't just put everything under the

53:18 → 53:22

carpet, but openly talk about it and don't don't

53:22 → 53:25

hesitate being more, how to say,

53:25 → 53:28

open for new challenges.

53:28 → 53:32

So these are great tips. And I believe we have a wrap. Right?

53:32 → 53:35

Thank you very much, guys,

53:35 → 53:38

for talking us through the challenges of mobile scale up

53:38 → 53:41

and for accepting my invitation to to this webinar.

53:42 → 53:46

Thank you to our audience for sticking with us.

53:46 → 53:50

If you have any questions about mobile development in general

53:50 → 53:52

or perhaps Mobile Scale Up,

53:52 → 53:56

don't hesitate to reach out to us via email or via LinkedIn.

53:56 → 53:59

We'll be happy to answer your questions.

53:59 → 54:02

Also don't forget to check out more of our mobile development

54:02 → 54:03

related content.

54:03 → 54:08

We have plenty of articles and videos about that on

54:08 → 54:10

our Merixstudio Insights.

54:10 → 54:12

And I guess, see you next time.