การเดินทางจาก Strategy สู่ Product Roadmap

ในแต่ละปี Product Owner จะต้องมีสิ่งที่เรียกว่า Product Roadmap ที่ถูกวางไว้ว่า แต่ละปี (เป็นอย่างต่ำ) จะต้องทำอะไรบ้าง ต้องทำฟีเจอร์ไหนบ้าง หรือต้องปรับปรุงส่วนไหน

ตอนที่ผมทำงานอยู่กับบริษัท startup ผมจะต้องวางแผน product roadmap กับน้องๆ ในทีมเสมอทำให้ผมเห็นภาพใหญ่ ที่มาที่ไปของมัน แต่พอเข้ามาในบริษัทที่ใหญ่ขึ้น ภาพใหญ่ตรงนี้อาจส่งไปไม่ถึงระดับ operation ทำให้หลายๆ ครั้ง คนทำงานไม่รู้ที่มาที่ไปของการเอา features นี้เข้ามา

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

บทความนี้จะมาเล่าที่มาที่ไปของ Product Roadmap ว่า ก่อนที่จะเป็น Product Roadmap นั้น มันเริ่มมาจากไหน ซึ่งเนื้อหาในบทความนี้มาจาก Product Management: Accelerated by Stanford School of Engineering และ บวกประสบการณ์ของผมเข้าไปด้วย เพราะมันคล้ายๆ กันเลย

Objectives to Strategy

ก่อนที่จะสร้าง Product Roadmap ได้ เราต้องมี Product Strategy ก่อน แต่เรามักจะเห็น หลายๆ บริษัทอาจสร้าง Product Roadmap ก่อน จากนั้นจึง Product Strategies จากแผนดังกล่าว ซึ่งจริงๆ แล้วการทํางานกลับกัน และ ไม่แนะนํา

บริษัทต้องมีวัตถุประสงค์ที่ชัดเจน วัตถุประสงค์ (Objectives) ซึ่งมันจะไปตอบ เป้าหมายของบริษัท (Goal) อีกทีนึง

อย่างบริษัทเก่าที่ผมทำงานอยู่เราจะมีการมาคุย Goal ของบริษัทกันเลยว่า เรามีเป้าหมายจะพาบริษัทไปยังจุดไหน เช่น อีก 2 ปี เราจะเริ่ม Rise Funding Series B

ดังนั้น เพื่อให้ hit เป้าหมายนี้ เราจะต้องทำอะไรบ้าง ไล่ลงไปเรื่อยๆ แต่ละฝ่าย หรือ แผนกก็จะต้องวางแผนของตัวเองเพื่อให้ตอบโจทย์ของบริษัทด้วยเช่นกัน อีกทั้งบางอย่างอาจจะต้องมีการร่วมมือกันข้ามฝ่าย ซึ่งถ้าพูดกันในภาพใหญ่ทั้งบริษัท มันซับซ้อนหน่อย ในบทความนี้เลยโฟกัสไปที่ product อย่างเดียว

เสริม...

ถ้าเรากำหนดเป้าหมายร่วมกันได้ ก็ค่อยเอาตัวชี้วัดเข้ามาใส่ ซึ่งมันก็จะเป็น OKRs หรือ KPIs นั้นแหละ...

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

Objectives

ถ้ามาเจาะลึกลงไปที่ objectives อีกหน่อย ก็จะบอกได้ว่า ในระดับนี้ มันคือ ระดับของ Vision ซึ่งเป็นการมองหา ไอเดีย (Idea) หรือ โอกาศ (Opportunity) ใหม่ๆ เพื่อนำมาปรับปรุง product ให้ดีขึ้น และยังรวมไปถึงการมองหา product ใหม่ๆ ด้วยเช่นกัน

From Strategy to Product Roadmap

มาเข้าเรื่องหลักของเรากัน มาดูกันว่า เราจะเปลี่ยน objectives เป็น product roadmap กันยังไง

โดยการเปลี่ยนจาก Strategy เป็น product roadmap นั้นจะมีอยู่ด้วยกัน 6 ขั้นตอน คือ

1. Company Strategies
2. Divide each strategy
3. Write the hypothesis
4. Prioritize
5. Develop a product strategy
6. Develop a product roadmap

เรามาเจาะลงไปแต่ละข้อกัน...

Objectives

บริษัทต้องกำหนด Objectives มาก่อนว่าปีนี้จะทำอะไร ถ้าให้ดีวางแผนว่าปีหน้าจะทำอะไร ซึ่งจะวางแผนกันช่วง Q4 แล้วค่อยมาปรับแผนเอาระหว่างทาง

