เวลาดู OKR ของทีม product ส่วนใหญ่ที่องค์กรเขียนกันมา 80% ของ Key Results คือรายการ feature ที่จะ ship ในไตรมาสนี้ — “launch onboarding v2”, “ship dashboard module”, “release mobile app” — ทั้งหมดนี้ไม่ใช่ Key Result แต่เป็น output ของ roadmap ที่ถูก copy ลงใน OKR template เฉย ๆ ปัญหาคือเมื่อสิ้นไตรมาส ทีมจะตอบไม่ได้ว่า “feature ที่ ship ไปสร้าง outcome อะไรกับ user หรือ business” ได้บ้าง ship ครบทุก feature = OKR 1.0 แต่ adoption ไม่ขยับเลย — นี่คืออาการคลาสสิกของ feature factory ที่ใส่เสื้อ OKR
ทำไม OKR ของ Product Team มักล้มเหลว
หลังจากช่วยทีม product หลายแห่งวาง OKR ใหม่ — รูปแบบความล้มเหลวซ้ำ ๆ มี 4 แบบ และเกือบทั้งหมดมีรากปัญหาเดียวกันคือ สับสนระหว่าง output กับ outcome
1. Feature Factory Trap — ทีมตั้ง KR ว่า “ship 3 features ใน Q2” ซึ่งแปลว่าทีม ship เสร็จก็ปิด KR ได้ทันที ไม่ว่า user จะใช้หรือไม่ ผลลัพธ์: roadmap ถูก execute ตามแผน แต่ product metrics นิ่ง
2. KR เป็น “ship X” แทนที่จะเป็น “เพิ่ม adoption Y%” — Key Result ที่ดีต้องวัดสิ่งที่ user ทำหลังจาก feature ถูก ship ไม่ใช่วัดว่าทีมส่ง code ไปแล้วหรือยัง การเขียน “launch payment module” คือ milestone ไม่ใช่ outcome — outcome คือ “% ของ user ที่ใช้ payment ภายใน 14 วัน”
3. ไม่มี Leading Indicator — Product KR ส่วนใหญ่เป็น lagging metric (retention 90 วัน, NPS, MRR) ซึ่งกว่าจะเห็นผลก็สิ้นไตรมาสไปแล้ว ทีมที่ไม่ตั้ง leading indicator (activation rate, time-to-first-value, week-1 retention) ไว้ด้วย จะรู้ว่า OKR fail ตอนสายเกินแก้
4. Roadmap = OKR Confusion — บาง PM เอา Jira epic list มาแปะเป็น Key Results โดยตรง สิ่งที่เกิดขึ้นคือ roadmap กลายเป็น OKR และ OKR กลายเป็น project plan — ทีมหมด leverage ในการตัดทิ้ง feature ที่ไม่สร้าง outcome เพราะมันถูกผูกเป็น KR ไปแล้ว ทำไม OKR ล้มเหลว ในบริบทอื่นก็มีรากเดียวกัน — KR ไม่วัด outcome จริง
ตัวอย่าง OKR สำหรับ Product Team
ด้านล่างคือ 4 OKR sets ที่แยกตามบทบาทของ Product Manager แต่ละแบบ — ใช้ตัวเลขจริงจาก benchmark SaaS / consumer app เพื่อให้เห็นรูปทรงของ KR ที่วัด outcome ได้
1. Growth / Adoption PM
| Type | Statement |
|---|---|
| Objective | เพิ่ม adoption ของ product core feature ในกลุ่ม user ใหม่ |
| KR1 | เพิ่ม activation rate (user ที่ทำ key action ภายใน 7 วันแรก) จาก 32% → 50% |
| KR2 | ลด time-to-first-value จาก 18 นาที → 8 นาที (median) |
| KR3 | เพิ่ม week-1 retention curve จาก 41% → 55% |
2. Retention PM
| Type | Statement |
|---|---|
| Objective | สร้าง habit loop ที่ทำให้ paying user ใช้ product สม่ำเสมอ |
| KR1 | เพิ่ม 30-day retention ของ paid cohort จาก 62% → 75% |
| KR2 | เพิ่ม DAU/MAU ratio จาก 0.21 → 0.32 (วัด stickiness จริง ไม่ใช่ DAU เปล่า) |
| KR3 | ลด churn rate ใน paid plan tier จาก 6.8%/mo → 4.0%/mo |
3. Platform / Infrastructure PM
| Type | Statement |
|---|---|
| Objective | ทำให้ developer และทีมภายในใช้ platform ได้เร็วขึ้นและเสถียรขึ้น |
| KR1 | ลด p95 API response latency จาก 850ms → 350ms |
| KR2 | เพิ่ม internal API adoption จาก 4 ทีม → 9 ทีม (มี call จริง > 1,000/สัปดาห์) |
| KR3 | ลด integration onboarding time ของทีมใหม่จาก 12 วัน → 4 วัน |
4. New Product / 0→1 PM
| Type | Statement |
|---|---|
| Objective | พิสูจน์ product-market fit ของ product ใหม่ใน segment เป้าหมาย |
| KR1 | ได้ paying customer แรก 25 ราย ใน segment SMB (>5 seats) |
| KR2 | Sean Ellis PMF survey: “very disappointed if product disappears” ≥ 40% |
| KR3 | Week-4 retention ของ active beta cohort ≥ 35% |
สังเกตว่าไม่มี KR ไหนเขียนว่า “ship feature X” — ทุก KR วัดสิ่งที่ user หรือ business ทำหลังจาก feature ถูกใช้งาน feature คือ input ของ KR ไม่ใช่ KR เอง — ดูตัวอย่างเพิ่มเติมที่ ตั้งและติดตาม OKRs อย่างมีประสิทธิภาพ
วิธีให้คะแนน OKR ของ Product Team
Product OKR ใช้ scoring scale 0.0–1.0 เหมือนทีมอื่น แต่มีความซับซ้อนเพิ่มขึ้นอีกชั้นคือ noisy signal — metric ที่วัดได้ในไตรมาสเดียวมักได้รับผลกระทบจากตัวแปรภายนอก (seasonality, marketing campaign, market change) จึงต้องดูทั้ง achievement และ confidence ควบคู่กัน
ตัวอย่างการคำนวณ — Growth PM ตอนสิ้น Q2:
| KR | เป้า | ผลจริง | คะแนน |
|---|---|---|---|
| KR1: Activation rate 32% → 50% | +18 pp | +12 pp (ได้ 44%) | 0.67 |
| KR2: Time-to-first-value 18 → 8 นาที | −10 นาที | −6 นาที (ได้ 12 นาที) | 0.60 |
| KR3: Week-1 retention 41% → 55% | +14 pp | +15 pp (ได้ 56%) | 1.00 |
OKR score = (0.67 + 0.60 + 1.00) / 3 = 0.76 ซึ่งอยู่ใน healthy zone ของ stretch goal (0.6–0.8)
สิ่งที่ทีม product ต้องเพิ่มเติมจาก scoring ปกติคือ confidence rating — แต่ละสัปดาห์ PM ควรให้ confidence score (1–10) ว่า KR จะ hit หรือไม่ ถ้า confidence ต่ำกว่า 5 ต่อเนื่อง 2 สัปดาห์ = ต้องคุยกันว่า assumption พังตรงไหน ไม่ใช่รอจนสิ้นไตรมาสค่อยมาดูคะแนน — รายละเอียด framework ดูได้ที่ OKR Scoring Method
Weekly Check-in สำหรับทีม Product
Product team ต้อง check-in สัปดาห์ละครั้ง 30 นาที — ไม่ใช่ทุกเดือนหรือทุกไตรมาส เหตุผลคือ user signal เปลี่ยนเร็วและการรอ 4 สัปดาห์เพื่อเห็น metric movement = ช้าเกินแก้แล้ว
คำถามที่ควรถามใน weekly check-in (เฉพาะทีม product):
- KR แต่ละตัวขยับไปทางไหนเทียบกับสัปดาห์ที่แล้ว — และขยับเพราะอะไร (feature ใหม่ / campaign / external factor)?
- User signal ใหม่อะไรที่เห็นสัปดาห์นี้ที่อาจกระทบ KR (support ticket, NPS comment, session recording, sales call feedback)?
- Confidence rating ของ KR แต่ละตัวเปลี่ยนไหม — ถ้าลดลง เพราะ assumption ตัวไหนเริ่มไม่จริง?
- Experiment / feature ที่ ship สัปดาห์นี้ส่งผลต่อ leading indicator ไหม (activation, time-to-value)?
- มี KR ตัวไหนที่ควร kill หรือเปลี่ยน definition เพราะ data บอกว่าวัดผิดสิ่ง?
ที่สำคัญคือ check-in ของ product ต้องดู dashboard จริงของ product analytics (Mixpanel, Amplitude, internal BI) ระหว่างประชุม ไม่ใช่ดูแต่ Notion / สเปรดชีตที่ PM อัปเดตเอง — เพราะตัวเลขที่ PM พิมพ์เข้าไปกับตัวเลขที่ระบบเก็บได้มักไม่ตรงกัน — โครงสร้าง agenda เต็ม ๆ ดูที่ Weekly OKR Check-in Template
5 ข้อผิดพลาดที่เจอบ่อยใน Product OKR
1. Feature-as-KR — เขียน “ship feature X” เป็น Key Result ผลคือทีม ship เสร็จได้ 1.0 ทันทีโดยไม่สนใจว่ามีคนใช้หรือไม่ แก้ด้วยการเขียน KR เป็น metric ที่ user ทำหลัง feature ถูกใช้งานเท่านั้น
2. No Instrumentation — ตั้ง KR ว่าจะวัด activation rate แต่ไม่มี event tracking รองรับใน product ผลคือสิ้นไตรมาสมาเก็บข้อมูลย้อนหลังไม่ได้ ก่อนเซ็ต KR ใด ๆ ต้องเช็คก่อนว่า analytics infra วัดได้จริง
3. Vanity DAU — ใช้ DAU / MAU เป็น KR โดยไม่แยก segment ทำให้ตัวเลขขยับเพราะ marketing campaign ไม่ใช่เพราะ product ดีขึ้น KR ที่ดีต้องลึกลงไปถึง retained DAU หรือ active DAU within paid cohort
4. Roadmap Drift — เริ่มไตรมาสด้วย OKR ที่ชัด พอเข้าสัปดาห์ที่ 4 ทีมเริ่มทำ feature นอกแผนเพราะ stakeholder ขอ — KR เดิมถูกทิ้งโดยไม่ revise OKR ก่อน ต้องมี kill criteria และกระบวนการแก้ OKR ระหว่างไตรมาสที่ชัดเจน
5. No Kill Criteria — ไม่มีเงื่อนไขว่าจะหยุด project / KR ตอนไหน ผลคือทีมทุ่มแรงกับ KR ที่ data บอกแล้วว่าไม่ work เพราะกลัวเสียหน้า — ตั้ง criteria ตั้งแต่ต้น เช่น “ถ้า activation rate ไม่ขยับใน 4 สัปดาห์ จะ pivot KR”
สรุป
OKR ของ Product Team ที่ใช้ได้จริงต้องวัด outcome ที่ user หรือ business ได้รับ ไม่ใช่นับ feature ที่ ship — ทุก KR ต้องตอบได้ว่า “ถ้าตัวเลขนี้ขยับ แปลว่า product สร้าง value มากขึ้นจริงในมุมไหน” และต้องมี leading indicator ให้ทีมเห็น signal ก่อน lagging metric จะมาถึง
คำถามทิ้งท้าย: Product team ของคุณวัด outcome (adoption, retention) หรือแค่ output (features ที่ ship)? ถ้าคำตอบคือ output — ก้าวต่อไปคือสร้าง outcome dashboard ที่ทีมเห็น activation, retention, time-to-value แบบ real-time ไม่ใช่รอ deck รายเดือน