Câu hỏi phỏng vấn Product Owner: trả lời bằng tình huống

Sắp phỏng vấn Product Owner mà chưa từng làm PO?

Đây là tình huống minh họa. Vy làm chăm sóc khách hàng ba năm cho một ứng dụng giao đồ ăn, rồi tự học về Scrum và xin vào vị trí Product Owner (PO) cho người mới ở một công ty khác. Vy đọc kỹ Scrum Guide, thuộc định nghĩa Product Backlog, biết tên mấy khung ưu tiên như MoSCoW hay RICE.

Vào buổi phỏng vấn, người phỏng vấn hỏi: “Cùng lúc có lỗi thanh toán, một yêu cầu gấp từ kinh doanh và một ý tưởng của giám đốc. Team chỉ làm kịp một việc. Em chọn gì?”. Vy trả lời bằng định nghĩa MoSCoW, rồi nói sẽ cố làm cả ba. Người phỏng vấn hỏi tiếp: “Vậy cái nào trước?”. Vy im lặng.

Vy không thiếu kiến thức. Vy thiếu cách biến kiến thức thành một lựa chọn có lý do, và thiếu một câu chuyện thật để chứng minh mình đã từng làm điều đó. Bài này giúp bạn chuẩn bị đúng hai phần ấy: biết mỗi nhóm câu hỏi đang kiểm tra gì, và trả lời bằng tình huống thay vì định nghĩa. Mọi câu hỏi mẫu trong bài là minh họa, không phải câu của một công ty cụ thể nào.

Vì sao phỏng vấn PO khó với người mới?

Phỏng vấn PO khác phỏng vấn một vị trí kỹ thuật ở chỗ ít câu có một đáp án đúng. Người phỏng vấn muốn nghe cách bạn nghĩ: bạn hỏi gì trước, bạn chọn gì, bạn chấp nhận mất gì và bạn sẽ kiểm tra lại thế nào. Học thuộc lý thuyết giúp bạn hiểu từ ngữ, nhưng không trả lời được câu “vậy em chọn cái nào”.

• Bạn chưa có chức danh PO, nên dễ nghĩ mình không có chuyện để kể. Thật ra nhiều việc ở vị trí cũ đã có phần ra quyết định, chỉ là bạn chưa kể nó theo cách đó.
• Áp lực khiến bạn muốn nói quá. Đổi chức danh, nhận việc của cả team là của mình hay làm tròn số liệu cho đẹp nghe có vẻ an toàn, nhưng chỉ cần một câu hỏi tiếp là lộ.
• Mỗi công ty dùng chữ PO một kiểu. Có nơi PO quyết thứ tự backlog và nói chuyện với người dùng. Có nơi PO chủ yếu viết tài liệu theo yêu cầu của người khác. Bạn cần biết mình đang ứng tuyển vào kiểu nào.
• Câu hỏi trộn nhiều dạng. Một buổi có thể có câu lý thuyết, câu tình huống giả định, bài viết story tại chỗ và câu về kinh nghiệm thật. Mỗi dạng cần cách trả lời khác nhau.

Tin tốt là cả bốn khó khăn trên đều chuẩn bị được trước. Bạn không thể có thêm kinh nghiệm trong một tuần. Bạn cần sắp xếp lại kinh nghiệm đang có, tập trả lời theo một cấu trúc, và chuẩn bị câu hỏi để hiểu rõ vai trò.

Phỏng vấn Product Owner thường có những loại câu hỏi nào?

Bảng dưới gom các câu hỏi thành sáu nhóm. Câu ví dụ chỉ để minh họa kiểu hỏi. Khi chuẩn bị, hãy nghĩ người phỏng vấn đang muốn kiểm tra điều gì, vì cùng một ý có thể được hỏi bằng nhiều cách.

Về câu hiểu vai trò, Scrum Guide 2020 viết PO chịu trách nhiệm tối đa hóa giá trị của sản phẩm mà Scrum Team làm ra, và chịu trách nhiệm quản lý Product Backlog (danh sách việc có thứ tự của sản phẩm). PO là một người, không phải một hội đồng. Trang “What is a Product Owner?” của Scrum.org còn liệt kê vài hiểu lầm về vai trò này, như xem PO chỉ là người viết story hay người gác cổng. Nếu bạn nói được những ý này bằng lời của mình, kèm một ví dụ, câu trả lời sẽ chắc hơn nhiều so với đọc lại định nghĩa.

• PO, PM và BA khác nhau thế nào

Trả lời câu hỏi tình huống theo cấu trúc nào?

Với câu hỏi về kinh nghiệm, bạn có thể dùng cấu trúc STAR. Trang hướng nghiệp của MIT (CAPD) mô tả STAR gồm bốn phần: Situation (bối cảnh), Task (nhiệm vụ của bạn), Action (việc bạn đã làm) và Result (kết quả). Trang này cũng khuyên dùng ví dụ có thật, nói rõ phần “tôi” đã làm khi kể việc của cả nhóm, chuẩn bị khoảng ba đến năm câu chuyện và không học thuộc như kịch bản.

