First Principles Thinking cho BA: Cách bẻ nhỏ một bài toán kinh doanh phức tạp thành những mảnh ghép cơ bản

Sau buổi họp kickoff dự án Reso, Minh mang về đúng một câu từ chị Lan Anh: "Tôi muốn một app để khách đặt phòng online, giống mấy khách sạn lớn có." Việc dễ nhất Minh có thể làm lúc này là mở Figma, vẽ vài màn hình "search phòng — chọn ngày — thanh toán" theo đúng khuôn mẫu các app đặt phòng đã quen mắt, rồi mang sang cho Huy dựng backlog. Nhanh, gọn, ai cũng gật đầu.

Nhưng Minh dừng lại ở một câu hỏi khó chịu hơn: "khách sạn lớn có app" — vậy chính xác thì cái app đó giải quyết vấn đề gì cho họ? Và Serene Hotels có đang gặp đúng vấn đề đó không, hay chỉ đang bắt chước cái vỏ ngoài của một giải pháp mà không ai kiểm chứng lại phần lõi?

Đây chính là lúc một BA cần một công cụ tư duy khác hẳn với "nhìn người ta làm sao thì mình làm vậy" — First Principles Thinking (tư duy theo nguyên lý gốc). Bài này sẽ đi cùng Minh áp dụng nó vào chính yêu cầu của chị Lan Anh, để lộ ra một sự thật mà cả hai phía — khách hàng lẫn đội dự án — chưa từng nói thẳng ra.

Sự thật cơ bản (First Principle)

Mọi bài toán kinh doanh phức tạp đều có thể bẻ nhỏ thành các sự thật/định luật cơ bản không ai phản bác được — và giải pháp đúng luôn được xây LẠI từ những sự thật đó, không phải suy luận theo phép loại suy (analogy — "khách sạn khác có app thì mình cũng cần có app").

Đây không phải triết lý suông. Elon Musk từng dùng chính tư duy này để bẻ giá pin xe điện: thay vì hỏi "giá pin thị trường bao nhiêu rồi cộng biên lợi nhuận", ông hỏi "pin làm từ những nguyên tố hoá học nào, giá nguyên liệu thô trên sàn London là bao nhiêu" — và phát hiện giá vật liệu gốc chỉ bằng một phần nhỏ giá pin thành phẩm đang bán. Từ đó Tesla xây lại chuỗi sản xuất pin từ gốc, thay vì chấp nhận mức giá "ai cũng vậy".

BA cũng đứng trước đúng dạng bẫy này mỗi ngày: khách hàng mô tả giải pháp mong muốn ("một cái app"), chứ hiếm khi mô tả sự thật kinh doanh đứng sau nó. Việc của BA không phải là hỏi "app nên có màn hình gì", mà là bóc ngược yêu cầu đó về những sự thật không ai cãi được, rồi xây lại vấn đề từ đó.

Phân tích

Tư duy loại suy vs. tư duy nguyên bản

Hai cách tư duy này khác nhau ở điểm xuất phát:

Tư duy loại suy (analogy thinking): xuất phát từ một giải pháp đã tồn tại ở nơi khác, rồi suy ra "mình cũng nên làm vậy". Đây là cách hầu hết khách hàng — và cả nhiều BA thiếu kinh nghiệm — mặc định sử dụng. Nó nhanh, an toàn về mặt cảm giác (vì "người khác đã làm rồi"), nhưng mang theo rủi ro lớn: sao chép luôn cả bối cảnh không phù hợp.
Tư duy nguyên bản (first principles thinking): xuất phát từ các sự thật/định luật cơ bản của chính bài toán đang giải, rồi xây dựng giải pháp từ đó — bất kể người khác có làm giống vậy hay không.

Câu nói của chị Lan Anh — "giống mấy khách sạn lớn có" — là một câu tư duy loại suy kinh điển. Nó không sai (chị ấy quan sát đúng: các chuỗi lớn đều có app riêng), nhưng nó dừng lại ở tầng hiện tượng, chưa chạm tới tầng nguyên nhân.

Bóc tách yêu cầu Reso về 4 sự thật gốc

Minh ngồi lại, gạt sang một bên câu hỏi "app cần tính năng gì", và tự hỏi: điều gì trong bức tranh này là sự thật không thể chối cãi, bất kể Serene có làm app hay không?

