How to launch a product with a bang

00:13 → 00:17

Hello everyone, this is Merrick Studio with our very first

00:17 → 00:20

LinkedIn live session.

00:20 → 00:24

We are very, very happy to have you here in our

00:24 → 00:27

our very first time with LinkedIn live.

00:28 → 00:32

Platform and we are very happy to have our guests,

00:32 → 00:36

which are Katazuna Kanevska, which is our user

00:36 → 00:39

experience designer with a great proven track record and

00:39 → 00:41

several projects behind her back,

00:41 → 00:43

as well as Wukashi Arusal,

00:44 → 00:48

business analyst, WizD startup founder.

00:48 → 00:51

Guys, how are you? How long do you do?

00:51 → 00:56

We are fine. Ready to start the conversation.

00:57 → 01:00

Okay. Lucas, how are you?

01:03 → 01:06

I can't wait to discuss the

01:07 → 01:10

POCs, MVP and prototyping.

01:10 → 01:12

Okay.

01:12 → 01:13

Thank you for this.

01:13 → 01:15

I think it would be beneficial if you could tell just a few

01:15 → 01:18

words about your proven track record, about your experience,

01:18 → 01:20

projects that you've been working on.

01:20 → 01:22

Kasia, perhaps you could start.

01:22 → 01:23

Sure.

01:23 → 01:27

So as Mike said, I've been working

01:28 → 01:32

and I am still working as a UX designer at Merix

01:32 → 01:33

Studio.

01:33 → 01:34

So

01:34 → 01:38

the projects I am working on are very

01:38 → 01:42

broad and starting from, for example,

01:42 → 01:46

my recent ones, so in tourism industry,

01:46 → 01:49

as well as fintech, as well as ad tech, as well as gaming.

01:49 → 01:53

So, well, sky is the limit.

01:55 → 01:59

Okay. Hukash, my great great teammate.

01:59 → 02:01

How does it look like from your perspective?

02:01 → 02:02

Okay.

02:02 → 02:06

So I'm a senior business analyst here at Marek Studio.

02:06 → 02:10

I'm also a two time founder, two startups.

02:10 → 02:12

One of them unfortunately failed,

02:12 → 02:16

giving me a great and necessary experience to kind of launch

02:16 → 02:20

another one, another product and gain traction effectively.

02:20 → 02:23

Okay, thank you very much.

02:23 → 02:26

Guys, let's start, let's say from

02:26 → 02:30

something that could be considered as a, let's say,

02:30 → 02:33

very initial point of initiating any startup,

02:33 → 02:36

any absolutely new concept in terms of digital,

02:36 → 02:39

terms of design, in terms of functionalities.

02:40 → 02:41

This is I think proof of concept.

02:41 → 02:46

So basically probably the most simple thing that any startup

02:46 → 02:49

founder could potentially perform in order to

02:49 → 02:52

verify his or hers idea.

02:52 → 02:54

So there are different kinds of proof of concepts.

02:54 → 02:56

Quite often as Merrick Studio,

02:56 → 02:59

we are receiving inquiries in regards to let's say more

02:59 → 03:01

technical proof of concepts.

03:01 → 03:03

Can I increase the efficiency of my database?

03:03 → 03:07

Can I speed up the rendering? Can I do this? Can I do that?

03:07 → 03:11

But how does from the product design

03:11 → 03:15

perspective look the aspect of proof of concept in

03:15 → 03:16

the startup world?

03:17 → 03:19

So let me take this one.

03:20 → 03:24

So I've been observing, I would say,

03:24 → 03:27

a proof of concept, for example,

03:27 → 03:31

in one of the projects workshops actually we had.

03:31 → 03:34

So that was a project about

03:35 → 03:39

a very advanced conferencing.

03:42 → 03:46

So this went actually far and beyond what

03:46 → 03:49

Google Classroom allowed us to do.

03:49 → 03:51

So therefore we had to

03:52 → 03:55

try and find out if the

03:55 → 03:58

functionalities that our client envisioned were actually

03:58 → 04:02

doable and if so, if it required a lot of

04:02 → 04:04

extra work.

04:04 → 04:06

So that was one of the proof of concepts.

04:06 → 04:10

So it wasn't exactly what I was responsible for.

04:10 → 04:15

It was still a development work and this is what

04:15 → 04:18

usually happens in my experience.

04:18 → 04:21

So the proof of concept gives us

04:21 → 04:25

the answer is this feasible or not.

04:25 → 04:29

So this is in many cases just one standalone

04:29 → 04:34

functionality that you test in

04:34 → 04:38

meaning try to check if that's going to

04:38 → 04:43

work or not with limited resources and

04:44 → 04:48

usually the limited resources include for example just

04:48 → 04:52

one developer who's checking the feasibility of something.

04:52 → 04:53

So

04:54 → 04:59

that's what I've been experiencing concerning

04:59 → 05:01

the proof of concept.

05:01 → 05:05

Yeah, and what I can add is to

05:05 → 05:08

just what Kasia said is that the main

05:08 → 05:12

proof of concept essentially proves that a certain

05:12 → 05:16

assumption is correct and can be implemented in real

05:16 → 05:20

life using the available technology, right?

05:20 → 05:24

So this is actually the main point of having this

05:24 → 05:27

exercise, building proof of concept, right?

05:27 → 05:29

So in this model of product development,

05:29 → 05:34

we're just leaving those frills like performance, usability,

05:34 → 05:40

