วงจรชีวิตผลิตภัณฑ์: การเดินทางของคุณลักษณะของผลิตภัณฑ์

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

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

ท – 30 วัน

ว่ากันว่าความจำเป็นเป็นต้นกำเนิดของการประดิษฐ์ นั่นคือกรณีที่เกี่ยวข้องกับการเกิดของคุณลักษณะผลิตภัณฑ์อย่างแท้จริง ทุกอย่างเริ่มต้นด้วยความรู้สึกไม่สบายในระดับหนึ่ง
พนักงานบางคนในบริษัทประสบปัญหาในการทำงานประจำวันของเขาให้สำเร็จ บางทีฐานผู้ใช้อาจเพิ่มขึ้นและเขาไม่สามารถจัดการด้วยกระบวนการแบบเก่าได้ ผู้บริหารบางคนในบริษัทดูแผ่นงาน Excel และคิดว่าบริษัทกำลังเสียเงินมากเกินไปเนื่องจากมีการยกเลิกผลิตภัณฑ์เป็นจำนวนมาก หรืออาจเป็นคู่แข่งที่เปิดตัวคุณลักษณะของผลิตภัณฑ์ที่ทำให้ลูกค้าออกจากผลิตภัณฑ์ของบริษัทดังกล่าว ผู้ที่ดูกระบวนการ Conversion ทางการตลาดพบว่ามีอัตราการออกจากตลาดสูงในบางช่วง และรู้สึกว่าการเพิ่มประสิทธิภาพอาจช่วยให้เขาบรรลุเป้าหมายรายไตรมาสได้ หรืออาจเป็น 100 เหตุผลที่แตกต่างกันจากการร้องเรียนของลูกค้าจำนวนมากสำหรับปัญหาทั่วไปไปจนถึงคุณลักษณะใหม่ที่ผู้ใช้ส่วนใหญ่ทำแบบสำรวจเมื่อสัปดาห์ที่แล้ว ประเด็นคือ - ทุกอย่างเริ่มต้นด้วยระดับของความรู้สึกไม่สบาย

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

ท – 25 วัน

ถึงเวลาที่ Product Manager จะพิจารณาคำชี้แจงปัญหา เขาไปและพูดคุยกับลูกค้าหรือผู้มีส่วนได้ส่วนเสียภายในที่รายงานความไม่สะดวกและผู้ที่ประสบกับมันจริงๆ ทั้งหมดมีจุดมุ่งหมายเดียว - เพื่อให้แน่ใจว่าเขาได้ระบุคำชี้แจงปัญหา 'ราก' หากขั้นตอนนี้ไม่รอบคอบหรือผู้จัดการผลิตภัณฑ์ใช้เวลาไม่เพียงพอกับสิ่งนี้ คุณลักษณะของผลิตภัณฑ์ที่เกิดจะเปราะบาง บิดเบี้ยว และพบจุดจบอย่างรวดเร็ว
เมื่อ Product Manager ระบุคำชี้แจงปัญหาหลักแล้ว เขาตัดสินใจว่าควรแก้ไขหรือไม่ ความรู้สึกไม่สบายเป็นเรื่องใหญ่จริงหรือหรือว่าเกินจริงหรือแย่กว่านั้นเพิ่งสร้างขึ้น? การแก้ปัญหานี้จะช่วยเพิ่มมูลค่าให้กับลูกค้าและ/หรือบริษัทได้จริงหรือ? การแก้ปัญหาดังกล่าวไม่ได้กำหนดบทลงโทษที่สำคัญกับลูกค้าและ/หรือบริษัทใช่หรือไม่? มีวิธีแก้ไขปัญหานี้ด้วยการปรับแต่งเล็กน้อยในกระบวนการหรือผ่านกิจกรรมใดๆ ที่ไม่ต้องการการเปลี่ยนแปลงผลิตภัณฑ์ เช่น การเปลี่ยนผู้ขาย การต่อรองราคาที่ดีขึ้นจากผู้ขายที่มีอยู่ การขอรับซอฟต์แวร์ของบุคคลที่สามเพื่อแก้ปัญหา การว่าจ้าง พนักงานเพิ่ม การเปลี่ยนแปลงในเนื้อหา กราฟิก ปุ่มเรียกร้องให้ดำเนินการ ฯลฯ?

