Reforge Artifacts

thanhhien 2 bình luận

Đôi nét về Reforge

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ùng
Tài liệu trên trang Reforge Artifact. Ảnh: Hoàng Tùng
Chi 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.

Theo dõi lưu lượng truy cập Website bằng VStat

thanhhien 1 bình luận

VStat là một công cụ cung cấp thông tin về lưu lượng truy cập và các thông tin như Monthly Visits, Monthly Views, Daily Visits, Daily Views, Bounce Rate, Page per visits, Time on site của một website.

Có hai cách để xem, một là cài đặt dưới dạng Chrome Extension để xem thông tin ngay trên các trình duyệt. Cách thứ hai là tra cứu thông tin trực tiếp trên website của nhà phát triển https://vstat.info/.

VStat có ưu điểm là cách hiển thị lưu lượng truy cập hàng tháng ngay trên biểu tượng extension của trình duyệt khi truy cập website. Ví dụ dưới đây khi truy cập trang báo VNExpress, chúng ta có thể thấy VNExpress có 158 triệu lượt người truy cập một tháng.

Lưu lượng truy cập của VNExpress hàng tháng từ VStat 2 Extension trên trình duyệt Brave. Ảnh: Hoàng Tùng

Các thông tin này khá hữu ích trong một số ngữ cảnh kinh doanh cần phân tích nhanh số liệu về website đối thủ về các thông tin về lưu lượng truy cập hoặc trong ngữ cảnh cá nhân cần đánh giá nhanh một website về độ phổ biến.

Khi nhấp vào biểu tượng extension VStat, chúng ta thấy thêm các thông tin chi tiết và thông kê lưu lượng truy cập một một số tháng đã qua.

Tổng quan báo cáo về lưu lượng truy cập của VNExpress cung cấp bởi VStat 2 Extension trên trình duyệt Brave. Ảnh: Hoàng Tùng

Ngoài VStat thì các công cụ như SimilarWeb, SemRush cũng cung cấp các thông tin rất hữu ích khác về Traffic, Engagement, Audiences, Competitors, Traffic Sources, v.v..

Biểu đồ thể hiện tỉ lệ truy cập chia theo Traffic Sources của VNExpress cung cấp bởi SimilarWeb. Ảnh: Hoàng Tùng
Tổng quan báo cáo về lưu lượng truy cập, tìm kiếm của VNExpress cung cấp bởi SemRush. Ảnh: Hoàng Tùng

Lưu ý rằng, dữ liệu từ VStat hay các công cụ tương tự như SimilarWeb, SemRush đối với Website hay SensorTower, AppAnnie đối với Mobile App chỉ mang tính tương đối và không phản ánh chính xác 100% traffic thực của các website/app như dữ liệu từ các công cụ Google Analytics, Amplitude mà chúng ta trực tiếp quản lý. Những dữ liệu này được mỗi nhà phát triển thu thập từ nhiều nguồn và có các thuật toán riêng cách xử lý số liệu riêng để đưa ra dự đoán. Vì vậy, khi sử dụng các nguồn dữ liệu này, tốt nhất nên tìm hiểu về cơ chế cũng như mức độ tin cậy để sử dụng phù hợp.

Conversation Cards

thanhhien Bình luận về bài viết này

Nhậu là một cách mà nhiều người chọn khi bắt đầu tạo những mối quan hệ mới hay tạo cơ hội để mở lòng, trở nên gắn kết hơn. Nhờ có một chút xúc tác của hơi men và cái không khí gần gũi mà người ta dễ mở lòng với nhau hơn. Tuy nhiên, tôi là người không uống được bia rượu nên nhậu không thường xuyên và cũng không hiệu quả.

Trong bài này tôi muốn giới thiệu với các bạn một phương pháp icebreaker “nhẹ nhàng” hơn, có thể áp dụng với nhiều đối tượng hơn để trong vài trường hợp phù hợp bạn có thể áp dụng.

Phương pháp có tên gọi là “Creative Conversation Cards” phát triển bởi team Dropbox Design. Hoạt động này có thể tổ chức cho nhóm từ 3-40 người đều khả thi. Nhưng theo kinh nghiệm của tôi, nên dừng lại trong phạm vi 5-10 người sẽ hiệu quả nhất.

Tổ chức

Đầu tiên, in các câu hỏi (tải về tại đây) và cắt thành các thẻ để mọi người có thể bốc thăm.

Khi bắt đầu, sắp xếp team ngồi thành vòng tròn, đi một vòng tròn đến lượt mỗi bạn bốc một câu hỏi để trả lời.

Các thành viên sau khi bốc thăm câu hỏi, suy nghĩ và trả lời các câu hỏi từ 1-2 phút.

Nếu là quản trò, hãy khuyến khích mọi người chia sẻ nhiều hơn hoặc giúp mọi người đặt câu hỏi sâu hơn cho nhau.

