10 เคล็ดลับแนวทางในการออกแบบ Product Roadmap
เนื่องจากช่วงนี้มีการจัดการงาน มีการกำหนด Product Owner เพื่อพัฒนา Product ของเราให้เป็นไปตามเป้าหมาย ดังนั้นจึงจำเป็นต้องหาความรู้ในการออกแบบ Product Roadmap ซึ่งสำคัญมาก พอดีไปเจอข้อมูลที่น่าสนใจ จึงอยากจะแชร์โดยนำมาเขียนสรุปตามความเข้าใจที่ง่ายๆในแบบของเรา
1. Focus on Goals and Benefits
เขาบอกว่าให้ Focus ที่ Goals เช่น วัตถุประสงค์, Outcomes ตัวอย่างเช่น การเพิ่มผู้ใช้ การลด technical debt (ปัญหาสะสม) ค่าที่เหมาะสม 3–5 feature ต่อ 1 Release กำหนดให้เป็นกฏไปเลย และในแต่ละ new major release เราสามารถเขียนบันทึก หรืออาจจะเขียนขึ้น board ดังนี้ได้
ความหมาย
- Date หรือ timeframe คือวันหรือช่วงเวลาที่จะ release
- Name ชื่อของ release
- Goal เหตุผลที่สร้าง release นี้ขึ้นมา เช่น feature การอับโหลดข้อมูลขึ้น S3 (AWS cloud storage)
- Feature คือมีอะไรบ้าง เขียนคร่าวๆแบบ high-level อย่างที่บอก 3–5 feature ต่อ release พอ
- Metric ตัวชี้วัดว่าถ้าเป้าหมายนี้สำเร็จ
2 Validate Product Strategy
กำหนด Product Strategy ก่อนที่จะทำ Product Roadmap โดย Product Strategy ตัวอย่างการคิด Product Strategy เช่น ปัญหาที่ต้องการจะแก้ ประโยชน์ที่ลูกค้าจะได้รับหรือที่เราจะทำให้, key feature, และ business goals เขียนทั้งหมดก่อน แล้ว validate มันก่อนที่จะแปลงเป้น Product Roadmap โดย Product Roadmap จะมีเฉพาะสิ่งที่ทำได้จริงหรือ Realistic เท่านั้น
3 Tell a Coherent Story
Product Roadmap จะต้องให้สอดคล้องไปในทิศทางที่ดูว่า product นั้นโตไปเรื่อยๆ ทุกๆ release ที่ออกไปจะต้องต่อยอดจาก release ก่อนหน้า เป็นไปในลักษณะเดินหน้าไปสู่ vision ที่ต้องการ ไม่ใช่ถอยหลังไปแก้สิ่งเดิมๆ การวัดความสำเร็จที่มองว่า product โตไปข้างหน้าคือ ดูจากใครคือผู้ใช้ product ถ้าเป็น internal ภายใน เช่นทำระบบ software ใช้ภายใน ก็ให้ดูว่า ผู้ใช้ใช้แล้วเขาสำเร็จหรือแก้ไขปัญหาเดิมได้หรือเปล่า เน้นย้ำ roadmap ต้องทำได้จริง
4 Keep it Simple
อย่าเพิ่มรายละเอียดใน roadmap มากเกินไป เน้นทำให้ง่ายต่อความเข้าใจ จับภาพสิ่งที่สำคัญ focus ที่เป้าหมาย อะไรไม่เกี่ยวข้องกำจัดออก ส่วนรายละเอียดของงานค่อยย่อยรายละเอียดต่างๆลง Backlog เช่น epics, user stories, UI design ไม่ต้องไปแสดงใน roadmap
5 Secure Strong Buy-in
Roadmap ทุกฝ่ายที่เป็น Stakeholder ต้อง buy-in คือเห็นด้วยที่จะต้องทำ ยอมรับถึงความสำคัญ และเหตุผลที่ต้องทำ คนที่เกี่ยวข้อง เช่น Developer, Marketing, Sale แนวทางที่ดีควรจะจัด workshop ร่วมกันออกแบบ สร้างความมีส่วนร่วม
6 กล้าที่จะพูดปฏิเสธ (Say no)
เมื่อเราต้องการให้ stakholder เรา buy-in ใน Idea คุณไม่จำเป็นต้อง say yes ในทุกๆอย่างที่ขอ Steve Job บอกว่า “นวัตกรรมไม่ได้เกิดจากการ say yes ในทุกๆสิ่ง แต่เกิดจากการ say no ทุกๆอย่าง คงไว้เพียง yes เฉพาะสิ่งที่สำคัญที่สุด” การตัดสินใจ ให้ยึดจาก product (business) vision และ product strategy
7 Know When to Show Dates
ในการเขียน dates หรือ timeframe ใน roadmap ต้องแยกกันระหว่างใช้สื่อสารภายในและใช้สื่อสารภายนอก สื่อสารภายในเช่น คุยให้ทุกฝ่ายภายในฟัง เช่น dev, marketing, sale ถ้าอย่างงี้ใน roadmap ต้องระบุ dates หรือ timeframe เพื่อให้ทุกฝ่ายรู้ มันเป้นส่วนสำคัญ คือ date-driven products ฝ่าย dev ก้จะได้เร่งดำเนินการ ฝ่ายขายก็จะได้สื่อสารกับลูกค้าได้ ฝ่ายการตลาดก็วางแผนการสื่อสารการตลาด ส่วนสื่อสารภายนอก เช่น roadmap ที่ระบุในเอกสารงานขาย หรือนำเสนอลูกค้า อย่างงี้ไม่ต้องระบุ date หรือ timeframe ให้ระบุเป็น release และ next release จะทำไร จะได้อะไร ระบุเป็น release ต่อๆกันไปเรื่อยๆเป็น sequencing
8 Make your Roadmap Measurable
เมื่อเราเอาเป้าหมายเป็น Goals ดังนั้นในทุกๆ Goals จะต้องวัดได้ เราจะได้รู้ว่าเราถึงเป้าหรือไม่ถึงเป้า เช่น ถ้า goals คือจำนวนผู้ใช้งาน App เราก็ต้องทราบว่าถึงเป้ายัง ถ้าเป้าเราคือลดปัญหาสะสมในเรื่องของ technical เราก็ต้องดูว่า เราลดปัญหานั้นได้ไหม. ต้องแน่ใจว่า เป้าหมายนั้นเป็นไปได้จริง
9 Determine Cost Top-Down
การพิจารณา cost ในการผลิต Software ในแต่ละ release ควรคิดจาก บนลงล่าง คือ จากเป้าหมายหรือ goals แล้วดูว่าจะใช้คนเท่าไหร่ ทักษะยังไงบ้าง แล้วคิดเป็นต้นทุนเท่าไหร่ ถ้าทำจริงแล้วไม่เป็นไปตามที่คิด เช่น คนทำงานยังไม่พอ หรือ feature ที่จะ release นั้นยากและซับซ้อนจนใช้เวลานาน ทำให้ต้นทุนเกินงบ ค่อยประเมินว่าจะปรับ roadmap หรือเปลี่ยนทิศทางไปเลย
10 Regularly Review and Adjust the Roadmap
มั่นทบทวน อาจจะ 4 สัปดาห์ต่อครั้งถึงทุกๆ 3 เดือนครั้ง ว่าแผนงานทำให้เกิดความคล่องตัว เกิดการเปลี่ยนแปลง ส่วนด้านการตลาด คือ product ยัง fit กับ market หรือไม่ หรือตลาดเปลี่ยนไปแล้ว. ดูจากตารางนี้ได้ครับ ระหว่าง Product ที่อยู่ในขั้น Mature product คือ product ที่อยู่ตัวติดตลาดแล้ว และ Young product คือ product ที่อยู่ในขั้นตอนเริ่มต้นในการพัฒนา
ข้อมูลอ้างอิง
ข้อมูลทั้งหมด มาจากแหล่งที่มาดังนี้ครับ
Blog ของ Roman Pichler http://www.romanpichler.com/blog/10-tips-creating-agile-product-roadmap
และหนังสือ
