"Outcomes over outputs" เป็นวลีที่แทบทุกคนในวงการ product ท่องได้ขึ้นใจ แต่พอต้องเอาไปใช้จริง มันกลับยากกว่าที่คิดมาก

ตัวแนวคิดมันเข้าใจไม่ยาก ตรงไปตรงมา คือ เราควรโฟกัสที่ impact ของสิ่งที่สร้างขึ้น ไม่ใช่แค่ ship feature ออกไปโดยไม่รู้ว่าผู้ใช้ต้องการหรือเปล่า

แต่ในโลกจริงมันไม่เคยขาวกับดำขนาดนั้น เพราะทีมเดียวกันที่ถูกสั่งให้ drive ด้วย "outcome" ก็มักโดนสั่งให้ส่ง "output ตามที่กำหนด" ไปพร้อมๆ กัน

ข้อมูลจาก CDH Benchmark survey ของ Product Talk สะท้อนภาพนี้ได้ชัดเจน:

มีทีม product เพียง 20% ที่บอกว่าตัวเองโฟกัสที่ outcome เป็นหลัก เกือบครึ่งหนึ่งบอกว่าทำงานแบบผสมทั้ง outcome และ output ส่วนอีกราว 30% ยังทำงานโดยยึด output เป็นหลัก

มองย้อนกลับไปในงานที่เราเจอส่วนใหญ่ ขับเคลื่อนด้วย output มากกว่า outcome ตัวอย่างที่เห็นได้ชัดเลย คือ Software House ที่รับงานพัฒนา software ให้แก่ลูกค้า พวกเขามีจุดคุ้มทุนอยู่ ถ้าหากใช้เวลานานเกินไป ต่อให้ได้ outcome ที่ดีกว่า ก็อาจมีปัญหาได้

บทความนี้จะเจาะให้ชัดว่า outcome กับ output ต่างกันตรงไหน ไล่ดูตัวอย่างหลายๆ อัน ซึ่งหลายอันจะเผยให้เห็นว่าสิ่งที่เราคิดว่าเป็น outcome จริงๆ แล้วเป็น output ที่ปลอมตัวมา พาไปสำรวจว่าทำไมการเปลี่ยนจาก output มาเป็น outcome ถึงยากนัก และปิดท้ายด้วยวิธีตั้ง outcome ที่ดีกว่าเดิมแบบลงมือทำได้จริง

นิยามง่าย ๆ ของ Outcome กับ Output ต่างกันยังไง

Output คือ สิ่งที่เราสร้างหรือผลิตขึ้นมา เช่น feature หนึ่งตัว โปรเจกต์หนึ่งอัน หรือ initiative หนึ่งเรื่อง มัน คือ สิ่งที่ทีม ship ออกไป

ส่วน Outcome คือ impact ของ output นั้น เช่น การเปลี่ยนแปลงพฤติกรรมของลูกค้า หรือ ผลลัพธ์ทางธุรกิจที่ตามมา

Josh Seiden สรุปไว้ในหนังสือ Outcomes Over Output ของเขาว่า

An outcome is a change in human behavior that drives business results.

จุดที่ควรแยกให้ออกต่อไป คือ business outcome กับ product outcome

Business outcome มักเป็น financial metric ที่วัดสุขภาพของธุรกิจ (เช่น เพิ่มรายได้ หรือลดต้นทุน)

ขณะที่ Product outcome วัดพฤติกรรมของลูกค้าใน product หรือ ความเชื่อมั่นที่ลูกค้ามีต่อ product

ลองดูตัวอย่างง่ายๆ บริษัท B2B จำนวนมากรองรับ integration หลายตัว integration พวกนี้คือ output การมี integration เฉยๆ ไม่ได้สร้าง value อะไรขึ้นมา แต่การที่ลูกค้าเข้าไปใช้แล้วเห็นว่ามันมีประโยชน์ต่างหากที่เป็น outcome และถ้าลูกค้าต่ออายุ subscription นานขึ้นเพราะ integration เหล่านั้น นั่นก็เป็น outcome เช่นกัน

หัวใจของเรื่องนี้อยู่ตรงประโยคเดียว คือ การสร้างของขึ้นมาไม่เท่ากับการสร้างคุณค่า (Value)

