🛑 เลิกก๊อปปี้ “Spotify Model”

🛑 เลิกก๊อปปี้ “Spotify Model”

เมื่อการลอกการบ้านบิ๊กเทค กลายเป็นทางลัดสู่ความล้มเหลวขององค์กรไทย?

“เราทำ Agile แล้วนะ”

“เรามี Product Owner ในทีมแล้ว”

“เราจัดทีมเป็น Squad แบบ Spotify แล้ว”

ประโยคเหล่านี้เป็นสิ่งที่ได้ยินบ่อยมากในองค์กรที่กำลังทำ Digital Transformation หรือพยายามเปลี่ยนตัวเองให้เป็น Tech Company แบบ Start-up style ที่บอกเน้นความคล่องตัว?

แต่พอถามลึกลงไปเช่นว่า Product Owner ในองค์กรนั้นทำอะไรจริง คำตอบที่ได้กลับมักเป็นเพียง “จัดลำดับ Backlog” “เขียน User Story” หรือ “รับ Requirement จากผู้บริหารมาให้ทีม Dev ทำต่อ”?

ตรงนี้เองคือจุดที่ Marty Cagan ผู้เขียน INSPIRED, EMPOWERED และ TRANSFORMED พยายามเตือนองค์กรทั่วโลกมาตลอดว่า

“ปัญหาไม่ได้อยู่ที่องค์กรไม่มี Framework…แต่อยู่ที่องค์กร ไม่เข้าใจว่ากำลังพยายามสร้างอะไรอยู่กันแน่?”

สิ่งที่องค์กรจำนวนมากทำอยู่ทุกวันนี้จึงไม่ใช่ Product Management…แต่เป็นเพียง Feature Factory ที่เปลี่ยนชื่อเรียกตำแหน่งให้ดูทันสมัยขึ้นเท่านั้น

และนั่นคือเหตุผลที่หลายองค์กรเปลี่ยนโครงสร้าง เปลี่ยนชื่อทีม เปลี่ยนศัพท์เต็มไปหมด

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

====

Product Operating Model ไม่ใช่ Framework แต่คือระบบคิดขององค์กร

สิ่งที่ Marty Cagan เรียกว่า Product Operating Model ไม่ใช่ methodology สำเร็จรูป ไม่ใช่ process แบบทีละขั้นตอน และไม่ใช่ template ที่ copy ไปติดตั้งแล้วใช้งานได้ทันที

มันคือ “ระบบคิด” ขององค์กรที่ต้องการสร้างผลิตภัณฑ์เทคโนโลยีให้เกิดผลลัพธ์ทางธุรกิจจริง

SVPG อธิบายไว้ชัดว่า Product Operating Model คือแนวทางการทำงานที่ทำให้องค์กรสามารถสร้าง technology-powered solutions ที่ให้ทั้งคุณค่ากับลูกค้า และผลลัพธ์กับธุรกิจได้อย่างสม่ำเสมอ โดยหัวใจสำคัญคือการขยับจากการส่งมอบ output ไปสู่การสร้าง outcome (svpg.com)

พูดให้ง่ายที่สุด คือองค์กรที่ทำ Product Operating Model จริง มักเริ่มจากคำถามว่า

* เราจะเลือกปัญหาที่ควรแก้ได้อย่างไร?

* เราจะค้นหาคำตอบที่ถูกต้องก่อนลงมือสร้างได้อย่างไร?

* และเราจะส่งมอบคุณค่าให้ลูกค้าได้ต่อเนื่องอย่างไร?

“ถ้าองค์กรยังตอบสามคำถามนี้ไม่ได้ ต่อให้มี Squad, Tribe, Chapter หรือ PO เต็มอาคาร…องค์กรก็ยังไม่ใช่ Product Organization อยู่ดี”

====

มายาคติเรื่อง “บทบาทหน้าที่” มักคือจุดเริ่มต้นของความพัง