ตัวอย่าง เช่น การเพิ่มรายได้, การเพิ่มยอด Transactions หรือ ลดค่าใช้จ่าย Operations เป็นต้น

แต่เราต้องระบุให้ชัดเจนว่า ที่เราต้องการนั้นเป็นตัวเลขเท่าไหร่ (อย่าใส่มาลอยๆ แบบตัวอย่างด้านบนนะ)

เช่น ปีนี้บริษัทต้องการมีรายได้ 50 ล้านบาท ซึ่งเป็น 2 เท่า ถ้าเทียบกับปีที่แล้ว เป็นต้น

พยายามระบุออกมาเป็นตัวเลขให้ชัดๆ เพื่อให้ง่ายต่อการวัดผล จากนั้นเราจะหยิบเอาแต่ละเรื่องไปลงรายละเอียดกัน

เมื่อเราได้ objectives แล้ว เราก็หยิบแต่ละตัวพอไปลงรายละเอียดใน step ถัดไป...

Step 1: ระบุ Company Strategies

หลังจากวิเคราะห์กลยุทธ์ของบริษัทแล้ว เราสามารถเริ่มแบ่งกลยุทธ์ออกเป็นของแต่ละ Product ได้ ซึ่งในบทความนี้จะโฟกัสไปที่ product แค่ตัวเดียว

ขั้นตอนแรกสําหรับ Product Owner / Product manager คือ การระบุกลยุทธ์ของบริษัทที่เกี่ยวข้องให้ได้มากที่สุด และหยิบเอามาสัก 3-5 กลยุทธ์ที่เกี่ยวข้องกับ Product นั้นๆ

ที่เราโฟกัสแค่ 3-5 กลยุทธ์ เพราะถ้าเรามาพิจารณาทุกข้อ มันจะเยอะเกินไป ดังนั้นเราจำเป็นต้อง จัดลําดับความสําคัญ ของกลยุทธ์เหล่านั้นด้วย

โดยการเขียนกลยุทธ์ของเรานั้น ต้องจะมี 2 อย่าง คือ

1. เรียบง่ายและรัดกุม (Simple and Concise)
2. จะอธิบายแบบ High Level Direction หมายความว่า เราจะต้องระบุแบบกว้างๆ ไว้ ไม่เฉพาะเจาะจงเกินไป เพราะมันอาจจะทำลาย idea ใหม่ๆ ที่จะเกิดขึ้นได้ (เพราะเดี๋ยวในขั้นตอนต่อๆ ไปจะมีการหยิบเอาไปลงรายละเอียดต่อ)

ตัวอย่าง เช่น สมมติว่าเรามีหนึ่งในกลยุทธ์ของบริษัทที่เกี่ยวข้องมากที่สุดอาจเป็น...

"การเพิ่มรายได้ โดย การเพิ่มความพึงพอใจของลูกค้า"

• Simple and Concise: การเพิ่มราย
• High Level Direction: เพิ่มความพึงพอใจของลูกค้า

ตัวอย่างอื่นๆ เช่น

• ต้องการเพิ่มรายได้ จาก กิจกรรมทางการตลาดกับลูกค้า
• ต้องการเพิ่มรายได้ จาก ช่องทางการเข้าถึงของลูกค้า
• ต้องการเพิ่มรายได้ จาก การลด operation costs

Step 2: แบ่งแต่ละกลยุทธ์ (Divide each strategy)

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

โดยในขั้นตอนนี้ จากตัวอย่าง เราอาจจะต้องมาแบ่งกลุ่มของลูกค้ากันหน่อยว่า เราจะเพิ่มความพึงพอใจให้ลูกค้ากลุ่มไหนได้บ้าง เช่น

• กลุ่ม new users (ลูกค้าใหม่)
• กลุ่ม existing user (ลูกค้าเดิม)

ในขั้นตอนนี้เราสามารถวางแต่ละกลุ่มไปเลยก่อนได้เลย แล้วเดียวในขั้นตอนถัดไปค่อยไปลงรายละเอียดเพิ่ม

กลุ่ม New users
สมมติว่า จากข้อมูลเราพบว่า new user ของ product ของเราจากมีคนกด register จะมี 10% ที่ไม่ได้ register จนจบ process และ อีก 50% ของ user ที่ register แล้ว ไม่ได้ทำอะไรต่อหลังจาก register ไปแล้ว ตรงนี้เราก็จะต้องไปดูว่าทำไม user ถึงหยุดระหว่างทาง

ซึ่งเราอาจจะเจอว่า user ไม่รู้ว่าจะต้องทำอะไรต่อ ดังนั้นเราก็เลยจะเพิ่มประสบการณ์การใช้งานให้แก่ user ด้วยระบบแนะนำผู้ใช้ใหม่ เป็นต้น