ทีมที่ขับเคลื่อนด้วย Outcome ต่างจากทีมที่ขับเคลื่อนด้วย Output อย่างไร

เวลาเรามอบหมายให้ทีมส่ง output ทีมจะถือว่างานเสร็จเมื่อ software ถูก ship ออกไป แต่เวลาเรามอบหมายให้ทีมส่ง outcome ทีมจะยังไม่เสร็จจนกว่า software จะถูก ship และ สร้าง impact ตามที่คาดหวังไว้ได้

ฟังดูเหมือนต่างกันนิดเดียว แต่มันเปลี่ยนแทบทุกอย่างในวิธีทำงานของทีม

Outputs Outcomes
วัดอะไร สิ่งที่เรา ship impact ของสิ่งที่เรา ship
ความอิสระของทีม ต่ำ — ถูกสั่งว่าต้องสร้างอะไร สูง — ถูกบอกว่าต้องบรรลุอะไร
รู้ได้ยังไงว่าเสร็จ ship แล้ว สร้าง impact ตามที่คาดได้แล้ว
Planning artifact feature roadmap opportunity solution tree

เมื่อทีมได้รับมอบหมายเป็น output ทีมแทบไม่มีพื้นที่ให้สำรวจว่าอะไร คือ ทางออกที่ดีที่สุด หน้าที่ของทีม คือ ทำตามแผนที่คนอื่นวางไว้

แต่เมื่อทีมได้รับมอบหมายเป็น outcome ทีมจะมีทั้งอิสระและความรับผิดชอบในการหาเส้นทางที่ดีที่สุดไปสู่ความสำเร็จเอง และนี่แหละ คือ ประตูที่เปิดไปสู่ product discovery ที่แท้จริง

ตัวอย่างที่ทำให้เห็นภาพ

วิธีที่ดีที่สุดในการเข้าใจความต่างนี้ คือ ดูจากตัวอย่าง เราจะเริ่มจากอันที่ชัดเจน แล้วค่อยขยับไปอันที่ยากขึ้น

ตัวอย่าง: "Outcome ของเรา คือ deliver Android app"

Android app เป็นสิ่งที่เราสร้างและ ship ออกไป อันนี้มัน คือ output ชัดๆ

ถ้าจะขยับให้เป็น outcome เราอาจถามว่า "การมี Android app มันมี value ยังไง" หรือ "เราจะรู้ได้ยังไงว่า Android app ตัวนี้ประสบความสำเร็จ"

คำตอบอาจเป็น "การมี Android app จะช่วยให้เรา engage ผู้ใช้ได้มากขึ้น และเราจะรู้ว่ามันสำเร็จเมื่อคนเข้ามาใช้ app อย่างสม่ำเสมอ"

คำตอบนี้มันช่วยเผยให้เห็น outcome ที่ซ่อนอยู่ออกมา คือ "engage คนให้มากขึ้น"

จากตรงนี้เราจึงถามต่อได้ว่า เป้าหมายของเรา คือ engage ลูกค้าแบบไหนก็ได้ หรือ ลูกค้าที่ใช้ mobile หรือเฉพาะผู้ใช้ Android ที่มี value นี้เป็นพิเศษกันแน่

การตั้งคำถามแบบนี้ช่วยให้เรากำหนด outcome ในขอบเขต (scope) ที่ถูกต้อง เราอาจเลือกอย่างใดอย่างหนึ่งต่อไปนี้:

  • เพิ่มสัดส่วนผู้ใช้ที่ engage บนทุก platform
  • เพิ่มสัดส่วนผู้ใช้ mobile ที่ engage
  • เพิ่มสัดส่วนผู้ใช้ Android ที่ engage

ไม่ว่าจะเลือก scope ไหน outcome เหล่านี้ ก็ให้พื้นที่ให้เราสำรวจได้มากกว่าการสั่งให้ "สร้าง Android app" เฉยๆ เพราะบางทีเราอาจไม่ต้องมี Android app เลยด้วยซ้ำ เราอาจ engage ผู้ใช้ Android ผ่านเว็บที่รองรับ mobile หรือผ่าน email inbox ของพวกเขาเลยก็ได้