Để tạo ra sự thoải mái nhất, không có câu hỏi nào là bắt buộc. Ai cũng có quyền lựa chọn cách trả lời và những gì sẽ trả lời. Sẽ không có câu trả lời đúng-sai. Hãy tôn trọng sự khác biệt của nhau. Điều quan trọng là chúng ta có có cơ hội lắng nghe nhau và chia sẻ suy nghĩ cho mọi người.

Một phiên bản nâng cấp hơn cho hoạt động này là bạn hãy soạn những câu hỏi về một chủ đề nhất định hoặc đi sâu vào vấn đề nhóm hoặc công ty đang cần sự thấu hiểu giữa các thành viên hơn.

Input metrics & Output metrics

thanhhien Bình luận về bài viết này

Khi phát triển một sản phẩm, xây dựng một tính năng hay đánh giá bất kỳ giả thuyết nào. Ngoài việc xác định mục tiêu, đối tượng mục tiêu, vấn đề/nhu cầu người dùng cần giải quyết, việc xác định chỉ số đo lường mức độ thành công (key measurement metrics) là cực kỳ quan trọng.

Đối với key measurement metrics, sẽ cần nhìn theo hai cấp độ: Input Metrics và Output metrics.

  • Output metrics là kết quả sau cùng mà chúng ta mong muốn đạt được, không thể cải thiện các chỉ số này một cách trực tiếp.
  • Input metrics là các chỉ số mà chúng ta có thể dễ dàng tác động trực tiếp, thông qua các input metrics để tác động lên output metrics.

Một metric vẫn có thể là input metrics của một metric, nhưng cũng có thể là output metrics của một metric khác.

Một output metrics có thể có nhiều input metrics và mỗi input metrics có mức độ tương quan (correlate) với output metric khác nhau.

Ví dụ

  • Goal: Archive Product-Solution Fit
    • Output metrics: Week 1 Retention (W1)
    • Input metrics: % New users open app, % Conversion at Onboarding, R1 Retention, …
  • Goal: Increase customer satisfaction
    • Output metrics: Customer Satisfaction Score (C-SAT)
    • Input metrics: System Usability Scale (SUS), R1 Retention, % App session crash

Sử dụng input metrics và output metrics

Hai loại metrics này có một số đặc điểm khác nhau như giải thích ở trên. Cho nên khi đo lường các chỉ số phát triển sản phẩm, chúng ta cần xác định rõ hai nhóm metrics để sử dụng cho phù hợp:

Với Output metrics

  • Output metrics thường được sử dụng như chỉ số chiến lược ở mức độ high-level. Thông thường Output metrics sẽ được đặt làm Key Result của sản phẩm trong Quý/Năm.
  • Output metrics được dùng để trao đổi, báo cáo với các cấp quản lý, trao đổi với các external Stakeholders và internal team. Giúp tất cả nắm được sức khỏe chung của sản phẩm.
  • Các Output metrics thường được đưa lên các BI Dashboard, Product Dashboard và được báo cáo mỗi Bi-Weekly, Monthly.
  • Nếu chỉ tập trung vào output metrics mà không nhìn vào input metrics:
    • Sẽ rất khó để cho chúng ta đánh giá ưu tiên và có những hành động cụ thể để trực tiếp tăng output metrics.
    • Tăng được output metrics nhưng không có learnings vì có quá nhiều metrics khác ảnh hưởng đến output metrics
    • Có thể đạt được kết quả mong đợi nhưng phải hy sinh các chỉ số khác và có thể gây tác động tiêu cực trong dài hạn. Ví dụ: Để tăng Revenue, team quyết định tăng tần suất hiển thị quảng cáo. Trong thời gian đầu, lợi nhuận tăng nhưng có thể khách hàng rời bỏ sản phẩm sớm hơn vì trải nghiệm không tốt khi xem quá nhiều quảng cáo. Nên nếu tính trọn vòng đợi khách hàng có thể giá trị khách hàng mang lại giảm đi.

Với Input metrics

  • Input metrics là chỉ số dễ dàng đo lường và thấy được thay đổi trong một khoảng thời gian ngắn (Hourly, Daily, Weekly). Giúp team có thể nhanh chóng đánh giá các hypothesis để đưa ra quyết định tiếp theo nhanh chóng.
  • Input metrics giúp chúng ta đánh giá sâu sát liệu các kế hoạch, chiến lược có đi đúng hướng hay không.
  • Dùng input metrics để phân bổ trách nhiệm xuống các nhóm chuyên môn/cá nhân. Ví dụ:
    • User Acquisition: IPM (Installs per Mille), CPI (Cost per Install), eCPI (Effective Cost per Install), ROAS, etc…
    • Tech: Sprint Velocity, Crash Rate, System Active
    • AI/ML: Model Accuracy, Recall Score, Precision Score, F1 score
    • Product: Retention Rate, Set up metrics, Aha metrics, Habit metrics, Engagement metrics, etc…
    • Monetization: LTV (User Lifetime Value), Subscription Rate, Refresh rate
  • Các input metrics thường là các chỉ số dùng để ra quyết định priorities của các actions để đặt được output metrics.