หนึ่งในความเข้าใจผิดที่แพร่หลายที่สุดคือการเชื่อว่า แค่มีตำแหน่ง Product Owner อยู่ในทีม Scrum ก็แปลว่าองค์กรกำลังทำ Product Management แล้ว แต่ Marty Cagan แยกเรื่องนี้ไว้ค่อนข้างชัด

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

1) Product Manager = ไม่ใช่คนจัด Backlog แต่คือคนรับผิดชอบ Value และ Viability

ความเข้าใจผิดในหลายองค์กรคือ Product Manager หรือ Product Owner เป็นเพียง “คนกลาง” ระหว่าง Business กับทีม Tech แต่ในโลกของ Product จริง Product Manager ต้องตอบคำถามสำคัญให้ได้ว่า

* ปัญหานี้มีคุณค่าพอให้ลูกค้าอยากใช้หรืออยากจ่ายเงินหรือไม่?

* แนวทางนี้สอดคล้องกับโมเดลธุรกิจ กฎหมาย ความเสี่ยง และข้อจำกัดขององค์กรหรือไม่?

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

ถ้า PM ไม่มีอำนาจ ไม่มีข้อมูล และไม่มีสิทธิ์ตั้งคำถามกับ stakeholder ตำแหน่งนี้ก็จะถูกลดทอนเหลือเพียง “คนจัด backlog” ตามที่หลายองค์กรเผชิญอยู่

2) Product Designer = ไม่ใช่คนวาดหน้าจอสวย แต่คือคนรับผิดชอบ Usability

อีกความเข้าใจผิดที่พบแทบทุกองค์กรคือ Designer ถูกดึงเข้ามาหลังจาก Requirement ถูกคิดจบไปหมดแล้ว บทบาทจึงเหลือเพียง

* ทำ wireframe

* จัด layout

* เลือกสี

* ทำให้หน้าจอดู modern เป็นต้น

แต่ใน Product Operating Model จริง Designer ต้องเข้ามาตั้งแต่ต้น เพื่อช่วยตอบคำถามว่า

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

3) Product Engineer = ไม่ใช่ช่างรับออเดอร์ แต่คือคนรับผิดชอบ Feasibility

หลายองค์กรยังมองวิศวกรเป็นเพียงผู้รับ Requirement แล้วลงมือเขียนโค้ดตามสเปก

“แต่นั่นคือมุมมองแบบโรงงาน ไม่ใช่มุมมองแบบ Product Company”

ในทีมที่แข็งแรง Engineer ต้องเข้ามามีส่วนร่วมตั้งแต่ช่วง Discovery เพื่อช่วยตอบว่า

* สิ่งนี้สร้างได้จริงไหม?

* ใช้เวลานานแค่ไหน?

* มีทางเลือกที่ฉลาดกว่าไหม

* และมีข้อจำกัดทางเทคนิคอะไรที่ทีมควรรู้ก่อนตัดสินใจ”

“ถ้า Engineer ถูกกันออกจากช่วงคิด องค์กรก็จะลงเอยกับการคิดฝันบนอากาศ แล้วโยนของที่สร้างยาก แพง และเสี่ยงให้ทีมพัฒนาไปแบกต่อ”

====

กับดักที่แพงมาก คือ “ลอกการบ้านโดยไม่เข้าใจบริบทตัวเอง”?

หนึ่งในสิ่งที่องค์กรไทยชอบทำมากที่สุดเวลาอยากเปลี่ยนแปลง คือการถามว่า

“บริษัทระดับโลกเขาจัดทีมกันยังไง?” แล้วจากนั้นก็รีบยกโครงสร้างนั้นมาทั้งชุด

* เราเลยเห็นหลายองค์กรพยายามแบ่งเป็น Tribe, Squad, Chapter แบบ Spotify

* หรือหยิบแนวคิดของ Amazon, Netflix หรือ Google มาใช้แบบ “ยกมาทั้งดุ้น”