และมันยังทำให้เราต้องรับผิดชอบต่อผลลัพธ์จริงๆ เพราะเราไม่ได้สำเร็จ เมื่อสร้าง Android app เสร็จ แต่เราสำเร็จเมื่อเรา engage คนที่ใช่ได้แล้วต่างหาก

ตัวอย่างที่หลอกแม้แต่ทีมเก๋าๆ: metric ที่ดูเป็น outcome แต่ไม่ใช่

<!– 🖼️ [รูปที่ 4] — รายการกับดักในการวัด outcome 4 แบบ: วัดผิดจังหวะ, output ที่ปลอมเป็น outcome, กับดัก traction และการพึ่ง sentiment metric อย่างเดียว -->

ตัวอย่างต่อไปนี้มักหลอกทีมที่มีประสบการณ์ มันดูเหมือน outcome เป็นตัวเลข วัดได้ แต่จริงๆ แล้วไม่ได้วัด impact เลย

วัดจังหวะที่เกิด value จริง: นับจำนวน "คนได้งาน" ไม่ใช่แค่ "คนสมัครงาน"

เวลาตั้ง outcome เรามักเผลอไปโฟกัสที่ metric ที่วัดง่ายที่สุด แต่ outcome ที่ดี ต้องวัด value ที่ลูกค้าได้รับจากการใช้ product ของเรา

สมมติว่าเราได้ไปทำงานในบริษัทที่ช่วยเด็กจบใหม่หางานแรกได้ ตอนเราเข้าไป outcome หลัก คือ "เพิ่มจำนวนใบสมัครงาน" ซึ่งในทางเทคนิคมันก็เป็น outcome แหละ เพราะมันวัดพฤติกรรมเฉพาะอย่างใน product ได้

แต่มันไม่ได้วัดจังหวะที่เกิด value จริงๆ เพราะคนหางานไม่ได้ value ตอน สมัครงาน แต่จะได้ value ก็ต่อเมื่อ ได้งาน แล้วต่างหาก

เช่นเดียวกัน นายจ้างไม่ได้ value จากผู้สมัคร คนไหนก็ได้ แต่ได้ value เมื่อ ผู้สมัครที่ใช่ เข้ามาสมัคร

job board หลายเจ้าพยายามวัด "ผู้สมัครที่มีคุณสมบัติ" แทนที่จะนับผู้สมัครทุกคน โดยเทียบคุณสมบัติของผู้สมัครกับ job description แล้วนับเฉพาะคนที่ผ่าน วิธีนี้มันดีกว่า แต่ก็ยังไม่ใช่การวัดจังหวะที่เกิด value อยู่ดี เพราะทั้งคนหางานและนายจ้างจะได้ value ก็ต่อเมื่อตำแหน่งงานที่เปิดถูกเติมเต็มสำเร็จ metric ที่ถูกต้อง คือ "จำนวนคนที่ได้งาน" (hires)

จริงอยู่ที่มีเหตุผลเชิงระบบมากมายที่ทำให้ hires วัดยาก จังหวะที่เกิด value ไม่ได้เกิดบนเว็บ แต่เกิดทีหลังมาก — หลังสัมภาษณ์ หลังยื่นข้อเสนอ หลังผู้สมัครตอบรับ คนที่เพิ่งได้งานก็ไม่ต้องใช้บริการอีกแล้วและไม่น่ากลับมาปิด loop ให้ ส่วนนายจ้างก็กลัวจะบอก job board ว่าจ้างใครไปแล้ว เพราะกลัวโดนขึ้นราคา มันไม่ใช่ metric ที่วัดง่ายเลย

แต่ metric ที่วัดง่ายไม่ได้แปลว่าเป็น outcome ที่ถูกต้องเสมอไป จงพยายามวัดจังหวะที่เกิด value จริง แม้มันจะเกิดขึ้นนอกบริการของเราก็ตาม

วัด impact ไม่ใช่ output ที่ผู้ใช้สร้าง: กับดัก reviews course

ถ้าใครเคยทำงานในบริษัทที่ทำเกี่ยวกับการเรียนการสอน คงเคยเจอกับการ review การสอน หรือ course