Bài học kinh nghiệm là bất kì một kế hoạch, hành động gì sau khi đặt mục tiêu cũng nên có những chỉ số để đo lường mức độ thành công của mục tiêu. Với các chỉ số này, rất dễ để thiết đặt mong đợi và giao tiếp giữa nội bộ team phát triển và với các stakeholders. Ngoài ra chú ý đến việc xác định các output metrics và input metrics để có cái nhìn bao quát trong việc đánh giá kết quả tổng thể và có sự chủ động trong hành động.

The making of a Product Guy

thanhhien Bình luận về bài viết này

Ban đầu tôi đặt tiêu đề bài viết là “The making of a Product Owner”, định viết về những điểm cần chú ý để giúp các bạn PO mới vào nghề đi xa và nhanh hơn. Tuy nhiên sau một hồi viết phần đầu có tên “Cảm hứng”, kỷ niệm trong tôi ùa về, nhớ lại chuyện ngày xưa khi mò mẫm bắt đầu con đường làm sản phẩm. Nên thôi, xin phép cho tôi kể một chút về hành trình của bản thân.

Khởi đầu

Năm 2015 khi đang thực tập ở F-Soft với vị trí Software Engineer Intern, anh Cường, một người anh tôi quen khi làm freelance nhắn tin cho tôi đại ý như thế này:

  • A.Cường: Tùng, biết làm UI/UX không em?
  • Tôi: UI/UX là của nợ gì vậy anh?
  • A.Cường: Hmmm, công ty anh đang tuyển UI/UX, anh thấy mấy làm Graphic Design được nên có vẻ cũng làm được UI/UX thôi. Anh gửi cho tài liệu này, đọc đi rồi gửi cái email ứng tuyển hen.
  • Tôi: Ok, cám ơn anh.

Tài liệu lúc đó anh Cường gửi tôi là UI Guideline dài cỡ 50 trang của anh Tú Bùi (hiện đang là Director of Product Design ở TIKI, hồi đó anh Tú Bùi làm ở Silicon Straits Saigon). Sau khi ngốn tài liệu trong 1 ngày, tôi nộp hồ sơ vào công ty, với kiến thức Graphic Design sẵn có tôi có thiết kế UI đầu tiên trên Photoshop và đậu vào vị trí UI/UX Design Intern. Cũng kể thêm, cái thời đó ai xài Windows thì không dùng được Sketch (Sketch thời đó là công cụ đỉnh cao của tụi UI Designer), mà phải dùng Photoshop hoặc Illustrator, công việc nặng gấp nhiều lần so với bây giờ. Nghĩ lại thì design trên UI bằng Photoshop thời đó khổ nhưng mà vui, vì cái gì cũng mới mẻ.

AmazingUX

Năm 2016 tôi cùng hai người anh em trong công ty tham gia một cuộc thi có tên là AmazingUX. Tôi đang làm UI/UX Design nên cũng có chút tự tin về mặt thể hiện ý tưởng, nghĩ là mình làm UI/UX Design nên chắc UX thì khỏi bàn. Năm đó nhóm chúng tôi dừng ở Top 20. Lý do cũng vì ham học hỏi, muốn thể hiện nên máu lên nên đăng ký còn nghĩ lại kiến thức về UX gần như bằng 0, lúc đó thực ra tôi chỉ biết làm UI thôi. Thật may mắn là sau cuộc thi tôi biết đến anh Tùng Jacob, đang là Product Manager ở Thế Giới Di Động, người mà qua anh tôi bắt đầu đặt những viên gạch đầu tiên và có đam mê trên con đường làm sản phẩm.

CODE Summit 2017

Năm 2017, tôi sang Singapore để tham dự CODE Summit 2017 (Tiền thân của UXSEA Summit). Lúc đó có một vài người bạn Việt Nam cùng tham gia: Tử Minh (hiện là Product Design Lead ở Momo), Khắc Minh (vẫn đang làm ở Interactive Labs) và anh Thái Lâm khi đó là thành viên BTC.

Lúc tôi đặt vé sự kiện thì vé đã hết, cũng may nhờ sếp tôi liên hệ và có anh Lâm hỗ trợ, chúng tôi vẫn được tham gia vào phút cuối bằng “vé vớt”.

Trong 3 ngày ở Singapore, tôi thực sự choáng ngợp. Một phần vì giao tiếp của mình chưa lưu loát, nhưng phần lớn là được gặp rất nhiều diễn giả và bạn bè từ khắp Đông Nam Á chủ yếu làm việc ở Singapore và học nhiều điều thực sự quá mới mẻ và quá “cao cấp”. Bản thân tôi đã được mở mang rất nhiều mà theo đánh giá cá nhân tôi, sau chừng đấy thời gian cho đến bây giờ, cộng đồng sản phẩm ở Việt Nam mới bắt đầu tiệm cận được như vậy.

UXVN Festival 2018

