5 điều mình học được sau khi đọc Empowered

Empowered của Marty Cagan và Chris Jones viết về cách xây dựng những product team có thể giải quyết vấn đề cho khách hàng và doanh nghiệp. Cuốn sách dành nhiều trang cho người lãnh đạo: họ tuyển ai, coaching thế nào, đưa team đi theo hướng nào và giao việc ra sao. Phần giới thiệu của Silicon Valley Product Group tóm tắt khá đầy đủ những chủ đề đó.
1. Xem team được giao vấn đề hay được giao sẵn giải pháp
Một team có thể được yêu cầu “tăng tỷ lệ khách hàng sử dụng sản phẩm” nhưng roadmap đã chốt ba tính năng phải làm trong quý. Khi đó, team vẫn phải làm tốt phần thiết kế và phát triển. Họ chỉ có ít cơ hội kiểm tra xem ba tính năng ấy có giải đúng lý do khách hàng bỏ đi hay không.
Empowered phân biệt khá rõ team nhận danh sách feature và team nhận một vấn đề cần giải. Người lãnh đạo chọn vấn đề đáng ưu tiên, nêu kết quả cần đạt; PM, designer và engineer tìm cách giải, thử với người dùng rồi điều chỉnh. Cagan viết rằng khả năng chọn cách giải là một cách kiểm tra team có thực sự được giao quyền quyết định hay không.
Trước khi chốt kế hoạch, có một câu nên hỏi: “Tính năng này đã là cam kết phải thực hiện, hay mới là một cách mà chúng mình nghĩ có thể giải vấn đề?” Cả hai câu trả lời đều có thể hợp lý. Chúng dẫn đến hai cách làm và hai kiểu trách nhiệm khác nhau.
2. Bối cảnh phải đủ rõ để team tự quyết
Giao cho team một chỉ số vẫn chưa đủ. Nếu chỉ nói “tăng retention”, mỗi người có thể hiểu một kiểu: giữ người dùng mới, giữ khách hàng trả tiền, hay kéo nhóm đã ngừng dùng quay lại. Các cách hiểu ấy dẫn tới những ưu tiên khác nhau.
Team cần biết công ty đang tập trung vào nhóm khách hàng nào, sản phẩm muốn giúp họ làm tốt việc gì, giới hạn về tiền bạc, kỹ thuật và pháp lý nằm ở đâu. Product vision và strategy trong sách có ích ở chỗ ấy: chúng giúp nhiều team đưa ra quyết định khác nhau mà vẫn đi về cùng một hướng. SVPG đặt việc tạo vision và strategy vào trách nhiệm của product leader.
Khi giao mục tiêu mới, người lãnh đạo cần giải thích vì sao nó được chọn và điều gì team được phép đánh đổi. Có bối cảnh ấy, việc phản biện một yêu cầu hay bỏ một ý tưởng khỏi backlog mới có cơ sở.
3. Coaching không thể gói trong câu “em chủ động lên”
Một PM quen nhận yêu cầu rồi viết PRD sẽ cần thời gian để học cách tìm vấn đề, đánh giá bằng chứng và bảo vệ một quyết định sản phẩm. Giao thêm quyền cho PM không tự động tạo ra những kỹ năng đó.
Empowered xem coaching là công việc đều đặn của manager. Trong buổi 1:1, thay vì chỉ hỏi task nào xong, manager có thể cùng PM xem một quyết định đang khó: PM đã biết gì về khách hàng, còn thiếu thông tin gì, ai trong công ty chịu ảnh hưởng, và vì sao PM nghiêng về phương án này. Cagan viết cụ thể về cách dùng buổi 1:1 để phát triển người.
Đây cũng là một cách để nhìn lại thời gian của người quản lý. Nếu lịch kín các buổi duyệt việc mà không còn chỗ để coaching, team sẽ tiếp tục cần họ duyệt những quyết định tương tự vào tháng sau.
4. Tuyển đúng người rồi vẫn phải giúp họ làm việc cùng nhau
Phụ đề của sách là Ordinary People, Extraordinary Products. Chữ “ordinary” rất dễ gây hiểu nhầm rằng năng lực của người trong team không quan trọng. Sách vẫn đặt trách nhiệm tuyển người, giúp họ đạt năng lực cần thiết và tiếp tục phát triển lên vai manager. Cagan cũng nhấn mạnh cả staffing lẫn coaching.
Một PM, designer và engineer giỏi riêng phần mình vẫn cần làm việc cùng nhau trên cùng một vấn đề. Designer cần hiểu khách hàng trước khi vẽ; engineer cần biết giới hạn kỹ thuật từ sớm; PM phải kết nối điều người dùng cần với việc doanh nghiệp có thể làm. Nếu mỗi người chỉ nhận brief ở đoạn việc của mình, thêm một nhân sự “siêu giỏi” cũng khó sửa cách team phối hợp.
Khi team làm việc chưa tốt, cần xem cả cách phân chia công việc và những kỹ năng đang thiếu trước khi kết luận rằng phải tuyển người giỏi hơn.
5. Team phải xây niềm tin bằng cách làm việc của mình
Được quyền chọn giải pháp không có nghĩa PM có thể bỏ qua sales, support, finance hay legal. Họ biết những cam kết và ràng buộc mà team sản phẩm có thể chưa thấy. Nếu một phương án mới ảnh hưởng đến lời hứa với khách hàng, PM cần đưa bằng chứng ra trao đổi sớm, cho mọi người xem prototype và nói rõ rủi ro còn lại. SVPG viết riêng về việc xây niềm tin với stakeholder.
Đây có lẽ là phần khó làm đều nhất. Viết “team tự quyết” vào một slide thì nhanh. Để người khác tin vào quyết định của team, PM phải hiểu công việc của họ, giữ lời với những điều đã cam kết và sẵn sàng giải thích khi kết quả không như dự tính.
All rights reserved