สมมติ ว่า ทีมนี้ตั้ง outcome ว่า "เพิ่มจำนวน reviews course บน platform"

ฟังดูเป็น outcome ใช่ไหม มันเป็น metric วัดได้ และเป็น action ที่ผู้ใช้ทำบนเว็บ — การเขียน review นั้น จริงๆ แล้วมัน คือ output ที่ปลอมตัวมา

Review จะมี value ก็ต่อเมื่อมันช่วยให้ผู้เรียนประเมิน course ได้ ถ้าผู้เรียนไม่เคยเห็นรีวิวเลย มันก็ไม่ได้สร้าง value อะไร การที่มี review เยอะขึ้นไม่ได้แปลว่าดีขึ้นเสมอไป ลองนึกภาพว่า review ทั้งหมดไปกระจุกอยู่ที่หน้า course ที่ไม่มีใครเคยเข้าดูเลย มันก็ไม่ได้สร้าง value เท่าไหร่

ดังนั้น การเพิ่มจำนวน reviews course บน platform มันคือ output ในกรณีนี้เป็น output ที่ผู้ใช้ของเราสร้างขึ้น ซึ่ง output นี้ สร้าง value ได้จริง แต่เฉพาะเมื่อผู้ใช้คนอื่นได้เห็นและได้ประโยชน์จากมันเท่านั้น

outcome ที่ดีกว่า คือ "เพิ่มจำนวนการดูคอร์ส (course views) ที่มี views ประกอบ"

เริ่มมองเห็นความต่างไหม อันแรกวัดสิ่งที่ผู้ใช้ผลิต (review) ส่วนอันที่ 2 วัด impact ต่อประสบการณ์ของลูกค้า (การได้เห็น course ที่มี review ตอนกำลังตัดสินใจ)

วิธีทดสอบว่าอะไรเป็น output หรือ outcome คือ ถามถึง impact ที่มันจะสร้าง ถ้าเราทำ metric นั้น ให้บรรลุได้โดยไม่ได้ช่วยลูกค้าจริงๆ มันก็น่าจะเป็น output ที่ปลอมตัวมา

วัดความสำเร็จ ไม่ใช่แค่การ adopt feature: กับดัก traction metric

"เพิ่มสัดส่วนผู้ใช้ที่เข้าดู performance report"

อันนี้ดูเหมือน outcome ที่ดี มันวัดพฤติกรรมเฉพาะอย่างใน product และอยู่ในการควบคุมของทีม แต่มัน คือ สิ่งที่เรียกว่า traction metric — หมายถึง วัดการ adopt ของ feature ตัวเดียว ไม่ใช่ value ที่ลูกค้าได้รับ

💡
Traction Metric คือ ตัวชี้วัดความเติบโตและผลตอบรับจากตลาด ของธุรกิจหรือสตาร์ทอัป เป็นเครื่องพิสูจน์ว่าผลิตภัณฑ์หรือบริการของคุณกำลังได้รับความนิยม มีลูกค้าใช้งานจริง และมีแนวโน้มที่จะประสบความสำเร็จในอนาคต

การใช้ traction metric เป็น outcome หลัก มีปัญหา 2 อย่าง คือ

  1. คนจำนวนมากอาจเข้าดู performance report แต่ไม่เจอสิ่งที่ต้องการ metric นี้วัดการใช้งาน แต่ไม่ได้วัดว่าการใช้งานนั้นสำเร็จหรือเปล่า
  2. เราอาจมีลูกค้าที่มีความสุขดีอยู่แล้วโดยไม่ต้องใช้ performance report เลย ถ้าเป็นแบบนั้น สิ่งสุดท้ายที่เราควรทำ คือ การไล่ให้เขาไปใช้ feature ที่เขาไม่ได้ต้องการ

เมื่อเราวัดจังหวะที่เกิด value แทนการวัด feature adoption เราจะวัดสิ่งที่ลูกค้าต้องการ ไม่ใช่สิ่งที่เราอยากให้เขาทำ

จับคู่ sentiment metric กับ behavior metric