Sau sự kiện này thì tôi có dịp kết nối với anh Lâm (a Lâm giờ là Lead Product Designer ở BEAMIN Việt Nam), hai anh em cùng chia sẻ ước mơ có thể tổ chức những sự kiện như Code Summit 2017 ở Việt Nam để mọi người có cơ hội học hỏi và giao lưu, phát triển môi trường trong nước. Vì vậy nên tôi hỗ trợ anh Lâm một chút để tổ chức UXVN Festival 2018, Design Research 2019 và một số workshop nhỏ. Cũng rất nể phục anh vì hầu như 99.9% những công việc trong các sự kiện này là anh lo hết, từ A tới Z.

Ở UXVN Festival 2018, điều làm tôi nhớ nhất là cơ hội được gặp và trò chuyện trực tiếp với anh Hiếu, người mà tôi xem như người thầy. Anh Hiếu là 1 trong 2 người trực tiếp truyền cảm hứng cho tôi đến với nghề và đến bây giờ vẫn học hỏi được rất nhiều từ anh. Thực sự lúc đấy anh Hiếu đang ở Úc khá lâu chưa về Việt Nam, tôi và anh Lâm chỉ biết anh Hiếu qua blog của anh chia sẻ nhiều câu chuyện về cách ở Úc người ta làm sản phẩm, làm UX. Đến khi mời được a Hiếu về để chia sẻ trong sự kiện này, tôi và anh Lâm như vỡ òa vì không tin là làm được một nhiệm vụ có vẻ như bất khả thi.

Hiện giờ anh Hiếu có một kênh Youtube HIEU.TV khá nổi tiếng về chủ đề Tự do tài chính và Kinh nghiệm sống. Có cơ hội tôi sẽ viết một bài riêng về anh Hiếu.

Trong ảnh từ trái qua: a.Quốc Anh (Zalo), c.Ngân Bling (Zalo), tôi, a.Hiếu, a.Lâm

Tập trung vào công việc

Sau khoảng thời gian này tôi tập trung vào công việc nhiều hơn, ít tham dự sự kiện hay hoạt động gì nổi bật. Nhưng nhìn lại những khoảng thời gian đó tôi vẫn thầm cảm ơn những người anh đã góp phần truyền cảm hứng cho tôi đến với công việc này, con đường này. Qua thời gian, khi nhìn lại thấy được ai cũng đã đều có những bước tiến vượt bậc trên con đường mình đang đi, tiếp tục đóng góp rất nhiều cho cộng đồng.

Riêng tôi không làm được gì nhiều, chỉ mong muốn qua blog nhỏ này và những bài viết của mình mang góp thêm một hạt cát nhỏ hy vọng có ích cho ai đó.

Effective Meeting

thanhhien Bình luận về bài viết này

Với dân văn phòng, người làm về công nghệ như chúng ta thì Meeting là một phần không thể tách rời khỏi công việc.

Khi mới đi làm, tôi chưa biết gì nhiều. Anh chị nào nhắn tôi bảo cần meeting là tôi ok luôn. Đến giờ là đi meeting thôi, vào meeting họ hỏi gì cần gì thì mình xoay xở nấy. Không suy nghĩ gì nhiều.

Đi làm được một vài năm, vai trò tăng lên chút, quản lý thêm một nhóm nhỏ. Có vấn đề gì cần giải quyết là tôi cứ vậy hẹn meeting để trao đổi. Tới meeting thì trình bày vấn đề để mọi người cùng trao đổi. Tôi cũng không suy nghĩ gì nhiều.

Sau này được công ty cho đi học, quan sát từ các sếp tôi bắt đầu biết cách hệ thống hóa lại chút, biết cách sao để tổ chức meeting hiệu quả hơn. Trước đây tôi khá bản năng, mặc dù cách làm thì không phải tệ, nhưng có đôi chỗ vì không nắm được gốc rễ nên nhiều khi meeting không hiệu quả, tôi nghĩ vì những lý do khác như vấn đề quá khó nên họp mãi mà không được gì.

So với các vị trí khác trong team phát triển thì công việc của Product Owner/Product Manager đòi hỏi giao tiếp nhiều, thường xuyên tổ chức meeting và tham gia nhiều meeting. Với tôi thì con số này chiếm khoảng 30% thời gian làm việc.

Tôi đã ước rằng có người chỉ tôi những kỹ năng này sớm hơn. Cho nên tôi viết bài để chia sẻ chút kinh nghiệm cho những ai vẫn thấy có khó khăn trong việc tổ chức và tham gia họp.

Host & Participant

Thông thường thì mỗi meeting có hai vai trò chính là Host và Participant.

Host là những người chủ động set up meetings, người này sẽ là người đặt vấn đề tại sao cần tổ chức meeting và cũng có thể là người dẫn dẵn meeting trong suốt quá trình diễn ra.

Participant là những người tham gia đóng góp với lời mời từ Host. Tham gia để nắm bắt thông tin, tham gia để đưa ý kiến, tham gia để cùng giải quyết vấn đề,..

Ngoài ra cũng sẽ có các thành phần khác có thể gọi tên như Secretary, Timekeeper, Decision Maker, etc. Nhưng đa phần sẽ được kiêm nhiệm bởi Host hoặc Participant.