ทั้งที่ความจริง แม้แต่ Spotify เองก็ไม่ได้เคยบอกว่า model ที่ถูกอ้างถึงกันทั่วโลกนั้นเป็นสูตรสำเร็จตายตัวสำหรับทุกองค์กร และโพสต์ของ Spotify Labs ตั้งแต่ปี 2013 ก็อธิบายมันในฐานะวิธีทำงานตามบริบทของบริษัท ณ เวลานั้น ไม่ใช่คู่มือสากลสำหรับทุกคน (labs.spotify.com)

ปัญหาจึงไม่ใช่แค่ “ลอกผิด” แต่คือลอกทั้งที่ไม่เข้าใจว่าของเขาเกิดจากบริบทอะไร?

องค์กรไทยจำนวนมากมี

* legacy systems หนาแน่น

* regulatory constraints สูง

* วัฒนธรรมลำดับชั้นแรง

* decision rights ไม่ชัด

* และ stakeholder ภายในจำนวนมาก

ถ้าโครงสร้างเหล่านี้ยังไม่เปลี่ยน ต่อให้เปลี่ยนชื่อทีมเป็น Squad “องค์กรก็ยังตัดสินใจช้าเหมือนเดิม”

นี่คือเหตุผลที่การลอกการบ้านบิ๊กเทค จึงมักจบลงด้วยความล้มเหลวที่แพงที่สุด เพราะองค์กรเสียทั้งเงิน เสียทั้งเวลา และยังสร้าง illusion ว่าตัวเองกำลัง transform ทั้งที่แก่นของระบบยังเหมือนเดิม

====

Why Spotify Copying Fails? เมื่อการลอกโครงสร้างไม่ได้สร้างความสามารถ

หนึ่งในความเข้าใจผิดที่แพร่หลายที่สุดของการทำ Digital Transformation คือการเชื่อว่า

“ถ้าโครงสร้างของบริษัทเทคโนโลยีเวิร์กกับเขา มันก็ควรเวิร์กกับเรา?”

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

* วัฒนธรรมการตัดสินใจที่กระจายอำนาจ

* ทีมวิศวกรที่มีความสามารถสูง

* ระบบเทคโนโลยีที่รองรับการ deploy อย่างต่อเนื่อง

* ผู้นำที่ยอมให้ทีมทดลองและล้มเหลวได้ เป็นต้น

เมื่อองค์กรนำเพียง "รูปแบบภายนอก" ไปใช้ แต่ไม่ได้เปลี่ยนระบบการตัดสินใจหรือวัฒนธรรมการทำงาน สิ่งที่เกิดขึ้นจึงไม่ใช่ Product Organization แต่คือ “โรงละครเวอร์ชันใหม่”

====

Hidden Cost of Feature Factory หรือ เมื่อองค์กรสร้างของที่ไม่มีใครต้องการ?

องค์กรจำนวนมากเชื่อว่าความสำเร็จของทีมเทคโนโลยีคือการส่งมอบ feature ให้ได้มากที่สุด แต่ในมุมมองของ Product Organization นั่นคือกับดักที่เรียกว่า Feature Factory คือ

“ทีมทำงานเร็วขึ้น ส่งมอบของได้มากขึ้น แต่ไม่มีหลักฐานว่าลูกค้าได้รับคุณค่าจริง”

ต้นทุนที่ซ่อนอยู่ของ Feature Factory ได้แก่

* เวลาและงบประมาณที่ถูกใช้ไปกับสิ่งที่ไม่มี impact

* ความซับซ้อนของระบบที่เพิ่มขึ้นจาก feature ที่ไม่มีคนใช้

* ทีมงานที่หมดแรงเพราะทำงานหนักแต่ไม่เห็นผลลัพธ์

