Product Management
Đăng nhập
ESC

Nhập từ khóa để tìm kiếm

↑↓ Di chuyển
Enter Mở
ESC Đóng

Product Ops là gì, và không phải là trợ lý của PM

Đã đọc 0/6 mục · còn khoảng 4 phút
Cách chúng tôi ghi nhận

Một mục được tính là đã đọc khi nó nằm giữa màn hình đủ lâu so với độ dài của nó (bảng và sơ đồ tính một nửa), bạn vẫn đang cuộn hoặc bấm phím, và bạn đã thấy tới cuối mục. Lướt nhanh hoặc để tab mở không được tính. Chúng tôi chỉ lưu thời gian đọc từng mục — không lưu gì khác.

Khi khối sản phẩm lớn nhanh hơn cách nó làm việc

Khi công ty chỉ có một đội sản phẩm, cách làm việc tự hình thành: mọi người ngồi gần nhau, có gì hỏi nhau là xong. Khi có năm, sáu đội, những thứ từng "tự chạy" bắt đầu hỏng cùng một lúc. Mỗi đội viết tài liệu một kiểu. Hai PM báo hai con số khác nhau cho cùng một chỉ số trong buổi họp với CEO. Kế hoạch quý trễ vài tuần. Góp ý của sales rơi vào khoảng trống giữa các đội.

Không ai trong số đó làm sai việc của mình. Vấn đề là không ai sở hữu cách cả khối sản phẩm làm việc với nhau. Product Ops (product operations) là tên của việc sở hữu đó. Khoá học này dành cho Head of Product, PO và trưởng nhóm PM — những người phải thiết kế cách đội làm việc, dù công ty đã có người product ops riêng hay chưa.

Ví dụ xuyên suốt khoá học: QuầyNhanh (giả định)

Để các bài sau cụ thể, ta theo một công ty giả định từ đầu đến cuối.

QuầyNhanh làm phần mềm bán hàng và quản lý cho quán cà phê, quán ăn nhỏ. Có 9.500 quán trả phí, phí trung bình 300.000 đồng mỗi tháng (3,6 triệu đồng mỗi năm). Công ty có 140 người, trong đó 62 người ở khối sản phẩm và kỹ thuật, chia thành sáu squad, mỗi squad một PM.

NgườiVai trò
chị MaiHead of Product, người dẫn việc thiết kế lại cách làm việc
anh LâmCEO
anh QuốcCTO
Hưng, Trang, Khoa, Nhi, Bảo, PhúcPM các squad Bán hàng tại quầy, Thanh toán, Kho và nguyên liệu, Ứng dụng chủ quán, Đặt món online, Nền tảng và tích hợp
TúData analyst duy nhất, phục vụ cả sáu squad
anh Đạt, chị HoaTrưởng sales, trưởng chăm sóc khách hàng (CS)
Cuối quý 2, chị Mai làm một khảo sát ngắn với sáu PM và ghi lại số liệu đầu kỳ. Các bài sau sẽ quay lại những con số này.

Chỉ số đầu kỳGiá trị
Thời gian PM dành cho việc vận hành (báo cáo, tìm số, điều phối)12 trên 45 giờ mỗi tuần, khoảng 27%
Giờ họp định kỳ của mỗi PM10 giờ mỗi tuần
Kế hoạch quý chốt trễ3 tuần, hai quý liên tiếp
Buổi họp định kỳ có đầu ra được ghi lại40%
Thời gian từ phản hồi của khách tới khi được gán cho squadtrung vị 23 ngày
Thời gian để PM mới tự làm việc được10 tuần
Mức hài lòng của PM với cách làm việc2,6 trên 5

Bài học sáu tháng của QuầyNhanh

Đầu năm, khi các PM than quá tải, anh Lâm tuyển Ngân làm "trợ lý sản phẩm". Ngân đặt phòng họp, ghi biên bản cho sáu PM, ghép báo cáo tuần cho CEO, trả lời câu hỏi của sales thay PM. Tháng đầu, PM rất vui.