Host

Before the meeting

1. Xác định purpose (mục đích) và objective (mục tiêu).

  • Purpose: Mục đích tổ chức meeting (Ví dụ: Planning). Xác định mục đích tổ chức giúp cả Host xác định dễ dàng hình thức tổ chức và các thành phần cần tham gia. Giúp Participants hiểu rõ vai trò và những gì mình cần làm trong meeting. Một số loại meeting phổ biến sau:
    • Information Meetings
    • Decision-Making Meetings
    • Problem Solving Meetings
    • Brainstorming Meetings
    • Planning Meetings
    • One-on-one Meetings
    • Status Update Meetings
    • Culture Buildings
  • Objective: Mục tiêu tổ chức meeting (Ví dụ: Tech Sprint 39 Planning). Mục tiêu thì cần nêu rõ vấn đề cụ thể phải tổ chức meeting.

2. Xác định participants (thành phần tham gia).

  • Thành phần tham gia cần đảm bảo trong số lượng hợp lý. Kinh nghiệm của tôi là chỉ mời những key participants mà bắt buộc cần có họ. Khi xác định đúng những người này cũng sẽ dễ hơn để đặt thời gian phù hợp, càng. Càng nhiều người tham gia meeting sẽ càng khó sắp xếp thời gian, càng có nhiều thành phần gây nhiễu và gây lãng phí thời gian của những người mà đáng lẽ họ không cần tham gia.

3. Thông tin rõ cho participants về meeting

  • Các thông tin sau cần truyền đạt rõ ràng qua nhiều hình thức.
    • Meeting Goal: Mục tiêu cuộc họp
    • Agenda: Lịch họp và thời gian dự kiến
    • Documents (Optional): Các tài liệu cần đọc trước để hiểu về chủ đề cần thảo luận.
    • Exercises before the meetings (Optional): Nếu trước họp cần các participants đọc trước tài liệu, điền biểu mẫu hay chuẩn bị bất cứ thứ gì cũng nên nêu rõ.

4. Chuẩn bị tài liệu đọc trước, tài liệu trình chiếu, công cụ hỗ trợ.

  • Với các cuộc họp dạng Information Meetings có lượng thông tin lớn. Host nên tìm cách chuẩn bị slide mô tả tóm gọn các thông tin chính để participants dễ nắm bắt trong suốt meetings. Kèm theo đó là các tài liệu đính kèm.
  • Tương tự, nếu là cuộc họp dạng Brainstorming Meetings, cần chuẩn bị các template sẵn từng bước trên các platform như Miro, FigJam để team dễ dàng đóng góp ý tưởng.

5. Đặt lịch hẹn

  • Khi đặt một lịch hẹn, cần chú ý các điểm sau:
    • Tiêu đề cần ngắn gọn và xúc tích, các keywords quan trọng luôn phải nằm trước
    • Trường hợp công ty làm việc hybrid mode, chú ý (1) Đặt phòng họp cho các stakeholders (2) Tạo link Google Meets hoặc Zoom.
    • Ghi rõ Purpose, Agenda, và các Documents trong tài liệu mô tả
    • Kiểm tra lịch họp của các key participants (những người mà không có họ cuộc họp khó có thể đạt được kết quả) xem có trùng với lịch có sẵn không. Trong trường hợp trùng lịch có hai giải pháp thường thấy: 1) Tìm khoảng thời gian khác phù hợp hơn 2) Tìm khoảng thời gian phù hợp với số đông sau đó đàm phán để những participant trùng lịch dời lịch họp cá nhân của họ.

In the meeting

Trước khi bắt đầu, nhắc lại một cách ngắn gọn về mục tiêu và mục đích của cuộc họp. Kết quả mong đợi sau cuộc họp.

Luôn cần có Facilitator trong cuộc họp để dẫn dắt lịch trình, hướng dẫn, kiểm soát thời gian, và khuyến khích mọi người đặt câu hỏi. Thường thấy thì Facilitator cũng là Host.

Luôn có dự kiến thời gian cho từng phần và đảm bảo lịch trình dự kiến giữa các phần không bị chênh quá nhiều.

Nêu rõ giao thức hỏi đáp, tranh luận. Thường sẽ có 3 cách:

  • Phần hỏi đáp cuối meeting
  • Phần hỏi đáp chèn giữa mỗi phần nếu meeting được chia làm nhiều phần
  • Cho phép stakeholders đặt câu hỏi, nêu ý kiến trong suốt quá trình.

Nếu xảy ra các trao đổi đi quá xa khỏi mục tiêu ban đầu (out of context) hoặc tranh luận kéo dài thì sẵn sàng cắt ngang. Facilitator hoặc Thư ký ghi nhận lại và có các follow ups offline hoặc ở một buổi họp khác.

After the meeting

