Product Ops & Operating Cadence

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

Khi một công ty có một đội sản phẩm, mọi người biết nhau, ngồi chung một phòng và cách làm việc tự hình thành. Khi có ba, năm, mười đội, mỗi đội viết PRD một kiểu, đặt OKR một kiểu, đo một bộ chỉ số khác nhau, và ban lãnh đạo mất hai ngày mỗi quý chỉ để ghép các báo cáo lại cho khớp. Product operations là việc 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.

Vì sao phân biệt quan trọng: nếu product ops bị dùng như trợ lý của PM, người làm ops sẽ ngập trong việc vặt, PM sẽ không học cách tự làm việc có hệ thống, và sau một năm công ty có thêm một người mà cách làm việc không khá hơn. Product ops làm việc cho hệ thống, không làm việc cho từng người.

Trang này có sẵn các template chiến lược và OKR, trong đó có Product Operating Cadence Calendar. Các template đó là công cụ; kỹ năng này là cách thực hành đằng sau chúng — vì sao mỗi nghi thức tồn tại, nó cần đầu vào gì, và làm sao biết nó còn đáng giữ.

Ba mảng của product ops

Product ops ở các công ty khác nhau trông rất khác nhau, nhưng hầu hết công việc rơi vào ba mảng. Một người product ops đầu tiên thường nên bắt đầu ở mảng đang đau nhất, không cố làm cả ba cùng lúc.

Ở công ty Việt Nam quy mô 30–150 người làm sản phẩm và kỹ thuật, mảng 1 thường đau nhất — đặc biệt khi công ty vừa tách từ một đội thành nhiều squad và các buổi họp cũ không còn phù hợp. Mảng 3 thường bị bỏ quên lâu nhất, dù đó là mảng tạo ra giá trị trực tiếp cho quyết định sản phẩm.

Thiết kế nhịp vận hành: tuần, tháng, quý

Nhịp vận hành (operating cadence) là bộ nghi thức lặp lại có lịch cố định, mỗi nghi thức có một mục đích, một bộ đầu vào và một đầu ra. Một buổi họp không nói được đầu ra của nó là buổi họp nên bỏ. Nguyên tắc thiết kế: chu kỳ càng dài thì càng ít người, càng nhiều chuẩn bị, và càng nhiều quyết định về hướng đi; chu kỳ càng ngắn thì càng gần việc thực thi.

Thứ tự trong năm cũng quan trọng. Lập kế hoạch quý phải xong trước khi quý bắt đầu, nên các đầu vào của nó (kết quả quý, báo cáo insight) phải sẵn sàng ba tuần trước cuối quý. Ở Việt Nam, hãy tính Tết vào lịch: quý 1 thực tế chỉ có khoảng chín tuần làm việc, và kế hoạch quý 1 nên được chốt trước kỳ nghỉ, không phải sau.

Lịch nhịp vận hành — ví dụ đã điền cho một công ty ba squad

Bối cảnh (giả định): ChợSỉ là nền tảng B2B kết nối nhà phân phối với tạp hoá, khoảng 70 người, ba squad: Đặt hàng (ứng dụng cho chủ tạp hoá), Kho vận (giao hàng và tồn kho), Tài chính (công nợ và thanh toán). Trước đây cả công ty có một buổi họp giao ban thứ Hai kéo dài hai tiếng, và mỗi quý mất ba tuần để chốt kế hoạch. Head of Product cùng người product ops đầu tiên thiết kế lại lịch như sau:

Kết quả sau hai quý (giả định): buổi giao ban hai tiếng bị bỏ; tổng thời gian họp định kỳ của mỗi PM giảm từ khoảng 9 giờ xuống 5 giờ mỗi tuần; kế hoạch quý được chốt trước ngày đầu quý thay vì trễ ba tuần. Điều quan trọng hơn: khi CEO hỏi "squad Tài chính đang làm gì", câu trả lời nằm ở một trang duy nhất, không cần ai nhắn tin hỏi.

Template, nguồn sự thật duy nhất và onboarding PM mới

Template chỉ đáng có khi nó giúp người đọc, không chỉ người viết. Một template PRD chung giúp kỹ sư chuyển giữa các squad mà không phải học lại cách đọc tài liệu; một template OKR chung giúp ban lãnh đạo so các đội với nhau. Nhưng template có quá nhiều ô sẽ được điền cho có. Quy tắc thực dụng: mỗi ô phải có người đọc nó để quyết định một việc gì đó; ô nào không ai đọc trong hai quý thì xoá.

Nguồn sự thật duy nhất nghĩa là với mỗi loại thông tin chỉ có một nơi được coi là đúng. Không cần một công cụ đắt tiền; cần một quy ước được mọi người tôn trọng:

Onboarding PM mới là bài kiểm tra tốt nhất cho product ops. Nếu một PM mới cần ba tháng mới hiểu công ty đo gì, quyết định thế nào, họp gì vào lúc nào, thì hệ thống chỉ tồn tại trong đầu người cũ. Một gói onboarding tốt gồm: lịch nhịp vận hành kèm lý do của từng buổi, từ điển chỉ số, ba PRD mẫu được coi là tốt, nhật ký quyết định sáu tháng gần nhất, danh sách mười người cần gặp trong hai tuần đầu, và một người kèm cụ thể. Mục tiêu: PM mới viết được bản cập nhật hằng tuần đầu tiên đúng chuẩn trong tuần thứ hai.

Khi nào cần một người product ops riêng, và làm sao biết nó hiệu quả

Không phải công ty nào cũng cần. Với một hoặc hai PM, Head of Product tự làm phần lớn công việc này là hợp lý. Tín hiệu nên có người riêng thường xuất hiện khi có từ bốn PM trở lên, hoặc khi PM phàn nàn rằng họ dành hơn một phần tư thời gian cho báo cáo, tìm số liệu và điều phối họp.

Đo xem product ops có hiệu quả — bằng kết quả cho PM và lãnh đạo, không bằng số template đã tạo:

Lỗi thường gặp

Luyện kỹ năng này trong tuần này

• Liệt kê mọi buổi họp định kỳ bạn tham gia. Với mỗi buổi, viết một câu: đầu ra của nó là gì, lưu ở đâu. Buổi nào không viết được câu đó là ứng viên đầu tiên để bỏ hoặc gộp.
• Vẽ lịch nhịp vận hành hiện tại của đội bạn theo dạng bảng ChợSỉ ở trên, kể cả khi nó lộn xộn. Chỉ việc nhìn thấy nó trên một trang đã gợi ra hai, ba thay đổi.
• Chọn một chỉ số mà hai người trong công ty hay báo khác nhau, viết định nghĩa chuẩn cho nó cùng data analyst, và đưa vào một trang từ điển chỉ số.
• Hỏi PM vào công ty gần đây nhất: điều gì mất nhiều thời gian nhất để hiểu? Câu trả lời là mục đầu tiên của gói onboarding.
• Đếm số giờ họp định kỳ mỗi tuần của bạn và đặt mục tiêu giảm một phần năm trong quý tới mà không mất quyết định nào.