or actually everything that this customer facing.

05:40 → 05:45

So those elements are simply not taken into consideration.

05:45 → 05:46

Yes, exactly.

05:46 → 05:52

So however, it gives a lot of actually

05:52 → 05:56

beneficial knowledge to the investors or our clients

05:56 → 06:00

because they learn first of all can we do it or

06:00 → 06:03

not, but also they gain some

06:03 → 06:06

experience by this

06:06 → 06:07

exercise.

06:07 → 06:11

They know, for example, if they have no

06:11 → 06:15

previous experience in cooperation with

06:15 → 06:20

development team, well, that gives them that hands on experience.

06:21 → 06:22

Exactly.

06:23 → 06:26

Guys, just question on the in regards to the proof of

06:26 → 06:30

concept, because when we are building a product or when

06:30 → 06:31

we are building a service,

06:31 → 06:34

there is a let's say a certain group or even widespread of

06:34 → 06:36

groups of potential users.

06:36 → 06:39

And we know that the list of functionalities are quite

06:39 → 06:41

complex and so on.

06:41 → 06:43

Now, the question is, is there for example,

06:43 → 06:47

a risk associated with designing a particular feature

06:47 → 06:51

or particular service that is standalone and that

06:51 → 06:54

perhaps cannot be verified in terms of usability

06:54 → 06:56

because it's just a, you know,

06:56 → 07:00

like an isolated aspect from something that is meant to be

07:00 → 07:02

brought in a bigger product or service.

07:02 → 07:06

Do you think that such risk exists and how

07:06 → 07:09

eventually a stakeholder startup founder could

07:09 → 07:11

potentially avoid it?

07:11 → 07:15

So maybe I will take this one too.

07:15 → 07:20

So in my experience mainly the proof of concept

07:20 → 07:25

is not that much related to the design or the users.

07:25 → 07:29

It's more like checking the limits or

07:29 → 07:32

if something is feasible or not.

07:32 → 07:36

And you can test it by trying to

07:36 → 07:40

confirm that yes you can do it or

07:40 → 07:44

disprove it by you know realizing okay

07:44 → 07:46

there is no point in

07:47 → 07:50

taking so much time into the subject.

07:50 → 07:54

But actually what you are saying is more

07:54 → 07:57

related to the prototype or the MVP actually

07:57 → 07:58

Mike.

07:58 → 08:03

So when we have the ready prototype we can

08:04 → 08:07

follow a certain path, a certain scenario,

08:07 → 08:09

and then test it with the users,

08:09 → 08:12

meaning they start

08:13 → 08:16

we create a scenario, for example,

08:16 → 08:19

from simple logging into the system,

08:19 → 08:23

then performing a task and then let's say logging out.

08:23 → 08:25

So this is a

08:26 → 08:29

full user experience path that we can test.

08:30 → 08:35

And of course, we need the design there and we need the user feedback there as well.

08:35 → 08:38

So, yeah.

08:39 → 08:41

Okay, thank you very much.

08:41 → 08:43

By taking just this quick chance,

08:43 → 08:48

I would like to encourage our audience to ask questions.

08:48 → 08:52

We would like to potentially react to all the

08:52 → 08:54

inquiries coming through your comments.

08:54 → 08:58

So please feel free to share your questions to provide them.

08:58 → 09:04

We'll try to cover as many of them as possible during today's broadcast.

09:04 → 09:07

Anyways, Kasia, thank you very much for putting a little bit of light on the

09:07 → 09:09

proof of concept now.

09:09 → 09:12

So have proof of concept could be potentially,

09:12 → 09:14

correct me if I'm wrong,

09:14 → 09:16

a part of let's say a prototyping aspect.

09:16 → 09:19

So this could be a part of let's say delivering new

09:19 → 09:20

prototype, right?

09:20 → 09:24

Now, what are let's say the good practices of building a

09:24 → 09:27

prototype and what exactly is a prototype and

09:27 → 09:31

what are the purposes of building a prototype in digital

09:31 → 09:33

product development?

09:33 → 09:36

So, you know,

09:36 → 09:38

I'm thinking about the prototype this way.

09:38 → 09:41

People usually like stories, right?

09:41 → 09:42

And when you go, let's say,

09:42 → 09:44

to pitch your product to investors,

09:44 → 09:47

because this is the main purpose of building POC,

09:47 → 09:49

one of the main purposes I would say,

09:49 → 09:53

of building POCs or prototypes is to kind of, you know,

09:53 → 09:57

validate initial hypothesis assumptions and also go and

09:57 → 10:00

pitch the product to investors.

10:00 → 10:04

So you basically tell them a story, your story.

10:04 → 10:07

So to tell it successfully, first of all,

10:07 → 10:09

it needs to be authentic.

10:09 → 10:11

It needs to be something immersive,

10:11 → 10:15

something attention grabbing, these kind of things.

10:15 → 10:16

In my opinion,

10:17 → 10:19

that it's covered.

10:20 → 10:23

We kind of built POCs and prototypes that we've just

10:23 → 10:27

mentioned to gather important feedback,

10:27 → 10:31

to build something that we can show so our investors and our

10:31 → 10:34

users actually have a chance to

10:35 → 10:37

click through it, to have this feeling

10:39 → 10:42

and immersive experience in what the product is like.

10:42 → 10:47

Yeah, So this is an opportunity for people,

10:48 → 10:52

end users, both end users and investors to

10:52 → 10:57

