30 ngày đầu làm Product Owner: mỗi tuần nên làm gì?

Ngày đầu làm Product Owner trông như thế nào?

Đây là tình huống minh họa. Bạn vừa nhận vị trí Product Owner (PO) cho Bếp Nhà, một ứng dụng đặt món hư cấu. Ngày đầu tiên, bạn được thêm vào năm nhóm chat và nhận quyền vào một board có vài trăm ticket. Quản lý trực tiếp nói: “Em cứ làm quen trước, cuối tháng mình nói chuyện.”

Chưa hết buổi sáng, bên kinh doanh đã hỏi khi nào có tính năng tích điểm. Một kỹ sư nhắn hỏi ticket sửa lỗi thanh toán có nên làm trước không. Còn trong cuộc họp đầu tiên, có người nhắc tới “roadmap quý sau” như thể bạn đã biết nó.

Lúc này dễ có hai phản xạ. Một là ngồi dọn lại toàn bộ backlog cho gọn, để thấy mình đang làm được việc. Hai là trả lời ngay mọi câu hỏi, để chứng tỏ mình nắm được vai trò. Cả hai đều dễ hiểu, nhưng cả hai đều có thể khiến bạn ra quyết định khi chưa đủ bối cảnh.

Bài này đưa ra một kế hoạch 30 ngày, chia theo tuần. Mỗi tuần có một mục tiêu, một vài việc cụ thể và một đầu ra để bạn biết mình đã xong tuần đó chưa. Nếu bạn chưa rõ công việc hằng ngày của PO gồm những gì, hãy đọc bài về một ngày của PO trước.

• Product Owner thực sự làm gì mỗi ngày?

Vì sao tháng đầu làm PO dễ choáng?

Tháng đầu khó không phải vì bạn thiếu kiến thức Scrum. Nó khó vì bạn phải vừa học bối cảnh, vừa bị kỳ vọng ra quyết định. Có thể có bốn lý do:

• Thông tin tới nhiều mà bạn chưa có khung để xếp. Mỗi người kể một phần, và phần nào cũng nghe quan trọng.
• Bạn chưa biết lịch sử. Một ticket nằm im ba tháng có thể là do bị quên, cũng có thể là do đã từng bị từ chối có lý do.
• Vai trò PO mỗi công ty hiểu một kiểu. Kỳ vọng của quản lý chưa chắc giống điều bạn đọc trong sách.
• Bạn muốn chứng tỏ mình nhanh. Ở vị trí mới, nói “có” hoặc đưa ra một kế hoạch lớn cho cảm giác mình đang đóng góp.

Scrum.org có một bài về những cái bẫy của PO mới. Bài đó nêu các bẫy như nhận mọi yêu cầu khiến backlog quá tải, chỉ làm việc với team mà ít gặp stakeholder, cuốn vào việc hằng ngày mà quên tầm nhìn sản phẩm, và quản quá sát công việc của kỹ sư. Theo góc nhìn của bài này, tháng đầu là lúc dễ rơi vào các bẫy đó, vì bạn chưa có gì để so.

Scrum Guide 2020 viết rằng PO chịu trách nhiệm quản lý Product Backlog hiệu quả, gồm cả việc sắp thứ tự các mục trong đó. Trách nhiệm này có từ ngày đầu, nhưng khả năng làm tốt nó thì phải xây dần. Một quyết định đưa ra khi chưa hiểu bối cảnh có thể đúng do may, nhưng bạn sẽ khó giải thích nó, và lần sau cũng khó lặp lại.

Kế hoạch 30 ngày đầu cho PO mới: mỗi tuần làm gì?

Bốn tuần đi từ nghe sang làm. Hai tuần đầu chủ yếu là hiểu. Hai tuần sau là nhận trách nhiệm, bắt đầu từ phần nhỏ. Thứ tự này giúp quyết định đầu tiên của bạn dựa trên bằng chứng thay vì cảm giác.

Kế hoạch này là một gợi ý, không phải lịch cố định. Nếu bạn vào giữa lúc team sắp phát hành, tuần 3 có thể tới sớm hơn. Điều nên giữ là thứ tự: hiểu trước, nhận phần nhỏ sau, quyết định lớn để sau khi đã có bằng chứng.