Với vị trí PO, bài này đề xuất một biến thể nhỏ: tách riêng phần quyết định và cái giá của nó. Lý do là việc cốt lõi của PO là chọn, và mỗi lựa chọn đều làm một việc khác phải chờ. Người phỏng vấn muốn nghe bạn thấy được cái giá đó.

Bối cảnh nên ngắn, chỉ đủ để người nghe hiểu. Phần của bạn cần rõ ràng: “mình đề xuất”, “mình gọi cho bốn khách”, “quản lý chọn phương án hai”. Phần quyết định là chỗ thể hiện tư duy PO, vì vậy nói ra cả phương án bạn không chọn và vì sao. Phần kết quả nên có con số kèm khoảng thời gian đo, nếu có; chưa đo thì nói rõ là chưa đo. Nếu kết quả không như mong đợi, đó vẫn là câu chuyện tốt khi bạn nói được mình học gì.

Nếu bạn chưa có câu chuyện nào đủ bốn phần, bài về chuyển từ BA, QA hoặc dev sang PO có cách tích kinh nghiệm ngay trong công việc hiện tại, kèm mẫu kể lại một quyết định mà không nói quá.

• Chuyển từ BA, QA hoặc dev sang Product Owner

Từng nhóm câu hỏi nên chuẩn bị thế nào?

Tình huống ưu tiên. Đừng trả lời bằng tên một khung ưu tiên. Hỏi lại một hai câu về mức ảnh hưởng và hạn chót thật, nói giả định của bạn, chọn một thứ tự, rồi nói việc gì phải chờ và bạn sẽ báo cho ai. Khung như RICE chỉ giúp bạn nói ra giả định, không thay cho lựa chọn.

Xung đột stakeholder. Người phỏng vấn muốn thấy bạn không chỉ nói có hoặc không. Một câu trả lời tốt nhắc lại vấn đề theo lời người kia, đưa ra hai ba phương án kèm cái giá của từng cái, và nói cách bạn giữ liên lạc sau đó.

Viết story hoặc AC tại chỗ. Trước khi viết, hỏi tính năng dành cho ai và để làm gì. Viết một story theo dạng “Là [người dùng], tôi muốn [việc cần làm], để [kết quả]”, rồi ba đến bốn acceptance criteria (AC, các điều kiện để biết story đã làm đúng), trong đó có ít nhất một trường hợp lỗi. Nói to điều bạn sẽ hỏi team phát triển nếu có thời gian.

Số đo. Nêu một số đo cho thấy người dùng được lợi, một số đo cần giữ không xấu đi, và đo trong bao lâu. Câu “ra mắt đúng hạn” là đầu ra, chưa phải kết quả.

• Ưu tiên backlog khi việc nào cũng gấp
• Cách viết user story cho người mới
• Đo lường tính năng sau khi ra mắt
• Nói không với stakeholder mà không mất lòng

Gặp câu hỏi không trả lời được thì nói gì?

Bạn có thể gặp câu hỏi mình không biết, ví dụ về một công cụ, một chỉ số hay một quy trình bạn chưa làm. Bịa ra kinh nghiệm là lựa chọn tệ nhất, vì câu hỏi tiếp theo sẽ đi vào chi tiết. Một cách làm an toàn hơn có ba bước:

• Xin vài giây để nghĩ, hoặc hỏi lại cho rõ: “Anh/chị muốn hỏi về cách tính hay cách dùng chỉ số này trong quyết định ạ?”.
• Nói thật phần mình chưa làm, rồi nói phần mình hiểu: “Em chưa trực tiếp làm phần này. Theo em hiểu thì…”.
• Nói cách bạn sẽ tìm hiểu nếu gặp trong công việc: hỏi ai, xem dữ liệu nào, thử nhỏ ra sao.

Câu trả lời này cho người phỏng vấn thấy bạn trung thực và biết cách học, hai điều PO cần mỗi ngày. Nó cũng tốt hơn nhiều so với một câu trả lời tự tin mà sai.

Hỏi gì để biết vai trò có phải Product Owner thật không?

Cuối buổi, khi được mời đặt câu hỏi, đừng bỏ qua. Đây là lúc bạn kiểm tra vai trò mình sắp nhận. Scrum Guide 2020 viết rằng để PO làm tốt, cả tổ chức phải tôn trọng quyết định của PO. Bộ câu hỏi dưới giúp bạn biết thực tế ở công ty đó gần với điều này tới đâu.