actually experience something that we have envisioned.

10:57 → 11:01

So it goes more into the I would say you can be

11:01 → 11:05

more immersed into the prototype just because it tells

11:05 → 11:06

you a full story.

11:06 → 11:09

So as I mentioned, from start to finish,

11:09 → 11:13

you manage to perform a full task just by

11:13 → 11:18

clicking through a prototype and just to

11:18 → 11:22

maybe shed some light what is the prototype?

11:22 → 11:26

So for example, if I'm creating a prototype,

11:26 → 11:31

then it's not something that is a working software.

11:31 → 11:35

This is more like a representation of how

11:35 → 11:41

something might look like, but also work like.

11:41 → 11:43

So it can be very interactive,

11:43 → 11:46

but it can be very simplistic.

11:46 → 11:49

Depends on what is needed actually.

11:50 → 11:53

Based on the feedback that we gather from the end users,

11:53 → 11:57

we actually improve the prototype, so we iterate.

11:57 → 12:01

So gathering feedback from people

12:01 → 12:05

makes the prototype so much better.

12:05 → 12:09

And I'm sure you are aware that a lot of

12:09 → 12:12

startups, majority of them actually fail.

12:12 → 12:17

And one of the main reasons of the failure is the mismatch

12:19 → 12:22

between the product and the market,

12:22 → 12:26

but also that the users do not like

12:26 → 12:27

it, simply said.

12:27 → 12:31

So well, when we are creating those user testing

12:31 → 12:35

through prototype, we are actually

12:37 → 12:42

maybe minimizing the risk that the product will not be

12:43 → 12:46

perfect on the market and for the users.

12:46 → 12:51

Exactly and you know we use prototypes as Kasia said to

12:51 → 12:53

gather this initial feedback.

12:53 → 12:57

It's great to use it for initial customer demand probing

12:57 → 13:03

and you know it's kind of a it's paving a way to building a great MVP.

13:03 → 13:05

Yes exactly.

13:05 → 13:09

So Ukash, I know you had some sort of the

13:09 → 13:13

prototype in your own startup so maybe you can

13:13 → 13:15

just tell us a little bit about this.

13:15 → 13:16

Sure, of course.

13:16 → 13:20

So you know, as mentioned in the beginning,

13:20 → 13:23

my first startup I co founded,

13:23 → 13:26

actually we failed and we launched an MVP,

13:26 → 13:30

what we called an MVP, but was too big in my opinion.

13:30 → 13:34

Know, one of the main mistakes that we did is we just

13:34 → 13:36

started development.

13:36 → 13:37

After hours, at this time,

13:37 → 13:39

after hours we started developments,

13:39 → 13:42

no user testing on this point, we just take it for granted,

13:42 → 13:43

you know, because

13:44 → 13:46

a little bit of a background here,

13:46 → 13:49

I'm very connected with the EdTech industry.

13:49 → 13:53

So the product was EdTech platform for teachers.

13:53 → 13:55

And I just thought, okay, I would like to use it.

13:55 → 13:58

So perhaps other teachers would like to use it as well.

13:58 → 14:00

But it's not always the case.

14:01 → 14:05

Yeah, we failed in the first startup.

14:05 → 14:09

So I've learned, I gained experience and knowledge.

14:09 → 14:12

I've read about it, you know,

14:12 → 14:16

important it is to actually have this initial user testing

14:16 → 14:19

and validate your ideas.

14:19 → 14:23

So the second attempt with the which is at this point,

14:23 → 14:25

I think it's quite successful.

14:25 → 14:28

We launched MVP, but it all started with the process called

14:28 → 14:30

customer development.

14:30 → 14:34

So interviewing customers, discussing the problem and then

14:34 → 14:36

discussing the solution.

14:36 → 14:39

But in the meantime, we had a process that's called the

14:39 → 14:44

design sprint, which gave us a lot of information.

14:44 → 14:48

We built a clickable prototype and we showed it to users and

14:48 → 14:50

we showed it to investors.

14:50 → 14:52

And thanks to it, I believe,

14:52 → 14:56

thanks to it and all the information that we gathered we managed to

14:58 → 15:01

get funded by Business Angel.

15:01 → 15:02

Perfect.

15:02 → 15:07

And also I would also like to add once we are

15:07 → 15:11

talking about a prototype that it's actually

15:11 → 15:14

in many projects this is the approach we are suggesting

15:14 → 15:19

because it's really relatively cheap

15:19 → 15:21

to create

15:22 → 15:25

comparing to the full development.

15:25 → 15:27

So let's put it this way:

15:27 → 15:31

if I'm creating a prototype and for example I've been

15:31 → 15:35

creating a prototype for an ad tech

15:35 → 15:38

sorry, not EdTech, FinTech client,

15:39 → 15:42

and it took me over three months.

15:42 → 15:45

So that was just the design phase.

15:45 → 15:49

And during that process, the prototype served not only

15:49 → 15:51

to cover all the scenarios,

15:51 → 15:55

of course the main purpose of the prototype was to show

15:55 → 15:58

it to investors and raise money,

15:58 → 16:01

but then it also served as a starting point of the

16:01 → 16:05

discussion what is needed actually within the system

16:05 → 16:07

and what is not.

16:07 → 16:08

So

16:09 → 16:12

this actually opens a discussion.

16:12 → 16:16

If we get from our clients just a functional

16:16 → 16:21

specification, while everyone interprets it

16:23 → 16:25

