Nguồn: https://www.youtube.com/watch?v=kMLgug3GrkU&t=449s
Physical product: Sản phẩm vật lý như ô tô, vật dụng, chiếc giày, túi xách,
Service Product: Bề mặt sản phẩm của The Coffee House là ly cafe (Physical Product), web, app (Digital Product). Bản chất sản phẩm của The Coffee House là 1 Service Product. Những sản phẩm khác (như ly cafe, web, app) chạy xung quanh Service Product đó.
Service Designer là những người làm Service Product.
Rất nhiều sản phẩm là sự kết hợp Physical Products + Service Products + Digital Products. Ví dụ máy tính Macbook, kết hợp cả 3.
Buổi conference này đi sâu về Digital Products, thông qua đó ta cũng biết cách làm những sản phẩm khác.
Cách tiếp cận thông thường của anh Hiếu: Why => How => Who => What. Hôm nay, anh Hiếu phá lệ bắt đầu bằng How, thông qua đó, từ từ anh Hiếu giúp chúng ta trả lời Why.
Làm sao để làm ra sản phẩm hiệu quả, mang lại xác suất thành công cao cho công ty.
Framework Product Management Tower: Model để review 1 sản phẩm hoặc thậm chí 1 business
Mô hình 13 lớp
Lớp 1: Target Market (All Markets)
Bất kỳ business chúng ta phải biết thị trường mục tiêu chúng ta muốn hướng đến là gì. 2 Điều cần lưu ý: (1) Our Expertise và (2) Market Size. Chúng ta phải có Expertise để hiểu sâu sắc lĩnh vực => Nắm bắt các problems => Có khả năng đưa ra Solution cho các Problems trong lĩnh vực ta chọn. Bản chất business là ta mang lại solutions cho các problems, thông qua đó khách hàng trả tiền cho chúng ta để có các solutions cho các vấn đề của họ.
Lớp 2: Segmentation
Chọn Target Market, chia nhỏ ra.
Phân nhỏ thị trường Target Market ra. Ta loại đi những phân khúc ta không muốn phục vụ hoặc phân khúc ta không thể phục vụ. Phần còn lại là những phân khúc tiềm năng ta cần tập trung.
Lớp 3: Target Customer
Những phân khúc sau khi đã loại bỏ.
Lớp 4: User Personas
User Personas là những profile đại diện cho những nhóm khách hàng, có cùng behavior và cùng goal khi họ sử dụng sản phẩm của chúng ta. Khi ta có lượng mẫu đủ lớn ta có thể form lên những pattern về hành vi: Ví dụ nhóm am hiểu về thiết bị digital vs nhóm kém trong việc sử dụng mobile; Ví dụ mục tiêu khác nhau: nhóm cần đặt nhanh vs nhóm cần tìm phòng rẻ.
Có những User Personas không thuộc Segment nào, nhưng thuộc Customer Journey. Ví dụ: Segment Business travel của Airbnb, nhóm thư ký/ admin không thuộc Segment, nhưng lại thuộc Customer Journey. Do đó, cũng cần xây dựng User Personas.
Lý do cho sự khác nhau giữa Segment và User Personal: Segment phân nhóm dựa trên tiềm năng của business. User Personas phân nhóm dựa trên hành vi và mục đích của họ khi sử dụng.
Khi có User Personas: Ta biết người dùng của chúng ta là ai, ta có thể mời họ làm User Interview hoặc Shadow Testing. Thông qua đó ta Extract những thông tin quan trọng cho những bước tiếp theo.
Trong đó có thông tin khá là quan trọng: Need.
Lớp 5: Needs
Thu thập nhu cầu (Need) của User Personas, sắp xếp các nhu cầu theo thứ tự từ lớn đến nhỏ.
Lớp 6: Underserved Needs (Pain Points)
Xác định Underserved Needs trong số các Needs của User Personas. Nhu cầu họ cần, nhưng chưa được phục vụ tốt bởi các dịch vụ hiện có.
Làm sao xác định Underserved? => Đi ngược: Loại đi những need đã được Overserved (được thị trường Serve tốt rồi) hoặc những need nằm ngoài khả năng phục vụ của chúng ta.
Lớp 7: Product Market Fit
Tồn tại connection mạnh giữa Underserved Needs và Value Proposition. Product Market Fit là tín hiệu quan trọng cho rất nhiều hoạt động sau này. Tín hiệu này trả lời cho câu hỏi có nên bước vào giai đoạn Scale hay không?
Tín hiệu cho rất nhiều hoạt động chiến lược của công ty.
Thông qua việc match Value Proposition với Underserved Needs => Dắt dây ra Product Market Fit.
Lớn 8: Value Proposition
Những Underserved Needs của khách hàng là cơ hội kinh doanh của chúng ta. Value Proposition là những giải pháp ta mang lại, giúp giảỉ quyết tôt Underserved Needs.
Value Proposition chính là những cái Value ta propose cho khách hàng, khả dĩ giải quyết được vấn đề của khách hàng.
Lớp 9: Product Feature Set
Khi đã tìm ra được Value Proposition rồi (giải pháp match với Underserved Needs), lúc đó ta mới nghĩ OK, vậy ta cần sản phẩm gì và features gì. Nhiều Features là Feature Set.
Lớp 10: User Experience
Khi đã thông các bước vững chắc, team UX sẽ không chỉ là làm cho người dùng có trải nghiệm tốt, mà team UX giúp người dùng giải quyết Underserved Needs.
Lớp 11: User Interface
Lớp 12: Front End
Lớp 13: Back End
Mô hình làm sản phẩm 1 cách bài bản và hiệu quả => Nâng tỷ lệ thành công của sản phẩm lên rất nhiều lần.
Bây giờ ta bắt đầu nhìn lại bức tranh tổng quát của Product Management Tower, để xem team nào phụ trách phần nào.
Lớp 1, 2, 3 Trả lời cho câu hỏi Why. Tại sao ta đánh/ tham gia thị trường này.
Lớp 4, 5, 6, 7, 8, 9 Trả lời cho câu hỏi What. Ta cần Build cái gì để đánh thị trường này.
Lớp 10, 11, 12, 13 Trả lời cho câu hỏi What. Ta Build như thế nào.
Liên tục test Hypothesis mà ta propose có validate hay không. Chúng ta không cần đợi có sản phẩm mới test, mà chung ta có thể test ở Value Proposition.
Ví dụ tàu đánh cá Nam Cực: User Centric Development
Product Manager có am hiểu về đóng tàu bắt cá. Ví dụ, Product Manager nhận “chiến lược” năm nay, sẽ đi bắt cá ở Nam Cực. Product Manager sẽ đưa ra yêu cầu như tàu phải phá được băng, đảm bảo ấm áp cho thủy thủ đoàn, có thiết bị đánh cá chuyên dụng trong vùng biển đó, có bao nhiêu thuyền cứu hộ.
Với yêu cầu của Product Manager như vậy, UX Designer sẽ thiết kế cấu trúc con tàu nhu thế nào, layout như thế nào để dễ điều khiển, dễ vận hành, giúp cho thủy thủ trong quá trịnh vận hành được hiệu quả nhất. Ví dụ để kéo 1 mẻ cá lên, thay vì 4 công đoạn thì chỉ cần 2 công đoạn. UX sẽ đưa ra yêu cầu cho đội đóng tàu là thuyền phải đạt bao nhiêu hải lý/giờ (UX không nên yêu cầu team kỹ thuật gắn loại máy nào, đó là chuyên môn của team kỹ thuật, không đ7ợc dẫm chân lên chuyên môn của người khác). UX cần biết rất rõ là lý do vì sao đưa ra tốc độ này, ví dụ cần đánh 1 loại cá nhất định.
UI Designer là người trực tiếp thiết kế công tắc điều khiển, nút bấm, bố trí cần gạt. Để thủy thủ dễ hiểu, dễ sử dụng.
Trách nhiệm của User Research và Data Analyst: Trong quá trình đóng tàu, cần liên tục mới User trong tương lại đến để trãi nghiệm, test thử con tàu, đưa ra thử cảm nhận, và ghi nhận lại những phản hồi của họ, để đảm bảo những gì ta đang build đạt kết quả tối ưu.
Founder đưa ra yêu cầu cho UI Design. Thậm chí, founder trực tiếp làm UI Design. Khi công ty mở rộng, nhưng vẫn theo model cũ. Nghĩa là nhiều ông Executive cùng đưa ra yêu cầu cho UI Design.
Mô hình Top-down Model: CEO và Executive team là những người có nhiều kinh nghiệm nhất định về User Needs, từ đó, họ tự đưa ra một số Product Ideas.
Có 2 rủi ro lớn nhất cho mô hình này:
- Chỉ cần 1 bước sai, toàn bộ sẽ sai. Khâu tốn kém nhất là khâu Build nằm ở cuối. Chỉ cần 1 bước sai, toàn bộ bước Build sẽ lãng phí.
Team Executives dù có kinh nghiệm đến mấy, dù họ đúng vài lần, chỉ cần sai 1 lần là chết.
2. Cách họ research
Khi họ nhìn đối thủ, họ chỉ nhìn thấy lớp bên trên User Interface. Họ không thể nhìn thấy lớp bên dưới là tạo ra để làm gì, hoặc chỉ đoán sơ bộ. Do đó, những quyết định làm sản phẩm nào, feature nào hoàn toàn là cảm tính.
Toàn bộ công ty sẽ dựa vào sự đúng đắn của quyết định của 1 người, thay vì dựa vào User.
Hầu như ai cũng nghĩ mình đều có năng lực làm sản phẩm. Bất kỳ ông nào trong công ty cũng đều rất hăng hái chỉ cho team sản phẩm là nên làm thế này, nên làm thế kia.
Ra được sản phẩm vs Ra sản phẩm đúng nhu cầu.
Những chi phí, sự phức tạp của quy trình bài bản, thời gian lâu, khó quản lý => Chỉ để đánh đổi 1 thứ: Tăng xác suất đưa ra sản phẩm đúng. Đúng sản phẩm mà người dùng cần.
Trách nhiệm công việc của team UX, UI, Product Management và Technical
Trách nhiệm của người làm Product Management chỉ gói gọn trong 1 câu: PM make sure là cả công ty không xây 1 sản phẩm tuyệt vời về UI, tuyệt vời về trãi nghiệm, nhưng mà end up là không ai cần.
Ví dụ công ty có team design mà không có team sản phẩm: sản phẩm lộng lẫy, nhưng không giải quyết vấn đề cho người dùng, nên kết quả là sản phẩm đó fail.
Để trả lời được câu hỏi này thì ai cũng trả lời được, nhưng để trả lời đúng thì cực kỳ khó. Đó là lý do ai cũng nghĩ mình làm sản phẩm được.
Giữ the RIGHT thing và the WRONG thing là câu chuyện mang tính sống còn cho cả công ty. Câu hỏi này quá quan trọng nên việc trả lời câu hỏi này phải được thực hiện cực kỳ cẩn thận, cực kỳ khoa học và phải có chuyên môn để làm việc đó.
Vậy team product làm việc này như thế nào?
Là người tìm ra điểm cân bằng giữa 2 nhóm đối tượng:
1 Đằng là đảm bảo sự hữu dụng cho người dùng (giúp họ giải quyết được vấn đề một cách tốt nhất)
1 Đằng đảm bảo lợi nhuận cho business
Việc quyết định điểm cân bằng này không phải được đưa ra bởi cảm tính, mà phải dựa trên khoa học, dựa vào số liệu, dựa vào insight và hàng loạt kỹ thuật chuyên môn.
Để Form ra các quyết định, họ không thể làm một mình, mà bắt buộc phối hợp với rất nhiều bộ phận khác trong công ty => [Kỹ năng làm việc với các stakeholder]
Họ phải kéo các bộ phân khác đi đúng quy trình làm sản phẩm, để đảm bảo làm sản phẩm hiệu quả nhất.
Cuối cùng, KPI chính là product đó có thành công hay không.
Trong 6 yếu tố này, anh Hiếu đào sâu Insight
https://youtu.be/kMLgug3GrkU?t=3349Quantitative Data:
Những data dựa trên số lượng lớn. Đa số các công ty đều có số liệu Quantitative, tuy nhiên có sai lầm đa số các công ty mắc phải là họ dựa hoàn toàn trên các Data này và họ cố gắng lý giải mọi thứ dựa trên Quantitative Data. Trong khi Quantitative chỉ trả lời được một nửa bức tranh. Quantitative Data chỉ trả lời được câu hỏi Who, What, When, Where. Còn câu hỏi Why và How thì không trả lời được.
Ví dụ: Quantitative cho chúng ta biết số lượng đặt hàng Online tăng đột biến trong khung giờ từ 2 đến 4 giờ, ở khu vực trung tâm Quận 1. Nhưng nó không thể trả lời cho ta câu hỏi tại sao lại như vậy. Nó cũng không trả lời được câu hỏi những người này đã suy nghĩ gì, cảm giác họ như thế nào.
Do đó, ta cần loại Data thứ 2. Đây là loại Data thiên về chất lượng, không thiên về số lượng. Việc extract Qualitative Data hoàn toàn khác với Quantitative Data, sử dụng những kỹ thuật hoàn toàn khác.
Làm product mà không có Data, thì giống như chạy xe ban đêm mà không có đèn. Cảm giác rất khủng khiếp khi không biết mình đang đi về đâu. Vậy mà có rất nhiều công ty đang hoạt động mà gần như không có Data gì trong tay.
Data rất quan trọng trong việc làm product theo phương pháp User Oriented Product Development, nên bên cạnh team product luôn có 2 team song hành, là team Data Analyst và team User Research.
Nếu nhìn vào đây thì thấy rằng dù là sản phẩm Online hay Offline, dù physical hay digital thì cách quản trị sản phẩm đúng nghĩa theo phương pháp User Centric Product Development đều là như nhau. Nó chỉ khác ở khúc build.
Những người có hiểu biết về ngành hoặc trong ngành sẽ có lợi thế trong việc làm product management. Ví dụ người có hiểu biết về ngành thời trang sẽ có lợi thế trong quản trị sản phẩm fashion. Tuy nhiên, đó chỉ là “nice-to-have”. Vì xung quanh những người làm product management sẽ luôn có những chuyên gia trong các lĩnh vực về chuyên môn. Việc chính của người làm product management không phải là để ngồi xuống đi pha ly cà phê, ngồi xuống để design cái app.
Việc chính của họ là quản trị process để đưa ra quuyết định là sẽ build những sản phẩm nào. Đó là lý do người ta gọi họ là product manager, không phải là product builder hay product designer.
Customer Journey Map
UX Designer để gối đầu giường. Customer Journey Map collect tất cả touch point của khách hàng, map lại theo trình tự chính xác với thực tế nhất. Từ đó, ta bắt đầu define ra những chỉ số đo lường cho từng loại touch point, bởi vì không phải touch point nào cũng có chỉ số đo lường như nhau.
Từ đó ta xác định những điểm nào tròng Customer Journey Map perform chưa tốt, sau đó có những giải pháp nâng trải nghiệm touch point lên. Đồng thời, đảm bảo những touch point khác trong toàn bộ trải nghiệm không bị ảnh hưởng.
Cách tổ chức team
Mô hình Silo chia team theo chuyên môn. Điểm yếu của mô hình Silo: Mô hình này rất khó để Scale.
Mô hình “Product Team” không chia team theo chuyên môn, mà chia team theo product. Ví dụ, AirBnB có team chuyên phụ trách về Mobile App. Trong team này có người lo về Product Management, UI, IX, Front-end, Back-end, đây là core team. Core team này được assign cho 1 project, trong trường hợp này là Mobile App. Ngoài ra, chạy vòng ngoài sẽ là các thành viên không thường trực, họ thuộc các team khác, ví dụ Marketing hay Legal, họ sẽ cung cấp insight trong lĩnh vực của họ mỗi khi core team cần. Core team này là team theo ý nghĩa vật lý, họ chuyển chỗ về ngồi gần nhau, làm việc cùng nhau, vui chơi giải trí cùng nhau. Sản phẩm team này phụ trách là cố định, gần như họ sẽ ăn ngủ, sống chết với sản phẩm đó.
Một thành viên trong Product Team, đồng thời thuộc team Tech (ví dụ). Để mỗi khi có vấn đề cần cố vấn chuyên môn, họ quay về họ hỏi thành viên trong team tech. Nghĩa là đồng thời họ cũng có mối liên hệ với team chuyên môn của mình.
Mô hình này mang lại nhiều lợi ích về mặt quản trị:
Motivation: Team này được trao quyền, góp ý kiến vào sản phẩm. Do đó họ có cảm giác đó chính là đứa con tinh thần.
Responsibility: Tinh thần trách nhiệm cao, do họ là 1 phần trong sự thành bại đó
Autonomy: Tính tự chủ cao do họ được trao quyền. Những gì họ làm phản ánh cụ thể vào sản phẩm cuối cùng. Nên mọi thành viên đều mong muốn đóng góp vào bức tranh chung.
Expertise: Do quanh năm suốt tháng họ chỉ làm 1 sản phẩm, nên chuyên môn về 1 sản phẩm của họ rất sâu. Khác với mô hình Silo, nay được assign project này, mai assign project khác.
Reward: Mô hình Silo cha chung không ai khóc.
Experience: Họ nắm từng ngóc ngách, từng dòng code, nên có vấn đề là họ xử lý được. Nếu có vấn đề, họ cũng học được kinh nghiệm và tránh sai lầm quá khứ.
Không ai dẫm chân lên ai do trong team nhỏ, phân chia dể hơn.
Squad chịu trách nhiệm sản phẩm, 1 tiểu đội gồm đầy đủ thành viên từ Product management, UI, UX, Dev
Tribe là bộ lạc, gồm các Squad có đặc điểm chung
Chapter là những người có cùng chuyên môn, support lẫn nhau về chuyên môn. Theo hàng ngang. Ví dụ, những người làm UX design sẽ report daily về cho hàng dọc Product Team. Nhưng về chuyên môn thì sẽ được support bởi hàng ngang. Những người lead về chuyên môn sẽ có hoạt động support và nâng cao kỹ năng chuyên môn.
Theo anh Hiếu, tại Việt Nam có 1 số công ty triển khai theo mô hình này, và họ hiện đang hoạt động rất tốt. Cá nhân anh Hiếu khi làm ở Bain, một trong những trách nhiệm chính là giúp công ty transform từ mô hình cũ sang mô hình mới. Từ đó anh Hiếu chứng kiến những thay đổi rất tích cực sau khi họ transform xong. Do đó, cá nhân anh Hiếu tin rằng đây là mô hình rất hiệu quả để các công ty nên đầu tư triển khai.