Nếu bạn làm việc trong quản lý sản phẩm đủ lâu, bạn sẽ nhận ra điều gì đó không thoải mái. Rào cản lớn nhất để tạo ra những sản phẩm tuyệt vời không phải là năng lực kỹ thuật. Đó là sự không đồng bộ giữa các bên liên quan. Các PM dành vô số giờ trong các cuộc họp tranh luận ý kiến, xem xét lại quyết định, làm rõ ngữ cảnh và sửa chữa các vòng giao tiếp bị đứt gãy.
\ Sự không đồng bộ là khoản thuế vô hình đối với mọi tổ chức công nghệ; nó làm chậm tiến độ, làm suy yếu niềm tin vào lộ trình và làm kiệt sức các đội ngũ. Nhưng tin tốt là sự đồng bộ giữa các bên liên quan là một kỹ năng mà các đội PM có thể cải thiện. Bài viết này phác thảo 10 chiến thuật thực tế được sử dụng bởi các tổ chức sản phẩm hoạt động hiệu quả cao để giảm sự không đồng bộ và đẩy nhanh quá trình thực hiện.
Sự không đồng bộ bắt đầu khi mỗi bộ phận hoạt động dựa trên phiên bản thực tế riêng của họ. Hãy tạo một nơi tập trung, luôn cập nhật cho:
\ Các công cụ cần xem xét bao gồm Notion, Confluence, Productboard và Aha.
\ Tại sao nó hiệu quả: Khi mọi người tham khảo cùng một nguồn, các tranh luận chuyển từ "Tôi nghĩ X" sang "SSOT nói Y."
Hầu hết các xung đột đến từ quyền sở hữu không rõ ràng. Ai quyết định? Ai đóng góp? Ai chỉ được thông báo?
\ Sử dụng DACI cho mọi luồng công việc chính:
\ Thêm DACI trực tiếp vào PRDs và lộ trình.
\ Kết quả: Các bên liên quan ngừng tranh luận về người quyết định và bắt đầu tập trung vào những gì quan trọng.
Các đội trở nên không đồng bộ vì họ đang giải quyết các vấn đề khác nhau mà không nhận ra điều đó.
\ Bắt đầu mọi dự án với:
\ Sử dụng các khung như JTBD, "5 Whys," hoặc lập bản đồ hành trình người dùng. Khi mọi người đồng ý về vấn đề, việc đồng bộ về giải pháp trở nên dễ dàng hơn nhiều.
Quá nhiều PM chỉ liên quan đến Kỹ thuật và Thiết kế sau khi quyết định hướng đi. Thay vào đó, hãy làm việc cùng nhau trong quá trình khám phá. Xác nhận tính khả thi ngay từ đầu và xác định mọi ràng buộc kỹ thuật sớm. Đồng bộ với chiến lược thử nghiệm của bạn. Tại sao điều này hiệu quả: Nó tránh khoảnh khắc đáng thất vọng "Chúng ta không thể xây dựng cái này" sau nhiều tuần lập kế hoạch.
Đây không chỉ là một cuộc họp trạng thái; đó là một nghi thức đồng bộ.
\ Thảo luận:
\ Kết quả: Không có bất ngờ, không có bất đồng im lặng và không có thay đổi phút chót từ lãnh đạo.
Các bên liên quan có thể tranh luận vô tận cho đến khi dữ liệu giải quyết vấn đề.
\ Xác định:
\ Ví dụ: "Một tính năng chỉ được triển khai nếu nó tăng PDP-to-Cart lên + 0.4% mà không làm tăng độ trễ quá 200ms." Số liệu làm cho các cuộc thảo luận khách quan hơn thay vì cảm tính.
Mượn mô hình Amazon. Một tường thuật một trang buộc phải rõ ràng.
\ Bao gồm:
\ Các bên liên quan sẽ đọc một trang. Họ sẽ không đọc hai mươi trang.
Các bên liên quan khác nhau tiếp thu thông tin theo những cách khác nhau.
\ Sử dụng:
\ Quy tắc chung: Nếu một người nói, "Tôi không biết về điều này," hãy tăng tần suất giao tiếp thay vì độ dài tài liệu.
Không có gì đồng bộ một đội nhanh hơn việc nhìn thấy:
\ Các đội ngừng tranh luận ý kiến khi người dùng thực sự tham gia.
Sự đồng bộ cải thiện đáng kể khi các PM nhất quán:
\ Các PM nhất quán tạo ra các tổ chức đồng bộ.
\ Chỉ riêng những bước này có thể loại bỏ 80% ma sát đồng bộ. Hầu hết các thất bại sản phẩm không xảy ra vì các đội thiếu tài năng. Chúng xảy ra vì các đội thiếu tập trung. Các đội sản phẩm nhanh nhất không phải là những đội xây dựng nhiều tính năng nhất; họ là những đội đưa ra quyết định rõ ràng ngay từ đầu.