หลายองค์กรพบว่าฟีเจอร์จำนวนมากที่ถูกสร้างขึ้นแทบไม่มีการใช้งานจริง แต่ยังต้องแบกรับต้นทุนในการดูแลระบบต่อไปนี่คือเหตุผลที่องค์กรระดับโลกเปลี่ยนจากการวัด Output (จำนวน feature) ไปสู่ Outcome (ผลลัพธ์ของลูกค้าและธุรกิจ)

====

Product Transformation ต้องทำยังไง?

จากบทเรียนขององค์กรเทคโนโลยีจำนวนมาก การเปลี่ยนผ่านสู่ Product Operating Model มักขึ้นอยู่กับ 4 ตัวแปรสำคัญ

1. Strategy Clarity – องค์กรต้องชัดเจนว่า Product Strategy คืออะไร และกำลังพยายามแก้ปัญหาอะไร?

2. Empowered Teams – ทีมต้องมีอำนาจตัดสินใจ ไม่ใช่เพียงทำตาม roadmap ที่ถูกกำหนดจากข้างบน?

3. Continuous Discovery – ทีมต้องสามารถเรียนรู้ลูกค้า ทดสอบสมมติฐาน และลดความเสี่ยงก่อนสร้าง?

4. Continuous Delivery – องค์กรต้องมีความสามารถในการส่งมอบซอฟต์แวร์หรือบริการได้อย่างต่อเนื่อง

“หากตัวแปรใดตัวแปรหนึ่งขาดหาย การเปลี่ยนผ่านสู่ Product Organization จะหยุดชะงักทันที”

====

Product Operating Model ของจริง ต้องตอบให้ได้ 3 คำถาม

SVPG สรุป Product Operating Model ไว้ในแก่นสำคัญที่ชัดมาก คือองค์กรต้องออกแบบตัวเองให้ตอบสามคำถามนี้ได้อย่างต่อเนื่อง (svpg.com)

1) How do you decide which problems to solve?

“นี่คือเรื่องของ Product Strategy”

องค์กรต้องตอบให้ได้ว่า จะเลือกแก้ปัญหาไหนก่อน และเลือกเพราะอะไร

ไม่ใช่เลือกเพราะใครเสียงดังที่สุดในห้องประชุม

ไม่ใช่เลือกเพราะผู้บริหารคนหนึ่งอยากได้

และไม่ใช่เลือกเพราะคู่แข่งเพิ่งปล่อยฟีเจอร์ใหม่

ถ้ายุทธศาสตร์การเลือกปัญหาไม่ชัด…ทุกอย่างหลังจากนั้นจะกลายเป็นการวิ่งเร็วไปในทิศทางที่ผิด

2) How do you solve problems?

นี่คือเรื่องของ Continuous Discovery

องค์กรต้องมีกลไกในการทำความเข้าใจผู้ใช้ ทดสอบสมมติฐาน และลดความเสี่ยงก่อนลงมือสร้างจริง

ความเสี่ยงหลักที่ทีมต้องเรียนรู้ให้ครบคือ

* Value – ลูกค้าอยากได้จริงไหม

* Usability – ใช้งานได้จริงไหม

* Feasibility – สร้างได้จริงไหม

* Viability – ธุรกิจรองรับไหม

หลายองค์กรข้ามขั้นนี้ แล้วรีบไปสร้าง…สุดท้ายจึงได้ของที่ “เสร็จ” แต่ไม่ “เวิร์ก”

3) How do you build?

นี่คือเรื่องของ Continuous Delivery

เมื่อรู้ว่าจะสร้างอะไร และมั่นใจแล้วว่ามันควรถูกสร้าง

องค์กรต้องมีกลไกในการส่งมอบซอฟต์แวร์หรือบริการได้ต่อเนื่อง รวดเร็ว และปลอดภัย

จุดนี้ไม่ได้หมายถึงแค่ Dev เร็วขึ้น แต่หมายถึงทั้งระบบตั้งแต่การ deploy, test, release, monitoring ไปจนถึงการรับ feedback จากตลาด