Tuần 1: PO mới nên gặp ai và hỏi gì?

Mục tiêu tuần đầu là vẽ được bốn tấm bản đồ. Chúng không cần đẹp. Một trang ghi chú cho mỗi tấm là đủ.

• Bản đồ người: ai quyết điều gì, ai cần được hỏi trước, ai chỉ cần được báo sau.
• Bản đồ sản phẩm: tự dùng sản phẩm như một người dùng mới, đi hết luồng chính và ghi lại chỗ nào làm bạn khựng lại.
• Bản đồ dữ liệu: team đang đo những gì, dashboard nằm ở đâu, số nào mọi người tin và số nào hay bị hỏi lại.
• Bản đồ backlog: đọc nhưng chưa sửa. Đánh dấu mục nào đang làm, mục nào đã có người hứa với ai, mục nào đã nằm rất lâu.

Để vẽ bản đồ người, hãy hẹn mỗi nhóm một buổi ngắn. Nielsen Norman Group gợi ý các buổi phỏng vấn stakeholder nên xoay quanh việc họ coi điều gì là thành công, họ đang ưu tiên gì, lịch sử và ràng buộc đã có, và họ muốn được tham gia hay cập nhật thế nào. Bảng dưới đây áp các ý đó vào từng nhóm mà PO mới hay làm việc cùng.

Trong tuần này, hãy hỏi nhiều và hứa ít. Khi ai đó cần bạn quyết một việc chưa gấp, một câu trả lời an toàn là: “Em ghi nhận rồi, em cần hiểu thêm bối cảnh và sẽ phản hồi trước [ngày].” Nếu là sự cố đang ảnh hưởng người dùng, đừng giữ nó lại vì mình còn mới. Hãy làm theo quy trình xử lý sự cố team đang có, và hỏi quản lý hoặc tech lead.

Đầu ra tuần 1: bốn trang bản đồ, và một danh sách câu hỏi bạn chưa trả lời được.

Tuần 2: làm sao hiểu người dùng và số liệu nhanh?

Tuần 1 cho bạn góc nhìn của người trong công ty. Tuần 2 kéo bạn ra phía người dùng. Đây là chỗ nhiều PO mới dễ bỏ qua, vì nghe stakeholder đã đủ bận.

• Đọc phản hồi gốc: phiếu hỗ trợ, đánh giá trên kho ứng dụng, ghi chú của đội chăm sóc khách hàng. Đọc nguyên văn, không chỉ đọc bản tóm tắt.
• Ngồi cùng đội hỗ trợ hoặc vận hành một buổi, nếu công ty cho phép. Bạn sẽ thấy những việc làm tay mà không ticket nào ghi lại.
• Nói chuyện với vài người dùng thật, kể cả chỉ qua điện thoại mười lăm phút. Hỏi họ dùng sản phẩm lúc nào, để làm gì, chỗ nào phiền.
• Tìm hiểu số liệu chính: team đang theo dõi chỉ số nào, nó được tính ra sao, lấy từ đâu, ai là người hiểu nó rõ nhất.

Với số liệu, đừng chỉ hỏi con số là bao nhiêu. Hãy hỏi nó được tính thế nào. Hai bộ phận có thể cùng nói “tỷ lệ đơn thành công” nhưng tính theo hai cách khác nhau. Nếu bạn muốn tự kiểm số mà không phải chờ người khác, bài về SQL cho PO mới có thể giúp.

Đầu ra tuần 2: một đoạn ngắn trả lời bốn câu. Người dùng chính là ai. Họ vướng nhiều nhất ở đâu. Team đang đo gì để biết sản phẩm tốt lên. Số nào bạn còn nghi ngờ và cần kiểm lại.

• SQL cho Product Owner mới bắt đầu

Tuần 3: nên nhận phần backlog nào trước?

Đến tuần 3, bạn bắt đầu giữ một phần backlog thật. Không phải toàn bộ. Hãy thống nhất với quản lý và team về một lát nhỏ, ví dụ một khu vực tính năng, hoặc vài mục đầu backlog cho một đến hai sprint tới. Sprint là một chu kỳ làm việc ngắn, có độ dài cố định (tối đa một tháng), trong đó team hướng tới một Sprint Goal chung.

