Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn là Product Owner của một ứng dụng đặt lịch khám bệnh. Trong buổi Sprint Planning, một Developer hỏi: "Người dùng có muốn nhận thông báo qua SMS hay chỉ cần in-app notification thôi?". Bạn ngập ngừng, rồi trả lời theo cảm tính: "Chắc là cả hai cho chắc." Hai Sprint sau, tính năng SMS tốn nhiều công sức nhưng tỷ lệ mở chỉ 3%, vì hóa ra phần lớn người dùng là nhân viên văn phòng trẻ, dùng app liên tục và ghét SMS quảng cáo.
Đó là cái giá của việc làm sản phẩm mà không có chân dung người dùng rõ ràng. Khi cả đội không cùng hình dung "chúng ta đang xây cho ai", mỗi người sẽ tự vẽ ra một người dùng khác nhau trong đầu — và mỗi quyết định nhỏ trong từng câu User Story đều có thể đi lệch hướng.
Persona và User Journey chính là hai công cụ giúp Product Owner biến những giả định mơ hồ thành một bức tranh chung, cụ thể, mà cả Scrum Team đều tin và đều dùng. Đây không phải tài liệu marketing đẹp mắt để treo tường, mà là công cụ ra quyết định hằng ngày: ưu tiên backlog, viết acceptance criteria, tranh luận với stakeholder. Với một PO, hiểu sâu người dùng không phải là "việc nên làm thêm" — đó là phần lõi của vai trò "đại diện tiếng nói khách hàng" trong Scrum. Bài học này sẽ giúp bạn xây Persona dựa trên nghiên cứu (chứ không bịa) và vẽ User Journey để phát hiện những điểm đau (pain point) mà backlog của bạn cần giải quyết.
Khái niệm cốt lõi
User Persona là gì?
Persona là một nhân vật hư cấu nhưng dựa trên dữ liệu nghiên cứu thật, đại diện cho một nhóm người dùng mục tiêu cụ thể. Persona gom những đặc điểm chung của nhiều người dùng thật thành một "khuôn mặt" duy nhất có tên, có nghề nghiệp, có mục tiêu, có nỗi đau — để cả đội dễ ghi nhớ và đồng cảm.
Ba đặc tính quan trọng cần nhớ:
- Hư cấu nhưng dựa trên nghiên cứu (fictional but research-based). "Chị Lan, 34 tuổi" là nhân vật không có thật, nhưng mọi chi tiết về chị phải đến từ phỏng vấn, khảo sát, dữ liệu hành vi thực tế — không phải từ trí tưởng tượng của PO. Persona bịa ra trong phòng họp gọi là "buyer persona giả định", và nó nguy hiểm vì tạo cảm giác chắc chắn sai lầm.
- Đại diện cho một phân khúc người dùng (target segment). Mỗi Persona ứng với một nhóm có nhu cầu và hành vi tương đồng. Một sản phẩm thường có 2–4 Persona chính, không nên quá nhiều.
- Dùng để đồng nhất sự hiểu của cả đội (align team understanding). Đây là mục đích thật sự. Khi Developer, Scrum Master, Designer và PO đều nhắc đến "anh Khoa muốn cái này", họ đang nói về cùng một con người trong đầu.
Thành phần của một Persona (Persona components)
Một Persona đủ dùng thường gồm:
- Tên, ảnh, một câu mô tả ("anh Khoa — quản lý kho bận rộn"): tạo tính người, dễ nhớ.
- Nhân khẩu học liên quan (relevant demographics): tuổi, nghề, địa điểm — chỉ giữ những gì ảnh hưởng đến hành vi dùng sản phẩm.
- Mục tiêu (goals): người này muốn đạt được điều gì khi dùng sản phẩm?
- Nỗi đau / sự bực bội (pain points / frustrations): điều gì cản trở họ hiện nay?
- Hành vi & bối cảnh (behaviors & context): họ dùng thiết bị gì, lúc nào, trong hoàn cảnh nào?
- Trích dẫn đặc trưng (a quote): một câu nói thật từ phỏng vấn, lột tả tinh thần của nhóm này.
User Journey là gì?
User Journey (hành trình người dùng) là chuỗi các bước, suy nghĩ và cảm xúc mà một Persona trải qua khi cố đạt một mục tiêu cụ thể với sản phẩm của bạn. Nếu Persona trả lời câu "ai", thì User Journey trả lời câu "họ đi qua những gì, và đau ở đâu".
Một User Journey Map cơ bản gồm các cột:
- Giai đoạn (stages): ví dụ Nhận biết → Cân nhắc → Đăng ký → Sử dụng lần đầu → Quay lại.
- Hành động (actions): người dùng làm gì ở mỗi giai đoạn.
- Suy nghĩ & cảm xúc (thoughts & emotions): họ đang nghĩ gì, cảm thấy ra sao (tin tưởng, lo lắng, bực bội).
- Điểm chạm (touchpoints): kênh tương tác — app, email, tổng đài, cửa hàng.
- Pain points & cơ hội: chỗ tắc nghẽn và ý tưởng cải thiện.
Persona và User Journey gắn với công việc của PO như thế nào
Với Scrum Product Owner, hai công cụ này phục vụ trực tiếp công việc:
- Khi viết User Story, mẫu "Là một [Persona], tôi muốn [mục tiêu] để [giá trị]" trở nên chân thật vì Persona là người có thật trong tâm trí đội.
- Khi ưu tiên Backlog, bạn ưu tiên hạng mục giải quyết pain point nằm ở điểm trũng cảm xúc trong Journey.
- Khi tranh luận với stakeholder, bạn có cơ sở: "Tính năng này phục vụ ai? Nó nằm ở giai đoạn nào trong hành trình của họ?".
Tình huống thực tế
Ví dụ 1: Tiki và Persona "người mua hàng tỉnh lẻ"
Một đội sản phẩm tại một sàn thương mại điện tử Việt Nam (lấy bối cảnh kiểu Tiki) ban đầu thiết kế luồng thanh toán mặc định ưu tiên thẻ tín dụng và ví điện tử, vì cả đội ở TP.HCM đều dùng thẻ. Họ giả định người dùng cũng vậy.
Sau khi phỏng vấn 25 khách hàng và phân tích dữ liệu đơn hàng, PO phát hiện một phân khúc lớn: "Chị Hằng, 29 tuổi, giáo viên ở Bến Tre". Mục tiêu: mua đồ gia dụng giá tốt mà ở địa phương không có. Pain point: không tin tưởng trả tiền trước online vì sợ "ôm bom" hàng kém chất lượng. Hành vi: dùng điện thoại Android tầm trung, 3G chập chờn, ưa COD (trả tiền khi nhận hàng).
Khi PO vẽ User Journey của chị Hằng, điểm trũng cảm xúc lớn nhất nằm ở bước "xác nhận thanh toán" — chị do dự và bỏ giỏ hàng. Đội liền đưa lên đầu backlog việc làm nổi bật tùy chọn COD và hiển thị chính sách đổi trả ngay tại bước thanh toán. Kết quả giả định nhưng hợp lý: tỷ lệ bỏ giỏ hàng ở nhóm tỉnh giảm khoảng 12%.
Bài học: Persona dựa trên nghiên cứu đã đập tan giả định "ai cũng giống mình" của đội ở thành phố lớn. Một pain point được phát hiện từ Journey đã trực tiếp định hình thứ tự ưu tiên backlog.
Ví dụ 2: Một startup SaaS chấm công nhầm Persona
Một startup SaaS Việt Nam làm phần mềm chấm công cho doanh nghiệp vừa và nhỏ. PO xây Persona duy nhất: "Anh Tuấn — chủ doanh nghiệp 40 tuổi", người ký hợp đồng mua. Cả backlog xoay quanh dashboard báo cáo đẹp cho sếp.
Sau ba Sprint, tỷ lệ dùng thực tế thấp. Khi phỏng vấn lại, đội nhận ra mình đã bỏ quên một Persona quan trọng: "Chị Mai — nhân sự (HR) 32 tuổi", người dùng phần mềm hằng ngày để duyệt đơn nghỉ phép, xuất bảng lương. Pain point của chị Mai là phải sửa tay hàng chục trường hợp quên chấm công mỗi tháng — nhưng tính năng "sửa công hàng loạt" lại nằm tận cuối backlog vì nó không "đẹp" với anh Tuấn.
PO tách thành hai Persona: người mua (economic buyer) và người dùng (end user), rồi vẽ Journey riêng cho chị Mai. Điểm trũng "cuối tháng làm bảng công" lập tức thành ưu tiên số một. Sản phẩm chỉ thật sự được giữ chân khi giải quyết được nỗi đau của người dùng hằng ngày, chứ không chỉ làm hài lòng người ký hợp đồng.
Bài học: Phân biệt rõ "ai trả tiền" và "ai dùng" là điều sống còn trong sản phẩm B2B. Thiếu một Persona có thể khiến cả backlog lệch hướng dù từng tính năng đều "chạy được".
Ví dụ 3: Grab và Journey của tài xế lúc cao điểm
Lấy bối cảnh một nền tảng gọi xe kiểu Grab tại Đông Nam Á. Đội tập trung mãi vào Persona hành khách mà ít chú ý Persona "anh Sơn — tài xế công nghệ 35 tuổi, chạy toàn thời gian". PO quyết định vẽ User Journey một ca làm việc của anh Sơn: bật app sáng → nhận chuyến → tắc đường giờ cao điểm → khách hủy → tìm chuyến mới → kết ca tính thu nhập.
Đường cảm xúc cho thấy hai điểm trũng sâu: lúc bị khách hủy không rõ lý do, và lúc cuối ca không hiểu vì sao thu nhập thấp hơn kỳ vọng. Hai pain point này biến thành hạng mục backlog: hiển thị lý do/đền bù khi bị hủy, và bảng phân tích thu nhập theo giờ minh bạch. Đây là những thứ nếu chỉ nhìn từ góc hành khách thì PO sẽ không bao giờ thấy.
Bài học: Trên nền tảng nhiều bên (marketplace), mỗi bên cần Persona và Journey riêng. Journey buộc đội nhìn theo dòng thời gian của một người, từ đó lộ ra pain point ẩn mà bảng tính năng tĩnh không bao giờ chỉ ra.
Hướng dẫn từng bước
Dưới đây là quy trình thực dụng để một PO xây Persona và Journey mà không tốn hàng tháng nghiên cứu.
Bước 1 — Thu thập dữ liệu (đừng bịa). Gom mọi nguồn sẵn có: 5–10 cuộc phỏng vấn người dùng thật, dữ liệu phân tích (analytics), ticket support, khảo sát, phản hồi từ sales. Mục tiêu là tìm các mẫu hành vi lặp lại, không phải ý kiến cá nhân.
Bước 2 — Nhóm thành phân khúc. Tìm xem người dùng tự nhiên chia thành mấy nhóm theo mục tiêu và hành vi (không phải theo tuổi tác đơn thuần). Mỗi nhóm rõ rệt sẽ thành một Persona. Giữ ở mức 2–4 Persona chính.
Bước 3 — Viết Persona một trang. Mỗi Persona đặt trên một trang gồm: tên + ảnh + câu mô tả, mục tiêu, pain point, hành vi/bối cảnh, một trích dẫn thật. Đánh dấu Persona nào là "primary" (đối tượng ưu tiên thiết kế cho).
Bước 4 — Chọn một Persona primary và một mục tiêu để vẽ Journey. Đừng vẽ Journey cho mọi thứ. Chọn hành trình quan trọng nhất, ví dụ "lần đầu đăng ký và dùng thử".
Bước 5 — Vẽ các cột Journey. Liệt kê các giai đoạn theo thời gian, rồi điền hành động, suy nghĩ/cảm xúc, điểm chạm cho từng giai đoạn. Có thể làm trên Miro, FigJam hoặc đơn giản là bảng giấy dán tường cùng cả đội.
Bước 6 — Đánh dấu điểm trũng cảm xúc và pain point. Khoanh tròn nơi cảm xúc rơi thấp nhất. Mỗi pain point là một ứng viên cho Product Backlog.
Bước 7 — Chuyển pain point thành backlog item. Viết thành User Story gắn với Persona: "Là chị Hằng, tôi muốn thấy tùy chọn COD ngay khi thanh toán để yên tâm đặt hàng". Đưa vào refinement để đội ước lượng và ưu tiên.
Bước 8 — Cập nhật định kỳ. Persona và Journey là tài liệu sống. Mỗi vài tháng, hoặc sau mỗi đợt nghiên cứu/đo lường mới, hãy xem lại và chỉnh sửa. Treo chúng ở nơi cả đội nhìn thấy.
Lỗi thường gặp & mẹo
Lỗi 1 — Persona bịa trong phòng họp. Đây là sai lầm phổ biến nhất: cả đội ngồi tưởng tượng "người dùng chắc là...". Persona không có dữ liệu là giả định ngụy trang thành sự thật. Mẹo: mỗi đặc điểm trong Persona phải trả lời được câu hỏi "căn cứ vào đâu?".
Lỗi 2 — Quá nhiều Persona. Vẽ 8–10 Persona khiến không ai nhớ nổi và mất tác dụng align. Mẹo: giới hạn 2–4 Persona chính, đánh dấu rõ primary.
Lỗi 3 — Persona đầy chi tiết vô dụng. "Thích nuôi mèo, hay đi phượt" — nếu không ảnh hưởng quyết định sản phẩm thì chỉ là nhiễu. Mẹo: mọi dòng phải có sức nặng ra quyết định.
Lỗi 4 — Làm xong rồi cất tủ. Persona đẹp in ra rồi không ai mở lại. Mẹo: dùng tên Persona trong mọi User Story, mọi buổi refinement; treo lên tường/Confluence/Jira.
Lỗi 5 — Nhầm User Journey với quy trình hệ thống (flow chart). Journey nói về cảm xúc và trải nghiệm của con người, không phải sơ đồ luồng dữ liệu. Mẹo: nếu bản đồ của bạn không có dòng cảm xúc, bạn đang vẽ flow chart chứ không phải Journey.
Lỗi 6 — Chỉ làm Persona cho người mua, quên người dùng (B2B). Như ví dụ chấm công ở trên. Mẹo: trong sản phẩm B2B, luôn tách economic buyer và end user.
Mẹo cho PO bận rộn: Bạn không cần nghiên cứu hoàn hảo mới bắt đầu. Hãy làm "proto-persona" (Persona giả thuyết ban đầu) rồi đánh dấu rõ phần nào là giả định, sau đó dùng các Sprint tiếp theo để kiểm chứng và thay giả định bằng dữ liệu thật.
Bài tập thực hành
- Xây một Persona primary. Chọn một sản phẩm bạn đang làm hoặc quen thuộc. Dựa trên mọi dữ liệu bạn có (hoặc 3 cuộc phỏng vấn nhanh với người dùng thật), viết một Persona một trang gồm đủ: tên, mô tả, mục tiêu, 3 pain point, hành vi/bối cảnh, một trích dẫn. Bên cạnh mỗi pain point, ghi nguồn dữ liệu đã căn cứ.
- Vẽ User Journey. Với Persona vừa tạo, chọn một mục tiêu quan trọng (ví dụ "đăng ký và dùng lần đầu"). Vẽ bảng Journey với 4–6 giai đoạn, điền hành động, cảm xúc, điểm chạm. Vẽ đường cảm xúc và khoanh 2 điểm trũng sâu nhất.
- Chuyển thành backlog. Từ 2 điểm trũng đó, viết 2 User Story theo định dạng "Là [Persona], tôi muốn [mục tiêu] để [giá trị]", kèm 2–3 acceptance criteria mỗi story. Tự xếp thứ tự ưu tiên và giải thích vì sao.
- Tự soát lỗi. Đọc lại Persona của bạn và gạch bỏ mọi dòng không ảnh hưởng đến quyết định sản phẩm. Nếu còn dòng nào bạn không trả lời được "căn cứ vào đâu", hãy đánh dấu đó là giả định cần kiểm chứng.
Tóm tắt
Persona là nhân vật hư cấu nhưng dựa trên nghiên cứu, đại diện cho một phân khúc người dùng mục tiêu, với mục đích cốt lõi là giúp cả Scrum Team cùng hiểu "chúng ta đang xây cho ai". Một Persona tốt gồm tên, mục tiêu, pain point, hành vi và một trích dẫn thật — và mọi chi tiết đều phải có căn cứ dữ liệu.
User Journey bổ sung chiều thời gian và cảm xúc: nó cho thấy người dùng đi qua những giai đoạn nào, nghĩ gì, cảm thấy ra sao, và quan trọng nhất là đau ở đâu. Những điểm trũng cảm xúc trong Journey chính là mỏ vàng để PO chọn ra hạng mục ưu tiên cho Product Backlog.
Với Product Owner, hai công cụ này không phải tài liệu trang trí mà là công cụ ra quyết định hằng ngày: viết User Story chân thật hơn, ưu tiên backlog có cơ sở hơn, và tranh luận với stakeholder thuyết phục hơn. Hãy nhớ ba nguyên tắc: dựa trên nghiên cứu (không bịa), giữ ít và sắc (2–4 Persona), và dùng nó liên tục (đừng cất tủ). Khi cả đội cùng gọi tên một con người thật trong tâm trí, mỗi câu chuyện bạn viết ra sẽ phục vụ đúng người cần được phục vụ.