สามคำถามนี้คือ “กระดูกสันหลัง” ของ Product Operating Model

* ไม่ใช่ชื่อทีม

* ไม่ใช่ตำแหน่ง

* และไม่ใช่พิธีกรรม

====

ทำไมองค์กรไทยถึงติด “Agile Theater” และ “Product Theater” พร้อมกัน?

สิ่งที่เกิดขึ้นบ่อยในองค์กรไทยคือการเปลี่ยนคำศัพท์ก่อนเปลี่ยนระบบ เช่น

* เปลี่ยน BA เป็น PO

* เปลี่ยน PM เป็น Product Manager

* เปลี่ยนทีม Project เป็น Squad และตั้งชื่อกันสวยงาม

* เปลี่ยนให้ทุกคนมานั่งรวมกัน เป็นต้น

แต่สิ่งที่ไม่เปลี่ยนคือ

* วิธีตัดสินใจยังเป็น Top-down

* Stakeholder ยังโยน roadmap ลงมาให้ทีมทำ

* ทีมยังถูกวัดจากการส่ง feature

* Designer ยังเข้ามาตอนปลาย

* Engineer ยังไม่มีสิทธิ์ตั้งคำถาม

“นี่คือสิ่งที่อันตรายมาก” เพราะองค์กรจะเข้าใจผิดว่าตัวเองกำลังทำ Product แล้ว

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

====

ถ้าอยากเริ่มจริง ต้องเริ่มจาก “pilot team” ไม่ใช่สั่งเปลี่ยนทั้งบริษัท

หนึ่งในข้อเสนอที่สำคัญมากของ Marty Cagan คือ

การเปลี่ยนผ่านสู่องค์กรแบบ Product ไม่ควรถูกทำเหมือน “โครงการติดตั้ง framework” แต่มันต้องเริ่มจากทีมเล็ก ๆ ที่ได้รับ “ความไว้วางใจ อำนาจ และโจทย์ที่ชัดเจน หรือที่เรียกง่ายๆ ว่า pilot team”

ทีมนี้ต้องมีองค์ประกอบครบ

* Product Manager

* Product Designer

* Tech Lead / Product Engineer

และที่สำคัญกว่านั้น ทีมต้องมีสิทธิ์ทำงานแบบ empowered จริง ไม่ใช่ได้รับอิสระเพียงในนาม เมื่อทีมพิสูจน์ได้ว่า model แบบนี้สร้าง outcome ที่ดีกว่า องค์กรจึงค่อยขยายผลไปยังส่วนอื่น

“ถ้าผู้นำยังไม่กล้าให้พื้นที่ทดลอง Product Operating Model จะไม่มีทางเกิดขึ้นจริง”

====

สัญญาณว่าองค์กรของคุณยังไม่ได้ทำ Product จริง?

หลายองค์กรเชื่อว่าตัวเองกำลังทำ Product Organization แล้ว แต่ความจริงอาจยังอยู่ในโหมด Project Organization แบบเดิม

ลองสังเกต 5 สัญญาณง่ายๆ

1. ทีมถูกวัดจากจำนวน feature ที่ส่งมอบ

ถ้าความสำเร็จของทีมยังถูกวัดจาก backlog ที่ปิดได้ หรือจำนวนฟีเจอร์ที่ปล่อย นั่นแปลว่าองค์กรยังโฟกัสที่ output ไม่ใช่ outcome

2. Roadmap ถูกกำหนดจากผู้บริหารล่วงหน้าทั้งปี

เมื่อ roadmap ถูกล็อกตั้งแต่ต้นปี ทีมจะไม่มีพื้นที่ในการค้นพบปัญหาที่แท้จริงของลูกค้า

3. ทีมไม่มีอำนาจตัดสินใจเรื่องผลิตภัณฑ์

ถ้าทุกการตัดสินใจต้องรอ approval จากหลายระดับ ทีมจะไม่สามารถทดลองและเรียนรู้ได้เร็วพอ