in their own way, right?

16:25 → 16:27

So you envision

16:28 → 16:32

such or such functionality which is

16:33 → 16:36

based on what other, for example,

16:36 → 16:39

systems or functionalities you are used to.

16:39 → 16:43

But everyone can be used to different things so they can

16:43 → 16:44

understand

16:45 → 16:47

should be the same thing,

16:47 → 16:49

but it turns out in a different way.

16:49 → 16:53

So if we have this prototype or something

16:53 → 16:57

tangible, something solid enough, everyone can see it

16:57 → 17:02

and then discuss what works, what doesn't work.

17:02 → 17:05

And we discuss the details of it,

17:05 → 17:08

not just a vision or a concept.

17:08 → 17:13

So this actually, well, helps a lot in terms of conversation

17:14 → 17:17

about the project and the shape of it.

17:17 → 17:22

Okay, guys, you touched several purposes of

17:22 → 17:26

building a prototype and this was fundraising for sure,

17:26 → 17:29

verifying the available for the market and slightly

17:29 → 17:33

slowly, we've been also touching an aspect in which

17:33 → 17:37

the prototype, let's say clickable prototype,

17:37 → 17:39

imagine it one way or another

17:40 → 17:42

could become a blueprint for a development team.

17:42 → 17:46

So basically prototype which can be used, listen,

17:46 → 17:49

this is the prototype of an application or a service that

17:49 → 17:50

we'd like to build.

17:50 → 17:51

And

17:52 → 17:56

basically a development team consisting of two or four or

17:56 → 17:59

six or eight people could basically develop it.

17:59 → 18:00

Now the question would be,

18:00 → 18:04

do you think that this is possible to achieve all these

18:04 → 18:06

goals with a one prototype?

18:06 → 18:09

So have something to present

18:09 → 18:12

the potential investors, that's the one thing.

18:12 → 18:15

Validate the market to let's say,

18:15 → 18:17

ask survey potential group of users.

18:17 → 18:21

Listen, do you find this attractive and what would you improve within the service?

18:21 → 18:25

And eventually later on to provide it to the engineering

18:25 → 18:28

team and listen, guys, I want to have this developed.

18:28 → 18:31

Do you think that this can all those purposes can be covered

18:31 → 18:33

with one prototype?

18:33 → 18:38

So, you know, building a product is actually a process.

18:38 → 18:42

So I think that we need to,

18:42 → 18:47

as founders, we need to verify our assumptions as

18:47 → 18:49

many times as possible.

18:49 → 18:53

Know, we also can't take every user feedback as

18:53 → 18:56

something that we should implement.

18:56 → 18:57

Also need to, you know,

18:57 → 19:01

take a closer look at this feedback and validate it

19:01 → 19:01

because, you know,

19:01 → 19:05

there'll be people that love our product and those who

19:05 → 19:06

simply don't.

19:06 → 19:07

So

19:08 → 19:10

as you've mentioned,

19:10 → 19:14

in my opinion, there is a call that we can call the

19:14 → 19:18

prototype, but we cannot say that we can

19:18 → 19:21

build it once and it will serve all the purpose, right?

19:21 → 19:23

So it will be used for pitching investors.

19:23 → 19:25

It will be used for development.

19:25 → 19:30

Of course, can be, but there will always be changes because

19:30 → 19:34

it's so initial phase that I can't imagine like how

19:34 → 19:35

lucky you are, you know,

19:35 → 19:39

having this perfect prototype moving it smoothly

19:39 → 19:44

to MVP phase launching without any changes, right?

19:44 → 19:45

Just

19:46 → 19:48

one question, quick one on this.

19:48 → 19:50

So think that this could be, let's say, a process.

19:50 → 19:54

We are building a prototype and this is when we are in a

19:54 → 19:58

conversation with investors and with potential users, this is,

19:58 → 20:01

let's say, a prototype work in progress.

20:01 → 20:04

And so these are those two activities that will need to be

20:04 → 20:09

performed before pushing it to the development team.

20:09 → 20:13

I believe yes, because like the prototype

20:13 → 20:16

can be described as a model of product development,

20:16 → 20:19

you know, focused on answering those how questions.

20:19 → 20:23

So how the application will look like, how it will be made,

20:23 → 20:26

you know, what technology we can use,

20:26 → 20:28

how the users will interact with it.

20:28 → 20:32

And by validating it, those assumptions,

20:32 → 20:35

because these all are hypotheses and assumptions,

20:35 → 20:38

we kind of change it a little bit, modify it and, you know,

20:38 → 20:40

discussing with development teams, discussing with

20:40 → 20:43

investors, brainstorming internally with

20:43 → 20:46

cofounders, pushing it forward.

20:46 → 20:47

Right?

20:47 → 20:53

So I would I I think I have a bit of a different angle here.

20:53 → 20:54

So

20:57 → 20:59

how to put it simply?

20:59 → 20:59

Okay.

20:59 → 21:01

So if

21:02 → 21:05

I'm creating a prototype that is aimed at user

21:05 → 21:08

testing, it's a totally

21:08 → 21:12

different prototype than the one I am creating where the

21:12 → 21:16

goal is, you know, to help the developers develop the app

21:16 → 21:18

or system or

21:21 → 21:22

the project.

21:22 → 21:25

Yeah? So what I mean by that?

21:25 → 21:28

So for example, if I go with the user testing,

21:28 → 21:32

as I said, I usually cover just the happy path,