โดยพื้นฐานแล้ว หากมีวิธีที่เราสามารถได้รับมูลค่าเพิ่มที่คล้ายคลึงกันจากวิธีการที่ไม่เกี่ยวข้องกับการเปลี่ยนแปลงผลิตภัณฑ์ เราจะดำเนินการเปลี่ยนแปลงสิ่งนั้นมากกว่าการเปลี่ยนแปลงใดๆ ในผลิตภัณฑ์ ไม่ว่าจะหมายถึงการเพิ่มหรือลบ เมื่อ Product Manager เชื่อมั่นว่าการแก้ไขคำชี้แจงปัญหาจะให้คุณค่าที่สำคัญ และการเปลี่ยนแปลงระดับผลิตภัณฑ์จะให้ ROI มากขึ้น (โดยพิจารณาจากเวลา เงิน และความพยายาม v/s มูลค่า) มากกว่าการเปลี่ยนแปลงระดับที่ไม่ใช่ผลิตภัณฑ์ ซึ่งเป็นจุดเริ่มต้นของการเปลี่ยนแปลงใหม่ คุณลักษณะของผลิตภัณฑ์ถูกปลูก

ท – 15 วัน

หาก Product Manager มีประสบการณ์มาก่อน เขาอาจเสนอวิธีแก้ปัญหาตามประสบการณ์นั้น อย่างไรก็ตาม นั่นอาจไม่ใช่ทางออกที่ดีที่สุดในทุกกรณี
หากคำชี้แจงปัญหาต้องใช้วิธีแก้ปัญหาด้านเทคนิคขั้นสูง Product Manager จะหารือในสิ่งเดียวกันนี้กับนักพัฒนาซอฟต์แวร์และผู้จัดการด้านวิศวกรรม และรับคำแนะนำเกี่ยวกับวิธีที่ดีที่สุดในการดำเนินการ หากโซลูชันต้องการการเปลี่ยนแปลงระดับการออกแบบ อาจมีการปรึกษาลีด UX อาจเป็นได้ว่า Product Manager และ UX จัดระเบียบการออกแบบ sprint และเลือกโซลูชันที่ผู้ใช้จริงของคุณสมบัตินั้นได้รับการตอบรับอย่างดี บางครั้งปัญหาก็เกี่ยวข้องกับธุรกิจโดยสิ้นเชิง จึงต้องมีการบายอินจากผู้บริหารระดับสูง
ดังนั้น จึงมีหลายวิธีที่สามารถสรุปวิธีแก้ปัญหาได้ แต่เมื่อเป็นเช่นนั้น Product Manager จะรับผิดชอบในการแปลงโซลูชันทางทฤษฎีนั้นเป็นคุณลักษณะของผลิตภัณฑ์ที่ใช้งานอยู่

T = 0 (หรือที่เรียกว่าคุณลักษณะของผลิตภัณฑ์)

เมื่อมีการระบุโซลูชันเฉพาะ ผู้จัดการผลิตภัณฑ์ร่วมกับทีมที่เกี่ยวข้องจะแฮ็กโครงร่างพื้นฐานของโซลูชัน อาจมีหรือไม่มีต้นแบบของการแก้ปัญหา บางครั้งเป็นเพียงแผ่นงาน Excel พื้นฐานที่มีเงื่อนไข 'ถ้า-แล้ว' เขียนว่าเมื่อใดที่จะแสดง CTA เฉพาะต่อผู้ใช้ ฯลฯ
ผู้จัดการผลิตภัณฑ์นำเสนอโซลูชันเป็นคำพูดใน PRD (เอกสารข้อกำหนดผลิตภัณฑ์) ที่เกี่ยวข้อง หากฟีเจอร์มีขนาดเล็ก อาจเป็นเพียงย่อหน้าใน PRD ที่มีอยู่สำหรับฟีเจอร์ที่ใหญ่กว่า บางครั้งคุณลักษณะนี้มีขนาดใหญ่มากจนต้องใช้ PRD ที่สมบูรณ์เพื่อให้รายละเอียดถูกต้อง PRD ดำเนินการโดยทีมที่เกี่ยวข้องและผู้จัดการผลิตภัณฑ์ทำให้แน่ใจว่ามีฉันทามติในวงกว้างเกี่ยวกับคุณลักษณะนี้

T + 15 วัน