4. Designer และ Engineer ถูกดึงเข้ามาหลังจากทุกอย่างถูกตัดสินใจแล้ว

หลายองค์กรคิด requirement เสร็จหมดแล้วก่อนเรียก designer หรือ engineer เข้ามาเกี่ยวข้อง ผลคือทีมเทคนิคกลายเป็นเพียงผู้รับคำสั่ง แทนที่จะเป็นผู้ร่วมค้นหาคำตอบตั้งแต่ต้น

5. ทีมทำงานหนักขึ้น แต่ผลลัพธ์ของผลิตภัณฑ์ไม่ดีขึ้น

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

องค์กรที่ทำ Product จริงจะพยายามลดสัญญาณเหล่านี้ลงให้มากที่สุด

====

หยุดยึดติดกับชื่อตำแหน่ง แล้วหันไปมอง “ความสามารถที่แท้จริง”

อีกสิ่งที่องค์กรชอบพลาดคือ “การยึดติดกับชื่อเรียกมากกว่าความสามารถ” หลายคนเชื่อว่าแค่เปลี่ยนชื่อคนเป็น Product Owner หรือ Product Manager แล้วองค์กรก็จะ product-led ขึ้นมาเอง

แต่ความจริงคือ “ตำแหน่งไม่เคยเปลี่ยนองค์กร competency ต่างหากที่เปลี่ยนองค์กร”

คนที่รับผิดชอบ Product ต้องตอบให้ได้ว่า

* ลูกค้าจะได้อะไร?

* ธุรกิจจะได้อะไร?

* เทคโนโลยีรองรับอย่างไร?

* ความเสี่ยงอยู่ตรงไหน?

ถ้าตอบไม่ได้ ต่อให้ชื่อตำแหน่งถูกต้องตามตำราแค่ไหน องค์กรก็ยังไม่ใช่ Product Organization อยู่ดี

====

Product Operating Model ไม่ใช่ปลายทาง แต่คือวิธีคิดใหม่ขององค์กร

หลังจากอ่านมาถึงตรงนี้ ผมอยากทิ้งประโยคสำคัญไว้ว่า Product Operating Model ไม่ใช่สิ่งที่องค์กร “ติดตั้ง” แล้วเสร็จ

มันคือวิธีคิดที่ต้องค่อยๆ ฝังลงไปในดีเอ็นเอขององค์กร

* ไม่ใช่แค่เปลี่ยนโครงสร้าง

* ไม่ใช่แค่เปลี่ยนชื่อทีม

* และไม่ใช่แค่ซื้อ training package ใหม่

เพราะท้ายที่สุดแล้ว สิ่งที่วัดว่าองค์กรทำ Product จริงหรือไม่?

* ไม่ใช่จำนวน Squad ที่ตั้งได้

* ไม่ใช่จำนวน PO ที่มี

* และไม่ใช่จำนวนคนที่สอบ certificate ผ่าน

แต่วัดจากคำถามเดียว “ลูกค้าได้รับคุณค่าเพิ่มขึ้นจริงหรือไม่?” ถ้าคำตอบยังไม่ใช่ นั่นแปลว่าองค์กรยังไม่ได้ทำ Product จริง แค่กำลังทำ “โปรเจกต์แบบใหม่ที่ใช้ศัพท์เดิมของบิ๊กเทค” เท่านั้นเอง

“หยุดพยายามนำกระบวนการของคนอื่นมาสวมใส่…แล้วเริ่มออกแบบระบบการทำงานที่เคารพบริบท ข้อจำกัด และความจริงขององค์กรตัวเอง…เพราะนั่นคือหนทางเดียวที่จะสร้างผลิตภัณฑ์ที่ยั่งยืนได้จริง”

#วันละเรื่องสองเรื่อง #ProductOperatingModel #MartyCagan #ProductManagement #EmpoweredTeams #DigitalTransformation #ProductStrategy