21:32 → 21:35

meaning you agree, we agree together with the

21:35 → 21:39

client what has to be achieved, what do we want to test.

21:39 → 21:44

So let's say I have a booking platform and I want to

21:44 → 21:47

book a stay, a holiday,

21:48 → 21:49

my holidays, right?

21:49 → 21:53

So my main goal here is to do the booking.

21:53 → 21:57

So I do it interactively enough so that the user

21:57 → 22:00

thinks it's the actual thing, right?

22:00 → 22:04

But at the same time, I do not cover the edge cases.

22:04 → 22:08

I do not cover the possible errors in the system.

22:09 → 22:14

I don't cover most of the cases, I would say,

22:14 → 22:18

by that interactive prototype that is

22:18 → 22:21

actually for user testing.

22:21 → 22:23

Why? Because there is no need, actually.

22:23 → 22:26

We don't want to check every possible

22:26 → 22:30

scenario because the whole system

22:30 → 22:32

will test that.

22:32 → 22:37

So there is an extra work that is not needed at that point.

22:37 → 22:39

We want to check different things.

22:39 → 22:43

However, if I'm working hand in hand with

22:43 → 22:47

developers, they actually require from me different

22:47 → 22:48

states, right?

22:48 → 22:52

So different statuses of the system.

22:52 → 22:55

So how the system behaves in such or such

22:55 → 22:56

situation.

22:56 → 23:01

So this way I create some extra

23:02 → 23:06

pieces of prototype just so they know how the

23:06 → 23:09

behavior of the system should be reflected.

23:09 → 23:13

So I would say there are two different things.

23:13 → 23:17

Of course, the developers can use the interactive

23:17 → 23:20

prototype as a starting point.

23:20 → 23:23

And sometimes our clients come to us with the prototype.

23:23 → 23:25

And this is really cool actually,

23:25 → 23:29

because we know what we are talking about,

23:29 → 23:33

We know how they envisioned it.

23:33 → 23:37

There is also an extreme case in that

23:37 → 23:39

scenario, I would say.

23:39 → 23:42

So when the client covers every single

23:42 → 23:45

possible case, and the risk of that

23:45 → 23:50

being we go with them to the workshops and

23:50 → 23:52

we say, okay, this is perfect.

23:52 → 23:55

However, with the limited resources,

23:55 → 23:58

there is no way we can implement it.

23:58 → 24:01

So we need to cut a lot of functionalities.

24:01 → 24:04

And then the prototype, you know,

24:04 → 24:07

without some functionalities looks empty,

24:07 → 24:11

and the client is actually very used to how it looked

24:11 → 24:14

like as a full working product.

24:14 → 24:18

So that can be actually painful and we experienced this a

24:18 → 24:22

couple of times that well they actually envisioned it.

24:22 → 24:25

They drew this so

24:25 → 24:28

they treat it as an almost

24:28 → 24:32

finished product and then we just come to them and say

24:32 → 24:34

oh is this a must have?

24:34 → 24:38

So for the tough discussion

24:38 → 24:42

usually taking place during our product design workshops we say

24:42 → 24:45

together, not really, right?

24:45 → 24:47

So this is a very nice to have,

24:47 → 24:49

but not a must have.

24:49 → 24:53

And I'm smoothly, I guess, moving to the MVP approach,

24:54 → 24:58

which is also connected with hard decisions,

24:58 → 25:02

so cutting a lot of things out of the scope.

25:03 → 25:06

Guys, and this was the question that I wanted to address,

25:06 → 25:09

and especially I wanted to address to Rukash because I

25:09 → 25:14

know that you have your lesson learned in the ad tech world.

25:14 → 25:18

So the question would be how to

25:18 → 25:21

avoid going beyond MVP,

25:21 → 25:25

beyond the minimum viable product at the beginning

25:25 → 25:28

of, let's say, the design process and while, let's say,

25:28 → 25:29

releasing the product?

25:29 → 25:33

How to avoid involving too much of your resources,

25:33 → 25:37

of your manpower, of your funds beyond something that isn't

25:37 → 25:40

feasible at the moment for the market?

25:40 → 25:41

So

25:42 → 25:46

one important thing while building an MVP is to really

25:46 → 25:50

focus on those things that are highest priority,

25:50 → 25:53

not very important, but top priority, right, in the project.

25:53 → 25:56

So we need to pick feature or two,

25:56 → 25:58

but it all also depends on the project, right,

25:58 → 26:02

because sometimes it's not so easy and sometimes we are

26:02 → 26:06

even not able to build an MVP because

26:06 → 26:09

it's required to build full product to be competitive in

26:09 → 26:10

the market, right?

26:10 → 26:14

So it's not always like we go strictly

26:14 → 26:18

the path like POC, prototype, then MVP.

26:18 → 26:21

Sometimes we just need to build a product.

26:21 → 26:22

It's how it is. Right?

26:22 → 26:26

But answering your question, so too many times today and I

26:26 → 26:29

made this mistake as I said myself,

26:29 → 26:32

too many times these days we see MVPs release that are

26:32 → 26:36

released to market that they just try to do too much,

26:36 → 26:41

you know, they try to do too much at once and they do it all poorly.

26:41 → 26:45

And the very essential thing I think is that

26:45 → 26:46

the

26:47 → 26:51

purpose of MVP is to release it quick as quickly as possible.

26:51 → 26:55

But by this word quickly,

26:55 → 26:59