Một phần backlog tốt để bắt đầu có bốn đặc điểm:

• Đủ nhỏ để bạn hiểu hết từng mục trong vài ngày.
• Đang có người chờ, để công sức của bạn có ích ngay.
• Rủi ro vừa phải, không chạm vào thanh toán hay dữ liệu nhạy cảm nếu bạn chưa hiểu rõ hệ thống.
• Đi qua đủ đường từ yêu cầu, làm rõ, phát triển, kiểm thử tới phát hành, để bạn học được cả quy trình.

Với mỗi mục trong phần đó, làm rõ đến khi team bắt tay làm được: vấn đề là gì, cho ai, phạm vi tới đâu, và tiêu chí chấp nhận (acceptance criteria, viết tắt AC) là gì. Tham gia buổi refinement, tức buổi team cùng làm rõ và ước lượng các mục sắp làm, và chuẩn bị cho sprint planning. Nếu team chưa có Definition of Done, đây là lúc hỏi về nó trước; Definition of Ready là tùy chọn.

Đầu ra tuần 3: phần backlog bạn giữ đã có thứ tự, mỗi mục đầu có vấn đề, phạm vi và AC rõ, và team đồng ý rằng có thể bắt đầu làm.

• Cách viết user story cho người mới
• Sprint planning: PO cần chuẩn bị gì?
• Definition of Ready và Definition of Done

Tuần 4: quyết định đầu tiên và chốt kỳ vọng với quản lý

Tuần 4 có hai việc. Việc thứ nhất là ra một quyết định đầu tiên trong phần backlog bạn giữ, và giải thích nó. Không cần là quyết định lớn. Nó có thể là đổi thứ tự hai mục, cắt bớt phạm vi một tính năng, hoặc hẹn lại một yêu cầu kèm ngày xem lại.

Điều quan trọng là cách bạn giải thích. Một quyết định dễ được chấp nhận khi nó trả lời được năm ý: vấn đề là gì, bằng chứng nào, đã cân nhắc những phương án nào, chọn gì và vì sao, khi nào sẽ xem lại. Nếu nhiều việc cùng gấp, bài về ưu tiên backlog có các cách so sánh cụ thể hơn.

Việc thứ hai là chốt kỳ vọng với quản lý. Câu “cuối tháng mình nói chuyện” ở ngày đầu chính là lúc này. Hãy mang theo những gì đã học trong ba tuần, rồi cùng thống nhất ba điều: sau 60 và 90 ngày bạn cần làm được gì, bạn được tự quyết những gì và việc nào cần hỏi trước, và hai bên cập nhật cho nhau theo nhịp nào. Sau buổi nói chuyện, ghi lại bằng văn bản và gửi để quản lý xác nhận.

Đầu ra tuần 4: một quyết định đã được giải thích cho team và stakeholder liên quan, và một ghi chú kỳ vọng đã được quản lý xác nhận.

• Ưu tiên backlog khi việc nào cũng gấp

Những việc PO mới không nên làm trong tháng đầu

Có những việc đúng về lâu dài nhưng sai thời điểm nếu làm trong tháng đầu. Bốn việc dưới đây dễ bị làm sớm vì chúng cho cảm giác mình đang tạo ra thay đổi.

Khi ai đó hỏi về roadmap trong tháng đầu, bạn không cần né. Một câu trả lời trung thực là: “Em đang tìm hiểu người dùng và số liệu. Cuối tháng em sẽ có đề xuất cho phần em giữ, còn roadmap lớn hơn em sẽ làm cùng anh/chị sau khi chốt kỳ vọng.”

Ví dụ: 30 ngày đầu của một PO ở ứng dụng đặt món

Quay lại Bếp Nhà. Đây là ví dụ minh họa, các con số trong đó là giả định để bạn dễ hình dung.

Ở tuần 4, PO trình bày quyết định với quản lý. Cuộc trao đổi rút gọn dưới đây cũng là minh họa.