Nhiều trường hợp trong cuộc họp trao đổi rất sôi nổi, nhiều ý kiến được đưa ra, chiều quyết định được thống nhất nhưng họp xong không có tóm tắt lại. Điều này rất quan trọng nhưng nhiều khi tôi thấy hay bị bỏ qua dẫn đến nhiều hệ lụy như đã thống nhất nhưng khi thực hiện thì không nhất quán vì tưởng rằng đã hiểu nhưng thực ra là chưa, hay người nhớ người quên..

Cho nên để chắc chắn, sau meeting thì bạn Facilitator hoặc Secretary sẽ là tóm tắt lại các Key Highlights, Pending Questions và Next Steps. Các tóm tắt này có thể được đăng lên các communication channels hoặc viết thành Meeting Minutes trong Confluence để dễ tra cứu.

Participant

Ở chiều đối diện, participant khi tham gia họp cũng cần làm rõ các thông tin phía trên:

  • Mục đích cuộc họp là gì?
  • Mục tiêu cuộc họp là gì?
  • Vai trò của tôi khi tham gia họp là gì? Tôi cần thực sự cần tham gia họp không?
  • Liệu rằng có tài liệu hay bài tập gì cần tôi đọc và chuẩn bị trước không?
  • Có những ai tham gia?
  • Sau cuộc họp tôi cần làm gì không?

Đặt câu hỏi, góp ý với thái độ cở mở, tích cực. Góp ý không nhằm mục đích công kích cá nhân hay phản bác thiếu căn cứ hay lập luận rõ ràng.

Các thông tin nếu chưa hiểu hãy nói ngay trong cuộc họp và xin làm rõ thêm, đừng ậm ờ cho qua. Nếu mất nhiều thời gian thì xin phép được catch-up sau để không mất thời gian của cả nhóm.

Trong cuộc họp thì nên tập trung hoàn toàn vào việc họp, việc nào ra việc đó cho dù là meeting online hay meeting offline. Đây là một lỗi cơ bản mà rất nhiều người gặp phải khiến cho cuộc họp vừa mất thời gian, vừa không hiệu quả.

INSPIRED – Marty Cagan

thanhhien Bình luận về bài viết này

Nếu có ai nhờ tôi giới thiệu một cuốn sách về Product Management, tôi sẽ đề xuất ngay cuốn “INSPIRED” của Marty Cagan.

Image: Amazon

INSPIRED mang đến các bài học rất thực tế từ các Product Manager trong ngành phát triển phầm mềm và giúp chúng ta có một bức tranh tương đối hoàn chỉnh về cả phương pháp phát triển, từng vai trò của từng thành viên trong nhóm phát triển và giới thiệu cả các công cụ mà có thể nhiều người đã khá quen thuộc một ít trong số đó.

Cuốn sách được chia làm các phần chính:

  • Part I: Lessons from top tech companies
  • Part II: The Right People
  • Part III: The Right Product
  • Part IV: The Right Process
  • Part V: Culture

Mặc dù được chia nhỏ nhiều phần nhưng mỗi ý trong bài đều được giới thiệu ngắn gọn dễ hiểu. Bám sát theo bộ ba People – Product – Process mà tác giả giới thiệu khá kĩ nên rất dễ nắm bắt.

Đây là một cuốn sách đối với tôi là cuốn sách gối đầu giường đích thực. Mỗi khi gặp khó khăn trong công việc mà bản thân chưa có lời giải, tôi thường dùng cuốn sách như một cuốn từ điển để tra cứu và giúp gợi mở nhiều hướng giải quyết mới.

Có một kỉ niệm vui về cuốn sách là khi tôi lead một team Product, các bạn trong team đều là những người trẻ, chưa có nhiều kinh nghiệm kể cả tôi. Quá trình làm việc gặp phải rất nhiều vấn đề về quy trình, tổ chức và phương pháp mà không ai biết nên làm gì và hỏi ai. May mắn là chúng tôi bén duyên với INSPIRED, mỗi thứ 6 cả nhóm lại với nhau ở phòng họp nhỏ cạnh công ty để cùng đọc và chia sẻ góc nhìn về những chủ đề mà mọi người quan tâm trong sách.

Team Product Cloudjet Solution – Tháng 11/2018

5 User Interface States

thanhhien Bình luận về bài viết này

Có một đợt, khi tôi đang còn làm sản phẩm về hệ thống đánh giá hiệu suất KPI (Key Performance Indicator) nhân viên. Sau khi phát hành một tính năng mới thì tôi nhận được một số phàn nàn của khách hàng về việc khi nhập kết quả đánh giá nhưng hệ thống xong nhưng hệ thông không ghi nhận. Khi tôi cùng anh em Tech điều ra thì không thấy có bug gì bất thường nhưng sau đó cùng ngồi với khách hàng phân tích use case bên họ mới phát hiện ra nguyên nhân khiến chúng tôi té ngửa những cũng là một bài học.