คุณลักษณะขนาดเล็กอาจใช้เวลาน้อยกว่าหนึ่งวันในการหยุดนิ่ง ฟีเจอร์ขนาดใหญ่บางครั้งอาจใช้เวลานานกว่า 30 วันเพื่อให้ทุกคนก้าวไปข้างหน้า
โดยเฉลี่ยแล้วจะใช้เวลา 15 วันในการบอกว่านี่คือช่วงเวลาที่คุณลักษณะแรกเกิดได้รับการแนะนำให้รู้จักกับนักพัฒนา การออกแบบที่เหมาะสมและการส่งมอบ PRD จะเกิดขึ้นโดยที่นักพัฒนาที่ทำงานในโครงการจะได้รับแจ้งเกี่ยวกับ 5W (อะไร ทำไม เมื่อไหร่ ที่ไหน ใคร) และกรณีทดสอบ (คุณลักษณะควรทำงานหรือไม่ทำงานอย่างไรเมื่อเผยแพร่) .
ร่วมกับผู้จัดการฝ่ายวิศวกรรม กำหนดกำหนดการเผยแพร่ที่เหมาะสมสำหรับฟีเจอร์นี้จะถูกกำหนดโดยกำหนดเส้นตายว่าการพัฒนาจะสิ้นสุดเมื่อใดเมื่อการทดสอบเริ่มต้น เมื่อจุดบกพร่องที่รายงานจะได้รับการแก้ไข และวันที่เผยแพร่ขั้นสุดท้าย จากนั้นไทม์ไลน์ทั้งหมดจะแบ่งออกเป็น sprint ที่วัดได้ (ปกติจะมีความยาว 15 วัน) เมื่อนักพัฒนาพอใจแล้ว การพัฒนาก็เริ่มขึ้น

T + 30 วัน

วิ่ง 1 สิ้นสุด ฟีเจอร์ผลิตภัณฑ์ส่วนหนึ่งเปิดตัวแล้ว อาจยังไม่ถึงขั้นที่ลูกค้าต้องเผชิญ แต่ทีมส่วนใหญ่ปฏิบัติตามระเบียบวิธีแบบ Agile ในปัจจุบันสำหรับการพัฒนาซอฟต์แวร์ ซึ่งหมายความว่าเราสร้างทีละน้อยและทำซ้ำ ดังนั้น แทนที่จะสร้างฟีเจอร์ขนาดใหญ่ใน 6 เดือนและปล่อยทั้งหมดในคราวเดียว เราแยกส่วนทั้งหมดออกเป็นส่วนอิสระที่สามารถทำงานได้ด้วยตัวเอง (กลุ่มเรื่องราวของผู้ใช้) และพร้อมที่จะตรวจสอบและทำซ้ำอย่างรวดเร็ว
ผู้จัดการผลิตภัณฑ์ตรวจสอบให้แน่ใจว่าไทม์ไลน์การเผยแพร่เป็นไปตามการประชุมและหารือกับผู้จัดการฝ่ายวิศวกรรมที่เกี่ยวข้องที่ทำงานในโครงการทุกวัน ในกรณีที่เกิดความล่าช้า ไทม์ไลน์จะถูกปรับตามนั้น หรือส่วนเล็กๆ ของคุณสมบัติต่างๆ จะลดลงเพื่อให้แน่ใจว่าการเปิดตัวนั้นตรงเวลา หลังจากการวิ่งแต่ละครั้ง ความคืบหน้าจะนำเสนอต่อผู้จัดการผลิตภัณฑ์และผู้มีส่วนได้ส่วนเสียที่เกี่ยวข้องในการประชุม และจะมีการประกาศภายหลังการอนุมัติ
หนึ่งปีของโปรแกรมการจัดการผลิตภัณฑ์ของ UpGrad

T + x วัน

หลังจากจำนวนการวิ่ง 'n' การพัฒนาเสร็จสมบูรณ์และคุณลักษณะทั้งหมดจะหมดลง ไม่จำเป็นที่ลูกค้าจะต้องใช้คุณลักษณะนี้เมื่อเปิดตัวอย่างสมบูรณ์เท่านั้น พวกเขาสามารถใช้งานได้ตั้งแต่เปิดตัวเมื่อสิ้นสุด sprint 1 เอง การปล่อยรอบการวิ่งที่ตามมาแต่ละครั้งจะทำให้คุณลักษณะนี้แข็งแกร่งยิ่งขึ้นและเข้าใกล้สิ่งที่ตั้งใจไว้มากขึ้นเท่านั้น
การเปิดตัวฟีเจอร์นั้นเป็นงานศิลปะและเกี่ยวข้องกับขั้นตอนมากมายที่เราจะข้ามไป และแค่สมมติว่าหลังจากการตีกลองและการตีหน้าอกหลายครั้ง ฟีเจอร์นั้นได้รับการประกาศให้โลกทราบแล้ว นี่อาจซับซ้อนพอ ๆ กับข่าวประชาสัมพันธ์ฉบับเต็มโดยที่ CEO พูดถึงการเปิดตัวใหม่นี้เอง หรืออาจเป็นแค่บางอย่างที่อีเมลถูกส่งไปยังแผนกใดแผนกหนึ่งที่กำลังจะใช้คุณสมบัตินี้และอาจร้องขอใน สถานที่แรก ตอนนี้ที่ฟีเจอร์นี้ออกมาแล้ว มาตั้งชื่อฟีเจอร์นี้กันดีกว่า – Mr. Feature

