Mở đầu — vì sao bài này quan trọng
Khi mới làm PM, bạn dồn hết năng lượng vào hai hướng: quản lý lên trên (sếp, exec) và làm việc với team thực thi (engineer, designer). Nhưng có một chiều thứ ba mà ít ai dạy, lại quyết định rất lớn đến việc bạn có hoàn thành roadmap hay không: chiều ngang — làm việc với những PM ngang hàng.
Peer PM là những người cùng cấp với bạn, không phải sếp của bạn, cũng không phải cấp dưới. Họ quản lý một product hoặc một mảng khác. Vấn đề nằm ở chỗ: bạn và họ thường dùng chung một "ngân hàng resource". Cùng một squad engineering, cùng một designer, cùng một data analyst, cùng một quỹ ngân sách quý. Khi bạn cần 3 engineer cho feature của mình, mà PM bên cạnh cũng cần đúng 3 engineer đó cho feature của họ — đột nhiên hai người trở thành đối thủ cạnh tranh tài nguyên, dù cùng phục vụ một công ty.
Chưa kể roadmap của các bạn thường chồng lấn. Cùng một customer segment, cùng một bề mặt sản phẩm (ví dụ: trang checkout, màn home), hai PM có thể đề xuất hai thay đổi mâu thuẫn nhau. Ai được ưu tiên? Ai phải lùi? Và khi một trong hai người được promote, người còn lại nhìn vào và tự hỏi "tại sao không phải mình?".
Đây chính là nghệ thuật managing sideways — quản lý chiều ngang. Bạn không có quyền lực chính thức để ra lệnh cho peer, nhưng thành công của bạn lại phụ thuộc rất nhiều vào sự hợp tác của họ. Bài này sẽ dạy bạn cách biến peer PM từ đối thủ tiềm tàng thành đồng minh thực sự — một kỹ năng phân biệt PM trung bình với PM xuất sắc.
Khái niệm cốt lõi
Peer PM là quan hệ "đối tác bắt buộc", không phải tùy chọn
Khác với một đồng nghiệp ở phòng ban xa, peer PM là người bạn buộc phải làm việc cùng vì cùng chia sẻ tài nguyên và bề mặt sản phẩm. Bạn không thể né tránh họ. Vì vậy chất lượng quan hệ này không phải chuyện "có thì tốt" mà là điều kiện sống còn cho việc giao hàng đúng hạn.
Có một sự thật ngầm: trong hầu hết tổ chức product, không có ai đứng ra "phân xử" chi tiết giữa hai PM. Sếp chung của các bạn (Head of Product, Group PM) bận và kỳ vọng các bạn tự giải quyết phần lớn xung đột. Nếu việc gì cũng đẩy lên sếp, bạn bị gắn nhãn "không tự xử lý được", còn peer thì cũng vậy. Người trưởng thành về product là người biết tự dàn xếp chiều ngang.
Ba nguồn căng thẳng kinh điển giữa peer PM
Một là tranh chấp resource. Engineering capacity là hữu hạn. Khi cả hai cùng "kéo" một squad, ai cũng tin feature của mình quan trọng hơn. Nếu không có cơ chế minh bạch, người to tiếng hơn hoặc thân với engineering manager hơn sẽ thắng — và đó là cách tổ chức tự làm hỏng văn hóa của mình.
Hai là chồng lấn roadmap (roadmap overlap). Hai PM đụng cùng một bề mặt. Ví dụ PM Growth muốn thêm banner khuyến mãi lên màn home, còn PM Core muốn làm gọn màn home để tăng tốc độ load. Hai mục tiêu chính đáng nhưng đối nghịch trên cùng một pixel.
Ba là cạnh tranh ngầm về thăng tiến (promotion). Đây là phần ít người nói thẳng nhưng ai cũng cảm nhận. Khi chỉ có một suất lên Senior PM trong năm, peer dễ rơi vào tâm lý "tổng bằng không" — coi thành công của người kia là mất mát của mình. Tâm lý này âm thầm phá hoại hợp tác: giấu thông tin, không chia sẻ insight, không nhường resource ngay cả khi hợp lý.
Nguyên tắc nền tảng: chuyển từ "win-lose" sang "win-win cho công ty"
Chìa khóa của managing sideways là tái định khung (reframe): mục tiêu chung không phải "feature của tôi thắng feature của bạn", mà là "công ty đạt được nhiều giá trị nhất với resource có hạn". Khi cả hai cùng nhìn về một North Star metric chung của tổ chức, cuộc tranh luận chuyển từ "ai quan trọng hơn" sang "đâu là phương án tốt nhất cho công ty". Đây là sự chuyển dịch tâm lý quan trọng nhất trong cả bài.
Bốn trụ cột của hợp tác peer hiệu quả
- Minh bạch roadmap — cả hai cùng nhìn thấy kế hoạch của nhau sớm, không giấu bài.
- Tiêu chí ưu tiên chung — thống nhất một khung đánh giá (impact, effort, chiến lược) để khi tranh chấp resource, dữ liệu phân xử thay vì cảm xúc.
- Có đi có lại (reciprocity) — khi bạn nhường resource lúc này, bạn xây "tín dụng" để được nhường lại sau.
- Tôn vinh công khai — khen peer trước mặt người khác, không tranh công. Đây là cách rẻ nhất nhưng mạnh nhất để xây niềm tin chiều ngang.
Tình huống thực tế
Tình huống 1 — Cuộc chiến giành squad ở một fintech Việt Nam
Tại một ví điện tử lớn ở TP.HCM (gọi là VíPay), có hai PM ngang hàng: Linh phụ trách mảng Payments, Tuấn phụ trách mảng Lending. Cả hai dùng chung một squad "Core Platform" gồm 4 engineer. Quý đó, Linh cần squad để build tính năng thanh toán hóa đơn điện nước (ước tính tăng 8% giao dịch hằng tháng), còn Tuấn cần đúng squad đó để ra mắt sản phẩm vay nhanh (tiềm năng doanh thu mới 2 tỷ/quý).
Ban đầu cả hai đều đi gặp riêng Engineering Manager để "chốt" squad cho mình, dẫn đến EM bị kẹt giữa hai làn đạn và bắt đầu né tránh cả hai. Tiến độ đứng im hai tuần.
Diễn giải: Vấn đề không phải feature nào quan trọng hơn, mà là không có cơ chế phân xử minh bạch. Linh chủ động đề xuất một buổi 30 phút với Tuấn, mang theo một bảng tính impact/effort đơn giản. Họ thống nhất chấm điểm cả hai feature theo cùng tiêu chí: doanh thu, số user ảnh hưởng, độ phù hợp chiến lược quý, effort engineering. Kết quả: feature vay nhanh điểm cao hơn về doanh thu nhưng effort gấp đôi và rủi ro pháp lý cao. Họ quyết định: tháng đầu squad làm hóa đơn của Linh (rủi ro thấp, ra nhanh, có "quick win"), tháng sau dồn cho lending của Tuấn. Linh cũng cam kết sẽ "trả nợ" bằng cách nhường người designer chung cho Tuấn trong sprint kế.
Bài học: Khi resource khan hiếm, người PM trưởng thành chủ động tạo cơ chế phân xử dựa trên dữ liệu thay vì đi cửa sau. Tuần tự hóa (sequencing) thường tốt hơn chia đôi resource — chia đôi khiến cả hai feature đều ra chậm và nửa vời.
Tình huống 2 — Roadmap chồng lấn trên màn home của một sàn TMĐT
Tại một sàn thương mại điện tử khu vực Đông Nam Á, Mai là PM Growth, Hùng là PM của team Core App. Mai muốn nhồi thêm các banner flash sale và widget gợi ý lên màn home để đẩy conversion. Hùng thì có OKR giảm thời gian load màn home từ 3.2s xuống 2s, và mỗi widget Mai thêm vào lại làm chậm thêm 200ms. Hai người va nhau gay gắt trong một buổi review, ai cũng cho rằng người kia phá hoại metric của mình.
Diễn giải: Đây là roadmap overlap kinh điển — cùng một bề mặt, hai mục tiêu đối nghịch. Thay vì để leo thang, Group PM yêu cầu hai người ngồi lại tìm "ràng buộc chung". Họ phát hiện cả hai đều phục vụ một North Star: GMV (tổng giá trị giao dịch). Banner làm tăng conversion nhưng load chậm lại làm tăng bounce rate — cả hai đều ảnh hưởng GMV. Họ thiết kế một thỏa thuận: Mai được thêm banner nhưng có "performance budget" cứng (tổng tải trọng màn home không vượt một ngưỡng ms nhất định), và mọi widget mới phải lazy-load. Họ cùng chạy một A/B test để dữ liệu quyết định thay vì ý kiến.
Bài học: Khi hai peer đụng nhau trên cùng bề mặt, đừng tranh luận "feature của ai". Hãy kéo lên một metric cấp cao chung mà cả hai cùng phục vụ, rồi thiết kế ràng buộc (constraint/budget) để cả hai cùng sống được. Dữ liệu (A/B test) là trọng tài tốt hơn cái tôi.
Tình huống 3 — Cạnh tranh ngầm về promotion
Tại một công ty SaaS ở Hà Nội, Đức và Phương là hai PM cùng vào một lượt, cùng nhắm suất Senior PM duy nhất sẽ mở vào cuối năm. Đức bắt đầu giấu các insight về khách hàng, không chia sẻ kết quả nghiên cứu cho Phương, và trong các buổi họp luôn cố làm nổi bật mình. Phương cảm nhận được và cũng dựng rào. Hệ quả: cả hai cùng làm chậm các dự án liên đới, và Head of Product nhận ra văn hóa team đang xấu đi.
Cuối năm, người được promote không phải Đức — dù feature của anh có số tốt hơn — mà là Phương, người vẫn giữ thái độ hợp tác và được các team khác đánh giá là "dễ làm việc cùng". Head of Product giải thích: ở cấp Senior, tiêu chí quan trọng nhất là khả năng nâng cả tổ chức lên, không phải tối ưu cục bộ cho product của riêng mình.
Diễn giải: Tâm lý "tổng bằng không" về promotion là cái bẫy phổ biến nhất ở chiều ngang. Thực tế, promotion ở cấp cao đánh giá khả năng influence và hợp tác chiều ngang — chính cái mà sự cạnh tranh ngầm phá hỏng.
Bài học: Cách tốt nhất để được thăng tiến không phải là hạ peer xuống, mà là trở thành người làm cho cả hệ thống tốt hơn. Reputation chiều ngang ("PM này dễ cộng tác, hào phóng, không tranh công") là tài sản sự nghiệp bền vững nhất.
Hướng dẫn từng bước
Khi bạn cần thiết lập hoặc cứu vãn quan hệ với một peer PM, hãy đi theo trình tự sau.
Bước 1 — Lập bản đồ điểm giao nhau. Trước khi vào quý, ngồi xuống liệt kê: chúng ta dùng chung resource nào (engineer, designer, data, ngân sách)? Roadmap có đụng bề mặt nào không? Có metric nào ảnh hưởng lẫn nhau? Biết trước điểm va chạm giúp bạn chủ động thay vì bị động.
Bước 2 — Chủ động đặt nhịp đồng bộ. Đề xuất một buổi peer sync ngắn định kỳ (15–30 phút mỗi hai tuần) chỉ để chia sẻ roadmap và cảnh báo sớm xung đột. Người chủ động mời thường là người kiểm soát được cuộc chơi.
Bước 3 — Thống nhất tiêu chí ưu tiên chung. Trước khi tranh chấp xảy ra, hãy cùng đồng ý một khung chấm điểm (ví dụ: impact lên North Star, effort, rủi ro, độ phù hợp chiến lược). Khi va chạm thực sự đến, bạn dùng khung này phân xử thay vì cãi nhau bằng cảm tính.
Bước 4 — Khi xung đột nổ ra, kéo lên mục tiêu chung. Đừng hỏi "feature của ai thắng". Hãy hỏi "phương án nào tối đa hóa giá trị cho công ty với resource này". Reframe từ win-lose sang win cho tổ chức.
Bước 5 — Ưu tiên sequencing và trao đổi có đi có lại. Thay vì chia đôi resource (khiến cả hai ra chậm), hãy xếp thứ tự: ai làm trước, ai làm sau, kèm cam kết "trả nợ" rõ ràng. Ghi lại thỏa thuận để không quên.
Bước 6 — Khi bế tắc thật sự, leo thang đúng cách. Nếu hai người không tự chốt được, hãy cùng nhau (không phải đi riêng) mang vấn đề lên sếp chung, trình bày cả hai phương án một cách công bằng, và xin một quyết định. Đi cùng nhau cho thấy bạn đã cố tự xử và không chơi xấu sau lưng.
Bước 7 — Đầu tư vào quan hệ ngoài lúc khủng hoảng. Cà phê, ăn trưa, chia sẻ insight, khen peer trước mặt sếp. Niềm tin được xây lúc bình yên sẽ là vốn để rút lúc xung đột.
Lỗi thường gặp & mẹo
Lỗi 1 — Đi cửa sau với engineering/sếp. Lén thuyết phục EM ưu tiên feature mình trước khi nói với peer là cách nhanh nhất phá vỡ niềm tin. Một khi bị lộ, bạn mất uy tín chiều ngang vĩnh viễn. Mẹo: luôn nói chuyện với peer trước, đi gặp sếp sau và đi cùng nhau.
Lỗi 2 — Coi peer là đối thủ thay vì đồng minh. Tâm lý cạnh tranh khiến bạn giấu thông tin, tranh công. Về dài hạn nó hủy hoại chính sự nghiệp bạn vì PM cấp cao được đánh giá bằng khả năng hợp tác. Mẹo: mỗi quý, tìm ít nhất một việc bạn có thể giúp peer mà không đòi lại ngay.
Lỗi 3 — Tranh luận bằng ý kiến thay vì dữ liệu. "Feature của tôi quan trọng hơn" là câu không có hồi kết. Mẹo: luôn quy về một metric chung và để A/B test hoặc khung chấm điểm làm trọng tài.
Lỗi 4 — Im lặng nuốt ấm ức. Nhường mãi mà không nói rõ kỳ vọng có đi có lại sẽ khiến bạn cạn kiệt và peer thì vô tâm hưởng lợi. Mẹo: khi nhường resource, nói rõ "lần này mình nhường, sprint tới mình mong bạn hỗ trợ lại phần X".
Lỗi 5 — Leo thang quá sớm. Đẩy mọi va chạm nhỏ lên sếp khiến cả bạn và peer bị xem là không tự xử lý được. Mẹo: chỉ leo thang sau khi đã thật sự cố gắng dàn xếp, và luôn mang theo phương án đề xuất, không chỉ mang vấn đề.
Lỗi 6 — Quên ghi nhận công khai. Khi dự án chung thành công, nếu bạn nhận hết công, peer sẽ nhớ rất lâu. Mẹo: chủ động nêu tên đóng góp của peer trong báo cáo và họp chung — chi phí bằng không, lợi ích khổng lồ.
Bài tập thực hành
Bài tập 1 — Bản đồ giao nhau. Liệt kê tất cả peer PM mà bạn chia sẻ resource hoặc bề mặt sản phẩm. Với mỗi người, ghi rõ: resource dùng chung, điểm roadmap có thể va chạm trong quý tới, và mức độ niềm tin hiện tại (cao/trung bình/thấp). Chọn một người có niềm tin thấp nhất để chủ động cải thiện.
Bài tập 2 — Thiết kế khung ưu tiên chung. Viết ra 4 tiêu chí bạn và một peer có thể dùng để chấm điểm feature khi tranh chấp resource. Gửi cho peer đó và đề xuất một buổi 20 phút để thống nhất. Mục tiêu là có một "trọng tài bằng dữ liệu" trước khi xung đột thật xảy ra.
Bài tập 3 — Tập reframe. Lấy một xung đột resource bạn đang gặp. Viết hai phiên bản câu mở đầu: một phiên bản "win-lose" (feature của tôi cần được ưu tiên) và một phiên bản "win cho công ty" (làm sao để công ty đạt giá trị cao nhất với squad này). Cảm nhận sự khác biệt và dùng phiên bản thứ hai trong cuộc nói chuyện tới.
Bài tập 4 — Gây dựng tín dụng. Trong hai tuần tới, tìm một việc cụ thể bạn có thể giúp một peer PM mà không đòi lại gì ngay (chia sẻ insight khách hàng, nhường một slot designer, giới thiệu một liên hệ). Quan sát quan hệ thay đổi thế nào.
Tóm tắt
Managing sideways là kỹ năng làm việc với những PM ngang hàng — những người bạn không có quyền ra lệnh nhưng lại phụ thuộc rất nhiều vào sự hợp tác của họ. Ba nguồn căng thẳng kinh điển là tranh chấp resource dùng chung, chồng lấn roadmap trên cùng bề mặt, và cạnh tranh ngầm về promotion.
Chìa khóa là reframe từ tư duy "feature của tôi thắng feature của bạn" sang "công ty đạt giá trị cao nhất với resource có hạn". Bốn trụ cột thực hành: minh bạch roadmap, tiêu chí ưu tiên chung, có đi có lại, và tôn vinh công khai. Khi xung đột nổ ra, hãy kéo lên một metric chung, ưu tiên sequencing thay vì chia đôi, và chỉ leo thang khi đã thật sự cố dàn xếp — mà phải đi cùng peer chứ không đi cửa sau.
Sự thật cuối cùng đáng nhớ: reputation chiều ngang của bạn — "PM này hào phóng, dễ cộng tác, không tranh công" — chính là tài sản sự nghiệp bền vững nhất. Người được thăng tiến không phải người hạ peer xuống, mà người nâng cả tổ chức lên.