# The Pyramid Principle: cuốn sách giúp FDE viết sao cho lãnh đạo khách hàng đọc câu đầu là hiểu

> Ở công ty tư vấn, một bản nháp bị trả về kèm lời dặn "make it Minto". FDE, người phải viết cho lãnh đạo khách hàng, rất nên học thói quen đó.

Bản gốc: https://fdetimes.net/vi/sach-khoa-hoc/sach-the-pyramid-principle-barbara-minto/

Câu này phổ biến đến mức phương pháp của Barbara Minto đã thành ngôn ngữ chung của giới làm nghề.

FDE không phải consultant, nhưng thử hình dung những văn bản một FDE có thể phải viết: email cập nhật cho VP bên khách, báo cáo sau pilot, đề xuất mở rộng deployment. Cách an toàn là cứ giả định người nhận chỉ đọc kỹ vài dòng đầu rồi mới quyết định có đọc tiếp hay không.

Vì vậy, code chạy đúng nhưng email viết rối thì dự án vẫn có thể bị dừng. Đó là lý do The Pyramid Principle đáng nằm trên bàn của bất kỳ kỹ sư nào làm việc trực tiếp với khách hàng.

## Một cuốn sách về tư duy, không chỉ về hành văn

Barbara Minto là tác giả kiêm nhà tư vấn người Mỹ chuyên về giao tiếp điều hành, có bằng MBA của Harvard Business School. Khóa học của bà đúc kết từ hơn 30 năm giảng dạy ở nhiều nước.

Sách ra lần đầu năm 1985. Bản 1996 do chính tác giả phát hành, tên The Minto Pyramid Principle: Logic in Writing, Thinking and Problem Solving, gồm 4 phần, 12 chương, 3 phụ lục, bán trực tiếp qua barbaraminto.com. Bản dễ tìm hơn là ấn bản thứ 3 của Pearson Education, The Pyramid Principle: Logic in Writing and Thinking.

Người mới nên bắt đầu từ bản Pearson, còn bản của tác giả hợp với lúc bạn muốn đi sâu vào phần giải quyết vấn đề.

Sách giúp bạn sắp xếp suy nghĩ về bất kỳ chủ đề nào để trình bày rõ cho người khác, và dạy dùng chính cấu trúc kim tự tháp để phát triển ý tưởng. Thứ tự ấy đáng chú ý: ý phải được xếp xong trong đầu trước khi chữ đầu tiên được gõ ra.

## Vì sao câu trả lời phải nằm ở đầu?

Nguyên tắc đầu tiên rất đơn giản: nêu ý tổng quát trước, sau đó mới đi xuống các ý hỗ trợ. Đây là cách giao tiếp từ trên xuống, trong đó ý chính là bản tóm tắt cấp cao của những ý bên dưới.

Thử hình dung bạn đang ở tuần thứ hai của một pilot dùng agent xử lý hóa đơn cho một công ty logistics.

Bản nháp theo thói quen của developer thường kể theo thứ tự thời gian: đã tích hợp API ERP, gặp lỗi timeout, đã sửa xong, chạy thử 500 hóa đơn, phát hiện nhóm hóa đơn nước ngoài sai định dạng. Mãi đến câu cuối mới có đề xuất lùi go-live một tuần.

Nếu VP bên khách chỉ kịp đọc hai dòng đầu, họ chỉ biết rằng team đang bận. Viết theo Minto, dòng đầu tiên sẽ là: "Đề xuất lùi go-live một tuần để xử lý hóa đơn nước ngoài; phần còn lại đã sẵn sàng." Các chi tiết kỹ thuật vẫn có trong email, nhưng chỉ làm bằng chứng cho đề xuất đó.

**Điểm mấu chốt:** Hãy viết như thể lãnh đạo khách hàng chỉ đọc đúng câu đầu tiên.

## Những ý nào được đứng chung một nhóm?

Quy tắc thứ hai là các ý được gom chung phải so sánh được với nhau về logic, và mỗi tầng phải tóm tắt được các ý ngay bên dưới nó.

