Mở đầu — vì sao bài này quan trọng
Nếu bạn đã làm Marketing một thời gian, chắc chắn bạn đã từng ngồi hàng giờ để xây dựng một bản persona khách hàng: tên giả định, tuổi, nghề nghiệp, thu nhập, sở thích, nỗi đau khi mua hàng, kênh họ hay lướt vào buổi tối... Bạn dán ảnh chân dung lên slide, đặt tên cho cô ấy là "Chị Lan, 32 tuổi, mẹ bỉm sữa ở Quận 7", và mọi chiến dịch quảng cáo sau đó đều xoay quanh chị Lan.
Tin tốt là: kỹ năng xây persona của bạn cực kỳ giá trị khi chuyển sang BA. Tin cần lưu ý là: BA dùng persona theo một cách khác, và quan trọng hơn — BA phải xây hai loại persona, không phải một. Đây chính là điểm nhiều marketer chuyển sang BA bị "hụt" vì cứ áp nguyên tư duy cũ.
Trong bài này, chúng ta sẽ làm rõ sự khác nhau giữa marketing persona (chân dung khách hàng để bán hàng) và hai loại persona mà một BA cần: user persona (người dùng cuối của sản phẩm) và stakeholder persona (các bên liên quan trong dự án — sếp, phòng ban, đối tác). Hiểu được điều này, bạn sẽ không chỉ "tái sử dụng" được kỹ năng cũ mà còn tránh được những hiểu lầm khiến dự án đi sai hướng. Đây là một trong những "cầu nối tư duy" đẹp nhất trong toàn bộ hành trình Marketing-sang-BA.
Khái niệm cốt lõi
Marketing persona tập trung vào điều gì?
Một marketing persona thường được xây dựng để trả lời câu hỏi: "Làm sao để người này mua hàng của tôi?". Vì vậy nó tập trung vào:
- Demographic (nhân khẩu học): tuổi, giới tính, thu nhập, khu vực sống, nghề nghiệp.
- Psychographic (tâm lý học): giá trị sống, sở thích, lối sống, động lực.
- Buying behavior (hành vi mua): họ mua qua kênh nào, quyết định nhanh hay chậm, nhạy cảm với giá hay với thương hiệu.
- Pain trong purchase journey (nỗi đau trong hành trình mua): điều gì khiến họ chần chừ, từ bỏ giỏ hàng, hoặc chọn đối thủ.
BA cần hai loại persona
Khi bạn trở thành BA, "khách hàng" không còn là một khái niệm duy nhất nữa. Bạn cần phân biệt rạch ròi:
1. User Persona — chân dung người dùng cuối
Đây là người thực sự sử dụng sản phẩm/phần mềm bạn đang xây. Câu hỏi cốt lõi không còn là "làm sao để họ mua" mà là "họ cần làm xong việc gì, và cái gì đang cản trở họ?". User persona tập trung vào:
- Goals (mục tiêu công việc): họ mở app này ra để hoàn thành tác vụ gì?
- Tasks & Workflow (tác vụ và luồng làm việc): các bước họ thực hiện, theo thứ tự nào.
- Pain points trong quá trình sử dụng: thao tác rườm rà, thông tin khó tìm, lỗi hay gặp.
- Bối cảnh sử dụng (context of use): họ dùng trên điện thoại hay máy tính, ở văn phòng hay ngoài đường, đang vội hay thong thả.
- Technical proficiency (mức độ rành công nghệ): rành hay không rành thiết bị.
2. Stakeholder Persona — chân dung các bên liên quan
Đây là loại persona mà marketer hầu như chưa từng nghĩ tới, nhưng lại quyết định sự thành bại của một BA. Stakeholder là bất kỳ ai có ảnh hưởng hoặc bị ảnh hưởng bởi dự án: giám đốc kinh doanh duyệt ngân sách, trưởng phòng vận hành sẽ dùng hệ thống, đội pháp chế lo về tuân thủ, đối tác tích hợp API... Stakeholder persona tập trung vào:
- Interest (mối quan tâm): họ muốn dự án này đạt được điều gì cho họ?
- Influence/Power (mức ảnh hưởng): họ có quyền quyết định, phủ quyết, hay chỉ góp ý?
- Concerns/Pain (nỗi lo): điều gì khiến họ phản đối hoặc trì hoãn dự án?
- Communication style (cách giao tiếp ưa thích): thích số liệu hay câu chuyện, thích email hay họp trực tiếp, thích chi tiết hay tổng quan.
- Success criteria (tiêu chí thành công của riêng họ): với họ, dự án "thành công" nghĩa là gì?
Bảng so sánh nhanh
| Tiêu chí | Marketing Persona | User Persona (BA) | Stakeholder Persona (BA) |
|---|---|---|---|
| Câu hỏi cốt lõi | Làm sao để họ mua? | Họ cần làm xong việc gì? | Họ muốn gì từ dự án và có quyền gì? |
| Trọng tâm | Conversion | Workflow & goals | Interest & influence |
| Mốc thời gian | Trước khi mua | Trong khi sử dụng | Suốt vòng đời dự án |
| Dữ liệu chính | Hành vi mua, tâm lý | Tác vụ, pain khi dùng | Quyền lực, mối quan tâm, nỗi lo |
Tình huống thực tế
Ví dụ 1 — App đặt lịch khám của một phòng khám tư ở TP.HCM
Chị Hương từng làm Marketing cho một chuỗi phòng khám đa khoa, nay chuyển sang làm BA cho dự án app đặt lịch khám online. Theo quán tính cũ, chị làm ngay một persona: "Cô Mai, 45 tuổi, nội trợ, lo lắng về sức khỏe, hay tìm thông tin trên Facebook" — một marketing persona điển hình, tập trung vào việc thuyết phục cô Mai tải app.
Nhưng khi vào họp với đội dev, mọi người hỏi: "Vậy cô Mai dùng app như thế nào? Cô ấy chọn bác sĩ trước hay chọn ngày trước? Cô ấy có biết phân biệt chuyên khoa không?". Chị Hương "đứng hình" vì persona cũ không trả lời được.
Chị làm lại thành user persona: "Cô Mai vào app với mục tiêu đặt được lịch khám tim mạch trong tuần này. Cô không rành chuyên khoa nên cần gợi ý triệu chứng → chuyên khoa. Cô dùng điện thoại, mắt kém nên cần font lớn. Pain lớn nhất: sợ đặt nhầm bác sĩ rồi mất tiền." Bản này dẫn thẳng đến các yêu cầu chức năng cụ thể: tính năng "chọn theo triệu chứng", cỡ chữ lớn, màn hình xác nhận rõ ràng.
Bài học: Marketing persona dừng ở "vì sao tải app". User persona đi tiếp vào "dùng app ra sao" — và chính phần sau mới sinh ra requirements.
Ví dụ 2 — Dự án hệ thống quản lý kho cho một công ty bán lẻ (kiểu Bách Hóa Xanh)
Anh Tuấn, BA mới chuyển từ Marketing, được giao dự án thay hệ thống quản lý tồn kho cũ. Anh phỏng vấn rất kỹ nhân viên kho (user) và xây user persona tốt. Nhưng anh bỏ qua hoàn toàn stakeholder persona.
Kết quả: đến buổi demo, Giám đốc Tài chính bất ngờ phản đối gay gắt vì hệ thống mới không xuất được báo cáo giá vốn theo chuẩn kế toán bà cần. Dự án bị "treo" hai tuần. Hóa ra bà CFO là một stakeholder có quyền phủ quyết ngân sách, mối quan tâm của bà là kiểm soát chi phí và tuân thủ kế toán, chứ không phải trải nghiệm của nhân viên kho.
Sau cú vấp này, anh Tuấn lập stakeholder persona cho từng bên: "CFO — quyền lực cao, quan tâm số liệu tài chính chính xác, ghét rủi ro tuân thủ, thích báo cáo dạng bảng chi tiết, cần được hỏi ý kiến SỚM." Nếu có bản này từ đầu, anh đã biết phải mời bà vào vòng lấy yêu cầu ngay tuần đầu tiên.
Bài học: Bỏ quên stakeholder persona là một trong những lỗi đắt giá nhất của BA mới. Người có quyền lớn nhất với dự án thường không phải người dùng hằng ngày.
Ví dụ 3 — Tái sử dụng dữ liệu Marketing để xây persona BA tại một fintech
Tại một ví điện tử giả định tên "PayViet", bạn — BA xuất thân Marketing — được giao thiết kế lại luồng nạp tiền. Lợi thế của bạn: bạn đã có sẵn kho dữ liệu hành vi từ thời làm Marketing — phân khúc người dùng theo độ tuổi, tần suất giao dịch, tỷ lệ rớt ở từng bước funnel.
Bạn biến dữ liệu đó thành ba user persona dựa trên hành vi thực: nhóm "giao dịch nhanh" (đã thuộc lòng thao tác, cần ít bước), nhóm "thận trọng" (kiểm tra kỹ, cần màn hình xác nhận), nhóm "mới và bối rối" (cần hướng dẫn). Mỗi nhóm dẫn đến một yêu cầu giao diện khác nhau. Đây là minh chứng rõ ràng rằng nền Marketing không phải gánh nặng — nó là mỏ vàng dữ liệu để xây persona BA sát thực tế hơn cả những BA thuần kỹ thuật.
Bài học: Đừng vứt bỏ dữ liệu và bản năng Marketing. Hãy chuyển hệ quy chiếu của chúng từ "bán hàng" sang "thiết kế giải pháp".
Hướng dẫn từng bước
Đây là quy trình thực dụng để xây persona theo tư duy BA:
- Liệt kê toàn bộ các bên liên quan trước. Trước khi nghĩ về người dùng, hãy vẽ một danh sách: ai duyệt ngân sách, ai dùng hệ thống, ai bị ảnh hưởng gián tiếp (kế toán, pháp chế, CSKH, đối tác). Đây là bước marketer hay quên.
- Phân loại từng bên thành "user" hay "stakeholder" (hoặc cả hai). Nhân viên kho vừa là user vừa là stakeholder. Sếp thường chỉ là stakeholder. Việc phân loại giúp bạn chọn đúng "trục thông tin" để khai thác.
- Với user persona, khai thác theo trục Goal → Task → Pain → Context. Hỏi: họ mở sản phẩm ra để làm xong việc gì? Các bước cụ thể? Vướng ở đâu? Dùng trong hoàn cảnh nào?
- Với stakeholder persona, khai thác theo trục Interest → Influence → Concern → Communication. Họ muốn gì? Có quyền gì? Lo điều gì? Muốn được trao đổi kiểu nào?
- Đặt mỗi persona lên một "bản đồ" để định mức ưu tiên. Với stakeholder, dùng ma trận Quyền lực–Mối quan tâm (Power–Interest grid): ai quyền cao + quan tâm cao thì phải "quản lý sát" (manage closely). (Phần RACI và Influence Map sẽ được đào sâu ở bài 27.)
- Viết persona ngắn gọn, một trang, có thể đưa cho dev/QA đọc. Persona không phải tài liệu để cất tủ. Nó phải đủ súc tích để cả team tra cứu khi tranh luận "nên làm tính năng này cho ai".
- Cập nhật persona khi có dữ liệu mới. Persona là tài liệu sống. Sau mỗi vòng phỏng vấn hay sau go-live, hãy chỉnh lại cho sát thực tế.
Lỗi thường gặp & mẹo
Lỗi 1 — Bê nguyên marketing persona vào dự án. Một bản đầy "sở thích, thu nhập, hay lướt TikTok" nhưng không có một dòng nào về cách họ thao tác sẽ vô dụng với dev. Mẹo: với mỗi persona, tự hỏi "thông tin này có dẫn tới một yêu cầu chức năng nào không?". Nếu không, có thể bỏ.
Lỗi 2 — Chỉ làm user persona, quên stakeholder persona. Như câu chuyện anh Tuấn ở trên. Mẹo: luôn hỏi "ai có thể nói không với dự án này?" — đó chắc chắn là một stakeholder cần persona riêng.
Lỗi 3 — Tạo quá nhiều persona. Marketer quen chia nhỏ phân khúc để target quảng cáo, nên dễ tạo 10 persona. Trong BA, 3–5 user persona cốt lõi là đủ. Quá nhiều sẽ làm loãng ưu tiên. Mẹo: gộp các nhóm có cùng goal và cùng workflow thành một.
Lỗi 4 — Persona "tưởng tượng" thay vì dựa trên dữ liệu. Đừng bịa ra một người dùng lý tưởng. Mẹo: neo persona vào dữ liệu thật — phỏng vấn, analytics, ticket hỗ trợ. Lợi thế của bạn là biết cách đọc dữ liệu hành vi từ thời Marketing.
Lỗi 5 — Nhầm "người mua" với "người dùng". Trong B2B, người ký hợp đồng (sếp) thường khác người dùng hằng ngày (nhân viên). Marketing hay gộp hai vai này. BA phải tách: người mua là stakeholder, người dùng là user.
Mẹo vàng: Khi chuyển từ marketing persona sang BA persona, hãy giữ lại phần "đồng cảm" (empathy) và chỉ thay phần "mục đích". Sự đồng cảm là kỹ năng quý nhất bạn mang theo từ Marketing.
Bài tập thực hành
Hãy chọn một sản phẩm bạn quen thuộc — ví dụ app giao đồ ăn như ShopeeFood hoặc một hệ thống nội bộ ở công ty bạn — và làm các bước sau:
- Liệt kê tối thiểu 5 bên liên quan của sản phẩm đó. Đánh dấu mỗi bên là user, stakeholder, hay cả hai.
- Xây 1 user persona hoàn chỉnh theo trục Goal → Task → Pain → Context. Viết gọn trong một trang, đặt tên và một câu mô tả ngắn cho nhân vật.
- Xây 1 stakeholder persona hoàn chỉnh theo trục Interest → Influence → Concern → Communication. Chọn người mà bạn nghĩ có quyền lực cao nhất.
- Lấy một marketing persona cũ (nếu bạn từng làm Marketing) và viết ra 3 điểm khác biệt khi bạn chuyển nó sang user persona. Cụ thể: thông tin nào bạn bỏ đi, thông tin nào bạn thêm vào?
- Tự kiểm tra: với mỗi dòng thông tin trong persona, gạch chân những dòng dẫn trực tiếp tới một yêu cầu chức năng. Nếu dưới một nửa số dòng làm được điều đó, persona của bạn còn quá "Marketing" — hãy viết lại.
Tóm tắt
- Marketing persona trả lời câu hỏi "làm sao để họ mua", tập trung demographic, psychographic, buying behavior và pain trong hành trình mua.
- BA cần hai loại persona: user persona (người dùng cuối — trục Goal/Task/Pain/Context) và stakeholder persona (các bên liên quan — trục Interest/Influence/Concern/Communication).
- Kỹ năng đồng cảm và đọc dữ liệu hành vi từ Marketing là lợi thế lớn; cái cần thay đổi chỉ là mục đích và trục thông tin nhấn mạnh.
- Lỗi chết người nhất của BA mới là quên stakeholder persona — người có quyền lớn nhất với dự án thường không phải người dùng hằng ngày.
- Persona BA phải dựa trên dữ liệu, ngắn gọn một trang, dẫn được tới yêu cầu chức năng, và được cập nhật như một tài liệu sống.