โดยทั่วไปแล้ว product outcome เป็น metric ที่วัดอย่างใดอย่างหนึ่งใน

  1. พฤติกรรมเฉพาะใน product
  2. ความรู้สึก ความคิดเห็น ทัศนคติ หรืออารมณ์ (sentiment) ที่มีต่อ product แต่ sentiment metric อย่าง CSAT หรือ NPS มันมีความ tricky อยู่ เวลาใช้ลำพัง

sentiment metric เป็น outcome ก็จริง แต่มันไม่ได้บอกทิศทาง มันไม่ได้บอกว่าเราควรไปสำรวจตรงไหน และไม่ได้ตั้ง guardrail ว่าตรงไหนที่ไม่ควรไป ผลก็ คือ เราไม่รู้ว่าจะโฟกัสตรงไหน

แทนที่จะเลือก sentiment metric อย่างเดียว เราจะจับคู่มันกับพฤติกรรม เช่น "เพิ่ม engagement โดยไม่ทำให้ความพึงพอใจ (satisfaction) แย่ลง" โดยใช้ sentiment metric เป็นตัวถ่วงดุล

Facebook กับ Instagram เป็นตัวอย่างชั้นดีที่ทำเห็นภาพว่า ทำไมวิธีนี้ถึงมีประโยชน์

Meta เก่งมากในการขับ engagement แต่เก่งจนเกินพอดี หลายคนไม่ชอบที่ product พวกนี้มันเสพติดได้ (ผมก็เป็นหนึ่งในนั้น) ถ้า Meta จับคู่ engagement กับ sentiment metric เช่น เพิ่ม engagement เฉพาะระดับที่ satisfaction ยังไม่แย่ลง แทนที่จะไล่ engagement แบบไม่คิดหน้าคิดหลัง จะได้ประโยชน์กว่านี้

ทำไมเรื่องนี้มันถึงยาก

ถ้าการแยก outcome กับ output มันง่าย ทุกคนคงเปลี่ยนไปแล้ว แต่มันมีเหตุผลเชิงโครงสร้างจริงๆ ที่ทำให้ทีมติดขัด

วงจรความไว้ใจ (the trust cycle)

manager ไม่ไว้ใจว่าทีมจะไปถึง outcome ได้เอง ก็เลย micromanage ตัว output ส่วนทีมเองก็ไม่ได้สื่อสารความคืบหน้าไปสู่ outcome แต่รายงานความคืบหน้าของ feature แทน ซึ่งยิ่งตอกย้ำความเชื่อของ manager ว่าตัวเองต้องคอยลงรายละเอียด กลายเป็นวงจรอุบาทว์วนไป

การจะทลายวงจรนี้ ต้องอาศัยความพยายามจากทั้ง 2 ฝั่ง ทีมต้องเรียนรู้ที่จะ "show their work" ซึ่งมันไม่ใช่แค่นำเสนอข้อสรุป แต่พา stakeholder เดินผ่านกระบวนการคิดที่นำไปสู่ข้อสรุปนั้น ส่วน manager ก็ต้องเรียนรู้ที่จะให้ feedback ต่อ วิธีคิด ไม่ใช่แค่ตอบสนองต่อ solution ที่เห็น

กับดัก accountability

เมื่อ performance review ถูกผูกกับการทำ outcome ให้สำเร็จ ทีมจะเล่น safe ตั้งเป้าแบบ sandbag (ตั้งเป้าต่ำๆ ไว้ก่อน) แล้วก็แอบเอา output มาปลอมเป็น outcome เพื่อการันตีว่าจะ "สำเร็จ" ซึ่งทำลายเจตนารมณ์ทั้งหมดของเรื่องนี้

ดังนั้นแนะนำให้มอง outcome เป็นโอกาสในการเรียนรู้ โดยเฉพาะในช่วงแรก เมื่อทีมเริ่มทำ outcome ใหม่ ให้ตั้ง learning goal — "เรียนรู้ว่าอะไรขยับ metric นี้ได้" — ก่อนจะตั้ง performance goal — "เพิ่ม X ขึ้น Y%"

วิธีนี้ให้พื้นที่ทีมได้สำรวจโดยไม่ต้องแบกความกดดันที่จะต้องส่งผลลัพธ์ทันที

