Reforge từ lâu đã là một địa chỉ học tập đáng tin cậy cho các bạn đang làm Growth và User Acquisition nói riêng và Product nói chung. Vì Reforge nhắm đến phân khúc khách hàng là lãnh đạo và quản lý sản phẩm cấp cao, nên chi phí học đắt đỏ, vì thế ở Việt Nam tôi ít thấy có nhiều người học hoặc chí ít cũng chưa nghe nhắc nhiều ở các cộng đồng sản phẩm. Nếu bạn quan tâm có thể tìm hiểu tại Reforge Plan hoặc email tôi về địa chỉ hoangtung240195@gmail.com, tôi sẽ gửi bạn tham khảo một vài tài liệu từ khoá học mà tôi may mắn có được.
Dù chi phí khoá học cao, rất may là vẫn có thể tìm thấy nhiều tài liệu miễn phí chất lượng từ blog của Brian Balfour, sáng lập của Reforge, về chủ đề Growth, Strategy & User Acquisition cũng như Reforge Blog và Reforge Artifacts mà tôi sẽ giới thiệu trong bài này.
Các bài đăng trên blog của Brian Balfour. Ảnh: Hoàng Tùng
Về Reforge Artifacts
Trước hết, phải xin thẳng thắn rằng có rất nhiều người giỏi nhưng vì giới hạn thời gian và nhiều rào cản mà không phải ai cũng có thể chia sẻ những kinh nghiệm, kiến thức và kể cả sai lầm của mình một cách rộng rãi. Riêng tôi thì blog này cũng là một nổ lực lớn, tôi không nghĩ mình giỏi hay viết hay, chỉ mong viết ra những gì mình biết để mong có ích cho 1-2 người là đã thấy vui. Vì vấn đề này, cho nên ngoài các cuốn sách, khoá học nhỏ, một số chia sẻ trên Youtube thì đa phần vẫn học qua thực tiễn công việc và đồng nghiệp. Kiến thức, tài liệu chưa được lan truyền mạnh mẽ.
Quay trở lại Reforge, là nơi có lợi thế là có đội ngũ giảng viên từ các công ty công nghệ lớn trên thế giới như Hubspot, Dropbox, Lift, Uber, Netflix, v.v.. và các thành viên cũng chất lượng đến từ các công ty công nghệ, khởi nghiệp toàn thế giới. Tận dụng lợi thế này, gần đây Reforge cho ra đời chuyên trang gọi là Artifacts, tại đây các đội ngũ giảng viên, học viên của họ chia sẻ các tài liệu thực tế trong quá trình làm việc của mình như Product Roadmap, Go-to-market Strategy, Strategy, Pitch Deck, v.v..
Một số giảng viên các chương trình của Reforge. Ảnh: Hoàng TùngTài liệu trên trang Reforge Artifact. Ảnh: Hoàng TùngChi tiết một tài liệu chia sẻ về Product Market Fit Score Driven Product Strategy và lý do tại sao có tài liệu này từ tác giả Nik Simak khi làm việc ở SideKick Browser, đi kèm các chú giải của tác giả. Ảnh: Hoàng Tùng
Bạn sẽ thấy rằng các tài liệu này rất đa dạng về phương pháp, đa dạng về cách trình bày và đa dạng về đối tượng sử dụng. Không như các template chung, các tài liệu này thể hiện rõ công ty và vai trò của người viết cộng thêm các chú giải trên các ví dụ khá sát thực tế sẽ giúp chúng ta dễ dàng hình dung bức tranh toàn cảnh. Từ đó khi áp dụng cho trường hợp của mình sẽ không bị miễn cưỡng và gò bó.
Cũng xin nói rằng, những tài liệu trên vẫn là đang áp dụng cho các công ty ở phương Tây. Mặc dù Việt Nam đi sau và rất nhanh chóng học tập cái mới nhưng còn nhiều điều kiện về thị trường, con người khác xa với thị trường quốc tế. Vì vậy, tôi nghĩ rằng khi dùng những tài liệu mẫu này để áp dụng ở nước ta, luôn phải cẩn thận. Có khi là những thử nghiệm và điều chỉnh phù hợp với đặc thù của riêng mình.
Nhân đây, tôi cũng mong tương lai cộng đồng chúng ta sẽ có những nơi như vậy để anh em cùng chia sẻ tài liệu để học hỏi lẫn nhau và nâng cao năng lực không thua kém ngoài kia.
Trong Quản Lý Dự Án (Project Management) mô hình Project Managemement Triangle) thường được sử dụng để đánh giá nguồn lực dựa trên ba yếu tố Time, Scope, Cost. Bởi vì thời gian là hữu hạn, chi phí có hạn nên việc xác định Scope là cực kì quan trọng. Và việc này càng quan trọng hơn với các sản phẩm start-up, khi mà nguồn lực không dồi dào và việc đánh giá mức độ ưu tiên một cánh đúng đắn của các mục tiêu và hành động giảm thiểu tỉ lệ thất bại của dự án.
Có nhiều cách để mô hình hoá và đánh giá mức độ ưu tiên của các công việc. Trong bài viết này, tôi muốn giới thiệu một mô hình giúp đánh giá mức độ ưu tiên hiệu quả đó là RICE Scoring Model.
RICE viết tắt của bốn yếu tố Reach (Độ tiếp cận), Impact (Độ ảnh hưởng), Confidence (Độ tự tin) và Effort (Công sức) khi nhìn nhận Ideas/Solutions/Actions mà trong bài viết này tôi gọi chung là Item.
Ý tưởng cơ bản của RICE Model là đánh giá Priority (Độ ưu tiên) của các Item dựa trên bốn yếu tố kể trên, để từ đó có sắp xếp sự ưu tiên hợp lý, tối ưu hoá nguồn lực để đạt đượt kết quả tối đa với nguồn lực có hạn.
RICE SCORE
Với mỗi Item, chúng ta sẽ đánh điểm theo RICE Score.
RICE Score = Reach (R) x Impact (I) x Confidence (C) / Effort (E)
Tiến hành sắp xếp các Item theo RICE Score chúng ta sẽ có danh sách các Item để từ đó đánh giá mức độ ưu tiên một cách nhanh và hợp lý hơn.
Reach (Độ tiếp cận)
Số lượng users chịu ảnh hưởng của giải pháp trong một khoảng thời gian nhất định.
Ví dụ:
10k users mới cài app trong 1 tháng.
Có hai cách cơ bản để tính Reach
1. Dựa vào số liệu thực tế đã thu thập được
Ví dụ : Trong tháng 1/2022, dữ liệu từ Google Analytics cho thấy có 10k new users. Nếu công ty vẫn duy trì ngân sách UA và eCPI không có nhiều biến động, qua tháng 2 dự kiến vẫn sẽ có 10k new users.
2. Tính toán dựa trên số liệu đã có hoặc phỏng đoán
Ví dụ: Sản phẩm chưa triển khai nhưng ở lĩnh vực này trung bình eCPI là $1. Công ty dự kiến sẽ bỏ ra $10k/tháng để chạy UA (User Acquisition Campaign). Giả sử CPI = $1 → Sau 1 tháng sẽ thu về 10k installs.
Impact
Impact thể hiện mức độ ảnh hưởng của giải pháp. Với Impact, chúng ta có thể nhìn lại các Key Metrics chính mà sản phẩm đang hướng tới để có phương pháp ước tính cho phù hợp.
Ví dụ:
Item 1: “Tăng tỉ lệ users hoàn thành bước Onboarding từ 50% lên 75% bằng cách thêm hướng dẫn sử dụng”.
Item 2: “Tăng tỉ lệ users mua gói 1 Year Subscription để sử dụng app từ 5% lên 10% bằng cách bổ sung thanh toán qua VISA”.
Nếu xét trên tiêu chí Revenue (Lợi nhuận) thì rõ ràng Item 1 có Reach cao hơn nhưng Impact lại không bằng Item 2.
Sau khi có phương pháp đánh giá Impact của từng Item, chúng ta có thể dùng thang đo để thể hiện mức độ quan trọng của từng Item:
3 điểm ➢ Massive Impact
2 điểm ➢ High Impact
1 điểm ➢ Medium Impact
0.5 điểm ➢ Massive Impact
0.25 điểm ➢ Minimal Impact
Confidence
Với mỗi Item, đôi khi chúng ta thấy chúng thực sự mang lại Impact lớn nhưng không đủ dữ liệu để chứng minh. Confidence là yếu tố giúp chúng ta
Với Confidence hãy dùng thang đo sau:
100% ➢ High confidence
80% ➢ Medium confidence
50% ➢ Low confidence
Với những Item có mức độ confidence cực thấp <50%, hãy giành thời gian để tìm thêm dữ liệu cho Item đó để tăng confidence hoặc đơn giản là để Item nguyên ở đó với Confidence Score = 0 để đánh giá ở các Phase sau khi chúng ta đã có đủ dữ liệu. Dữ liệu ở đây có thể là metrics sản phẩm đang có, quantitative data từ primary/secondary research, published papers, case study, expert advising, learnings from other products, etc.
Effort
Là tổng thời gian để hoàn thành Item theo dự kiến bao gồm nguồn lực từ nhiều team chức năng như Product, Marketing, Engineer, etc.
Effort có thể lấy đơn vị theo person-months (tổng số người cần cho N tháng) hay man-months (tổng thời gian làm việc cần cho N tháng).
Ví dụ:
Với Action Item “Tăng tỉ lệ users mua gói 1 Year Subscription để sử dụng app từ 5% lên 10% bằng cách bổ sung thanh toán qua VISA” cần: 1 Product Owner 0.5 tháng, 1 UI Designer 0.25 tháng, 1 Back-end 0.5 tháng, 1 Mobile Developer 0.5 tháng ➣ Total: 1.75 person-month
Khi nào có thể áp dụng RICE Scoring Model?
Đa phần với các giai đoạn hay mô hình phát triển sản phẩm như Agile, Waterfall hay Design Thinking ở các giai đoạn cần đánh giá Priority của các Item đều có thể áp dụng RICE Scoring Model.
Kinh nghiệm áp dụng RICE Scoring Model
Lý thuyết có thể dễ học, tuy nhiên việc áp dụng cho từng trường hợp sản phẩm, team, công ty luôn luôn đòi hỏi sự khéo léo của Product Manager.
Qua quá trình áp dụng trong các sản phẩm mà tôi từng làm việc, có một số kinh nghiệm sau:
Tìm cách chia sẻ kiến thức, case study trước khi khi áp dụng thực tế. Hoặc ít nhất hãy cho các stakeholders thời gian để tìm hiểu, đặt câu hỏi và nhận được dự đồng thuận của team.
Thống nhất phương pháp đánh giá các yếu tố Reach, Impact, Confidence, Effort.
Ưu tiên các stakeholders tham gia vào việc đánh giá RICE là những người có authority để make decisions. Điều này để đảm bảo thời gian planning không bị chia ra quá nhiều giai đoạn và phải giải thích, đàm phán lại Score khi đến mức cao hơn.
Đảm bảo số lượng stakeholders tham gia đánh giá RICE không quá nhiều và vừa đủ. Ví dụ: 1 leader/manager từ mỗi team Product, Marketing, Technical, etc.
Áp dụng RICE Score một cách mềm dẻo và các item cần được rà soát, điều chỉnh thường xuyên ở mỗi đợt review & planning như Sprint Planning/Bi-weekly Review/Quarterly Review & Planning, etc.
Với 4 yếu tố Reach, Impact, Confidence, Effort hoàn toàn có thể đi sâu hơn và có sự đánh giá chính xác hơn nhưng điều này cũng đồng nghĩa với sự phức tạp và thời gian tăng lên. Cho nên tuỳ trường hợp mà Product Manager cần quyết định phù hợp.
ICE Score
Trong những những hợp nguồn dữ liệu chưa sẵn có hoặc chưa đảm bảo độ tin cậy. Một biến thể của RICE Scoring là ICE Scoring thường được áp dụng, ở đây chúng ta loại bỏ Reach trong công thức tính.
RICE Scoring Model không phải là phương pháp đánh giá Priority tốt nhất và theo tôi không có phương pháp nào là tốt nhất. Có nhiều model để đánh giá Priority, mỗi phương pháp sẽ phù hợp cho từng trường hợp nhất định. Chúng ta nên biết và tuỳ trường hợp mà chọn lựa để áp dụng cho hiệu quả.
Xin liệt kê một số mô hình khác để bạn tìm hiểu thêm:
Cost of Delay (CoD)
Kano Model
MoSCoW (Must Have, Should Have, Could Have, Won’t Have)
Bài này tôi có vài đúc kết về công việc hàng ngày của Product Owner kinh nghiệm của tôi và các bạn bè trong ngành. Mục đích là nhằm cung cấp thêm góc nhìn cho các bạn quan tâm và cần tìm hiểu thêm về công việc này.
Cá nhân tôi tự thấy may mắn khi từng trải qua các công ty có tính chất và lĩnh vực khá đa dạng như Software Outsourcing (Gia công phần mềm), Nông nghiệp (Agritech), Quản lý nhân lực (HRM), Du lịch (TravelTech), Thương mại điện tử (E-Commerce), Giáo dục (EdTech), Game. Mặc dù chức danh có thể thay đổi nhưng vai trò và nhiệm vụ của một Product Owner (PO) vẫn chiếm khá nhiều thời gian trong những gì tôi làm.
Tôi sẽ chia các công việc theo tần suất: Hàng ngày (Daily), Hàng tuần (Weekly)/Mỗi hai tuần (Bi-Weekly), Hàng quý (Quarterly) để mọi người dễ hình dung.
Daily
Các đầu việc diễn ra hàng ngày của PO không khác nhiều so với các thành viên khác của Development team (nhóm phát triển).
Cập nhật tiến độ công việc hàng ngày với đồng đội: thường diễn ra vào buổi Daily Stand-up (buổi họp nhanh kéo dài tối đa 15 phút đầu ngày để mỗi người cập nhật: Hôm qua làm gì? Hôm nay làm gì? Vấn đề phát sinh cần được hỗ trợ)
Tham gia các cuộc họp đã lên lịch định kỳ hoặc không định kỳ với Development team, Stakeholders (Các bên liên quan có ảnh hưởng đến dự án), Users (Người dùng sản phẩm) hoặc Clients (Khách hàng).
Tham gia thảo luận các vấn đề liên quan đến công việc trên các ứng dụng chat nhóm như Slack/Discord/Skype.
Giải quyết các Ad-hoc Tasks (Các công việc đặc biệt, phát sinh không có kế hoạch nhưng quan trọng). Có thể là bổ sung trường hợp thiếu sót trong Product Requirement Document (Bản mô tả sản phẩm) để bạn Developer tiếp tục coding hay là cùng team điều tra nguyên nhân của một Bug (lỗi phần mềm ảnh hưởng đến việc sử dụng của người dùng) quan trọng.
Weekly/Bi-Weekly (theo Sprint)
Các team làm sản phẩm (không làm việc theo dự án kiểu Waterfall) thường áp dụng mô hình Scrum để chia công việc theo từng Sprint, mỗi Sprint sẽ kéo dài theo chu kỳ 1 hoặc 2 tuần và cứ thế lặp lại. Ưu điểm của mô hình này là có thể nhanh chóng phát hành sản phẩm đến tay người dùng (hoặc khách hàng) để nhanh chóng lấy đánh giá cho lần cải tiến tiếp theo.
Trong mỗi Sprint, PO sẽ thực hiện các công việc:
Lên mục tiêu và kế hoạch cho Sprint tiếp theo: Thường dưới dạng Sprint Objectives, Product Roadmap, Epic.
Chuẩn bị Product Backlog cho Sprint tiếp theo. Bao gồm: Đánh giá mức độ ưu tiên; tính khả thi của các Backlog Items (Vấn đề, Ý tưởng, Giải pháp, Yêu cầu).
Hoàn thiện các mô tả yêu cầu tính năng (Product Requirement Documents (PRDs) hoặc User Stories) đã lên kế hoạch. Ở bước này PO sẽ làm việc với User Experience Researcher (UXR) để lấy thêm insights từ người dùng (Pains, Gains, Needs,…), xác nhận các giả thiết (Hypothesis), hoặc tìm cách đánh giá các bản Prototype (bản thử nghiệm); làm việc với User Experience Designer (UXD) để thiết kế tính năng có trải nghiệm tốt nhất dưới dạng User Flow/Wireframe; nếu PO làm cả phần việc của UXD thì PO cũng sẽ làm việc với UI Designer để biến các bản Wireframe thành các thiết kế có bố cục, phân cấp, màu sắc,… có thể handoff cho Developer tiến hành coding giao diện. Và nhiều vị trí chuyên môn khác để đảm bảo tính năng được hoàn thiện yêu cầu trước khi chuyển sang Developer để tiến hành hiện thực hoá.
Ở bước trên, nếu chỉ gửi cho Developer file UI Design (ví dụ: Figma file, Sketch file) thôi thì chưa đủ. Có nhiều tính năng có User Flow và yêu cầu phức tạp, PO sẽ có buổi Backlog Grooming để giải thích về PRDs/User Stories cho Developers. Đảm bảo rằng các Developers hiểu rõ tại sao cần làm tính năng này, luồng đi của người dùng, các trường hợp xảy ra và cách xử lý mỗi trường hợp, các điều kiện,… giúp Developers đánh giá Feasibility, Constraint và Effort.
Theo dõi các chỉ số về sản phẩm: Thông qua các công cụ tracking (vd: Firebase Analysis, Appflyer, Amplitude,…) để đánh giá mức độ hiệu quả của các tính năng sau khi triển khai, phẩn hồi và xử lý các vấn đề quan trọng kịp thời.
Liên lục lấy phản hồi từ người dùng: Thông qua các buổi phỏng vấn, khảo sát hoặc phản hồi qua các kênh liên lạc (Contact Form, Email, Live chat, Bug Report, Social Media, Store Review,…) để có thêm thông tin cho việc đánh giá và cải tiến sản phẩm, giải quyết các vấn đề tiềm năng, nâng cao trải nghiệm người dùng.
Quarterly
Cùng với các cấp cao hơn (ví dụ: Product Manager, Business Owner, CEO) đánh giá lại các kết quả đạt được trong quý, về Objectives và Key Results đã đề ra, các Milestones đã hoàn thành. Đánh giá các điểm đã làm tốt, các điểm làm chưa tốt, những khó khăn để rút ra các bài học cho giai đoạn tiếp theo.
Làm việc với Product Manager/Business Owner, CEO, Stakeholders và Development team để đánh giá lại mục tiêu dài hạn, xác định mục tiêu ngắn hạn, nguồn lực, sản phẩm và nhiều thông tin khác để lên kế hoạch phát triển cho giai đoạn tiếp theo dưới dạng Objectives – Key Results – Action Plans hoặc Product Roadmaps.
Và rất nhiều công việc “không tên”
Trong nhóm phát triển sản phẩm, PO như một chất keo kết dính mọi người, tháo gỡ các khó khăn và đảm bảo rằng cả nhóm sẽ cùng đi đến được các mục tiêu đề ra (điều này không đồng nghĩa với việc PO là người quản lý nhóm phát triển). Chính vì vậy, sẽ có nhiều lúc PO đảm nhận nhiều công việc “không tên” hay kiệm nhiệm nhiều vai trò đồng thời.
Việc này có cái hại và cái lợi, đôi khi gây ra rất nhiều áp lực nhưng chính là cơ hội để PO xây dựng nền tảng theo T-Shape Skillset và phát triển lên các vị trí cao hơn như Product Manager.
Nhìn chung, công việc của PO ở các công ty khác nhau rất nhiều do phụ thuộc vào tính chất công ty, thị trường, tính chất sản phẩm, các đồng nghiệp và rất nhiều yếu tố khác. Khi ứng tuyển công việc có chức danh (Job title) là “Product Owner” hay các công việc có tính chất tương tự, điều cần làm là giành thời gian tìm hiểu thêm về công ty và quy trình làm việc ở đó; sản phẩm đang giải quyết vấn đề gì, cho ai và ở giai đoạn nào; các đồng đội tương lai họ là ai và có ưu nhược điểm gì; các đầu mục công việc cần làm; các bài toán cần giải quyết để có sự hình dung và chuẩn bị tốt nhất trước khi tham gia.
Chắc hẳn các bạn làm sản phẩm hay UI Designer nói riêng thì các trang Mobbin, Ptrrns chắc không hề xa lạ. Trong quá trình thiết kế sản phẩm digital, việc tham khảo các ý tưởng và giải pháp thiết kế của các ứng dụng khác là điều bình thường và nên làm để hạn chế reinvent the wheel và giúp người dùng không phải học lại cái mới bằng việc sử dụng UI pattern quen thuộc.
UI Designer ngoài nắm vững các nguyên lý thiết kế, platform design guideline còn luôn cập nhật thường xuyên các xu hướng thiết kế cũng như UI Patterns để tiết kiệm thời gian và chủ động trong công việc.
Tôi luôn có ý định thu nhặt để tạo thành một kho thư viện nhỏ về các thiết kế cho các ứng dụng phổ biến ở thị trường Việt Nam vì các trang thư viện UI Pattern trên không có nhiều sản phẩm đang phổ biến ở thị trường Việt Nam hay là sử dụng ngôn ngữ Tiếng Việt.
Để làm một website thì hiện tại sẽ mất thời gian và tôi chưa đủ nguồn lực để phát triển cho nên trước hết các ứng dụng trong quá trình khám phá, tôi sẽ gom góp lại và đưa vào Folder mà bạn có thể xem tại đây.
Hoàng Tùng 