Trong ví dụ trên, ba ý hỗ trợ tốt sẽ là: tích hợp ERP đã xong, hóa đơn nội địa đạt độ chính xác yêu cầu, hóa đơn nước ngoài còn lỗi. Cả ba đều trả lời cùng một câu hỏi: hệ thống đã sẵn sàng đến đâu.

Ngược lại, một nhóm gồm "đang dùng model X", "khách chưa cấp quyền truy cập" và "nên thêm dashboard" là ba loại thông tin khác nhau, và người đọc sẽ không biết rút ra điều gì. Phép thử nhanh: nếu không viết được một câu tóm tắt cả nhóm thì nhóm đó đang sai.

## Người đọc đang hỏi gì?

Đây là nền tảng của khung Situation–Complication–Question.

Áp vào pilot ở trên, Situation là agent đã chạy được hai tuần. Complication là một nhóm hóa đơn bị lỗi. Câu hỏi tự nhiên của VP là "có kịp go-live không?", và câu trả lời cho câu hỏi đó chính là đỉnh kim tự tháp.

Quy tắc này nối trực tiếp với customer discovery. Nếu bạn không biết lãnh đạo bên khách đang lo điều gì, kim tự tháp có chặt chẽ đến đâu cũng chỉ trả lời nhầm câu hỏi.

## Học bằng cách sửa chính email của mình

Thứ tự hợp lý là đọc bài tóm tắt "Lessons from Barbara Minto" của Antoine Buteau trước để nắm các quy tắc, rồi mới đọc sách. Trong lúc đọc, mỗi ngày hãy viết lại một email thật theo phương pháp này thay vì chỉ gạch chân.

Với developer Việt Nam muốn chuyển sang FDE, đây là kỹ năng có thể đem ra cho người khác thấy. Lời khuyên là chuẩn bị sẵn một design doc hoặc báo cáo dự án đã viết theo cấu trúc kim tự tháp, kết luận ở dòng đầu, để mang theo khi phỏng vấn cho các vị trí làm việc trực tiếp với khách hàng.

Bài tập đầu tiên dành cho bạn: lấy lại nhóm ý lộn xộn ở phần trước, gồm "đang dùng model X", "khách chưa cấp quyền truy cập" và "nên thêm dashboard". Hãy tự viết lại trước khi đọc tiếp.

Ba câu hỏi gợi ý cho bạn tự kiểm tra. VP đang muốn biết điều gì về pilot lúc này? Trong ba ý, ý nào thật sự trả lời câu hỏi đó và xứng đáng lên đỉnh? Ý nào chỉ là bằng chứng, và ý nào thuộc về một email hoàn toàn khác?

Nhà tuyển dụng có thể kiểm tra kỹ năng code của bạn bằng một bài test. Còn khả năng làm lãnh đạo khách hàng gật đầu ngay sau câu đầu tiên thì bạn phải tự cho họ thấy.

**Thử ngay tuần này:**

- Lấy email cập nhật dự án gần nhất bạn đã gửi, chuyển câu kết luận lên dòng đầu rồi xếp lại tối đa ba ý hỗ trợ cùng loại
- Trước khi viết báo cáo tiếp theo, ghi ra một câu: lãnh đạo bên khách đang muốn hỏi điều gì. Sau đó để câu trả lời cho câu hỏi đó làm đỉnh kim tự tháp
- Đọc bài 'Lessons from Barbara Minto' của Antoine Buteau để nắm các quy tắc chính trước khi mua sách

## Nguồn

- [The Minto Pyramid Principle (barbaraminto.com – About)](https://barbaraminto.com/about)

- [Textbook – The Minto Pyramid Principle (barbaraminto.com)](https://barbaraminto.com/textbook)

- [Barbara Minto – Wikipedia](https://en.wikipedia.org/wiki/Barbara_Minto)

- [Lessons from Barbara Minto (Antoine Buteau)](https://www.antoinebuteau.com/lessons-from-barbara-minto/)

- [The Pyramid Principle: Logic In Writing And Thinking, 3/E (Oxford Bookstore)](https://oxfordbookstore.com/products/the-pyramid-principle-logic-in-writing-and-thinking-3-e)