T + y วัน

แม้หลังจากการเปิดตัวครั้งสุดท้าย บางสิ่งก็ผิดพลาด Mr. Feature ซึ่งครั้งหนึ่งเคยเป็นมันเงาและมีค่า อาจไม่เหมือนเดิมอีกต่อไปและอาจมีหลายสาเหตุ ระยะนี้ในวัฏจักรของผลิตภัณฑ์เป็นเรื่องเกี่ยวกับการสนับสนุนผลิตภัณฑ์ วันหนึ่งที่ดี มีการเปิดตัวอีกรุ่นหนึ่งซึ่งทำให้ Mr. Feature ทำงานในลักษณะที่ไม่ได้ตั้งใจ (หรือที่รู้จักว่ากลายเป็นรถบั๊กกี้) หรืออาจมีการนำฟีเจอร์อื่นออกซึ่งมีการพึ่งพา Mr. Feature และสิ่งนี้ทำให้เกิดพฤติกรรมบั๊กกี้ อาจเป็นไปได้ว่าเมื่อสร้างฟีเจอร์นี้ขึ้นมา เราประเมินจำนวนผู้ใช้ที่จะใช้มันหรือไม่ได้วางแผนกรณีใช้งานทั้งหมดต่ำไป และตอนนี้ฟีเจอร์นี้ไม่สามารถขยายให้ครอบคลุมผู้ใช้หรือกรณีใช้งานจำนวนมากเหล่านี้ได้

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

ผู้จัดการผลิตภัณฑ์พยายามทำความเข้าใจสาเหตุที่แท้จริงของจุดบกพร่อง และจัดกำหนดการการแก้ไขสำหรับรอบการเผยแพร่ถัดไปตามลำดับความสำคัญ คุณสามารถเพิ่มได้ในการวิ่งปัจจุบันหากมีความสำคัญสูงหรือแม้แต่การวิ่งที่ตามมา หลังจากที่จุดบกพร่องได้รับการแก้ไขและเผยแพร่แล้ว Mr. Feature ยังมีชีวิตอยู่เพื่อดูวันอื่น แม้ว่าจะอยู่ในรูปแบบที่ปรับปรุงใหม่ – Mr. Feature 2.0 – ต้องขอบคุณ Product Manager และทีมวิศวกร รุ่งโรจน์!

T + z วัน

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

ไม่ว่าจะด้วยเหตุผลใดก็ตาม จะมีการสื่อสารไปยัง Product Manager (หรือเขาคือผู้ที่เริ่มการสนทนา) ว่าจะไม่ต้องการบริการของ Mr. Feature อีกต่อไป ตอนนี้ Product Manager มีหน้าที่วาง Mr. Feature เพื่อพักผ่อน แม้ว่าก่อนหน้านั้น เขาต้องการให้แน่ใจว่าบางสิ่งเช่นการแจ้งผู้ใช้ที่ใช้ Mr. Feature ว่าจะไม่สามารถใช้ได้จากวันที่กำหนด คุณลักษณะใหม่นี้ทำงานได้ดีก่อนที่จะลบ Mr. Feature ไม่ใช่อย่างอื่น กระแสได้รับผลกระทบเมื่อ Mr. Feature หายไป เป็นต้น

ดังนั้น ถึงเวลาต้องกล่าว RIP กับ Mr. Feature ในอาชีพการจัดการผลิตภัณฑ์ของคุณ คุณจะต้องทำเช่นนี้หลายครั้ง แต่อย่าลืมว่า จุดสิ้นสุดของคุณลักษณะหนึ่งคือจุดเริ่มต้นของอีกคุณลักษณะหนึ่ง และวัฏจักรจะดำเนินต่อไป นั่นคือชีวิตการจัดการผลิตภัณฑ์!

ศึกษา หลักสูตรการจัดการผลิตภัณฑ์ ออนไลน์จากมหาวิทยาลัยชั้นนำของโลก รับ Masters, Executive PGP หรือ Advanced Certificate Programs เพื่อติดตามอาชีพของคุณอย่างรวดเร็ว

โครงการเด่นสำหรับคุณ: โครงการรับรองการคิดเชิงออกแบบจาก Duke CE