Công ty khách hàng chúng tôi khi đó là công ty lớn, có đến hơn 10 cấp bậc tính từ nhân viên cấp thấp nhất đến quản lý cao nhất. Mỗi khi nhân viên cập nhật kết quả, hiệu suất sẽ được tính toán và cập nhật có nhân viên cấp I, lấy kết quả nhân viên cấp 1 tính cho quản lý cấp 2 và cứ thế lên quản lý cấp cao nhất là 10. Vì vậy nên mỗi lần nhập kết quả, hệ thống xử lý và ghi nhận kết quả mất hơn 10s mà khách hàng thường không kiên nhẫn, khi nhập vào kết quả thấy 2-3s không có cập nhật gì theo thói quen họ F5 để xem kết quả được cập nhật hay không. Chuyện không có gì để nói nếu như chúng tôi làm tốt 1 trong 2 chuyện:

  • Một là ở khía cạnh kỹ thuật, chúng tôi xử lý tính toán ở phía Server thay vì ở Client-side, như vậy không có chuyện người dùng F5 thì việc tính toán bị ngắt quãng. Và tốt hơn hết là tìm thuật toán xử lý tối ưu hơn để giảm thời gian xử lý.
  • Hai là ở khía cạnh sản phẩm, nếu chúng tôi thêm một trạng thái chờ để người dùng biết hệ thống vẫn đang xử lý thì sẽ hạn chế bớt việc người dùng hiểu nhầm và nhấn F5.

Và trong việc làm sản phẩm thì những chuyện như trên xảy ra thường xuyên. Đôi khi ta quá chú tâm vào thiết kế các flow chính của sản phẩm mà quên đi các trường hợp phát sinh, hay gọi là edge cases ảnh hưởng tiêu cực đến trải nghiệm người dùng, hoặc tệ hơn là khiến user churn.

Riêng tôi, thường sử dụng một framework khá đơn giản là với bất kì màn hình hình, cũng sẽ đi qua một checklist gồm 5 trạng thái của UI bao gồm:

  • Blank State
  • Loading State
  • Partial State
  • Error State
  • Ideal State

Theo tôi, cho dù là ai với vị trí nào trong team phát triển từ UX Designer, Product Owner hay là UI/UX và kể cả Developer khi nắm và luôn đi qua 5 trạng thái này mỗi khi phát triển một màn hình, tính năng không bao giờ là thừa.

Blank State

Blank State hay đôi khi gọi là Empty State là trạng thái thường gặp khi ứng dụng không có nội dung để hiển thị cho người dùng.

Một vài use case phổ biến như người dùng vừa khởi tạo tài khoản, tìm kiếm không có kết quả, etc.

Phần lớn các designer sẽ tận dụng việc có UI nhiều khoảng trống ở state này để làm tốt Onboarding sản phẩm. Giúp người dùng hiểu các tính năng và giúp họ biết họ cần làm gì tiếp theo. Ngoài ra, các hình ảnh minh họa và câu chữ được thể hiện tốt là lợi thế để tạo được tone & voice của sản phẩm.

Loading State

Đây là trạng thái khi ứng dụng đang tải hoặc xử ý dữ liệu để hiện thị lên giao diện cho người dùng.

Trạng thái này rất phổ biến đối với các sản phẩm có kho dữ liệu nội dung lớn hoặc triển khai ở các vùng địa lý có tốc độ băng thông kém hoặc cả hai.

Partial State

Partial State là trạng thái khi người dùng đã thao tác với ứng dụng và có một ít dữ liệu nhất định nhưng chưa hoàn toàn đầy đủ.

Partial State là trạng thái lửng lơ giữa Blank State và Ideal State (trạng thái dữ liệu đầy đủ như mong đợi). Trạng thái này sẽ xuất hiện nhiều ở các màn hình Onboarding hay Set up cho nên cũng không thường xuyên cần đến. Tuy nhiên, đối với giai đoạn Activation khi cần chuyển đổi từ New Users (người dùng mới) sang Engaged Users (người dùng lâu dài) thì Partial State rất quan trọng, là nơi có thể tận dụng để áp dụng các kĩ thuật thiết kế trải nghiệm nhằm tăng Activation Rate/Conversion Rate.

Error State

Error State xuất hiện khi xảy ra các lỗi có thể từ phía người dùng cũng có thể từ phía ứng dụng.

Thường thì mục đích chính của Error State là báo cho người dùng biết đã có lỗi gì xảy ra và đề xuất hướng xử lý.

Ideal State

Ideal State có lẽ không cần phải giải thích thêm, đây là trạng thái phổ biến nhất mà đa phần trong mọi trường hợp ta sẽ bắt tay vào thiết kế đầu tiên.

Trong thực tế thì khi thiết kế UI cho Ideal State, designer thường chia nhỏ thêm các trường hợp cho text, image, content. Ví dụ: Text quá dài, text quá ngắn, text bao gồm một từ đơn rất dài,…

Immersive Experience Design

thanhhien Bình luận về bài viết này

Immersive Experience Design (thiết kế trải nghiệm đắm chìm) là kĩ thuật được ứng dụng ở nhiều sản phẩm giúp đạt được sự tập trung tối đa từ người dùng, giảm thiểu các yếu tố dễ gây xao nhãng nhằm khuyến khích người dùng trải nghiệm Core Value sản phẩm nhanh nhất.