Một khách sạn kiếm tiền theo đúng một công thức: doanh thu phòng = số phòng bán được × giá phòng × tỷ lệ lấp đầy (occupancy rate). Không có biến số nào khác. Bất kỳ giải pháp nào cũng phải tác động được vào một trong ba biến này thì mới có ý nghĩa tài chính thật.
Mỗi đặt phòng qua kênh OTA (Booking.com, Agoda, Traveloka...) khiến khách sạn mất một phần đáng kể doanh thu cho hoa hồng — với Serene, con số này rơi vào khoảng 15-20% giá trị mỗi đơn. Đây là chi phí cố định gắn liền với kênh phân phối, không liên quan gì đến chất lượng app.
Khách hàng hiện tại của Serene phần lớn đặt qua OTA vì họ quen thuộc và tin tưởng kênh đó hơn — chứ không phải vì họ yêu thích OTA hơn bản thân khách sạn. Họ tin Booking.com sẽ bảo vệ họ nếu có tranh chấp, tin đánh giá trên đó, quen thao tác trên đó. Đây là hành vi, không phải sở thích.
"Có một cái app" tự nó không tạo ra giá trị. Một app chỉ có ý nghĩa nếu nó thay đổi được hành vi đặt phòng của khách theo hướng có lợi cho khách sạn — tức là kéo được một phần đặt phòng từ OTA sang kênh trực tiếp, hoặc mở ra được nguồn doanh thu mới (bán thêm spa, tour, đưa đón sân bay) mà OTA không cho phép khách sạn tiếp cận khách để chào bán.

Đặt 4 sự thật này cạnh nhau, bức tranh đổi khác hoàn toàn. Yêu cầu "làm một cái app" chỉ là phương tiện được đề xuất — vấn đề thật nằm ở chỗ khác.

Xây dựng lại vấn đề

Từ 4 sự thật trên, Minh viết lại phát biểu vấn đề (problem statement) của dự án:

Đây KHÔNG PHẢI dự án "làm một cái app đặt phòng". Đây là dự án "dịch chuyển hành vi đặt phòng của khách hàng từ kênh OTA sang kênh trực tiếp, đồng thời sở hữu dữ liệu khách hàng để bán thêm dịch vụ" — và app chỉ là MỘT công cụ có thể phục vụ mục tiêu đó, chứ không phải bản thân mục tiêu.

Sự khác biệt này quyết định toàn bộ hướng đi phía sau. Nếu vấn đề là "làm app", tiêu chí thành công là "app chạy được, khách tải về dùng". Nếu vấn đề là "dịch chuyển hành vi đặt phòng", tiêu chí thành công phải là tỷ lệ đặt phòng trực tiếp tăng lên, chi phí hoa hồng OTA giảm xuống — và app chỉ là một trong nhiều đòn bẩy (có thể còn cần chính sách giá ưu đãi đặt trực tiếp, chương trình khách hàng thân thiết, tích hợp với PMS để đồng bộ tồn phòng thời gian thực...).

Đây cũng chính là điều mà ban giám đốc Serene vừa giao cho chị Lan Anh: giảm chi phí hoa hồng OTA trong năm tới. Áp lực đó chưa từng xuất hiện trong câu nói ban đầu của chị, nhưng nó chính là động lực thật đứng sau yêu cầu "làm app" — và First Principles Thinking là con đường ngắn nhất để một BA như Minh chạm tới nó từ những buổi làm việc đầu tiên, thay vì phát hiện ra giữa chừng dự án khi đã lỡ code gần xong một app "giống khách sạn lớn có" mà không giải quyết đúng gốc rễ.

Giải pháp

Quy trình 3 bước First Principles cho BA

Đây là một kỹ thuật lặp lại được cho bất kỳ dự án nào, không riêng Reso:

Bước 1 — Liệt kê mọi giả định đang được coi là hiển nhiên trong yêu cầu ban đầu.
Đọc kỹ câu nói của khách hàng và gạch dưới từng cụm từ ẩn chứa một giả định chưa kiểm chứng. Với câu của chị Lan Anh, các giả định ẩn là: "có app thì khách sẽ đặt trực tiếp nhiều hơn", "khách sạn lớn có app nên app là giải pháp đúng", "vấn đề nằm ở việc thiếu công nghệ, không phải ở hành vi/chính sách".

Bước 2 — Bóc tách tới các sự thật/định luật kinh doanh gốc mà không ai phản bác được.
Với mỗi giả định ở bước 1, tự hỏi "vì sao điều này đúng?" liên tục cho tới khi chạm đáy — tới điểm mà câu trả lời là một quy luật vận hành/tài chính khách quan (công thức doanh thu, cấu trúc chi phí kênh phân phối, dữ liệu hành vi khách hàng đã quan sát được), không phải một niềm tin hay thói quen.

