การคิดผลิตภัณฑ์สำหรับทีมข้อมูล

คุณเคยเผชิญกับสถานการณ์ใด ๆ ในองค์กรของคุณหรือไม่?

• ระดับ C หรือผู้นำระดับสูงพบว่าแดชบอร์ดที่สำคัญทางธุรกิจไม่ได้รับการอัปเดตเป็นระยะเวลาหนึ่งในการประชุมที่สำคัญ
• ผู้จัดการผลิตภัณฑ์ผู้ บริโภคข้อมูลแจ้งทีมวิเคราะห์ข้อมูลผู้ผลิตข้อมูลว่าดาต้ามาร์ทไม่ได้รับการอัปเดตในช่วง n วันที่ผ่านมา
• ทีมวิศวกรรมซอฟต์แวร์เปลี่ยนสคีมาฐานข้อมูลการผลิตและลืมแจ้งทีมวิศวกรรมข้อมูลให้อัปเดตเหตุการณ์ผู้บริโภคเกี่ยวกับการทดลอง Growth Hacker ที่สำคัญ

ความจริงอันไม่พึงประสงค์

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

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

แต่อะไรคือความแตกต่างระหว่างผลิตภัณฑ์ข้อมูลและโครงการข้อมูล เพื่อตอบคำถามนี้ เราต้องเข้าใจความแตกต่างระหว่างผลิตภัณฑ์และโครงการ!

ผลิตภัณฑ์เทียบกับโครงการ

ฉันชอบคำอธิบายที่สร้างโดยFuturice ;

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

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

จากคำอธิบายเหล่านี้ เราจะยกตัวอย่างโครงการข้อมูลและผลิตภัณฑ์ข้อมูล

• ผลิตภัณฑ์ข้อมูล:สร้างระบบเครื่องมือแนะนำสำหรับเว็บไซต์อีคอมเมิร์ซของคุณเพื่อปรับปรุงการปรับแต่งและการมีส่วนร่วมของลูกค้า ลูกค้ามีส่วนร่วมกับคำแนะนำของคุณ คุณรวบรวมจุดข้อมูล และปรับปรุงโมเดลของคุณ เรื่องนี้ไม่จบ
• โครงการข้อมูล:จัดทำรายงานเฉพาะกิจสำหรับระดับ C ซึ่งมีคำอธิบายและเป้าหมายที่ชัดเจน และคุณรู้ว่าสิ่งนี้จะไม่เกิดขึ้นซ้ำอีกในอนาคต! คุณส่งรายงานเวลา 21.00 น. และโครงการเสร็จสิ้น!

การคิดผลิตภัณฑ์สำหรับผู้เริ่มต้น

ในบทความของเขา“การคิดผลิตภัณฑ์ 101” นเรนทร์ คาตาคำได้ให้คำอธิบายและตัวอย่างที่ดีเกี่ยวกับการคิดผลิตภัณฑ์ ตามที่นเรนทร์;

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

ในโลกของข้อมูล ผู้ใช้ ลูกค้า หรือผู้มีส่วนได้ส่วนเสียของเราอาจคิดว่าพวกเขารู้ดีที่สุดและขอให้เราส่งมอบสิ่งที่พวกเขาต้องการ เช่น รายงานเฉพาะกิจระดับ C การส่งเรื่องที่กำหนดอาจเป็นเรื่องน่าดึงดูดใจ เพราะคุณไม่จำเป็นต้องลงทุนเพิ่มเติมในการวิจัยพื้นที่ปัญหา และคุณมีวิธีแก้ปัญหาอยู่ในใจแล้ว อย่าทำอย่างนั้น! อย่าเป็นคนให้ข้อมูลที่ชี้แนะผู้มีส่วนได้ส่วนเสียให้จิราสร้างตั๋วข้อมูล!

มีข้อผิดพลาดอื่น ๆ อีกมากมายที่คุณอาจตกอยู่และวิธีหลีกเลี่ยง

เริ่มต้นด้วยปัญหาไม่ใช่วิธีแก้ปัญหา

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

