The product tower

Trong phần này thì Hiếu sẽ share với mọi người một cái mô hình mà Hiếu gọi là Product Management Tower. Đây là một cái framework do Hiếu tự develop để mà Hiếu dùng mỗi khi Hiếu cần review lại một cái sản phẩm nào đó hoặc là kể cả một cái business nào đó luôn. Hiếu đặt tên cho nó là Product Management Tower bởi vì nhìn cái hình dáng nó sẽ giống như những cái tòa tháp, tí nữa mọi người sẽ thấy. Thì để minh họa cho cái model này thì Hiếu sẽ lấy Airbnb ra làm ví dụ. Tuy nhiên mọi người lưu ý rằng các cái data trong này chỉ là ví dụ thôi. Có thể nó sẽ không chính xác 100% với trường hợp cái business model của Airbnb. Cái lý do mà Hiếu chọn Airbnb là bởi vì hầu hết mọi người đều biết Airbnb là công ty nào và cái cách hoạt động của nó như thế nào. Do đó mọi người sẽ dễ hình dung hơn khi mà tiếp thu cái framework này. Nhưng again những cái data ở trong cái ví dụ này chỉ là nhằm mục đích minh họa cho mọi người hiểu được cái framework này thôi. Mô hình này có tổng cộng là 13 lớp. Trước đây thì nó chỉ có 11 lớp thôi nhưng mà gần đây thì Hiếu thêm vô 2 lớp về technical nữa nên nó có tổng cộng là 13 lớp. Lớp đầu tiên mà Hiếu gọi đó là Target Market. Thì gốc rễ của bất kỳ một cái business nào chúng ta làm nó phải là cái Target Market là cái thị trường mục tiêu mà chúng ta muốn hướng đến là cái gì. Trong trường hợp của Airbnb thì nó là Travel Industry. Họ sẽ không chọn những cái market khác như là ví dụ như là Logistics hay là Banking. Khi chọn một cái Target Market thì có 2 điều quan trọng nhất mà chúng ta cần phải lưu ý. Thứ nhất đó là expertise của chúng ta ở trong cái lĩnh vực đó, cái sự am hiểu của chúng ta ở trong lĩnh vực đó. Và thứ hai đó là cái độ lớn của cái market. Điểm thứ nhất thì là hiểu nhiên là chúng ta cần phải hiểu về một cái lĩnh vực nào đó thì chúng ta mới nhận ra đâu là vấn đề đang có ở trong lĩnh vực đó. Và bởi vì chúng ta hiểu về lĩnh vực đó nên chúng ta sẽ đưa ra được những cái solution cho những cái vấn đề đang còn tồn tại đó. Và xét cho cùng một cái business là chúng ta đưa ra một cái solution cho một cái vấn đề nào đó. Và thông qua đó người dùng trả tiền cho chúng ta để có được cái solution đó thì nó form lên một cái business. Tất nhiên là chúng ta còn rất là nhiều khía cảnh khác ở trong cái business. Nhưng cái cốt lỗi của một cái business chỉ là vậy thôi. Thì có rất là nhiều người chọn Target là dựa trên cái expertise. Tuy nhiên vấn đề mà một số người thường mắc phải là họ chỉ focus duy nhất cái điểm đó mà họ quên đi điểm thứ hai. Đó là cái phân tích về cái độ lớn của cái market đó. Vì sao cái điểm này là quan trọng? Bởi vì nếu market của chúng ta quá nhỏ thì nó sẽ dẫn đến một cái trường hợp là dù chúng ta có thành công, chúng ta dominate được cái market đó. Thì nó vẫn không đủ sức để chúng ta duy trì cái business của chúng ta bởi vì market nó quá nhỏ. Lúc đó chúng ta lại phải lay hoay để đi tìm một cái market khác. Lý tưởng nhất là chúng ta có một cái market đủ lớn. Tuy nhiên kể cả khi cái market nó nhỏ nhưng chúng ta có làm cái bước phân tích độ lớn của market thì nó cũng giúp chúng ta biết được cái market của mình nó đến đâu và có những cái bước chuẩn bị thích hợp. Thì đó là hai cái điều lưu ý của Hiếu khi chúng ta chọn một cái target market. Rồi sau khi chúng ta đã chọn được cái thị trường tiềm năng rồi thì chúng ta sẽ bước đến cái bước thứ hai là chúng ta phân khúc cái thị trường đó ra. Ví dụ như trong trường hợp này thì chúng ta sẽ chia ra thành 5 phân khúc. Thứ nhất là đối tượng trẻ em. Thứ hai là đối tượng trẻ. Và thứ ba là đối tượng gia đình. Thứ tư là đối tượng e-travel cho business. Và thứ năm là cái đối tượng luxury travel. Thì sau khi mà có được cái phân khúc này rồi thì chúng ta sẽ bước đến một cái bước tiếp theo nữa là chúng ta loại đi những cái phân khúc mà chúng ta không muốn phục vụ hoặc những cái phân khúc mà chúng ta không thể phục vụ. Ví dụ như trong trường hợp này thì cái đối tượng trẻ em là cái đối tượng mà chúng ta không muốn phục vụ. Bởi vì có thể là nó dựa trên những cái insight là đối tượng này khi mà đi du lịch thì thường là đi với lại gia đình hoặc là đi với lại trường. Và thường là gia đình hoặc trường đã sắp xếp cái nơi ăn chúng ở cho cái đối tượng này rồi. Và chúng ta không muốn touch vô cái phân khúc này. Ngoài ra luxury là một cái phân khúc mà chúng ta không thể phục vụ. Bởi vì khi mà họ đi du lịch thì cái đối tượng này có những cái yêu cầu rất là cao. Trong khi cái business model của Airbnb là dùng những cái phòng hoặc là những cái nhà của những cái user khác. Thì có thể nó sẽ không đáp ứng được những cái nhu cầu của cái đối tượng luxury này. Dẫn đến cái trải nghiệm của đối tượng này sẽ không tốt khi mà dùng cái dịch vụ của chúng ta. Do đó đây là những đối tượng mà chúng ta không thể phục vụ. Nghĩa là sau khi check mình xong thì chúng ta sẽ loại ra hai nhóm đối tượng. Một nhóm đối tượng là chúng ta không thấy tiềm năng và chúng ta không muốn phục vụ. Và một nhóm đối tượng khác là nhóm đối tượng mà chúng ta không thể phục vụ. Bởi vì khi phục vụ nó sẽ có tiềm ẩn cái nguy cơ là dẫn đến cái trải nghiệm không tốt cho cái đối tượng đó. Rồi sau khi đã loại ra hai nhóm đối tượng đó thì cái phần còn lại nó chính là cái tập khách hàng tiềm năng của chúng ta. Và từ đây chúng ta sẽ bắt đầu xây dựng lên những cái user persona. Thế thì user persona là cái gì? User persona là những cái profile đại diện cho những nhóm khách hàng có cùng behavior và cùng cái goal khi mà họ sử dụng cái sản phẩm của chúng ta. Trong đại đa số trường hợp thì cái phần segmentation mà chúng ta đã phân tích ở bước 2, nó sẽ reflect đâu đó khoảng 80% những cái user persona mà chúng ta có. Tuy nhiên nó sẽ không giống 100% bởi vì sẽ có những trường hợp là những cái persona của chúng ta nó nằm ở trong cái customer journey. Nhưng nó lại không thuộc vào bất kỳ 1 cái segment nào ở trong cái target customer của chúng ta. Bởi vì cái lý do là 2 cái phân nhóm này nó được phân nhóm dựa trên 2 yếu tố khác nhau. Cái phân nhóm về segmentation là nó phân nhóm dựa trên cái tiềm năng của người đó ở góc độ làm business. Còn trong trường hợp của user persona là nó được phân nhóm dựa trên hành vi và cái mục đích của họ khi sử dụng sản phẩm của chúng ta. Ví dụ khi chúng ta phân tích cái target customer ở 1 cái lượng mẫu đủ lớn thì từ từ chúng ta sẽ form lên những cái pattern về hành vi. Ví dụ như là chúng ta sẽ có 1 nhóm rất là am hiểu về những cái thiết bị digital. Bên cạnh đó thì chúng ta lại có 1 cái nhóm khác rất là kém trong việc sử dụng mobile. Thì đó là 2 nhóm hành vi khác nhau. Hoặc là chúng ta có những cái nhóm mà mục tiêu của họ là bút phòng càng nhanh càng tốt. Nhưng mà có 1 cái nhóm khác thì cái goal của họ là bút phòng càng rẻ càng tốt. Thì đó là những cái goal khác nhau. Và khi chúng ta có 1 cái lượng mẫu đủ lớn thì chúng ta sẽ form lên những cái nhóm như vậy. Đó là phân nhóm dựa trên hành vi và dựa trên goal của họ khi mà họ sử dụng cái sản phẩm của chúng ta. Ví dụ trong trường hợp của cái nhóm business travel thì sẽ có 1 số trường hợp là họ sẽ tự lên website của Airbnb để bút phòng. Tuy nhiên sẽ có trường hợp là thư ký của họ hoặc là phòng admin của công ty họ bút phòng cho họ. Thì trong cái ngữ cảnh này á, cái nhóm thư ký hoặc là cái nhóm admin đó rõ ràng là không nằm trong cái segmentation của chúng ta. Tuy nhiên họ lại là 1 cái đối tượng quan trọng trong cái customer journey. Do đó bắt buộc chúng ta phải xây dựng lên những cái persona cho cái đối tượng này. Thì sau khi mà có được cái bức tranh khá là rõ ràng về những cái người dùng của chúng ta là ai. Thì chúng ta mới bắt đầu bắt tay vô làm những cái công việc về research. Ví dụ như chúng ta có thể làm user interview, chúng ta mời họ đến để mà phỏng vấn họ. Hoặc là chúng ta có thể dùng shadow testing để mà xem những cái phản ứng của họ trong cái môi trường của họ như thế nào. Và thông qua đó thì chúng ta sẽ extract những cái thông tin mà có giá trị để dùng cho các cái bước tiếp theo. Trong đó có 1 cái loại thông tin khá là quan trọng, đó là những cái nhu cầu của họ, những cái needs của họ. Thì trong cái ví dụ này chúng ta có là khi mà những cái tập khách hàng tiềm năng của chúng ta đi du lịch thì đây là những nhu cầu của họ. Họ cần 1 nơi để ở, họ cần phương tiện để đi lại, họ cần bảo hiểm khi mà họ đi du lịch. Và họ cần tìm hiểu về chất lượng về những nơi mà họ sẽ đến. Họ cần tìm những cái hoạt động mà họ sẽ làm trong cái chuyến du lịch của họ. Cũng như những cái nơi mà họ sẽ ăn trong cái chuyến đi của họ. Ngoài ra họ cũng có nhu cầu tìm tour guide và bút vé máy bay hoặc là đổi tiền sang cái đơn vị tiền tệ của cái nước mà họ sẽ đến. Thì sau khi có được tất cả những cái nhu cầu của họ rồi thì chúng ta mới làm thêm 1 cái bước nữa là chúng ta sắp xếp những cái bước này theo thứ tự ưu tiên từ cái nhu cầu lớn nhất đến cái nhu cầu nhỏ nhất. Ví dụ trong trường hợp này là cái nhu cầu có 1 cái nơi để ở là 1 cái nhu cầu quan trọng nhất thì mình xót nó lên đầu. Thì sau khi mà mình biết được cái nhu cầu của họ rồi mình cũng đã phân cấp cái nhu cầu nào quan trọng hơn nhu cầu nào. Thì chúng ta sẽ bước qua được 1 cái phần thứ 6 là cái phần rất là quan trọng là chúng ta xác định đâu là những cái underserved needs. Đó là những cái nhu cầu mà họ cần nhưng mà lại đang không được phục vụ tốt bởi những cái dịch vụ hiện đang có. Nó chính là 1 cái term rất là quan trọng đó là những cái pain points mà user đang có. Thì bây giờ câu hỏi đặt ra là làm sao chúng ta xác định được underserved needs trong tất cả những cái needs của user. Thật ra nó rất là đơn giản. Chúng ta sẽ làm bằng cách đi ngược trở lại. Nghĩa là chúng ta sẽ loại đi những cái needs nào mà đã được served tốt rồi. Hoặc là chúng ta loại đi những cái needs nào mà nó nằm ngoài cái khả năng phục vụ của chúng ta. Thì ví dụ như trong trường hợp này là có cái nhu cầu đi lại. Thì cái chuyện đi lại đã được Uber serve rất là tốt rồi. Airbnb không nên touch vô cái mảng này nữa. Tương tự như vậy là cái việc review cho những cái điểm đến. Thì TripAdvisor đã làm quá tốt cho việc này rồi. Airbnb nếu có muốn thì nên hợp tác với TripAdvisor chứ không nên touch vô cái mảng này. Ngoài ra thì có cái phần là travel insurance. Thì nó lại nằm ngoài cái khả năng phục vụ của Airbnb. Bởi vì rõ ràng Airbnb không phải là 1 công ty bảo hiểm. Do đó nên dẫu rằng đây là 1 cái nhu cầu rất là quan trọng của người dùng. Nhưng nó nằm ngoài cái expertise của Airbnb. Nên Airbnb cũng sẽ loại nó ra. Và tương tự như vậy cho đặt vé máy bay và chuyển đổi ngoại tệ. Thì sau khi chúng ta đã loại bỏ những cái nhu cầu mà đang được serve tốt rồi. Và những cái nhu cầu nằm ngoài cái khả năng phục vụ của chúng ta. Thì nó còn lại gì? Nó còn lại là những cái nhu cầu đang không được serve tốt. Và nằm trong cái khả năng phục vụ của chúng ta. Nghĩa là chúng ta tin rằng chúng ta có thể serve tốt hơn với những gì mà thị trường đang có. Thì từ đây nó sẽ ignite lên 1 cái cơ hội kinh doanh đúng không nè. Vì rõ ràng là user đang gặp vấn đề. Bởi vì những cái dịch vụ ở trên thị trường không đáp ứng được yêu cầu của họ. Và chúng ta có khả năng là mang đến 1 cái giải pháp tốt hơn những cái gì mà họ đang được serve. Thì cái đó nó gọi là value proposition. Nghĩa là chúng ta propose cho họ 1 cái value mà khả dĩ sẽ giải quyết được những cái vấn đề mà họ đang gặp phải. Những cái pinpoint mà họ đang có ở đây. Thì thông qua cái việc mà match cái value proposition của chúng ta với cái underserved need của user. Nó dắt dây tới 1 cái khái niệm cực kỳ quan trọng không chỉ trong làm product. Mà cả trong cái việc mà điều hành 1 cái business. Đó là product market fit. Mọi người lưu ý cái term này cho thật kỹ. Bởi vì nó là 1 cái tín hiệu rất là quan trọng cho rất là nhiều cái hoạt động sau này. Ví dụ ở cái tầm chiến lược của công ty luôn chứ không phải chỉ của team product không. Sẽ đến 1 lúc chúng ta phải ra 1 cái quyết định là công ty có nên bắt đầu bước vô giai đoạn scale hay không. Và câu trả lời cho cái câu hỏi cực kỳ quan trọng đó là công ty đã tìm ra được cái product market fit chưa. Nếu chưa tìm ra được cái product market fit thì công ty không được bước vào cái giai đoạn scale. Bởi vì nếu chưa có cái đó bước vô càng scale càng chết. Thì ở đây Hiếu chỉ muốn lưu ý là cái product market fit là 1 cái term rất là quan trọng. Nó được dùng làm tín hiệu cho rất là nhiều cái hoạt động chiến lược cho các công ty. Rồi sau khi đã tìm ra được cái value proposition cho cái business của mình rồi. Thì lúc đó chúng ta mới bắt đầu nghĩ tới chuyện là ok. Với những cái value mà chúng ta dự định sẽ cung cấp cho khách hàng. Thì chúng ta cần sản phẩm gì và chúng ta cần những cái feature gì ở bên trong sản phẩm đó. Nhiều feature gọp lại thì nó gọi là 1 feature set. Cụ thể trong trường hợp này thì Airbnb quyết định là sẽ có 2 sản phẩm. Một là Airbnb cho family và thứ 2 là Airbnb for work. Trong cái phần về experience thì Hiếu ví dụ là họ sẽ có những cái feature như là listing, search, rồi highlight, rồi booking, rồi payment. Ví dụ là như vậy. Thì sau khi đã định nghĩa được về sản phẩm và về feature. Thì chúng ta mới bắt đầu nói đến câu chuyện là làm user experience như thế nào. Và bởi vì chúng ta đã đi qua những cái bước rất là vững chắc về nền tảng như vầy. Nên khi đến cái bước làm experience đó. Chúng ta mới thấy rõ là cái team làm user experience đó. Nó sẽ contribute vô một cái mục đích lớn hơn là chỉ là trải nghiệm. Đó là những cái gì mà họ làm ở đây đó nhằm cái mục đích là giải quyết một cái vấn đề gì đó cho người dùng. Chứ không chỉ đơn thuần là làm cho một cái trải nghiệm tốt mà thôi. Và tương tự như vậy. Sau khi mà nói xong câu chuyện user experience rồi. Thì chúng ta bắt đầu chúng ta làm user interface. Rồi những bước tiếp theo là chúng ta làm frontend. Và làm backend là những cái phạm trù về kỹ thuật. Thì đây là một cái bức tranh tổng quan về một cái mô hình làm sản phẩm. Một cách bài bản và hiệu quả. Tuy rằng nó qua rất là nhiều công đoạn. Nhưng nó hiệu quả. Và chút nữa Hiếu sẽ chứng minh cho mọi người xem tại sao nó hiệu quả. Và nhờ đó nó sẽ nâng cái tỷ lệ thành công của cái sản phẩm của chúng ta lên rất là nhiều lần. Bây giờ với cái bức tranh tổng quan như vầy. Thì chúng ta sẽ bắt đầu chúng ta nhìn lại là những cái team nào. Phụ trách những cái mảng nào ở trong cái tower này. Đầu tiên là cái phần móng gồm có thị trường tiềm năng là gì. Thì segmentation là như thế nào. Và target customer là ai. Thì cái phần này là công ty chúng ta sẽ đánh vô cái market nào. Hướng về những cái đối tượng người dùng như thế nào. Thì nó sẽ quyết định bởi cái executive team. Sau khi mà đã có một cái định hướng như vậy rồi. Thì những cái bước tiếp theo. Cái bước từ thứ 4 cho tới thứ 9. 6 cái bước này sẽ do team product management đảm nhận. Và bởi vì như vậy nên cơ bản chúng ta có thể form lên một cái job description cho cái bộ phần product management. Như sau. Team này phải là team luôn nắm bắt được sâu sát cái đối tượng người dùng của mình là ai. Để từ đó nắm được những cái nhu cầu của họ. Những cái pinpoint của họ. Kết hợp với cái am hiểu về những cái đối thủ trên thị trường đang làm gì. Cộng với những cái am hiểu về những cái khả năng của business của mình. Và từ đó form lên những cái quyết định là mình sẽ build cái chức năng nào hoặc sản phẩm nào. Để khả dĩ nó đem lại cái sát xuất thành công cao nhất trong công ty. Đó là trách nhiệm của team product. Nghĩa là cái tầng móng ở bên dưới này là cái team executive sẽ cung cấp cái cầu hỏi why. Tại sao chúng ta làm những việc này. Bởi vì cái thị trường này nó tiềm năng. Bởi vì cái thị trường này nó lớn. Bởi vì chúng ta có khả năng đánh vô cái thị trường này. Cái team product management là cái team sẽ trả lời câu hỏi what. Bây giờ đã có cái lý do tại sao chúng ta đánh rồi. Bây giờ chúng ta sẽ build cái gì để đánh vô cái thị trường đó. Và cái team UX và UI sẽ là cái team để trả lời câu hỏi là how. Chúng ta sẽ build nó như thế nào. Tuy nhiên mọi người để ý ở đây. Khi mà hiếu vẽ những cái đường này á. Ví dụ như team product management. Hiếu vẽ nên lấn sâu xuống bên dưới. Hiếu ở đây là tuy rằng trách nhiệm của họ là từ layer số 4 trở đến layer số 9. Tuy nhiên họ càng hiểu được sâu xuống bên dưới chừng nào thì càng tốt chừng đó. Và tương tự như vậy. Tuy rằng họ không trực tiếp làm user experience design. Nhưng họ cũng nên có những cái hiểu biết nhất định về user experience design. Và họ phải phân định rõ trách nhiệm chính của họ là ở đây. Họ hiểu biết ở đây. Họ hiểu biết những cái mảng này là để support cho những cái team này. Chứ không phải để dẫm chân lên những cái team bên trên. Tương tự như vậy cho UX design. Cần hiểu về những cái problem mà mình đang cố gắng giải quyết cho user. Cái business model của công ty là như thế nào. Tuy nhiên trách nhiệm chính của họ là trả lời câu hỏi là how to build it. Thì họ sẽ focus chính vào cái phần này. Và tương tự như vậy họ cũng cần phải có những cái hiểu biết về user interface. Để make sure là những cái gì mà họ define ra ở đoạn này. Nó sẽ được hiện thực hóa ở trong cái phần user interface. Tương tự như vậy cái team UI design cũng phải nắm được những cái hiểu biết về user experience design. Và frontend development. Để make sure là những gì họ design ở đây nè. Có thể build được cho phần frontend. Và suốt dọc cái quá trình mà làm tất cả những cái bước này. Chúng ta cần phải luôn luôn quay trở lại test và validate những cái hypothesis, những cái giả thuyết của chúng ta. Cái cách làm là chúng ta form lên một số cái idea hoặc là những cái giả thuyết. Và chúng ta phải liên tục test với user. Và chúng ta không phải là chúng ta đợi đến khi nào chúng ta có wireframe hay là có interface rồi chúng ta mới test. Chúng ta hoàn toàn có thể test ở những cái tầng sâu ở bên dưới này. Ví dụ như khi chúng ta form lên những cái value proposition. Lúc đó chúng ta hoàn toàn chưa có sản phẩm. Chúng ta vẫn có thể có cách để mà test với lại user. Xem những cái hypothesis mà chúng ta đang propose ở đây. Nó có chính xác hay không. Đó là lý do mà user research sẽ là một cái team chạy dọc theo nguyên cái quá trình này. Để support cho những cái team này. Nói support thì cũng không đúng. Để cùng phối hợp với các cái team này validate với user. Đó mới là cái cách làm user-centric product development. Bây giờ Hieu đi tiếp lên hai cái layer ở trên là về frontend và backend. Thật ra cơ bản nó cũng khá là rõ ràng rồi. Frontend do chính cái team frontend đảm nhiệm. Nhưng lý tưởng nhất là cái team frontend này cũng có những cái kiến thức về user interface design. Để khi mà họ build những cái design. Họ cũng sẽ lại tiếp tục contribute vô trải nghiệm của người dùng. Và họ cũng phải có một số cái hiểu biết nhất định về backend development. Để make sure là nó có thể integrate tốt với lại phần backend bên dưới. Tương tự như vậy backend cũng phải có những cái hiểu biết về frontend. Thì đó là một cái mô hình lý tưởng trong cái việc làm product development. Rồi. Chúng ta vừa qua một cái bức tranh rất là phức tạp về làm product. Thì để cho mọi người dễ hình dung. Thì Hieu có một cái ví dụ mà Hieu sẽ dùng xuyên suốt trong cái buổi training hôm nay. Mọi người hình dung cái việc build một cái product mới giống như việc chúng ta đóng một con tàu. Thì trong cái ví dụ này. Chủ hãng tàu chính là Board of Director. Cái người CEO chính là cái người điều hành hãng tàu. Còn những cái người stakeholder. Đó sẽ là những cái người vận hành cái con tàu, lái cái con tàu sau khi nó được đóng xong. Ví dụ như cái sản phẩm khi mà chúng ta build ra xong. Thì nó sẽ được vận hành bởi cái team operation. Thì trong trường hợp đó thì cái chief of operation sẽ chính là cái người thuyền trưởng lái tàu. Còn các nhân sự ở trong team operation đó là các cái thủy thủ vận hành con tàu. Thì product manager sẽ là người có am hiểu về cái việc đóng tàu đi bắt cá. Ví dụ họ nhận cái chiến lược là năm nay công ty chúng ta sẽ đi bắt cá ở cái vùng Nam Cực. Thì cái người phụ trách đóng tàu sẽ đưa ra những cái yêu cầu mà con tàu cần phải có. Ví dụ như là nó phải phá được băng. Nó phải đảm bảo được cái ấm áp cho các cái thủy thủ đoàn. Nó phải có những cái thiết bị đánh cá chuyên dụng trong cái vùng biển đó. Hoặc là nó phải có bao nhiêu cái thuyền cứu hộ. Rồi sau khi mà đã đưa ra được những cái yêu cầu đó rồi. Đến cái phần UX design. Thì họ sẽ bắt tay vô phân tích với các cái yêu cầu của product manager như vậy. Thì chúng ta sẽ thiết kế cái cấu trúc của con tàu này như thế nào. Cái layout của nó như thế nào để nó dễ điều khiển, dễ vận hành. Giúp cho những cái thủy thủ ở trong quá trình hoạt động được hiệu quả nhất. Ví dụ là để kéo một cái mẻ cá lên thay vì phải tiến hành qua 4 công đoạn. Thì họ chỉ cần phải làm qua 2 công đoạn thôi. Rồi UX cũng sẽ là cái team đưa ra những yêu cầu xuống cho cái bộ phần kỹ thuật. Ví dụ như là cái tốc độ thuyền phải đạt được bao nhiêu hải lý một giờ. Ở đây cần lưu ý rõ là UX chỉ đưa ra là nó phải đạt được bao nhiêu hải lý một giờ thôi. Chứ UX không đưa ra yêu cầu là cái team kỹ thuật phải gắn cái loại máy nào. Đó là chuyên môn của team kỹ thuật. Không được dẫm chân lên chuyên môn của người khác. Nhưng mình phải biết rất rõ là lý do tại sao mình đưa ra cái yêu cầu đó. Bởi vì ví dụ như là cần đánh một cái loại cá nhất định thì thuyền phải đạt được cái tốc độ đó. Thì mới bắt được cái loại cá đó. Đến cái phần UI Design thì họ sẽ là những người trực tiếp thiết kế các công tác điều khiển làm sao cho dễ điều khiển nhất. Hình dạng các cái cần gạt như thế nào, cách bố trí các cái vị trí cần gạt như thế nào, các nút bấm ra sao cho nó dễ bấm, dễ hiểu, dễ sử dụng. Và trong suốt quá trình đóng con tàu này thì chúng ta phải liên tục mời những người sẽ là user trong tương lai, là những người sẽ sử dụng con tàu đến để trải nghiệm thử, test thử con tàu, đưa ra những cái cảm nhận và ghi nhận lại những cái phản hồi của họ để đảm bảo là những gì chúng ta đang build sẽ đạt được cái kết quả tối ưu nhất. Thì đó chính là cái trách nhiệm của team User Research và Data Analyst. Thì cái mô hình như thế này nó gọi là cái mô hình làm User Centric Product Development, nghĩa là tất cả những gì chúng ta làm sẽ xoay quanh cái nhu cầu của người sử dụng.