🧠 Product Thinking
⚙️ Execution
🤝 Stakeholder
📊 Data & Metrics
🪞 Self-Awareness
📋 Scoresheet
PRODUCT THINKING — Tư duy sản phẩm
Khi nhận được một yêu cầu tính năng từ business, bước đầu tiên bạn làm là gì? Walk me through quá trình đi từ "request" đến "solution".
→ Test: có discovery mindset không hay nhận spec và build ngay?
✅ Tốt: Hỏi "why" trước khi hỏi "what". Gặp user để validate pain point. Define problem statement trước khi đề xuất solution. Kể được lần push back một request vì root cause khác.
🚨 Pass: "Tôi viết user story rồi estimate với dev." — Nhận request, build ngay, không validate.
↳ Follow-up: "Lần gần nhất bạn phát hiện yêu cầu ban đầu sai — bạn xử lý thế nào?"
Backlog của bạn có 30 item. Business muốn feature A (revenue), design muốn fix UX debt B, tech muốn refactor C. Bạn làm gì?
→ Test: có framework ưu tiên không? Biết trade-off không? Dám nói "không" không?
✅ Tốt: Dùng framework (RICE, MoSCoW, ICE) hoặc tự xây. Map với OKR. Negotiate trade-off rõ ràng với từng bên. Không hide sau consensus.
🚨 Watch out: "Tôi họp để mọi người đồng thuận." — Symptom của PO yếu, tránh ra quyết định.
↳ Follow-up: "Lần nào bạn nói 'không' với stakeholder senior? Họ phản ứng thế nào?"
Kể về lần gần nhất bạn nói chuyện trực tiếp với user (không qua report, không qua CS ticket). Bạn phát hiện điều gì mà data không cho thấy?
→ Test: có thực sự làm user research không? Hay chỉ đọc report?
✅ Tốt: Có câu chuyện cụ thể. Nêu được "aha moment" analytics không capture. Thay đổi decision dựa trên đó.
🚨 Red flag: "Tôi đọc feedback từ CS" hoặc "chúng tôi có survey hàng quý" — không direct contact. PO sống trong ivory tower.
Nếu được giao làm PO publisher side tại ACCESSTRADE — 6 tháng đầu bạn tập trung vào điều gì? Tại sao không phải điều khác?
→ Test: có tư duy strategy không? Phân biệt "urgent vs important" ở level product?
✅ Tốt: Hỏi context trước (north star, team size, current pain). Propose discovery phase. Phân biệt quick wins vs. foundation. Không list features ngay.
🚨 Pass: Đưa ra roadmap cụ thể ngay ("làm dashboard mới, notification, payout nhanh hơn") — features không có insight.
EXECUTION — Năng lực triển khai
Bạn viết user story như thế nào? Cho tôi xem ví dụ thực tế về user story tốt nhất bạn từng viết và tại sao bạn cho là tốt.
→ Test: có biết viết acceptance criteria rõ ràng không? Có "definition of done" không?
✅ Tốt: Format As/I want/So that + acceptance criteria cụ thể, testable. Mention edge cases. Tư duy rõ ràng về "done means what."
↳ Follow-up: "Khi dev xong nhưng bạn thấy không đúng với intent ban đầu — bạn làm gì?"
Sprint đang chạy, giữa chừng stakeholder yêu cầu thêm feature vì "urgent business need." Bạn xử lý thế nào?
→ Test: giữ được sprint goal hay bị scope creep?
✅ Tốt: "Assess impact — thêm X thì bỏ Y. Không thêm mà không bỏ. Nếu không urgent thực sự, đưa vào backlog sprint sau." Bảo vệ được sprint commitment.
🚨 Red flag: "Tôi sẽ cố gắng để team làm thêm" — add scope không có trade-off.
Bạn propose feature X nhưng tech lead nói "technically không feasible trong timeline." Bạn làm gì?
→ Test: có respect technical constraint không? Hay chỉ push deadline?
✅ Tốt: Ngồi với tech để hiểu constraint thực sự. Explore alternative approach. Co-create solution, không bypass.
↳ Follow-up: "Bạn có thể giải thích được cơ bản về REST API, database index, và tại sao cần cache không?"
Feature sắp release. Checklist launch của bạn gồm những gì? Ai cần được inform và theo thứ tự nào?
→ Test: có tư duy end-to-end không? Nhớ đến CS, Marketing, Sales không?
✅ Tốt: Staging test, regression, CS briefing, user comms, rollback plan, monitoring 24h đầu, baseline metrics trước launch để so sánh sau.
🚨 Pass: "Dev merge xong là release." — Không có awareness về downstream impact.
STAKEHOLDER MANAGEMENT — Quản lý kỳ vọng
CEO/CPO hỏi "feature đó bao giờ xong?" — thực tế team đang trễ 2 tuần. Bạn nói gì?
→ Test: honest hay overpromise? Có prep giải pháp kèm không?
✅ Tốt: Nói thật ngay: "Hiện trễ 2 tuần, dự kiến xong [date]. Nguyên nhân [X]. Tôi đang làm [Y] để minimize." Không giấu, không spin.
🚨 Pass: "Tôi sẽ nói đang cố gắng để on track." — Khi lộ ra mất trust hoàn toàn.
Sales muốn feature custom cho 1 khách lớn (30% revenue). Bạn thấy nó tạo technical debt và distract team. Bạn làm gì?
→ Test: biết balance business vs. product health không?
✅ Tốt: Không từ chối ngay, không đồng ý ngay. Evaluate: có thể generalize không? Negotiate với Sales về long-term cost. Bring data. Escalate với context nếu cần CEO quyết định.
↳ Follow-up: "Nếu CEO quyết định làm custom — bạn xử lý với team thế nào?"
Một stakeholder liên tục request feature nhỏ bypass backlog, nhắn trực tiếp cho dev. Bạn làm gì?
→ Test: có protect team process không? Có courage set boundary không?
✅ Tốt: Nói chuyện thẳng với stakeholder — explain process và tại sao nó tồn tại. Set expectation rõ. Loop in manager nếu tiếp tục tái phạm.
🚨 Red flag: "Tôi không muốn gây conflict." — PO sợ conflict không protect team được.
Bạn update tiến độ với CEO và với dev khác nhau như thế nào?
→ Test: biết adapt communication style không?
✅ Tốt: CEO → outcome/impact (số), business context. Dev → technical clarity, "why" behind decisions. Không dùng cùng 1 format. Kênh: weekly update, sprint demo, async doc.
DATA & METRICS — Tư duy đo lường
Bạn define success cho một feature như thế nào trước khi build? Và sau launch, bạn biết feature đó "thành công" hay "thất bại" dựa trên điều gì?
→ Test: có định nghĩa success criteria trước launch không?
✅ Tốt: Baseline + target + timeframe trước launch. Compare với baseline sau launch. Segment theo user group. Phân biệt correlation vs. causation.
🚨 Red flag: "Nhìn số click hoặc user feedback." — Vanity metrics, không có pre-defined criteria.
↳ Follow-up: "Feature nào bạn build mà data sau launch cho thấy bạn sai hoàn toàn về assumption?"
Bạn có kinh nghiệm A/B testing không? Kể về một lần A/B test cho kết quả bạn không expect. Bạn làm gì với kết quả đó?
→ Test: hiểu statistical significance không? Biết interpret kết quả phức tạp không?
✅ Tốt: Biết sample size, duration, confidence level. "Test failed = learning." Điều chỉnh hypothesis và test lại.
Số lượng publisher active tháng này giảm 15% so với tháng trước. Bạn điều tra như thế nào?
→ Test: có structured troubleshooting không? Biết drill down không?
✅ Tốt — structured: 1) Confirm data. 2) Segment loại publisher nào giảm. 3) External: policy/đối thủ? 4) Funnel: step nào giảm? 5) Hypothesis → verify → action.
🚨 Red flag: Đưa ra nguyên nhân ngay không hỏi thêm. Hoặc "tôi sẽ hỏi data team" — PO cần tự drill down.
Bạn được giao OKR "Tăng GMV publisher side 30% trong Q3." Bạn translate OKR đó thành product roadmap thế nào?
→ Test: biết link business goal với product initiative không?
✅ Tốt: Break down GMV = số publisher × conversion rate × avg payout. Identify lever nào tác động nhất. Map từng initiative với lever cụ thể. Không list feature random.
SELF-AWARENESS & GROWTH — Nhận thức bản thân
Kể về feature hoặc quyết định product tệ nhất bạn từng ra — không phải vì team không làm được, mà vì quyết định của bạn sai. Điều gì thay đổi sau đó?
→ Test: có honest về failure không? Có growth mindset không?
✅ Tốt: Câu chuyện cụ thể. Nhận accountability rõ. Hệ quả thực sự. Điều cụ thể thay đổi sau đó.
🚨 Immediate pass: Không nghĩ ra failure nào. Mọi failure đều do team/market. Không có gì thay đổi sau failure.
PO cần cân bằng nhiều thứ: strategy, execution, người, data, communication. Bạn yếu nhất ở đâu? Bạn đang làm gì để cải thiện?
→ Test: có self-awareness thực sự không?
✅ Tốt: Weakness thật (không phải "tôi hay perfectionist"). Có evidence cụ thể. Đang actively address bằng action cụ thể.
🚨 Red flag: "Tôi có xu hướng làm việc quá chăm chỉ." — Không tự biết điểm yếu.
3 năm nữa bạn muốn làm gì? ACCESSTRADE cần làm gì để giữ bạn ở đây đến 3 năm đó?
→ Test: kỳ vọng align không? Sẽ rời sớm vì lý do gì?
✅ Tốt: Nói được hướng grow cụ thể. Honest về điều gì sẽ giữ họ ở lại hay rời đi.
↳ Follow-up nếu muốn CPO trong 2 năm: "ACCESSTRADE hiện không có lộ trình đó — điều đó có thay đổi quyết định không?"
Bạn biết gì về affiliate marketing và publisher ecosystem? Bạn sẽ làm gì trong 30 ngày đầu để ramp up domain knowledge?
→ Test: đã chuẩn bị trước khi phỏng vấn chưa? Có learning agility không?
✅ Tốt: Đã research ACCESSTRADE và competitor. Có plan 30 ngày cụ thể: gặp publisher, ngồi với CS, theo dõi publisher journey, đọc về CPA/CPS mechanics.
🚨 Red flag: "Tôi sẽ học dần trong quá trình làm việc." — Không có proactive learning plan.
SCORESHEET — Chấm điểm tổng hợp
1 = Pass
2 = Mediocre
3 = Good
4 = Excellent
≥52 = Hire · 40–51 = Consider · <40 = Pass · Tối đa 64đ
| Năng lực | Tín hiệu chính cần quan sát |
|---|