ข้อผิดพลาดทั่วไปคือการคิดเกี่ยวกับวิธีแก้ปัญหาและผลิตภัณฑ์ขั้นสุดท้ายในสถานะขั้นกลางโดยไม่มีคำจำกัดความของปัญหาและ KPI ที่เหมาะสมที่เชื่อมโยงกับพวกเขา ดังที่แอชกล่าวไว้ในบทความของเขา เรื่อง Love the Problem , Not Your Solution

หลีกเลี่ยงการเป็นโรงงานคุณลักษณะ

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

แต่สิ่งนี้เกิดขึ้นได้อย่างไร? ทีมผลิตภัณฑ์หรือองค์กรไม่สามารถเลือกคุณสมบัติที่สำคัญได้อย่างไร

• เอฟเฟกต์ HIPPO: HIPPO เป็นตัวย่อและย่อมาจากH ighest P aid Person ’s O pinion ผลระบุว่าความคิดเห็นของบุคคลที่ได้รับค่าตอบแทนสูงสุดจะได้รับการพิจารณามากขึ้นในการตัดสินใจเนื่องจากมีมูลค่าสูงกว่า เรื่องของความเห็นจึงเชื่อมโยงกับเงินเดือนของผู้แสดงความเห็นดังกล่าว ยิ่งเงินเดือนสูง ก็ยิ่งมีความเห็นวิพากษ์มากขึ้น
• พยายามทำให้ทุกคนพอใจ:เมื่อไม่มีวิธีการแบบรวมศูนย์เพื่อจัดลำดับความสำคัญของความคิดริเริ่มและคุณลักษณะต่างๆ วิสัยทัศน์ของทีมข้อมูลของคุณก็ไม่ชัดเจน และผู้มีส่วนได้ส่วนเสียของคุณกำลังกดดันให้คุณส่งมอบสิ่งต่างๆ คุณอาจสูญเสียอำนาจทั้งหมดของคุณในการควบคุมสิ่งต่างๆ และทำให้ทุกคนพอใจ ในตอนท้ายของวัน คุณสร้างสิ่งที่ไม่จำเป็นซึ่งไม่มีใครใช้

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

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

คุณมีแนวโน้มที่จะล้มเหลวหากคุณพัฒนาโครงการ

คุณอยู่ท่ามกลางสถิติที่บอกว่าโครงการข้อมูลของคุณกำลังจะล้มเหลว

• 85% ของโครงการข้อมูลขนาดใหญ่ล้มเหลว ( Gartner , 2017)
• 87% ของโครงการด้านวิทยาศาสตร์ข้อมูลไม่เคยผลิตจริง ( VentureBeat , 2019)
• “ภายในปี 2565 ข้อมูลเชิงลึกเชิงวิเคราะห์เพียง 20% เท่านั้นที่จะส่งมอบผลลัพธ์ทางธุรกิจ” ( Gartner , 2019)

บทสรุป

การคิดผลิตภัณฑ์เป็นความคิดและวัฒนธรรมที่ต้องได้รับการหล่อเลี้ยงในทีมข้อมูล เช่นเดียวกับการเปลี่ยนแปลงความคิดใดๆ ก็ตาม สิ่งนี้ต้องใช้เวลาในการน้อมรับและนำไปใช้ทุกที่ เริ่มต้นเล็ก ๆ เลือกทีมนำร่องหรือโครงการ และเริ่มปฏิบัติต่อพวกเขาในฐานะทีมผลิตภัณฑ์ รวบรวมการเรียนรู้ ปรับปรุง และปรับขนาด ฟังดูเหมือน Product Thinking มากกว่าองค์กรของคุณใช่ไหม? หากคุณกำลังลำบากในการหาจุดเริ่มต้น เพียงเสนอกาแฟให้กับเพื่อนวิศวกรรมของคุณ พวกเขากำลังใช้สิ่งนี้ในช่วง 40 ปีที่ผ่านมา!

ขอบคุณที่อ่านครับ

ในบทความนี้ ฉันพยายามสร้างภาพรวมของการคิดผลิตภัณฑ์สำหรับทีมข้อมูล (ผู้ผลิต) ในบทความหน้า ฉันจะแนะนำผู้เล่นหลักของทีมข้อมูล: Data Product Manager!