Để ý rằng PO không viết lại cả backlog, cũng không hứa roadmap. Quyết định nằm gọn trong phần được giao ở tuần 3, có bằng chứng từ tuần 2, có ngày xem lại, và người bị hẹn lại được báo trước. Câu cuối của quản lý chính là một phần kỳ vọng cần ghi vào ghi chú.

Mẫu kế hoạch 30 ngày và ghi chú chốt kỳ vọng

Hai mẫu dưới đây để bạn copy vào công cụ ghi chú của mình. Mẫu đầu là checklist theo tuần. Mẫu sau là ghi chú gửi quản lý sau buổi chốt kỳ vọng ở tuần 4.

TUẦN 1: NGHE VÀ VẼ BẢN ĐỒ
[ ] Gặp quản lý trực tiếp: kỳ vọng sau 3 tháng, quyền tự quyết
[ ] Gặp tech lead và kỹ sư: phần dễ vỡ, ticket hay bị thiếu
[ ] Gặp thiết kế, QA, kinh doanh, vận hành, chăm sóc khách hàng
[ ] Gặp người giữ vai trò trước (nếu có): cam kết đang treo
[ ] Tự dùng sản phẩm hết luồng chính, ghi chỗ khựng lại
[ ] Đọc backlog, chưa sửa: mục đang làm, mục đã hứa, mục nằm lâu
Đầu ra: bản đồ người, sản phẩm, dữ liệu, backlog + danh sách câu hỏi mở

TUẦN 2: HIỂU NGƯỜI DÙNG VÀ SỐ LIỆU
[ ] Đọc phản hồi gốc: phiếu hỗ trợ, đánh giá, ghi chú chăm sóc khách hàng
[ ] Ngồi cùng đội hỗ trợ hoặc vận hành một buổi
[ ] Nói chuyện với vài người dùng thật
[ ] Hỏi cách tính các chỉ số chính và nguồn dữ liệu
Đầu ra: người dùng chính là ai, vướng ở đâu, team đo gì, số nào cần kiểm lại

TUẦN 3: NHẬN MỘT PHẦN BACKLOG NHỎ
[ ] Thống nhất với quản lý và team phần backlog mình giữ
[ ] Làm rõ vấn đề, phạm vi, AC cho các mục đầu
[ ] Tham gia refinement, chuẩn bị sprint planning
Đầu ra: phần backlog có thứ tự, team đồng ý bắt đầu làm

TUẦN 4: QUYẾT ĐỊNH ĐẦU TIÊN VÀ CHỐT KỲ VỌNG
[ ] Ra một quyết định trong phần mình giữ
[ ] Giải thích: vấn đề, bằng chứng, phương án, lựa chọn, ngày xem lại
[ ] Báo trước cho người bị ảnh hưởng
[ ] Gặp quản lý chốt kỳ vọng, gửi ghi chú để xác nhận
Đầu ra: ghi chú quyết định + ghi chú kỳ vọng đã xác nhận

Chào anh/chị [tên],
Em tóm tắt lại buổi trao đổi hôm [ngày] để mình cùng xác nhận.

1. Sau 60 ngày, em cần làm được: [kết quả cụ thể]
2. Sau 90 ngày, em cần làm được: [kết quả cụ thể]
3. Em tự quyết: [ví dụ: thứ tự trong khu vực X]
4. Em cần hỏi anh/chị trước khi: [ví dụ: hứa ngày với khách, đổi phạm vi lớn]
5. Nhịp cập nhật: [kênh, tần suất, độ dài]
6. Điều em còn chưa rõ: [câu hỏi mở]

Nếu có ý nào em hiểu chưa đúng, anh/chị sửa giúp em nhé. Em sẽ xem lại ghi chú này cùng anh/chị vào [ngày].

Ghi chú kỳ vọng nên ngắn, đủ để đọc trong một phút. Nó không phải hợp đồng. Giá trị của nó là để hai bên cùng nhìn một thứ khi nhìn lại sau 60 ngày, thay vì mỗi người nhớ một kiểu.

Những lỗi PO mới dễ mắc trong tháng đầu