I don't mean reduction in time. I don't mean the reduction.

26:59 → 27:04

I mean actually reduction in the feature set and not the quality.

27:04 → 27:05

So

27:06 → 27:08

I don't know if it's answering your question,

27:08 → 27:12

but more or less I think MPP is, know,

27:12 → 27:16

at the first sight it's pretty easy to understand the concept.

27:16 → 27:19

We need to release something quickly, fast,

27:19 → 27:24

and something that we can validate later

27:24 → 27:27

on, finding our product market fit.

27:27 → 27:30

But it's not so easy in real life to just cut the scope

27:30 → 27:33

because the first time founders really have this tendency to

27:33 → 27:35

love the product so much,

27:35 → 27:37

they're obsessed with the product.

27:37 → 27:39

And the second time founders,

27:40 → 27:43

very often, they are focusing on other things like distribution

27:43 → 27:45

and this kind of matters.

27:45 → 27:48

So so, yeah, we need to have it in mind.

27:48 → 27:49

Okay, guys.

27:49 → 27:51

And what do you think

27:52 → 27:56

about the situation that we are actually dealing with every day?

27:56 → 27:59

I mean, we are approached by people who

27:59 → 28:01

are, let's say, specialists in their industries.

28:01 → 28:02

Right?

28:02 → 28:04

Generally, for example,

28:04 → 28:07

bread and butter of a company that we're working for is

28:07 → 28:09

custom software development.

28:09 → 28:13

Now we are approached by representatives of variety of

28:13 → 28:14

industries, right?

28:14 → 28:16

And how a person that is,

28:16 → 28:20

let's say more project oriented, but didn't spend,

28:20 → 28:23

let's say eight or twelve years only in FinTech or EdTech

28:23 → 28:26

or let's say any other industry,

28:26 → 28:30

just one single industry, how such person can potentially

28:30 → 28:34

support building the MVP, eliminating

28:34 → 28:37

unnecessary work features and so on,

28:37 → 28:41

and support decision making process of such a stakeholder.

28:41 → 28:43

So let me take this one.

28:43 → 28:48

So this is something we are working on during the

28:48 → 28:50

project design workshops.

28:50 → 28:53

I'm not a specialist in every single domain that I've

28:53 → 28:56

been working on in terms of design.

28:56 → 29:00

So this is normal I would say.

29:00 → 29:04

However, what we do and what supports us are the tools we have.

29:04 → 29:09

So we try to empathize

29:09 → 29:13

with the users as well as with the clients.

29:13 → 29:17

So one of the tools that is very broadly used by

29:17 → 29:19

us is creating the personas.

29:19 → 29:23

I'm sure everyone heard about this and think it's

29:23 → 29:25

a useful tool.

29:25 → 29:27

I hope so at least.

29:27 → 29:30

So by creating personas,

29:33 → 29:36

we get into end users' shoes.

29:36 → 29:40

So we understand what are the pain points of people who will

29:40 → 29:42

be the end users of

29:43 → 29:44

the solution.

29:44 → 29:47

What we also do and how we assist our

29:47 → 29:51

clients is trying to understand the

29:51 → 29:53

business model as well.

29:53 → 29:54

So

29:55 → 29:57

we don't have to be a specialist in every domain to

29:57 → 30:01

understand that some business models are more risky than

30:01 → 30:05

others, and we know this by experience

30:05 → 30:07

with the previous clients for example,

30:07 → 30:11

or as Wukash's first hand experience

30:11 → 30:14

as well is taken into account.

30:14 → 30:18

So another tool

30:19 → 30:23

that we sometimes are using is in

30:23 → 30:25

shaping the MVP.

30:25 → 30:29

What is important and what is not is, for example,

30:29 → 30:33

creating a matrix for our

30:33 → 30:36

users and comparing the functionalities.

30:36 → 30:38

What I mean by that is

30:39 → 30:43

we select, let's say, the core functionality,

30:43 → 30:48

the one that is crucial to the existence

30:48 → 30:51

of the system and gives the most value.

30:51 → 30:53

So by

30:54 → 30:57

comparing this one functionality with other

30:57 → 31:00

functionalities in terms of business value,

31:00 → 31:02

as well as, for example,

31:02 → 31:05

the complexity of creating it,

31:05 → 31:08

it's so much easier for our clients to make

31:08 → 31:09

the tough decisions.

31:09 → 31:12

So I like this, let's say I like

31:12 → 31:16

this functionality, but it's going to take twice as much

31:16 → 31:21

time as the functionality that is maybe good

31:21 → 31:25

enough for the very first version of the product.

31:25 → 31:27

And just one more thing.

31:28 → 31:31

As I said, we create the personas, right?

31:31 → 31:34

So sometimes it's better to actually

31:34 → 31:39

focus on your either primary persona being

31:39 → 31:42

a group of users that is the most

31:43 → 31:46

numerous, or the most important to you,

31:46 → 31:49

or giving you the most revenue, right?

31:49 → 31:51

So keeping that in mind,

31:52 → 31:56

it's easier to assist in that sort of tough

31:56 → 31:57

decisions.

31:57 → 32:01

And even if you don't know exactly

32:02 → 32:06

every single detail about a domain

32:07 → 32:09

that this project is about.

32:09 → 32:11

Okay.

32:12 → 32:14

Orkaz, anything to add?

32:15 → 32:17

Oh, I've been talking too much.

32:17 → 32:21

Okay, I think we've covered the basics.

