Mở đầu — vì sao bài này quan trọng
Nếu bạn từng đứng trước khách hàng và "chốt" được một hợp đồng khó, bạn đã sở hữu một năng lực mà nhiều BA mới vào nghề phải mất hàng năm để học: khả năng biến một mong muốn mơ hồ của con người thành một cam kết cụ thể, có thể hành động được. Đó chính xác là điều một Business Analyst làm mỗi ngày — chỉ khác là sản phẩm cuối không phải chữ ký trên hợp đồng, mà là một tài liệu yêu cầu sản phẩm (Product Requirements) mà đội kỹ thuật có thể đem đi xây.
Bài học này tập trung vào một phép dịch rất cụ thể: từ Sales Pitch sang Product Requirements. Đây không phải bài nói về "BA là gì" (Bài 2 đã lo), cũng không phải bài dạy viết User Story chi tiết (Bài 4 và Bài 17 sẽ đi sâu). Bài 7 trả lời một câu hỏi hẹp nhưng quan trọng: Bạn — người quen kể chuyện để bán hàng — phải thay đổi cách tư duy và cách viết như thế nào để tạo ra một bản yêu cầu sản phẩm đúng chuẩn?
Lý do bài này quan trọng với người chuyển nghề từ Sales/BD: bản năng đầu tiên của bạn khi nhận một yêu cầu sẽ là "đóng gói" nó thành một câu chuyện hấp dẫn, có cảm xúc, hướng tới việc thuyết phục. Nhưng Product Requirements lại đòi hỏi điều gần như ngược lại — sự chính xác, trung lập, có thể kiểm chứng. Nếu bạn không nhận ra sự khác biệt này sớm, bạn sẽ viết ra những tài liệu "nghe rất hay" nhưng dev đọc xong không biết phải code cái gì. Học được phép dịch này, bạn vừa giữ được thế mạnh kể chuyện, vừa có thêm kỷ luật của một người làm yêu cầu.
Khái niệm cốt lõi
Sales Pitch và Product Requirements khác nhau ở đâu?
Hãy hình dung hai văn bản đặt cạnh nhau.
Sales Pitch là công cụ thuyết phục. Mục tiêu của nó là tạo ra một quyết định mua. Nó có cấu trúc cảm xúc: nêu nỗi đau, khuấy động nó lên, rồi đưa ra giải pháp như một sự giải thoát. Nó dùng ngôn ngữ tối đa hóa lợi ích ("tăng doanh thu gấp đôi", "tiết kiệm 80% thời gian"), thường mơ hồ về chi tiết kỹ thuật vì chi tiết làm chậm quyết định mua. Người nghe là người ra quyết định mua hàng, không phải người xây sản phẩm.
Product Requirements là công cụ xây dựng. Mục tiêu của nó là tạo ra một sản phẩm đúng. Nó có cấu trúc logic: ai cần gì, trong bối cảnh nào, để đạt mục tiêu gì, và làm sao biết là đã đạt. Nó dùng ngôn ngữ chính xác, có thể kiểm chứng và đo lường được. Người đọc là dev, tester, designer — những người sẽ biến chữ thành code.
Sự khác biệt cốt lõi nằm ở hướng của cam kết. Sales Pitch hướng cam kết ra ngoài — bạn hứa với khách hàng. Product Requirements hướng cam kết vào trong — bạn ràng buộc đội phát triển phải làm đúng một điều cụ thể. Một bên là nghệ thuật phóng đại có kiểm soát; một bên là kỷ luật của sự rõ ràng.
Ba thứ Sales Pitch hay "giấu" mà Requirements bắt phải "lộ"
Khi dịch từ pitch sang requirements, có ba thứ mà người Sales theo bản năng hay bỏ qua, nhưng BA bắt buộc phải làm rõ:
- Điều kiện biên (edge cases). Pitch luôn nói về kịch bản đẹp nhất — khách hàng dùng đúng cách, dữ liệu sạch, mọi thứ suôn sẻ. Requirements phải mô tả cả khi sai: nhập sai định dạng thì sao, mất mạng giữa chừng thì sao, hai người sửa cùng lúc thì sao.
- Tiêu chí "đủ tốt" (acceptance criteria). Pitch nói "nhanh", "dễ dùng", "mạnh mẽ". Requirements phải định lượng: nhanh là dưới 2 giây, dễ dùng là hoàn tất trong 3 bước, mạnh mẽ là chịu được 500 người dùng đồng thời.
- Phạm vi (scope). Pitch ngầm hứa "tất cả mọi thứ". Requirements phải vẽ ra rõ ràng cái gì làm, cái gì không làm trong phiên bản này. Việc nói "không làm" là kỹ năng mới mà người Sales hay thấy khó chịu, nhưng nó cứu cả dự án.
Khung dịch 5 lớp: từ một câu pitch sang yêu cầu
Bạn có thể dùng khung này như một bộ lọc. Lấy bất kỳ câu nói nào trong pitch và bóc tách qua 5 lớp:
- Lớp 1 — Lời hứa (Promise): Câu pitch đang hứa điều gì? ("Hệ thống tự động nhắc khách hàng gia hạn.")
- Lớp 2 — Người dùng & bối cảnh (Who & When): Ai được hưởng lợi, vào lúc nào? ("Nhân viên CSKM, khi hợp đồng còn 30 ngày là hết hạn.")
- Lớp 3 — Hành vi cụ thể (Behavior): Hệ thống thực sự làm gì? ("Gửi email + tạo task trong CRM cho nhân viên phụ trách.")
- Lớp 4 — Quy tắc & điều kiện (Rules & Edge): Khi nào kích hoạt, khi nào không, ngoại lệ gì? ("Chỉ với hợp đồng trạng thái Active; bỏ qua nếu khách đã gia hạn; nếu email lỗi thì retry 3 lần.")
- Lớp 5 — Tiêu chí nghiệm thu (Acceptance): Làm sao biết đã đúng? ("Đúng 100% hợp đồng đủ điều kiện được nhắc trong vòng 1 giờ kể từ mốc 30 ngày.")
Tình huống thực tế
Ví dụ 1 — Pitch "tự động hóa" tại một công ty SaaS quản lý phòng gym ở TP.HCM
Bối cảnh: Một công ty SaaS (gọi là GymUp) bán phần mềm quản lý phòng tập. Trong buổi demo, Sales đã pitch: "Phần mềm sẽ tự động giữ chân hội viên sắp bỏ tập — hệ thống thông minh nhận diện ai có nguy cơ rời đi và nhắc nhở họ quay lại." Khách hàng — một chuỗi 8 phòng gym — gật đầu ký hợp đồng. Giờ tài liệu đó về tay bạn, BA mới chuyển từ Sales.
Diễn giải: Câu pitch nghe tuyệt vời nhưng chứa ba quả bom mơ hồ. "Thông minh nhận diện ai có nguy cơ" — dựa trên dữ liệu nào? "Nhắc nhở quay lại" — bằng kênh gì, ai bấm nút? "Tự động" — chạy lúc nào?
Khi áp khung 5 lớp, bạn phải ngồi lại với chủ phòng gym và đào ra: nguy cơ rời đi được định nghĩa là "hội viên không check-in quá 14 ngày liên tiếp" (một quy tắc cụ thể, không phải AI thần thánh). Nhắc nhở là gửi tin nhắn Zalo + giảm giá 1 buổi PT. Tự động là job chạy mỗi sáng 6h, gửi tối đa 50 tin/ngày để không spam.
Bài học rút ra: Cái mà pitch gọi là "thông minh" thường chỉ là một business rule đơn giản mà chưa ai chịu viết ra. Việc của BA không phải là hứa hẹn AI, mà là làm lộ ra cái quy tắc cụ thể đằng sau lời hứa. Khi bạn dịch "thông minh" thành "không check-in quá 14 ngày", bạn vừa cứu đội dev khỏi 3 tháng hiểu lầm.
Ví dụ 2 — BD pitch tích hợp thanh toán cho một ví điện tử
Bối cảnh: Một BD của startup fintech (gọi là PayNhanh) đã chốt được deal tích hợp ví điện tử vào một sàn thương mại điện tử. Trong email chốt deal, BD viết cho đối tác: "Bên anh chỉ cần thêm vài dòng, khách của anh sẽ thanh toán bằng ví chỉ với một chạm, mượt mà như Apple Pay." Đối tác hào hứng. Bạn là BA phải viết requirements cho team kỹ thuật của PayNhanh.
Diễn giải: "Một chạm" và "mượt như Apple Pay" là ngôn ngữ pitch điển hình — tối đa hóa cảm giác đơn giản, giấu đi sự phức tạp. Nhưng để dev xây, bạn phải bóc ra: "một chạm" thực ra cần luồng xác thực (OTP lần đầu, lưu token cho lần sau), cần xử lý khi số dư không đủ, khi giao dịch timeout, khi đối tác gọi lại để hoàn tiền (refund). "Mượt như Apple Pay" phải dịch thành tiêu chí đo được: thời gian phản hồi API dưới 1,5 giây ở mức 95th percentile, tỷ lệ giao dịch thành công trên 99%.
Bạn viết acceptance criteria dạng: "Cho một khách đã liên kết ví và đủ số dư, khi bấm Thanh toán bằng PayNhanh, hệ thống hoàn tất giao dịch và hiển thị màn hình thành công trong dưới 2 giây ở 95% trường hợp." Đồng thời bạn liệt kê 4 luồng thất bại mà pitch không hề nhắc tới.
Bài học rút ra: Sales/BD bán cảm giác đơn giản; BA phải quản lý độ phức tạp đằng sau cảm giác đó. Mỗi từ êm tai trong pitch ("một chạm", "tức thì", "an toàn tuyệt đối") là một tín hiệu để bạn dừng lại và hỏi: "Cụ thể luồng nào, đo bằng con số nào, hỏng thì xử lý ra sao?"
Ví dụ 3 — Lời hứa "báo cáo real-time" trong một deal B2B
Bối cảnh: Tại một công ty cung cấp phần mềm logistics ở Hà Nội, Sales đã hứa với một khách hàng vận tải lớn: "Sếp sẽ thấy vị trí toàn bộ đội xe theo thời gian thực, cập nhật từng giây." Khách rất thích cụm "từng giây". Bạn nhận yêu cầu viết spec.
Diễn giải: "Từng giây" nghe thì oai nhưng nếu làm thật, mỗi xe gửi tọa độ mỗi giây sẽ tạo ra hàng triệu bản ghi mỗi ngày, đội chi phí hạ tầng và pin thiết bị GPS lên gấp nhiều lần — mà người dùng thực tế nhìn bản đồ không phân biệt nổi giữa 1 giây và 15 giây. Là BA, bạn phải quay lại đào nhu cầu thật phía sau lời hứa: điều khách cần là "biết xe đang ở đâu, có đi đúng tuyến không, có dừng bất thường không". Tần suất 10–15 giây là quá đủ.
Bạn dịch yêu cầu thành: "Vị trí xe cập nhật tối thiểu mỗi 15 giây; cảnh báo khi xe lệch tuyến quá 500m hoặc dừng quá 10 phút ngoài điểm giao." Đây mới là requirement vừa khả thi kỹ thuật, vừa giải đúng bài toán kinh doanh.
Bài học rút ra: Đôi khi việc dịch pitch sang requirements buộc bạn phải thương lượng lại lời hứa — không phải để "lật kèo" khách, mà để tìm ra điều khách thực sự cần thay vì điều Sales đã lỡ nói. Đây chính là lúc kỹ năng đào nhu cầu (vốn là sở trường của Sales giỏi) trở thành vũ khí của BA.
Hướng dẫn từng bước
Đây là quy trình bạn có thể áp dụng cho bất kỳ tài liệu pitch nào rơi vào tay mình:
Bước 1 — Thu thập nguyên liệu pitch. Tập hợp tất cả những gì đã được hứa: bản demo, slide bán hàng, email chốt deal, ghi chú cuộc gọi. Đây là "nguồn sự thật" về kỳ vọng của khách hàng — nhưng là kỳ vọng chưa được dịch.
Bước 2 — Gạch chân mọi từ mơ hồ. Đọc lại và đánh dấu các từ kiểu "thông minh", "tự động", "real-time", "dễ dùng", "an toàn", "tích hợp liền mạch". Mỗi từ được gạch chân là một yêu cầu cần được làm rõ.
Bước 3 — Áp khung 5 lớp cho từng lời hứa. Với mỗi lời hứa, lần lượt trả lời: Hứa gì? Cho ai, khi nào? Hành vi cụ thể là gì? Quy tắc và ngoại lệ ra sao? Đo bằng tiêu chí nào? Nếu có lớp nào bạn không trả lời được, đó là câu hỏi để mang đi phỏng vấn stakeholder.
Bước 4 — Phân loại: nhu cầu thật vs. lời nói tô vẽ. Tách ra đâu là yêu cầu kinh doanh thực sự, đâu là ngôn ngữ phóng đại để bán. Với phần phóng đại, hãy đào xuống nhu cầu gốc (như ví dụ "từng giây" thật ra chỉ cần 15 giây).
Bước 5 — Viết lại dưới dạng yêu cầu kiểm chứng được. Mỗi yêu cầu phải đi kèm tiêu chí nghiệm thu đo được. Mẹo kiểm tra: nếu hai dev đọc xong mà có thể hiểu thành hai thứ khác nhau, yêu cầu chưa đủ rõ.
Bước 6 — Đánh dấu rõ phạm vi và giả định. Ghi rõ "trong phiên bản này KHÔNG bao gồm…" và "giả định rằng…". Điều này bảo vệ cả bạn lẫn đội dev khi khách hàng sau này đòi thứ chưa từng được cam kết chính thức.
Bước 7 — Đối chiếu ngược với khách hàng. Trước khi bàn giao cho dev, gửi lại bản đã dịch cho người ra quyết định (qua Sales/account manager) để xác nhận: "Đây là điều chúng ta sẽ xây, đúng với điều anh/chị mong đợi không?" Bước này dùng đúng kỹ năng "chốt" của bạn — nhưng giờ là chốt phạm vi, không phải chốt hợp đồng.
Lỗi thường gặp & mẹo
Lỗi 1 — Copy nguyên ngôn ngữ pitch vào tài liệu yêu cầu. Nhiều ex-Sales viết requirements mà đọc lên vẫn như slide bán hàng: đầy tính từ, thiếu con số. Mẹo: sau khi viết xong, tự hỏi từng câu "dev test cái này bằng cách nào?". Nếu không trả lời được, viết lại.
Lỗi 2 — Sợ nói "không" với khách. Người Sales có bản năng làm hài lòng, nên hay viết yêu cầu ôm đồm mọi lời hứa. Kết quả là scope phình to, dự án trễ. Mẹo: học cách nói "cái này để phase 2" một cách chuyên nghiệp — đó là bảo vệ deal, không phải phá deal.
Lỗi 3 — Bỏ qua luồng thất bại. Pitch không bao giờ nói về lỗi, nên ex-Sales hay quên viết edge case. Mẹo: với mỗi luồng "happy path", ép bản thân viết ít nhất 2 câu hỏi "nếu… thì sao?" (mất mạng, sai dữ liệu, trùng thao tác).
Lỗi 4 — Nhầm lẫn giữa lợi ích và tính năng. Pitch nói lợi ích ("tăng doanh thu"); requirements cần tính năng ("báo cáo doanh thu theo chi nhánh, xuất Excel"). Mẹo: lợi ích trả lời "tại sao", tính năng trả lời "cái gì". Tài liệu yêu cầu cần cả hai nhưng phải tách bạch.
Mẹo tận dụng thế mạnh: Đừng vứt bỏ khả năng kể chuyện. Hãy dùng nó ở phần bối cảnh và mục tiêu kinh doanh của tài liệu — nơi giúp dev hiểu "tại sao chúng ta làm cái này". Chỉ cần chuyển sang giọng chính xác, đo được khi tới phần yêu cầu chi tiết. Một BA xuất thân Sales giỏi nhất là người biết bật/tắt đúng lúc giữa hai giọng văn này.
Bài tập thực hành
Bài 1 — Dịch một câu pitch của chính bạn. Lấy một câu bán hàng bạn từng dùng (hoặc một câu quảng cáo phần mềm bất kỳ). Áp khung 5 lớp và viết ra đầy đủ: Promise, Who & When, Behavior, Rules & Edge, Acceptance. Mục tiêu: biến một câu marketing thành một yêu cầu dev có thể đọc và xây.
Bài 2 — Săn từ mơ hồ. Tìm một trang landing page của một sản phẩm SaaS Việt Nam (ví dụ phần mềm kế toán, CRM, hay POS). Gạch chân tất cả từ mơ hồ ("thông minh", "tự động", "nhanh chóng"…) và với mỗi từ, viết một câu hỏi bạn sẽ hỏi stakeholder để làm rõ.
Bài 3 — Viết acceptance criteria đo được. Lấy lời hứa "ứng dụng tải nhanh và mượt mà". Viết lại thành ít nhất 3 tiêu chí nghiệm thu có con số cụ thể (thời gian tải, percentile, số người dùng đồng thời…).
Bài 4 — Phát hiện scope ẩn. Đọc Ví dụ 1 (GymUp) lần nữa và liệt kê 3 thứ mà câu pitch ngầm hứa nhưng không nói rõ, rồi đề xuất cách bạn sẽ khoanh vùng "làm" và "không làm trong phiên bản đầu".
Sau khi làm xong, hãy tự chấm bằng một câu hỏi duy nhất: "Nếu đưa bản này cho một dev chưa từng gặp khách hàng, họ có xây ra đúng thứ khách cần không?"
Tóm tắt
Phép dịch từ Sales Pitch sang Product Requirements là một trong những kỹ năng bản lề của người chuyển từ Sales/BD sang BA. Cốt lõi nằm ở việc nhận ra rằng pitch và requirements có mục đích ngược nhau: một bên thuyết phục mua, một bên hướng dẫn xây; một bên tối đa hóa cảm xúc, một bên tối đa hóa sự chính xác.
Công cụ trung tâm của bài là khung 5 lớp — Promise, Who & When, Behavior, Rules & Edge, Acceptance — giúp bạn bóc tách bất kỳ lời hứa bán hàng nào thành yêu cầu kiểm chứng được. Ba tình huống thực tế (GymUp, PayNhanh, logistics) cho thấy ngôn ngữ tô vẽ của pitch ("thông minh", "một chạm", "từng giây") luôn che giấu những business rule, edge case và tiêu chí đo lường mà BA bắt buộc phải làm lộ ra.
Điều đáng giá nhất: bạn không cần vứt bỏ năng lực Sales. Khả năng đào nhu cầu thật, khả năng kể chuyện để tạo bối cảnh, khả năng "chốt" sự đồng thuận — tất cả vẫn là vũ khí. Bạn chỉ cần thêm vào đó một kỷ luật mới: sự rõ ràng có thể kiểm chứng. Khi làm chủ được phép dịch này, bạn trở thành cầu nối hiếm có giữa thế giới kinh doanh và thế giới kỹ thuật — đúng vị trí mà một BA giỏi đứng.