Hỏi bằng giọng tò mò, không phải kiểm tra người phỏng vấn. Câu hỏi tốt nhất là câu xin một ví dụ cụ thể, vì ví dụ cho bạn thấy thực tế rõ hơn mô tả công việc. Danh sách đầy đủ để bạn copy nằm ở phần mẫu bên dưới.

Ví dụ: câu trả lời yếu và câu trả lời mạnh cho một tình huống ưu tiên

Đây là ví dụ minh họa. Tên cửa hàng và mọi con số đều là giả định. Câu hỏi: “Bạn là PO của Gốm Mây, một shop bán gốm online. Cùng lúc có ba việc: thanh toán qua một ngân hàng bị lỗi khiến một phần đơn thất bại; bộ phận kinh doanh cần mã giảm giá riêng cho từng nhóm khách để chạy chiến dịch sau hai tuần nữa; giám đốc muốn làm lại trang chủ. Sprint tới team chỉ làm kịp một việc lớn. Bạn chọn gì?”

Ghép lại, câu trả lời mạnh nghe như sau: “Trước khi chọn, em muốn hỏi lỗi thanh toán ảnh hưởng bao nhiêu đơn và chiến dịch có ngày cố định không. Giả sử lỗi làm khoảng một phần mười đơn qua ngân hàng đó thất bại, em chọn sửa lỗi trước, vì nó làm mất doanh thu mỗi ngày và làm khách mất niềm tin. Em sẽ hỏi Developers ước lượng để chắc việc này vừa sprint. Với chiến dịch, em đề xuất dùng mã chung tạo thủ công. Cái giá là kinh doanh chưa nhắm theo nhóm khách được, em sẽ nói rõ với họ ngay hôm đó. Trang chủ em hẹn lại và hỏi giám đốc muốn đạt điều gì để đo được. Sau khi sửa, em theo tỉ lệ đơn thất bại trong một tuần. Nếu số đơn lỗi ít hơn em nghĩ, em sẽ cân lại.”

Câu trả lời yếu không sai về kiến thức. Nó yếu vì không chọn, không thấy cái giá, và hứa “tăng ca để làm hết” là điều PO không nên hứa thay team. Ở đây PO sắp thứ tự, còn Developers ước lượng và quyết bao nhiêu việc vừa sprint. Câu trả lời mạnh cũng không cần đúng ý người phỏng vấn. Nếu họ hỏi “nếu giám đốc nhất quyết muốn trang chủ trước thì sao?”, bạn quay lại đúng cấu trúc: hỏi giám đốc lý do, nói cái giá của việc đổi thứ tự, rồi để người có quyền quyết chốt kèm thông tin đầy đủ.

Mẫu chuẩn bị phỏng vấn và danh sách câu hỏi nên hỏi lại

Hai mẫu dưới đây dùng trước buổi phỏng vấn. Mẫu đầu giúp bạn sắp xếp câu chuyện và bài tập. Mẫu sau là các câu hỏi để hỏi lại nhà tuyển dụng. Bạn copy rồi điền theo vị trí mình ứng tuyển.

Vị trí: [tên vị trí, công ty]
Ba điều mô tả công việc nhấn mạnh: [1], [2], [3]
Sản phẩm của họ: [ai dùng, dùng để làm gì, một điều mình thấy có thể cải thiện]

Câu chuyện 1, dùng cho nhóm câu: [ưu tiên / stakeholder / quyết định / số đo]
- Bối cảnh: [sản phẩm, người dùng, chức danh thật của tôi lúc đó]
- Phần tôi làm: [việc tôi trực tiếp làm]
- Phần người khác làm hoặc quyết: [ai, làm gì]
- Các phương án và cái giá: [phương án, việc phải chờ]
- Kết quả: [số đo trước] -> [số đo sau], trong [khoảng thời gian]
- Điều tôi học được hoặc chưa chắc: [...]
(Lặp lại cho 3 đến 5 câu chuyện)

Hai câu hỏi tiếp theo dễ bị hỏi cho mỗi câu chuyện, và câu trả lời thật: [...]

Tập tại chỗ: viết một user story và 3 đến 4 AC, có một trường hợp lỗi, cho [một tính năng trong sản phẩm của họ], trong 10 phút.
Một số đo kết quả và một số đo cần giữ không xấu đi cho tính năng đó: [...]

Kiểm tra cuối: chức danh, phạm vi và số liệu trong mọi câu chuyện đều đúng như thật.

1. Ai quyết thứ tự backlog, và khi có bất đồng thì ai chốt?
2. Gần đây có lần nào có người muốn đổi ưu tiên giữa chừng không? Chuyện đó được xử lý thế nào?
3. PO ở đây có nói chuyện trực tiếp với người dùng không, bao lâu một lần?
4. Team biết một tính năng thành công bằng cách nào? Có tính năng nào gần đây được đo sau khi ra mắt không?
5. Một tuần của PO trong team này dành cho những việc gì?
6. PO làm việc với những stakeholder nào, và yêu cầu thường đến từ đâu?
7. Team phát triển và kiểm thử có cố định cho sản phẩm này không?
8. Sau ba tháng, người ở vị trí này cần làm được điều gì thì anh/chị thấy là tốt?
9. Khó khăn lớn nhất của sản phẩm hiện giờ là gì?