• แนะนำการใช้งาน (Onboarding): เน้นไปที่การสร้างประสบการณ์ และ กระบวนการแนะนําผู้ใช้ใหม่ให้กับผลิตภัณฑ์
• ระบบการสมัคร (Register): เน้นไปที่การสร้างประสบการณ์ในการสมัครที่ลื่นไหล เรียบง่าย และ ไม่ติดปัญหา

กลุ่ม Existing users
สมมติว่า จากข้อมูลหลังบ้านเราพบว่า ยังมีการทำงานบางอย่างในระบบของเราที่ทำให้การใช้งานของ user ไม่ลื่นไหล จนทำให้ user ไม่ใช้งานต่อ หรือ เราอาจจะเห็น pain points บางอย่างของ user เราก็สามารถระบุเรื่องเหล่านี้ลงไปได้

โดยจะจัดกลุ่มมันไว้ด้วยก็ได้นะ

• Smooth experience:
  • ข้อบกพร่อง / ปัญหา: ปัญหาที่ทราบ (Bugs/Issues: Known issues) - หากมีปัญหามากเกินไปผู้ใช้อาจเปลี่ยนไปใช้ทางเลือกอื่น
  • ประสิทธิภาพของผลิตภัณฑ์ (Performance: Product efficiency) - หากผลิตภัณฑ์ช้าเกินไปผู้คนอาจหงุดหงิดและจากไป
• Solve users’ pain points
  • คําขอคุณสมบัติใหม่ (New Feature Requests): ลองนึกถึง ฟีเจอร์อะไรที่ลูกค้าต้องการจริงๆ? และการเพิ่มคุณสมบัติใหม่จะทําให้ลูกค้ามีความสุขมากขึ้นหรือไม่

Step 3: เขียนสมมติฐานสําหรับแต่ละหัวข้อย่อย (ความคิดริเริ่ม) (Write the hypothesis)

หยิบแต่ละข้อใน step ก่อนหน้ามาลงรายละเอียดต่อว่าในแต่ละข้อนั้น อะไรเป็นสมมติฐานของเรา ที่น่าจะเป็นไปได้ ส่วนนี้เราจำเป็นต้องนำเอา data analysis เข้ามาช่วย

พยายามอย่าใส่แค่ส่วนของหัวข้อย่อย (Initiatives) เพียงอย่างเดียว เพราะเราไม่ได้ทําเพียงเพราะอยากจะ breaking down มันเฉยๆ และพยายใช้ข้อมูลให้ได้เยอะๆ

เราทำเพื่อ ทําความเข้าใจเหตุผล ในการทําในแต่ละเรื่องให้ออกมาอย่างชัดเจน และ วิธีที่ช่วยให้บรรลุเป้าหมายของบริษัท

เช่น

จากข้อมูลเราพบว่า ผู้ใช้ 75% รู้สึกว่าประสบการณ์การเริ่มต้นใช้งาน (onboarding) ไม่ดี ทำให้ผู้ใช้งานอีก 25% ทำรายการไม่เสร็จและไม่เข้ามาใช้งานอีก

Step 4: จัดลําดับความสําคัญ (Prioritize)

การเรียงลำดับในข้อนี้ จะเป็นการเรียงลำดับเพื่อให้ง่ายต่อการหยิบไปใส่ไว้ใน Product Roadmap แล้ว ซึ่งอีก 2 ข้อที่เหลือ เราก็จะเรียงลำดับภายในตัวของมันเองด้วยเช่นกัน

ดังนั้นหลังจากใส่สมมติฐานของเราเรียบร้อยแล้ว เราจะใช้การวิเคราะห์เชิงคุณภาพหรือเชิงปริมาณ (Qualitative or Quantitative) เพื่อจัดลําดับความสําคัญ

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

การเรียงลำดับช่วยให้เราตัดสินใจได้ง่ายว่าควรทำอะไรก่อนหลัง

เช่น

จากข้อมูลเราพบว่า ผู้ใช้ 75% รู้สึกว่าประสบการณ์การเริ่มต้นใช้งาน (onboarding) ไม่ดี ทำให้ผู้ใช้งานอีก 25% ทำรายการไม่เสร็จและไม่เข้ามาใช้งานอีก

ในขณะที่ ปัญหาเรื่องของการทำงานช้าของระบบ จริงๆ แล้ว ไม่มีใครพูดถึงปัญหาเกี่ยวกับประสิทธิภาพหรือข้อบกพร่องเลยในช่วง 6 เดือนหลังมานี้

