โรดแมปผลิตภัณฑ์ส่วนใหญ่ถูกทิ้งภายในหนึ่งไตรมาสหลังจากเขียนเสร็จ ไม่ใช่เพราะทีมขาดวินัย แต่เพราะโรดแมปถูกสร้างบนรากฐานที่ผิด คือวันที่ตายตัว รายการฟีเจอร์ และความต้องการของผู้มีส่วนได้ส่วนเสียที่ถูกห่อให้ดูเป็นแผน เมื่อความเป็นจริงเบี่ยงเบนไปจากแผนอย่างหลีกเลี่ยงไม่ได้ — ฟีเจอร์ใช้เวลานานกว่าที่คิด ความต้องการของลูกค้าเปลี่ยน คู่แข่งขยับตัว — โรดแมปก็กลายเป็นนิยาย และทีมก็เลิกเปิดดู
โรดแมปที่คนทำตามจริงไม่ใช่แผนภูมิแกนต์ (Gantt chart) ที่แต่งตัวเป็นกลยุทธ์ผลิตภัณฑ์ แต่เป็นเอกสารที่มีชีวิต ซึ่งสะท้อนความคิดที่ดีที่สุดของทีม ณ ปัจจุบันว่าควรแก้ปัญหาใดก่อนหลังอย่างไร โดยมีโครงสร้างที่ซื่อสัตย์ต่อสิ่งที่รู้และสิ่งที่ยังไม่รู้
ก่อนออกแบบโรดแมป ควรเข้าใจให้ชัดก่อนว่ามีไว้เพื่ออะไร โรดแมปทำสามอย่าง: สื่อสารทิศทาง (เรากำลังจะไปไหนและเพราะอะไร) บังคับให้จัดลำดับความสำคัญ (เราทำทุกอย่างไม่ได้ แล้วอะไรมาก่อน) และสร้างฐานให้ทุกฝ่ายเดินไปในทิศทางเดียวกัน (เพื่อให้วิศวกรรม ดีไซน์ ฝ่ายขาย และฝ่ายซัพพอร์ตทำงานเพื่อเป้าหมายเดียวกัน)
โรดแมปไม่ได้รับประกันวันส่งมอบ ไม่ได้ผูกมัดว่าจะต้องมีฟีเจอร์ใดโดยเฉพาะ และไม่ได้มาแทนที่การทำ discovery อย่างต่อเนื่อง หากผู้มีส่วนได้ส่วนเสียมองโรดแมปเป็นคำมั่นสัญญา นั่นคือปัญหาของกระบวนการ ไม่ใช่เหตุผลที่จะใส่ความแม่นยำปลอมลงในเอกสาร
รูปแบบโรดแมปที่ทนทานที่สุดสำหรับทีมส่วนใหญ่คือโมเดลสามช่วงเวลา มันซื่อสัตย์ต่อความไม่แน่นอน: รายการใน "ตอนนี้" คือสิ่งที่ผูกมัดแล้ว รายการใน "ถัดไป" วางแผนไว้แต่ยังไม่ล็อก และรายการใน "ภายหลัง" ถูกต้องในแง่ทิศทาง แต่อาจเปลี่ยนไปเมื่อคุณเรียนรู้เพิ่ม
สังเกตว่าแต่ละรายการไม่ได้บอกแค่ว่าคืออะไร แต่บอกด้วยว่าทำไมจึงอยู่ตรงนั้น โรดแมปที่ไม่มีเหตุผลกำกับก็เป็นเพียงรายการ เมื่อสมาชิกทีมเข้าใจว่าทำไมจึงเลือกแต่ละรายการ พวกเขาจะตัดสินใจได้ดีขึ้นเมื่อสถานการณ์เปลี่ยน — และคุยกันได้ตรงประเด็นมากขึ้นเมื่อลูกค้าขอสิ่งที่ไม่อยู่ในรายการ
โรดแมปแบบเน้นฟีเจอร์ ("สร้าง X สร้าง Y สร้าง Z") สร้างพลวัตที่อันตราย: ทีมส่งมอบฟีเจอร์แล้วถือว่างานเสร็จ ทั้งที่ฟีเจอร์เหล่านั้นไม่ได้ขยับตัวชี้วัดที่ควรขยับ ฟีเจอร์ถูกส่งมอบแล้ว แต่ปัญหาไม่ได้รับการแก้
โรดแมปแบบเน้นผลลัพธ์จะเปลี่ยนกรอบของแต่ละรายการให้เป็นเป้าหมาย: "ลดเวลาก่อนผู้ใช้ใหม่เห็นคุณค่าครั้งแรก (time-to-first-value) จาก 4 วันเหลือไม่ถึง 24 ชั่วโมง" แล้วให้ทีมตัดสินใจ — และกลับมาทบทวน — ว่าจะบรรลุผลลัพธ์นั้นอย่างไร โครงสร้างแบบนี้ยังทำให้ลดลำดับความสำคัญของฟีเจอร์ได้ง่ายขึ้นมากเมื่อพบวิธีที่ดีกว่าในการไปถึงผลลัพธ์เดียวกัน
ผู้จัดการผลิตภัณฑ์ (PM) เป็นเจ้าของโรดแมป หมายความว่าต้องรับผิดชอบต่อเนื้อหา การอัปเดต และการสื่อสารกับผู้มีส่วนได้ส่วนเสีย แต่การเป็นเจ้าของไม่ได้หมายความว่าต้องเขียนคนเดียว — โรดแมปที่ดีที่สุดสร้างขึ้นร่วมกัน โดยรับข้อมูลจากวิศวกรรม (เรื่องความเป็นไปได้และแรงที่ต้องใช้) ดีไซน์ (เรื่องผลต่อประสบการณ์ผู้ใช้) และทีมที่ดูแลลูกค้าโดยตรง (เรื่องสัญญาณจากตลาด)
สิ่งที่ PM ควรหลีกเลี่ยงคือการออกแบบโรดแมปแบบคณะกรรมการ ผู้มีส่วนได้ส่วนเสียให้ข้อมูลได้ แต่ไม่ควรมีสิทธิ์วีโต้รายการใดรายการหนึ่ง PM เป็นผู้สังเคราะห์ข้อมูลและเป็นคนตัดสิน หากทุกคนเชื่อมั่นในกระบวนการตัดสินนั้น ผลลัพธ์ก็จะได้รับความเชื่อมั่นเช่นกัน
คอลัมน์ "ตอนนี้" ควรทบทวนทุกสปรินต์ คอลัมน์ "ถัดไป" ควรทบทวนต้นไตรมาสทุกครั้ง หรือเมื่อใดก็ตามที่มีหลักฐานใหม่สำคัญเข้ามา (ลูกค้ารายใหญ่ยกเลิกบริการ คู่แข่งเปิดตัวสิ่งที่เกี่ยวข้อง สปรินต์ discovery ให้ข้อค้นพบที่น่าประหลาดใจ) ส่วนคอลัมน์ "ภายหลัง" ต้องกลับมาดูไตรมาสละครั้ง ไม่ใช่เพื่อปรับให้ละเอียด แต่เพื่อยืนยันว่าการเดิมพันเชิงทิศทางเหล่านั้นยังสมเหตุสมผล
เป้าหมายคือโรดแมปที่ไม่ล้าสมัยจนน่าอาย แต่ก็ไม่อัปเดตถี่จนสร้างความวิตกกังวล ทีมส่วนใหญ่มักพลาดด้านอัปเดตน้อยเกินไป — โรดแมปสะท้อนการตัดสินใจเมื่อหกเดือนก่อน และไม่มีใครรู้แน่ว่าแก้ไขล่าสุดเมื่อไร
ทีมจะทำตามโรดแมปก็ต่อเมื่อ — และเฉพาะเมื่อ — เชื่อมั่นในมัน ความเชื่อมั่นนั้นมาจากสามอย่าง: เหตุผลของแต่ละรายการมองเห็นได้และฟังขึ้น ทีมมีส่วนร่วมสร้างแทนที่จะถูกยื่นให้ และ PM อัปเดตทันทีเมื่อสถานการณ์เปลี่ยน แทนที่จะแสร้งทำเหมือนแผนเดิมยังใช้ได้
โรดแมปที่ถูกใช้เป็นเครื่องมือต่อรอง หรือเป็นเอกสารที่ทำขึ้นเพื่อเอาใจผู้บริหาร จะถูกเมินในระดับทีมและสร้างความไม่พอใจให้ผู้มีส่วนได้ส่วนเสีย ส่วนโรดแมปที่สะท้อนการคิดอย่างจริงจัง การแลกเปลี่ยน (trade-off) ที่เป็นจริง และความไม่แน่นอนที่พูดตรง ๆ จะกลายเป็นเครื่องมือที่คนหยิบมาใช้ — เพราะช่วยให้พวกเขาตัดสินใจได้จริง ๆ