Sáu tháng sau, thời gian vận hành của PM chỉ giảm từ 13 xuống 12 giờ mỗi tuần. Kế hoạch quý vẫn trễ ba tuần. Hai đội vẫn báo hai con số "quán hoạt động" khác nhau. Còn Ngân thì kiệt sức và xin nghỉ.

Không yêu cầu nào Ngân nhận là vô lý. Vấn đề là cô làm việc cho từng người, không làm việc cho hệ thống. Ghép báo cáo hộ một PM giúp PM đó tuần này; nó không làm cho tuần sau bớt việc. Mỗi việc vặt được làm hộ còn che đi vấn đề thật: mẫu báo cáo quá dài, số liệu nằm ở năm nơi, không ai định nghĩa chỉ số.

Product Ops là gì — và không là gì

Product Ops là thiết kế và vận hành cách tổ chức sản phẩm làm việc, để PM dành thời gian cho khách hàng và quyết định, không phải cho việc tìm số liệu và xếp lịch họp. Định nghĩa này thống nhất với trang kỹ năng Product Ops & Operating Cadence.

Product Ops làProduct Ops không phải là
Thiết kế nhịp vận hành, quy trình lập kế hoạch và review cho cả khốiThư ký đặt phòng họp và ghi biên bản cho PM
Xây và giữ nguồn sự thật duy nhất cho roadmap, OKR, chỉ sốNgười làm báo cáo thay PM mỗi tuần
Đưa insight của khách hàng tới đúng PM một cách có hệ thốngNgười lọc và trả lời mọi yêu cầu từ sales
Chuẩn hoá công cụ, template, định nghĩa chỉ sốNgười quản trị Jira
Đo xem cách làm việc có đang tốt lênMột lớp phê duyệt mới giữa PM và lãnh đạo
Dòng cuối quan trọng không kém dòng đầu. Product Ops thiết kế đường đi của quyết định; nó không đứng giữa đường để duyệt quyết định. Nếu PM phải xin product ops đồng ý trước khi gặp CEO, bạn vừa thêm một tầng chậm trễ, không phải bớt đi.

Ba câu hỏi để phân loại một việc

Khi một yêu cầu đến, người làm product ops (hoặc Head of Product đang kiêm việc này) hỏi ba câu:

  • Làm xong việc này, hệ thống có tốt lên không, hay chỉ xong một lần cho một người?
  • Nó có giúp ít nhất hai đội không?
  • Lần sau gặp lại việc này, còn ai phải làm bằng tay không?
Yêu cầuCách làm kiểu trợ lýCách làm kiểu Product Ops
"Ghép báo cáo tuần cho anh Lâm"Mỗi thứ Sáu ngồi copy số từ sáu fileThiết kế mẫu ba dòng mỗi PM tự điền trong 10 phút, tổng hợp tự động
"Sales hỏi tính năng X bao giờ có"Hỏi PM rồi trả lời salesLàm một trang roadmap mà sales tự xem được
"Đặt lịch họp với ba squad"Đặt lịchHỏi vì sao cần họp; nếu là phụ thuộc, đưa vào product sync tuần

Làm ngay

Liệt kê mười việc vận hành bạn hoặc đội bạn đã làm trong hai tuần qua: báo cáo, tìm số, điều phối, trả lời câu hỏi. Với mỗi việc, áp ba câu hỏi ở trên và đánh dấu "làm hộ" hay "sửa hệ thống". Đếm số giờ cho mỗi nhóm. Nếu phần "làm hộ" chiếm hơn một nửa, chọn một việc lặp lại nhiều nhất và viết một câu: thay đổi nào trong hệ thống sẽ làm việc đó biến mất?

Học xong bài này rồi? Tạo tài khoản miễn phí để lưu lại — lần sau vào là biết ngay đang dở ở đâu, và học hết khóa thì có chứng chỉ. Lưu tiến độ của tôi