Bước 3 — Xây dựng lại vấn đề và giải pháp từ những sự thật đó, bỏ qua cách làm "quen thuộc" của người khác.
Từ các sự thật gốc, viết lại phát biểu vấn đề bằng ngôn ngữ mục tiêu kinh doanh (không phải ngôn ngữ tính năng), rồi mới bắt đầu nghĩ giải pháp — lúc này giải pháp có thể trùng với "làm app" (như trường hợp Reso), nhưng được thiết kế đúng trọng tâm, đúng tiêu chí đo lường, thay vì sao chép mù quáng tính năng của đối thủ.

Ba bước này nên được làm thành thói quen ngay ở giai đoạn discovery của bất kỳ dự án nào — càng làm sớm, chi phí sửa sai càng thấp.

📎 Actionable Template

Bảng "First Principles Breakdown" — dùng ngay trong buổi làm việc đầu tiên với sponsor, điền trực tiếp lên màn hình chia sẻ để cùng khách hàng nhìn thấy quá trình bóc tách:

Giả định ban đầu (trong yêu cầu của khách)	Sự thật cơ bản đứng sau (không ai phản bác được)	Vấn đề được xây lại
"Có app thì khách sẽ đặt phòng trực tiếp nhiều hơn."	Doanh thu phòng = số phòng bán × giá phòng × tỷ lệ lấp đầy. Kênh phân phối chỉ là biến trung gian, không phải biến chính.	App phải được thiết kế để tối ưu trực tiếp một trong ba biến trên (đặc biệt là dịch chuyển tỷ trọng kênh bán), không phải chỉ "có mặt" như một kênh mới.
"Khách sạn lớn có app, nên Serene cũng cần app tương tự."	Mỗi đơn qua OTA khiến Serene mất 15-20% doanh thu cho hoa hồng — đây là chi phí kênh phân phối, không phải chi phí công nghệ.	Đây là dự án giảm chi phí kênh phân phối, không phải dự án "bắt kịp công nghệ". Thước đo thành công là % hoa hồng OTA giảm, không phải "app có bao nhiêu tính năng".
"Khách hàng thích đặt qua OTA hơn."	Khách hàng đặt qua OTA vì quen thuộc/tin tưởng kênh đó (hành vi), không phải vì họ yêu thích OTA hơn bản thân khách sạn (sở thích).	Giải pháp cần giải quyết niềm tin và thói quen (chính sách bảo đảm, ưu đãi đặt trực tiếp, trải nghiệm đủ tin cậy), không chỉ là "có nút đặt phòng trên điện thoại".
"Cứ có app đặt phòng là xong việc."	Một công cụ chỉ có giá trị nếu nó thay đổi được hành vi thật của người dùng theo hướng có lợi cho mục tiêu kinh doanh.	Vấn đề thật là "dịch chuyển hành vi đặt phòng từ OTA sang kênh trực tiếp + sở hữu dữ liệu khách hàng để bán thêm dịch vụ" — app chỉ là một đòn bẩy trong đó.

🧠 Tư duy phản biện: Nếu ngày mai Serene có một cái app hoàn hảo về mặt kỹ thuật nhưng khách vẫn quen tay mở Booking.com để đặt như cũ, dự án này có được coi là thành công không? Nếu câu trả lời là "không", vậy tại sao KPI của dự án vẫn đang được viết theo kiểu "app ra mắt đúng hạn" thay vì "tỷ lệ đặt phòng trực tiếp tăng X%"?

🔗 Case Study & Bài viết liên quan

Đây là chương thứ hai trong hành trình Reso — case study xuyên suốt 12 bài của series "BA 4.0: Từ Phân tích đến Giải pháp". Ở bài mở đầu, Minh mới chỉ tiếp nhận yêu cầu và đặt câu hỏi về vai trò của mình; bài này là lúc bài toán thật bắt đầu lộ diện qua lăng kính First Principles.

Minh đã có được phát biểu vấn đề đúng — "dịch chuyển hành vi đặt phòng từ OTA sang kênh trực tiếp". Nhưng một phát biểu đúng trên giấy không tự động chuyển hoá thành hành động đúng trong các buổi làm việc với chị Lan Anh và đội của Huy. Để biến 4 sự thật cơ bản này thành những câu hỏi đúng, đúng lúc, đúng người — Minh cần một kỹ năng khác: nghệ thuật đặt câu hỏi. Đó là chủ đề của bài tiếp theo, khi Minh lần đầu ngồi xuống hỏi thẳng chị Lan Anh về những con số OTA mà trước giờ chưa ai trong phòng họp nói ra thành lời.

Bài trước: BA là ai trong kỷ nguyên AI? — Định nghĩa lại vai trò từ "người ghi chép" thành "người kiến tạo giải pháp" · Bài tiếp theo: Kỹ năng "Đặt câu hỏi" (The Art of Questioning)