ดังนั้น เราควรจัดลําดับความสําคัญของการเริ่มต้นใช้งาน (onboarding) ให้เป็นอันดับที่ 1 และ New Features เป็นลำดับที่ 2 และ การปรับปรุงเรื่อง performance ไว้หลังสุด แบบนี้ก็ได้

หรือ

ถ้าหาก New Features สามารถเพิ่มรายได้ ได้มากกว่า onboarding ก็หยิบ new features ขึ้นมาก่อนก็ได้เช่นกัน

Step 5: พัฒนา Product strategy

เราจะสร้างรายการกลยุทธ์ของ product (Initiatives) ซึ่งอาจไม่จําเป็นต้องทำทั้งหมดตามที่วางไว้ก่อนหน้านี้ก็ได้ ถ้าอันไหนมันไม่ได้สร้าง value ให้เยอะพอ

ในขั้นตอนนี้ เป็นการบอกว่าเราต้องการทําอะไร (What?)

เช่น

• Onboarding: เราจะทำการปรับปรุงประสบการณ์ในการใช้งาน Onboarding ให้ดีขึ้น
• New Features: สร้างแรงจูงใจสําหรับผู้ใช้ที่พึงพอใจในการแบ่งปันประสบการณ์
• Performance / Bugs / Issues: ปรับปรุงประสบการณ์ในการบริการลูกค้า

Step 6: พัฒนา Product Roadmap

จากรายการกลยุทธ์ด้านบนเราสามารถนำไปทำ product roadmap ได้แล้ว จากข้างบน เราได้กำหนด What ไว้แล้วว่า เราต้องการทําอะไร

ดังนั้นในขั้นตอนนี้จะเป็นในส่วนที่เราต้องบอกให้ได้แล้วว่า

• เราจะบรรลุเป้าหมายได้อย่างไร (How?)
• เราจะบรรลุมันเมื่อไหร่ (When?)

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

เช่น

การปรับปรุงประสบการณ์ในการใช้งาน Onboarding ให้ดีขึ้น (Better experience) เราจะทำอย่างไรกับมัน

• สร้าง onboarding ใหม่ ที่มีกระบวนการง่ายยิ่งขึ้น
• สร้าง onboarding guild ที่ให้ผู้ใช้งานโต้ตอบได้

หรือ โปรเจคอื่นๆ อะไรก็ว่ากันไป เสร็จแล้ว อย่าลืมเรียงลำดับให้มันด้วยว่าจะทำอะไรก่อนหลัง

เมื่อได้ทั้งหมดนี้แล้ว เราสามารถหยิบเอามันไปใส่ไว้ใน Product Plan ของเราได้แล้ว 👍

ทีนี้ ถ้าเราอยากจะเพิ่มตัวชี้วัดว่า ที่เราทำมันสำเร็จหรือเปล่า ก็ไปดูข้อมูลในขั้นตอนที่ 3 (hypothesis) แล้วเอามาใส่เป็น เป้าหมายงานชิ้นนั้นๆ (อย่าลืมย่อย Goal ลงมาด้วยนะ)

เท่านี้เราก็สามารถวัดได้แล้วว่า สิ่งที่เราทำนั้น เท่าเพื่ออะไร และเป็นไปตามเป้าหมายหรือไม่

กลับมาที่หัวข้อนี้...

จำไว้ว่า...

เราสามารถย่อยสิ่งที่ต้องทำลงมาอีก กับ ตัวแผนงานจะต้องมีคุณสมบัติ 3 ข้อนี้

1. Living (เป็นอยู่ / มีชีวิต): Product managers สามารถปรับเปลี่ยนได้ตลอดเวลาอย่างสม่ำเสมอ
2. Prioritized: ต้องมีลําดับความสําคัญและเหตุผลอยู่เบื้องหลัง
3. Projects: มีลักษณะเป็น Projects ขนาดไหนก็ได้ และ ไม่จำกัดว่าจะต้อง features เท่าเท่านั้น

จบแล้ว 6 ขั้นตอนในการเปลี่ยนจาก Strategy สู่ Product Roadmap จริงๆ แล้ว เวลาที่เราใช้งานจริงๆ มีบางข้อที่เราอาจจะคิดมันไว้แค่ในหัวของเรา แค่ไม่ได้เขียนมันออกมา หรือ บางอย่างเราก็อาจรวบเป็นข้อเดียวกันเลย ซึ่งในความคิดของผมมันก็ไม่ได้ผิดอะไร แค่เรามีเหตุผล ที่มาที่ไป อย่างชัดเจน มันก็ช่วยให้เราสามารถบริหารโครงการได้ง่ายขึ้นแล้ว