จะเริ่มตั้ง Outcome ที่ดีได้ยังไง

ถ้าอยากเปลี่ยนจาก output มาเป็น outcome นี่คือ ขั้นตอนที่เราสามารถลงมือทำได้จริง

1.แปลง business outcome เป็น product outcome

business outcome อย่างรายได้ retention หรือ market share เป็น lagging indicator กว่าเราจะเห็นตัวเลข ก็สายเกินจะทำอะไรแล้ว ส่วน product outcome วัดการเปลี่ยนพฤติกรรมภายใน product ที่ นำไปสู่ ผลลัพธ์ทางธุรกิจเหล่านั้น มันคือ leading indicator ที่อยู่ในการควบคุมของทีม

2.ต่อรอง outcome กับทีม

การตั้ง outcome ควรเป็นบทสนทนา 2 ทาง ผู้นำนำมุมมองภาพรวมทั้งธุรกิจว่า ธุรกิจต้องการอะไร ส่วนทีมนำความรู้เรื่องลูกค้า และ technology มา พร้อมสื่อสารว่า เชื่อว่าตัวเองขยับ metric ได้แค่ไหน ไม่มีฝ่ายไหนควรสั่งการฝ่ายเดียว

3.คาดหวังไว้ว่าต้องปรับปรุงตัวชี้วัด

metric แรกที่ตั้งมักจะยังไม่ถูก มันเป็นเรื่องปกติ เราจำเป็นต้องปรับปรุงตัวชี้วัดหลายรอบ เวลาตั้ง metric เพื่อวัด business outcome มันจำเป็นต้องย่อยลงไปหลายรอบจึงจะเจอ metric ที่ใช่จริงๆ สิ่งนี้ เป็นส่วนหนึ่งของกระบวนการ ไม่ใช่ ความล้มเหลว

4.ระวังข้อผิดพลาดที่พบบ่อย

output ที่ปลอมเป็น outcome, traction metric ที่แอบอ้างว่าเป็น product outcome, sentiment metric ที่ไม่มีทิศทาง และ business outcome ที่ถูกโยนตรงๆ ไปให้ product team รับผิดชอบ สิ่งเหล่านี้ คือ จุดที่ต้องระมัดระวัง

5.ลงลึกต่อ

เรื่อง outcome ยังมีรายละเอียดอีกเยอะ เช่น ควรใช้เวลากับ outcome หนึ่งนานแค่ไหน ทีมหนึ่งทำ outcome พร้อมกันได้กี่อัน และ outcome เปลี่ยนไปตามเวลาอย่างไร รวมถึงถ้าองค์กรใช้ OKRs ก็ควรทำความเข้าใจว่า OKRs กับ outcome สัมพันธ์กันยังไง สิ่งเหล่านี้ แต่ละบริษัทจะต้องเอาไปคิดต่อ เนื่องจากแต่ละที่มักมีจุดที่สนใจต่างกัน จึงยากที่จะบอกได้หมด

สรุป

การเปลี่ยนจาก mindset ที่เอา output เป็นตัวตั้ง มาเป็น mindset ที่เอา outcome เป็นตัวตั้ง ไม่ได้แปลว่า output จะหมดความสำคัญ product team จะยังต้อง delivery feature อยู่เสมอ และความสามารถในการ delivery ได้เร็ว โดยคงคุณภาพก็เป็นเรื่องสำคัญมาก การเปลี่ยนครั้งนี้เป็นเรื่องของการทำให้แน่ใจว่า feature เหล่านั้นสร้าง impact ตามที่ตั้งใจไว้จริงๆ เราไม่ได้เสร็จเมื่อ delivery แต่เราทำมันเสร็จเมื่อสิ่งที่เรา delivery ออกไปสร้าง impact ตามที่ตั้งใจได้

เมื่อเราวัดความสำเร็จด้วยสิ่งที่ delivery ออกไป เราจะได้ feature factory แต่เมื่อเราวัดความสำเร็จด้วย impact ของสิ่งที่ delivery เราจะได้ product team ที่เรียนรู้ ปรับตัว และสร้าง value ที่แท้จริง

Reference: