Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng một buổi sáng thứ Hai. Bạn mở laptop và một công cụ AI vừa tạo ra cho bạn 100 mockup khác nhau cho màn hình thanh toán của ứng dụng. Tất cả đều "ổn". Tất cả đều "đẹp". Tất cả đều "hợp lý". Và rồi sếp hỏi: "Em chọn cái nào?"
Đây chính là khoảnh khắc mà nghề Product Manager (PM) thực sự bộc lộ giá trị. Trong vài năm gần đây, việc tạo ra các lựa chọn đã trở nên gần như miễn phí — AI vẽ giao diện trong 10 phút, engineer prototype trong một buổi chiều, designer có sẵn thư viện component. Thứ khan hiếm không còn là khả năng tạo ra options, mà là khả năng nhìn vào 100 options và chọn đúng 1 cái. Đó chính là Product Taste (gu sản phẩm) và Judgment (khả năng phán đoán).
Trong một khóa học về "Kỹ năng con người cho PM", vì sao bài đầu tiên lại là Product Taste? Bởi vì tất cả những kỹ năng còn lại — thuyết phục stakeholder, kể chuyện, ra quyết định — đều phục vụ cho một mục tiêu duy nhất: đưa sản phẩm đi đúng hướng. Mà "đúng hướng" thì cần một la bàn nội tại. Product Taste chính là chiếc la bàn đó. Bạn có thể thuyết phục cả công ty đi theo quyết định của mình, nhưng nếu cái gu của bạn sai, bạn chỉ đang dẫn mọi người đi nhanh hơn xuống vực.
Tin tốt là: Product Taste không phải năng khiếu bẩm sinh. Nó là một kỹ năng có thể rèn luyện một cách có hệ thống. Bài học này sẽ giúp bạn hiểu nó là gì, vì sao nó quan trọng hơn bao giờ hết, và làm thế nào để bắt đầu xây dựng nó.
Khái niệm cốt lõi
Product Taste là gì?
Product Taste là khả năng nhận ra đâu là một lựa chọn sản phẩm tốt trong vô số lựa chọn khả thi — và quan trọng hơn, là khả năng giải thích được vì sao nó tốt. Nó không phải là cảm tính kiểu "anh thấy cái này đẹp". Taste của một PM giỏi luôn có cấu trúc bên dưới: nó kết nối lựa chọn với nhu cầu người dùng, với mục tiêu kinh doanh, với bối cảnh thị trường và với khả năng thực thi của team.
Một cách phân biệt hữu ích: Designer taste thiên về thẩm mỹ và trải nghiệm — màu sắc, khoảng cách, chuyển động. Product taste rộng hơn: nó hỏi "Tính năng này có nên tồn tại không?", "Phiên bản đơn giản nhất giải quyết được 80% vấn đề là gì?", "Cái gì nên cắt bỏ?". PM có taste tốt thường nổi tiếng vì biết nói KHÔNG đúng lúc nhiều hơn là vì biết thêm tính năng.
Judgment — taste khi đặt vào áp lực thực tế
Nếu Taste là khả năng nhận ra cái tốt trong điều kiện lý tưởng, thì Judgment là khả năng ra quyết định tốt khi thiếu thông tin, thiếu thời gian và thiếu sự đồng thuận. Trong thực tế, bạn gần như không bao giờ có đủ dữ liệu. Judgment là khi bạn cân được: "Với 60% thông tin tôi đang có, hướng đi nào có kỳ vọng giá trị cao nhất nếu xét cả mặt trái?"
Taste cho bạn biết đâu là "đẹp". Judgment cho bạn biết đâu là "đúng trong hoàn cảnh này". Một mockup có thể có taste hoàn hảo nhưng là judgment tồi nếu nó đòi hỏi 3 tháng kỹ thuật trong khi đối thủ sắp ra mắt sau 3 tuần.
Ba trụ cột của Product Taste
1. Hiểu sâu người dùng và bối cảnh. Taste không tồn tại trong chân không. Một lựa chọn "tốt" cho người dùng Gen Z ở Sài Gòn dùng app mua sắm có thể là lựa chọn tồi cho kế toán viên 45 tuổi dùng phần mềm doanh nghiệp. Taste giỏi luôn được neo vào một người dùng cụ thể.
2. Tích lũy reference (kho tham chiếu). Người có gu tốt là người đã nhìn nhiều. Họ biết Grab giải quyết onboarding tài xế ra sao, Shopee xử lý flash sale thế nào, Notion làm empty state ra sao. Mỗi sản phẩm tốt bạn dùng và mổ xẻ đều bổ sung vào "thư viện" trong đầu bạn, để khi đối diện 100 options, bạn có cơ sở so sánh.
3. Khả năng diễn đạt tiêu chí. Taste mơ hồ thì không scale được. Nếu bạn chỉ nói "anh thấy không ổn", team sẽ chiều bạn nhưng không học được gì. PM có taste trưởng thành biến trực giác thành tiêu chí rõ ràng: "Phương án này tốt hơn vì nó giảm một bước trong luồng thanh toán, mà dữ liệu cho thấy đó là bước rớt 30% người dùng."
Vì sao kỷ nguyên AI làm Taste trở nên quý hơn
Khi việc sản xuất options gần như miễn phí, lợi thế cạnh tranh dịch chuyển sang khâu chọn lọc. Mọi đối thủ của bạn đều có cùng công cụ AI, cùng template, cùng tốc độ tạo prototype. Thứ khác biệt duy nhất là chất lượng phán đoán của con người ngồi sau bàn phím. Taste tốt giờ là "moat" (con hào phòng thủ) thực sự của một PM.
Tình huống thực tế
Tình huống 1 — 100 mockup và một quyết định
Linh là PM tại một startup fintech ở TP.HCM, làm app ví điện tử cạnh tranh trực tiếp với MoMo và ZaloPay. Team dùng AI tạo ra 80 biến thể cho màn hình "chuyển tiền". Một số có animation đẹp mắt, một số có nhiều shortcut, một số tối giản đến mức chỉ còn một ô nhập.
Junior PM trong team thích phương án nhiều shortcut nhất vì "trông xịn và nhiều tính năng". Linh thì chọn phương án gần như tối giản nhất. Khi bị hỏi vì sao, cô không nói "chị thấy đẹp hơn". Cô mở dữ liệu: 73% giao dịch chuyển tiền của họ là gửi cho 3 người quen thuộc nhất; người dùng chính là phụ nữ 28–40 tuổi, chuyển tiền lúc đang bận. Phương án nhiều shortcut tạo "choice overload" — quá nhiều lựa chọn khiến người ta chần chừ. Phương án tối giản đặt 3 người gần đây ngay đầu màn hình, giảm thao tác.
Bài học: Taste của Linh không phải cảm tính. Nó là sự kết hợp giữa hiểu người dùng (ai, làm gì, trong hoàn cảnh nào) với khả năng diễn đạt tiêu chí. Cô không chọn cái "đẹp nhất" mà chọn cái "đúng nhất với người dùng của mình". Sau khi A/B test, phương án tối giản tăng tỷ lệ hoàn tất giao dịch lên 12%.
Tình huống 2 — Khi gu tốt nhưng judgment tồi
Tuấn là PM giàu kinh nghiệm tại một công ty SaaS làm phần mềm quản lý nhà hàng cho thị trường Đông Nam Á. Anh có con mắt thẩm mỹ rất tốt. Khi team xây tính năng đặt bàn, anh kiên quyết theo đuổi một thiết kế lịch đặt bàn cực kỳ tinh tế, kéo-thả mượt mà, với hiệu ứng chuyển cảnh đẹp như app của một startup Thung lũng Silicon.
Vấn đề: khách hàng của họ là các chủ nhà hàng vừa và nhỏ ở Việt Nam, Indonesia, Philippines — nhiều người dùng máy tính cấu hình thấp, đường truyền yếu, và nhân viên thay đổi liên tục. Thiết kế đẹp của Tuấn nặng, lag trên máy yếu, và cần training mới dùng được. Đối thủ ra một bản "xấu hơn nhưng chạy nhẹ và ai cũng hiểu ngay" trước anh 6 tuần, và giành mất nhiều khách.
Bài học: Taste (thẩm mỹ) của Tuấn rất tốt, nhưng Judgment thì sai. Anh tối ưu cho cái đẹp lý tưởng thay vì cái phù hợp với bối cảnh thực — thiết bị, đường truyền, năng lực người dùng và áp lực thời gian thị trường. Judgment giỏi là biết khi nào "đủ tốt và kịp lúc" thắng "hoàn hảo nhưng trễ".
Tình huống 3 — Xây kho reference để nâng gu
Mai mới chuyển từ vị trí business analyst sang PM cho một sàn thương mại điện tử. Cô tự thấy gu sản phẩm còn yếu: khi xem các đề xuất thiết kế, cô không biết cái nào tốt hơn vì không có gì để so sánh.
Cô áp dụng một thói quen đơn giản trong 3 tháng: mỗi tuần chọn một sản phẩm cô ngưỡng mộ (Shopee, Grab, TikTok, Spotify, Notion) và viết một ghi chú ngắn mổ xẻ một quyết định thiết kế — vì sao Grab đặt nút "đặt lại chuyến cũ" ở đó, vì sao Shopee để bộ đếm ngược flash sale to như vậy. Cô lưu tất cả vào một thư viện cá nhân, kèm screenshot.
Sau 3 tháng, khi nhìn vào các option của team, Mai bắt đầu nói được những câu như: "Cách này giống pattern 'progressive disclosure' của Notion — ẩn bớt thông tin phức tạp đến khi người dùng cần." Đồng nghiệp bắt đầu hỏi ý kiến cô nhiều hơn.
Bài học: Taste là cơ bắp được xây bằng số lượng reference được phân tích có chủ đích, không phải số reference lướt qua. Việc viết ra "vì sao" quan trọng hơn việc chỉ xem.
Hướng dẫn từng bước
Dưới đây là quy trình bạn có thể áp dụng khi đối diện với "100 options và phải chọn 1".
Bước 1 — Xác định người dùng và bối cảnh trước khi nhìn options. Trước khi mở mockup, viết ra một câu: "Người dùng là ai, đang cố làm gì, trong hoàn cảnh nào?" Nếu bạn nhìn options trước, bạn sẽ bị "đẹp mắt" dẫn dắt thay vì "đúng việc".
Bước 2 — Định nghĩa 2–3 tiêu chí thắng/thua rõ ràng. Ví dụ: (a) giảm số thao tác cho tác vụ phổ biến nhất, (b) chạy được trên thiết bị yếu, (c) không cần training. Tiêu chí biến taste mơ hồ thành phán đoán có thể tranh luận.
Bước 3 — Loại nhanh, đừng chấm điểm từng cái. Với 100 options, đừng chấm điểm cả 100. Loại nhanh 90 cái rõ ràng yếu theo tiêu chí Bước 2. Bạn sẽ còn khoảng 5–10 ứng viên thực sự.
Bước 4 — So sánh ứng viên cuối với reference. Tự hỏi: "Sản phẩm tốt nhất tôi từng thấy giải quyết vấn đề này thế nào?" Đối chiếu để phát hiện điểm yếu mình bỏ sót.
Bước 5 — Áp judgment về thực thi. Hỏi: phương án này tốn bao nhiêu công sức kỹ thuật? Có kịp thị trường không? Rủi ro nếu sai là gì? Đôi khi phương án "tốt thứ hai về taste" lại là quyết định đúng vì rẻ và nhanh hơn nhiều.
Bước 6 — Viết ra một đoạn lý do (rationale). Một đoạn ngắn: "Tôi chọn A vì… , tôi loại B vì… , đánh đổi tôi chấp nhận là…". Đoạn này vừa kiểm tra logic của chính bạn, vừa giúp team học theo gu của bạn.
Lỗi thường gặp & mẹo
Lỗi 1 — Nhầm taste với sở thích cá nhân. "Tôi thích màu này" không phải taste. Taste luôn neo vào người dùng, không vào bạn. Mẹo: mỗi khi định nói "tôi thích", hãy ép mình đổi thành "người dùng X sẽ dễ hơn vì…".
Lỗi 2 — Bị "tê liệt vì lựa chọn" trước 100 options. Càng nhiều option, càng dễ chần chừ. Mẹo: định nghĩa tiêu chí trước khi xem options, rồi loại nhanh. Quyết định nằm ở tiêu chí, không ở việc ngắm từng cái.
Lỗi 3 — Tối ưu cho "đẹp" thay vì "đúng bối cảnh". Như câu chuyện của Tuấn — gu thẩm mỹ tốt vẫn dẫn tới quyết định tồi. Mẹo: luôn hỏi "đẹp với ai, trên thiết bị gì, kịp thời gian nào?".
Lỗi 4 — Trực giác mạnh nhưng không diễn đạt được. Nếu bạn chỉ nói "không ổn", team sẽ phục tùng nhưng không trưởng thành, và bạn không scale được. Mẹo: tập thói quen viết một dòng rationale cho mỗi quyết định.
Lỗi 5 — Không nuôi kho reference. Gu không tự lớn. PM nào ngừng quan sát sản phẩm khác sẽ tụt hậu nhanh. Mẹo: dành 30 phút mỗi tuần mổ xẻ một quyết định thiết kế của một sản phẩm bạn ngưỡng mộ.
Mẹo nâng cao — "Calibrate" gu với người giỏi hơn. Mỗi khi bạn ra một quyết định taste, hãy hỏi một PM/designer mà bạn nể: "Anh/chị sẽ chọn cái nào và vì sao?" So sánh lý do của họ với lý do của bạn. Đây là cách nhanh nhất để hiệu chỉnh la bàn nội tại.
Bài tập thực hành
Bài tập 1 — Mổ xẻ reference (làm hằng tuần, bắt đầu ngay tuần này). Chọn một sản phẩm bạn dùng thường xuyên (Shopee, Grab, Spotify, Notion…). Chọn một màn hình. Viết 150–200 từ trả lời: PM/designer đã đưa ra những lựa chọn nào? Họ đã không làm gì (cắt bỏ gì)? Vì sao bạn nghĩ họ chọn vậy? Lưu lại thành ghi chú đầu tiên trong "thư viện reference" của bạn.
Bài tập 2 — 10 options, 3 tiêu chí. Lấy một tính năng bạn đang làm (hoặc tự nghĩ ra: ví dụ "màn hình đăng nhập"). Tự phác hoặc dùng AI tạo 10 biến thể. Trước khi xem, viết ra người dùng mục tiêu và 3 tiêu chí thắng/thua. Sau đó loại còn 2 ứng viên và viết một đoạn rationale 200 từ giải thích lựa chọn cuối cùng cùng đánh đổi bạn chấp nhận.
Bài tập 3 — Calibration với đồng nghiệp. Đưa cùng bài tập 2 cho một đồng nghiệp mà không cho họ xem lựa chọn của bạn. So sánh kết quả và lý do. Ghi lại: tiêu chí nào bạn bỏ sót mà họ thấy? Đây là điểm để bạn nâng gu.
Tóm tắt
- Product Taste là khả năng nhìn vào rất nhiều lựa chọn và nhận ra — cùng giải thích được — đâu là lựa chọn tốt nhất cho người dùng cụ thể của bạn. Nó không phải sở thích cá nhân, mà là trực giác có cấu trúc.
- Judgment là taste khi đặt vào áp lực thực tế: thiếu thông tin, thiếu thời gian, thiếu đồng thuận. Gu đẹp mà judgment sai vẫn dẫn tới quyết định tồi (bài học từ Tuấn).
- Trong kỷ nguyên AI, tạo ra options gần như miễn phí, nên giá trị của PM dịch chuyển sang khâu chọn lọc. Taste tốt là con hào phòng thủ thực sự.
- Ba trụ cột để xây taste: hiểu sâu người dùng, tích lũy kho reference qua phân tích có chủ đích, và khả năng diễn đạt tiêu chí rõ ràng.
- Quy trình chọn 1 trong 100: xác định người dùng → định nghĩa tiêu chí → loại nhanh → đối chiếu reference → áp judgment thực thi → viết rationale.
- Taste là cơ bắp, không phải năng khiếu. Mỗi tuần một ghi chú reference, mỗi quyết định một dòng lý do, mỗi tháng một lần hiệu chỉnh với người giỏi hơn — đó là con đường rèn luyện.