32:23 → 32:25

Okay then, and

32:26 → 32:31

I will sorry, I will add one more thing and this is I

32:31 → 32:33

suppose a good piece of advice.

32:33 → 32:36

So we talked previously,

32:37 → 32:41

well, internally that it's great when people come

32:41 → 32:46

to us with a prototype because it gave

32:46 → 32:50

well, they have made a lot of effort for them

32:51 → 32:53

to create something.

32:53 → 32:58

So this is also something that the

32:58 → 33:02

investors are interested in because they understand you

33:02 → 33:05

have made a lot of effort to make this work, right?

33:05 → 33:07

Maybe you haven't developed it yet,

33:07 → 33:11

but still you have spent hours and hours on thinking

33:11 → 33:13

how this would work.

33:13 → 33:15

So this shows your persistence.

33:16 → 33:20

Testing the prototypes or the well,

33:20 → 33:23

your idea is actually a great

33:24 → 33:25

is a great

33:26 → 33:28

opportunity.

33:28 → 33:31

But this piece of advice I told you about.

33:31 → 33:35

So I would encourage everyone to actually maybe test

33:35 → 33:39

this this idea of yours maybe with not your

33:39 → 33:44

closest friends, because the thing is they like you, okay?

33:44 → 33:46

They don't want to disappoint you.

33:46 → 33:49

So if you test something with them,

33:49 → 33:53

I can almost ninety nine percent of cases,

33:53 → 33:56

they will say it's perfect.

33:56 → 34:01

And you want someone who is objective, right?

34:01 → 34:03

Maybe be difficult to,

34:04 → 34:08

let's say, look at your product, look at your design,

34:08 → 34:12

look at your concept in cold blood almost literally.

34:12 → 34:13

Exactly.

34:13 → 34:16

Because, you know, in the future when you develop it,

34:18 → 34:21

this is not just going to be your friends who just,

34:21 → 34:23

you know, say, oh, great job.

34:23 → 34:24

You've done so well.

34:24 → 34:26

It's going to be a lot of users,

34:26 → 34:29

and they might be demanding because if they are paying for

34:29 → 34:31

something, why shouldn't they?

34:31 → 34:35

Right? They They have some expectations.

34:35 → 34:38

So if you, well, test it with more

34:38 → 34:41

realistic, I would say, group of people,

34:41 → 34:44

it also gives you more valuable feedback.

34:45 → 34:48

Okay then. Thank you very much for this.

34:48 → 34:52

Guys, we have a little bit of questions

34:52 → 34:56

and answers section.

34:56 → 34:57

And there is Mr.

34:57 → 34:59

Andriy Bezugli

34:59 → 35:04

asking us about the expected duration of the of the

35:05 → 35:07

design sprint.

35:07 → 35:09

He's also asking about our pricing.

35:09 → 35:13

I would be glad to schedule a call with him and to discuss it further.

35:13 → 35:14

But, Katarzyna,

35:14 → 35:18

if you could tell put a little bit of light on the concept of

35:18 → 35:19

the design screen,

35:19 → 35:23

on the expected duration and everything around it.

35:23 → 35:27

I'm not sure about everything, but

35:27 → 35:28

okay.

35:28 → 35:31

So it usually takes a week.

35:31 → 35:36

And this is like a development of product

35:36 → 35:38

in one week.

35:38 → 35:41

So it's very short, and each day focuses on

35:41 → 35:44

different activity first empathizing with the

35:44 → 35:48

users, understanding what has to be done.

35:48 → 35:51

Then also there is a prototyping phase and

35:51 → 35:55

validating the ideas with the users, right?

35:55 → 35:58

So for example, if you want to

35:59 → 36:02

test the idea with the end users,

36:02 → 36:05

it's actually perfect to

36:06 → 36:09

if we go to the client

36:09 → 36:13

and test it in their natural environment because,

36:13 → 36:17

well, that's how people are going to use the

36:18 → 36:20

software, etc.

36:20 → 36:24

So this is like a whole

36:26 → 36:29

process of creating from idea to

36:29 → 36:33

some testing and feedback in just one week.

36:33 → 36:35

What I can add to this,

36:35 → 36:39

because I have a great experience with design sprints,

36:39 → 36:43

I just love them, and I always recommend founders,

36:43 → 36:46

if you are in this initial stage, idea stage,

36:46 → 36:48

you have this idea, this can be,

36:48 → 36:50

it's worth exploring maybe you think.

36:50 → 36:54

So I always recommend to start with the customer

36:54 → 36:57

development by Steve Blank.

36:57 → 37:01

First initial interviews with customers about the problem,

37:01 → 37:03

leave the solution part for later on,

37:03 → 37:07

and then just kind of stop in the middle after those first

37:07 → 37:10

initial interviews and do the design sprint.

37:10 → 37:11

It's a great exercise.

37:11 → 37:14

It will give you so much insights.

37:14 → 37:16

You have those

37:17 → 37:20

screens or wireframes or even clickable

37:20 → 37:22

prototype after the workshop.

37:22 → 37:26

It depends how you approach this because

37:26 → 37:28

there are many ways, right?

37:28 → 37:31

But totally recommend design sprint and then carrying on

37:31 → 37:33

with the customer development.

37:33 → 37:37

In my opinion, it's a perfect start for every idea

37:38 → 37:40

that you want to turn into a real product.

37:40 → 37:43

Okay. Thank you very much for that.