Bạn không cần hỏi hết chín câu. Chọn ba bốn câu quan trọng nhất với mình, ưu tiên câu một, hai và bốn vì chúng cho thấy rõ nhất vai trò có gần PO thật hay không.

Những lỗi dễ gặp khi phỏng vấn Product Owner

• Nói quá chức danh, phạm vi hoặc số liệu. Ghi “phụ trách sản phẩm” khi bạn là QA, hay nói “giảm 50%” mà không nói đo trong bao lâu, sẽ lộ ở câu hỏi thứ hai. Giữ đúng sự thật và kể rõ phần mình làm.
• Trả lời bằng tên khung lý thuyết. Nói “em dùng RICE” không thay cho việc chọn. Nếu nhắc tới một khung, hãy dùng nó để nói ra giả định rồi đưa ra lựa chọn.
• Kể “chúng tôi” từ đầu tới cuối. Người phỏng vấn không biết bạn làm phần nào. Nói rõ phần của bạn, và ghi công đúng cho người khác.
• Không nói cái giá. Mỗi lựa chọn đều làm một việc khác phải chờ. Không nhắc tới điều đó nghe như bạn chưa từng phải chọn thật.
• Hứa thay team. “Cả team tăng ca làm hết” hay “em sẽ bảo dev làm trong hai ngày” cho thấy bạn chưa rõ ai quyết bao nhiêu việc vào sprint.
• Không hỏi lại gì. Bỏ qua phần đặt câu hỏi là mất cơ hội biết vai trò thật, và có thể bị xem là chưa quan tâm tới sản phẩm.
• Chê đồng nghiệp hoặc công ty cũ khi kể xung đột. Kể vấn đề và cách bạn xử lý, không kể ai sai.

Tóm tắt

• Phỏng vấn PO có thể có sáu nhóm câu: hiểu vai trò, ưu tiên, stakeholder, viết story hoặc AC tại chỗ, số đo và kể một quyết định. Mỗi nhóm kiểm tra một kỹ năng khác nhau.
• Trả lời bằng tình huống theo bốn phần: bối cảnh, phần của bạn, quyết định và cái giá, kết quả và điều học được. Với câu giả định, hỏi lại, nói giả định và nói cách bạn sẽ kiểm tra.
• Gặp câu không biết thì nói thật, nói phần mình hiểu và cách mình sẽ tìm hiểu, đừng bịa kinh nghiệm.
• Cuối buổi, hỏi ai quyết thứ tự backlog, PO có gặp người dùng không và team đo kết quả thế nào để biết vai trò có phải PO thật.
• Giữ đúng chức danh, phạm vi và số liệu. Câu chuyện khiêm tốn mà bảo vệ được mạnh hơn câu chuyện lớn mà không bảo vệ được.

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

Phỏng vấn Product Owner có thể hỏi những gì?

Bạn có thể gặp sáu nhóm câu: hiểu vai trò PO, tình huống ưu tiên, xung đột với stakeholder, viết user story hoặc acceptance criteria tại chỗ, số đo sau khi ra mắt, và kể về một quyết định bạn đã đưa ra. Mỗi nhóm kiểm tra một kỹ năng khác nhau, nên chuẩn bị riêng cho từng nhóm.

Chưa từng làm PO thì trả lời câu hỏi kinh nghiệm thế nào?

Kể một việc thật ở vị trí hiện tại mà bạn đã theo từ vấn đề tới kết quả, nói rõ phần mình làm và phần người khác quyết. Giữ đúng chức danh, phạm vi và số liệu, vì người phỏng vấn có thể hỏi tiếp tới chi tiết.

Phương pháp STAR trong phỏng vấn là gì?

STAR là cách kể một ví dụ theo bốn phần: Situation (bối cảnh), Task (nhiệm vụ của bạn), Action (việc bạn đã làm) và Result (kết quả). Với vị trí PO, nên nói thêm phương án bạn đã chọn và cái giá của lựa chọn đó.

Nguồn kiểm tra

• Scrum Guide 2020: Product Owner
• Scrum.org: What is a Product Owner?
• MIT CAPD: Using the STAR method for your next behavioral interview

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ì.
• 30 ngày đầu làm Product Owner: mỗi tuần nên làm gì?: Kế hoạch bốn tuần cho PO mới: nghe và vẽ bản đồ, hiểu người dùng và số liệu, nhận một phần backlog nhỏ, rồi ra quyết định đầu tiên và chốt kỳ vọng với quản lý.
• 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.