• Nghe mà không ghi. Sau hai tuần gặp gỡ, nếu không có ghi chú, bạn chỉ còn lại ấn tượng của người nói to nhất.
• Chỉ gặp team phát triển. Scrum.org nêu việc ít gặp stakeholder là một bẫy của PO mới. Kỳ vọng lệch dễ lộ ra muộn, lúc đã khó sửa.
• Đợi hiểu hết mới quyết. Sẽ không có lúc nào bạn hiểu hết. Tuần 4 vẫn nên có một quyết định nhỏ, kèm ngày xem lại.
• Nhận phần backlog quá lớn hoặc quá rủi ro ở tuần 3. Một phần nhỏ làm trọn sẽ dạy bạn nhiều hơn một phần lớn làm dở.
• Chốt kỳ vọng bằng lời. Ba tháng sau, cả bạn và quản lý có thể nhớ khác nhau. Hãy ghi lại và xin xác nhận.
• Cố làm giống người PO trước. Hỏi họ để hiểu lịch sử, nhưng cách làm của bạn nên xuất phát từ những gì bạn thấy ở người dùng và team.

Tóm tắt

• Tuần 1: nghe và vẽ bản đồ người, sản phẩm, dữ liệu và backlog. Hỏi nhiều, hứa ít.
• Tuần 2: đọc phản hồi gốc, nói chuyện với người dùng, hiểu cách tính các chỉ số chính.
• Tuần 3: nhận một phần backlog nhỏ và làm rõ đến khi team bắt tay làm được.
• Tuần 4: ra một quyết định có bằng chứng và ngày xem lại, rồi chốt kỳ vọng với quản lý bằng văn bản.
• Trong tháng đầu, tránh viết lại toàn bộ backlog, hứa roadmap, đổi quy trình hay quản sát kỹ sư.

Mình đang soạn thêm các tình huống PO khác theo cùng khung này, kèm mẫu dùng ngay. Nếu bạn muốn nhận khi có bài mới, đăng ký bản tin bên dưới.

• Nhận bài mới qua email

Câu hỏi thường gặp

Product Owner mới có nên sửa lại backlog ngay không?

Không nên sửa toàn bộ trong tháng đầu. Hãy đọc backlog để hiểu vì sao nó như hiện tại, rồi chỉ nhận và làm rõ một phần nhỏ ở tuần thứ ba.

30 ngày đầu làm PO cần đạt được gì?

Cuối tháng đầu, bạn nên có bản đồ người và hệ thống, hiểu người dùng chính và số liệu team đang theo dõi, đã giữ một phần backlog nhỏ, đã ra một quyết định có giải thích và có kỳ vọng được ghi lại cùng quản lý.

Khi gặp stakeholder lần đầu, PO mới nên hỏi gì?

Hỏi họ coi điều gì là thành công, họ đang lo vấn đề gì, trước đây đã thử những gì, và họ muốn được cập nhật theo cách nào. Ở buổi đầu, nghe và ghi lại quan trọng hơn hứa hẹn.

Nguồn kiểm tra

• Scrum Guide 2020: Product Owner
• Scrum.org: Top 5 Pitfalls of New Product Owners
• Nielsen Norman Group: Stakeholder Interviews 101

Bài liên quan

• PO, PM và BA khác nhau thế nào? Đọc JD để biết vai trò thật: Phân biệt PO, PM và BA theo trách nhiệm thật, cách ranh giới thay đổi theo từng loại công ty ở Việt Nam, và cách đọc tin tuyển dụng để biết vị trí đó thực chất là gì.
• Không biết code có làm Product Owner được không?: PO không cần viết code, nhưng cần đủ hiểu biết kỹ thuật để hỏi đúng câu, tôn trọng quyền quyết “làm thế nào” của Developers và bàn đánh đổi một cách rõ ràng.
• Chuyển từ BA, QA, dev sang Product Owner: cần học thêm gì?: Thế mạnh nào của BA, QA và dev mang sang PO được, điểm mù nào cần để ý, và cách tích kinh nghiệm PO ngay trong công việc hiện tại.
• Câu hỏi phỏng vấn Product Owner: trả lời bằng tình huống: Các nhóm câu hỏi khi phỏng vấn vị trí PO, cách trả lời bằng một tình huống cụ thể, cách xử lý câu không biết và những câu nên hỏi lại nhà tuyển dụng.