Khi thiết kế một Immersive Experience có thể dựa trên ba yếu tố căn bản:

  • Sound
  • Visual
  • Touch

Tùy thuộc core value của sản phẩm và giới hạn của thiết bị mà một trong ba thành tố này được tập trung khai thác hoặc gia giảm cho phù hợp.

Một số ví dụ về Immersive Experience trong các digital product.

Netflix

Khi mở Netflix (phiên bản Web), người xem thấy ngay bộ phim được giới thiệu chiếm phần lớn màn hình và tự động được phát trailer kèm âm thanh.

Hướng sự chú ý của người dùng vào bộ phim này và khuyến khích hành động “Play” (core value).

Beatstar

Beatstar, một tựa game âm nhạc đình đám hiện nay. Khi mở game, người chơi thấy ngay bài hát được đề xuất ở giao diện chính, đồng thời bài hát được phát để trigger việc “Play”.

Typeform

Typeform, công cụ tạo khảo sát trực tuyến. Khi người dùng bắt đầu làm khảo sát, trên màn hình luôn luôn tập trung một câu hỏi duy nhất.

TikTok

Với TikTok, các videos ngắn được đề xuất luôn luôn là trung tâm của màn hình và chiếm tối đa diện tích với tỉ lệ video theo tỉ lệ mobile để tận dụng tối đa không gian.

Image: Engadget

Để ứng dụng và thiết kế tốt Immersive Experience, người thiết kế cần hiểu rất rõ Core Value của sản phẩm đối với từng Use Case cụ thể. Ngoài ra, qua các ví dụ trên các bạn cũng có thể thấy Immersive Experience thường được ứng dụng trong các Consumer Product thiên về trải nghiệm nghe nhìn và không cần nhiều thao tác.

Zero, Listening & Skill

thanhhien Bình luận về bài viết này

Trong một buổi học lái xe gần đây, xảy ra một tình huống mà thầy tôi có chia sẻ một vài bài học tôi thấy có giá trị nên muốn viết lại, chủ yếu là để ghi nhớ và luôn tự nhắc nhở bản thân mình.

Giấu dốt

Chuyện là khi mới học lái xe gặp những đoạn ngã tư đèn xanh đỏ, tôi và anh bạn học vài lần làm xe tắt máy đột ngột.

Trong tình huống này, tụi tôi phần vì không muốn xe sau phải đợi lâu, phần vì cố gắng xử lý thật nhanh để không để người ta thấy mình thiếu kinh nghiệm nên sẽ đạp ga thật mạnh. Tuy nhiên khi đi xe số sàn, khi lên số thì phải theo trình tự: đạp côn, lên số, nhả côn và cuối cùng mới tăng ga. Nếu trình tự không đúng thì xe sẽ không chạy. Tụi tôi vì đang cuống quá nên đầu óc rối tung, mà làm sai thao tác xe không chạy lại càng rối.

Thấy vậy, thầy khuyên trong trường hợp này hãy bình tĩnh xử lý và cũng không cần phải dấu dốt làm chi. Mình mới học nên kinh nghiệm chưa có, nên dốt là dốt thật, không có gì phải dấu cả. Cứ bình tĩnh xử lý, để xe sau từ từ chờ đợi thì mọi chuyện sẽ ổn.

Lắng nghe

Khi bắt đầu học lái ô tô, kiến thức của tôi hoàn toàn là tờ giấy trắng. Thầy khuyên tôi cứ đặt niềm tin ở thầy, nghe thầy và làm theo. Dần sẽ học được nhiều, sau này tích lũy được nhiều thì sau đó tự có những đúc kết của bản thân.

Thêm nữa, ngay cả khi đã có kinh nghiệm ta cũng nên cở mở để lắng nghe, kể cả có lắng nghe những người ít tuổi, ít kinh nghiệm hơn cũng nên lắng nghe. Đôi khi họ vẫn cho ta rất nhiều chia sẻ bổ ích hay kiến thức có giá trị.

Kỹ năng

Lái xe là một dạng kỹ năng, mà kỹ năng thì hoàn toàn có thể học được. Khi chưa học, chúng ta thua kém người đã học trước, có kinh nghiệm là điều dễ hiểu. Tuy nhiên, điều này không đồng nghĩa việc ta suốt đời thua kém những người đó.

Khi tiếp cận một kiến thức, kỹ năng hay dấn thân vào lĩnh vực mới, luôn tin rằng ta có thể học. Sau khi giành thời gian tiếp thu kiến thức, rèn luyện để tích lũy kinh nghiệm chúng ta có thể tự tin không thua kém ai cho dù là cả những người đi trước.

Đúc kết lại, tôi tin rằng mọi kiến thức chúng ta có thể học và làm chủ. Chỉ cần luôn sẵn sàng học hỏi, không giấu dốt để tránh tạo áp lực vô hình và để được hỗ trợ những điểm ta còn hạn chế. Ra sức cởi mở để lắng nghe tiếp thu nhiều kiến thức, kinh nghiệm có giá trị.