37:43 → 37:47

Guys, I think absolutely atomic question coming

37:47 → 37:49

from Berota Vytorak.

37:50 → 37:53

Our teammate, we're not hiding that fact,

37:53 → 37:57

she is asking about the eventual necessity of

37:57 → 38:01

going through all three steps that we

38:01 → 38:02

covered today.

38:02 → 38:06

So basically, proof of concept, prototype and MVP.

38:06 → 38:08

Do you think that every project,

38:08 → 38:12

every initiative requires demands basically

38:12 → 38:16

going through all three of those processes?

38:16 → 38:19

No, the simple answer

38:20 → 38:22

is no, of course not.

38:22 → 38:25

It all depends on stage of the product

38:25 → 38:28

development, what you want to achieve,

38:29 → 38:32

the markets, so many different factors.

38:32 → 38:35

But the short answer is really you don't need to go through

38:35 → 38:39

everything POC, then prototype, then MPP.

38:39 → 38:44

Sometimes you even I think you sometimes are not required to

38:44 → 38:45

do any of that.

38:45 → 38:49

You just can build a product if you want. It's possible.

38:49 → 38:52

However, highly unlikely.

38:53 → 38:58

Just one thing to add about the three stages.

38:58 → 39:02

It's not a continuum. We mix them. We mix them a lot.

39:02 → 39:03

So,

39:04 → 39:07

well, for example, maybe we did not highlight it enough,

39:07 → 39:09

but the proof of concept

39:10 → 39:14

idea is mainly used for for example technology or

39:14 → 39:17

solutions that are new, right?

39:17 → 39:21

So if you want to test the limits, test the feasibility,

39:21 → 39:23

then go for proof of concept.

39:23 → 39:26

But if you want a new, I don't know,

39:26 → 39:30

mailing solution, you know that there are like

39:30 → 39:33

thousands of them already existing.

39:33 → 39:36

You don't need to test if it's possible to do it.

39:36 → 39:40

You know it. So the same with prototype.

39:40 → 39:43

We can actually skip this space and use the

39:43 → 39:45

prototyping

39:47 → 39:51

technique while creating the MVP.

39:51 → 39:53

So it's well, no.

39:53 → 39:55

Short answer being still no,

39:55 → 39:59

we don't need all three of them as a continuum.

39:59 → 40:03

Yeah, and what I can add to this is even after, let's say,

40:03 → 40:07

after you launch your MVP, you're already in the market, right?

40:08 → 40:11

You can still have design sprints regarding the new

40:11 → 40:14

features that you want to introduce and show your clients.

40:14 → 40:15

It's not like it's finished.

40:15 → 40:18

It's finished right at this point and you just build something.

40:18 → 40:22

You can use prototyping, can use POC,

40:22 → 40:25

you can use design sprint or other workshops just to try to

40:25 → 40:29

validate every single feature if you want.

40:29 → 40:32

Sure, thank you very much guys.

40:33 → 40:37

I wanted to put a little bit of light on our

40:37 → 40:39

today's conversation.

40:39 → 40:43

First of all, I hope that our audience enjoyed

40:43 → 40:47

or took at least some takeaways from today's session.

40:47 → 40:51

We are not hiding the fact that today's session,

40:51 → 40:56

today LinkedIn Live, Merix Studio Live is a proof of concept.

40:56 → 41:00

Basically, and gentlemen, we are trying out a new way of

41:00 → 41:02

communicating with you, sharing knowledge,

41:02 → 41:05

something that we really, really love to do.

41:05 → 41:09

If you have any ideas in regards to what

41:09 → 41:12

kind of aspects, what kind of topics we could

41:12 → 41:17

potentially cover in upcoming sessions,

41:17 → 41:18

please let us know.

41:18 → 41:21

Currently they are not on regular basis.

41:21 → 41:23

We will be doing them quite ad hoc, but we really,

41:23 → 41:28

really hope that at some point we will be doing them quite frequently.

41:28 → 41:30

So if you have any ideas,

41:30 → 41:32

any questions related to the product design,

41:32 → 41:36

user experience, as well as other aspects of basically

41:36 → 41:38

agile project management,

41:39 → 41:42

service design, software engineering, front end,

41:42 → 41:46

back end, and basically developing mobile as well as

41:46 → 41:50

web products and services, please let us know.

41:50 → 41:52

We would be glad to hear it from you.

41:52 → 41:56

We are happy to cover those questions and the tougher questions,

41:56 → 41:59

more difficult questions are always more attractive and we

41:59 → 42:03

will receive them with gratitude basically.

42:03 → 42:04

Guys,

42:05 → 42:08

thank you very much for your time.

42:08 → 42:12

Thank you very much for sharing this knowledge together with us.

42:13 → 42:17

I hope that we will have a chance to

42:17 → 42:21

see you with you soon, and I hope that our audience,

42:21 → 42:24

you know, enjoy it as much as we did.

42:24 → 42:27

We hope so too and thank you very much.

42:27 → 42:30

Thank you very much guys. Take care.

42:30 → 42:32

Thank you, LinkedIn family. Have a great day.

42:32 → 42:37

US East Coast is probably showing up at the office while

42:37 → 42:39

Europe is looking to the watches,

42:39 → 42:41

thinking about leaving the offices.

42:41 → 42:44

Anyways, have a great day. Thank you. See you soon. Bye.

42:44 → 42:46

See you. Bye.

42:46 → 42:47

Bye bye.