How Guru Uses Guru for Product Enablement เรียนรู้ว่าทีมต่างๆ ทั่วทั้งบริษัทสามารถใช้ Guru เพื่อให้ง่ายขึ้นและทำให้การพัฒนาผลิตภัณฑ์ การเปิดตัว และการโปรโมตชัดเจนและสะอาดขึ้น
ความเชี่ยวชาญในผลิตภัณฑ์ไม่ได้เกิดขึ้นในทันที กระบวนการพัฒนาผลิตภัณฑ์ทั้งหมดคือสิ่งที่สร้าง “ผู้เชี่ยวชาญ” รอบฟีเจอร์และฟังก์ชันการทำงานบางอย่าง และเป็นพื้นฐานสำหรับเอกสารทั้งหมดที่มีมาก่อนและตามมาหลังการเปิดตัวของพวกเขา
ทีมที่ใช้ Guru เพื่อการพัฒนาผลิตภัณฑ์ ตระหนักถึงความสำคัญของการมีแหล่งข้อมูลที่เชื่อถือได้เพียงแห่งเดียวเกี่ยวกับความรู้ที่ครอบคลุมทั่วทั้งวงจรการเปิดตัวผลิตภัณฑ์—ตั้งแต่การพัฒนาตั้งแต่เริ่มต้นจนถึงการสนับสนุนและการบำรุงรักษาอย่างต่อเนื่อง โดยการให้ทุกแผนกมีสถานที่ที่ทุกคนตกลงกันไว้อย่างเชื่อถือได้ในการเก็บข้อมูลที่ได้รับการตรวจสอบโดยผู้เชี่ยวชาญ ทุกคนที่เกี่ยวข้องในกระบวนการข้ามฟังก์ชันเหล่านี้สามารถทำงานได้ดีขึ้น มาเดินผ่านการเปิดตัวฟีเจอร์ล่าสุดที่ Guru เป็นตัวอย่างของการพัฒนาผลิตภัณฑ์ในสถานการณ์จริงกันเถอะ
ตลอดเดือนมกราคม ทีม Monetization ที่สร้างขึ้นใหม่ของเรา pod ได้ทำงานในส่วนแรกของการปรับปรุงประสบการณ์การเรียกเก็บเงินใน Guru โครงการนี้เกี่ยวข้องกับทีมพัฒนาผลิตภัณฑ์ตามปกติ—การจัดการผลิตภัณฑ์ การออกแบบ วิศวกรรม และการตลาดผลิตภัณฑ์—รวมถึงผู้มีส่วนได้ส่วนเสียอื่นๆ อีกหลายคน รวมถึงการเงิน การสนับสนุน และการดำเนินงานขาย นี่คือการอัปเดตทางเทคนิคที่ต้องการการสื่อสารและการประสานงานที่แน่นแฟ้นระหว่างทีมที่มีส่วนร่วมทั้งหมด รวมถึงการเตรียมการอย่างมากมายเพื่อให้ฝ่ายที่ติดต่อกับลูกค้าของเราได้พูดคุยเรื่องการเปลี่ยนแปลงนี้ได้อย่างมั่นใจ สามขั้นตอนต่อไปนี้อธิบายวิธีหลักที่เราจะใช้ Guru สำหรับการพัฒนาผลิตภัณฑ์รอบการเปิดตัวฟีเจอร์เช่นนี้
ขั้นตอนที่ 1: การวางแผนฟีเจอร์และการพัฒนา การพัฒนาผลิตภัณฑ์เริ่มต้นขึ้นในทันทีที่โครงการของทีมผลิตภัณฑ์ได้รับไฟเขียว นี่อาจเป็นการปรับปรุงฟังก์ชันการทำงานเล็กน้อย การออกแบบหน้าใหม่ หรือฟีเจอร์ใหม่ทั้งหมด ตั้งแต่ช่วงเวลาที่มีการร่างข้อกำหนดโครงการโดยผู้จัดการผลิตภัณฑ์ (PM) และแชร์กับวิศวกร นักออกแบบ และผู้มีส่วนได้ส่วนเสียคนอื่นๆ ทุกคนจำเป็นต้องเข้าถึงเอกสารที่เชื่อถือได้และทันสมัยจากผู้แต่งหลายคน
การวางแผนของเราเริ่มต้นขึ้นในเดือนธันวาคม โดยที่ผู้จัดการผลิตภัณฑ์ของเราระบุสถานที่สำคัญบางแห่งทั่วทั้งประสบการณ์การเรียกเก็บเงินและการชำระเงินที่ต้องการปรับปรุง จากจุดนั้น พวกเขาจึงหมุนแผนโครงการและเริ่มร่างข้อกำหนดฟีเจอร์พื้นฐานสำหรับโครงการแรกในชุด เมื่อพวกเขาพร้อมที่จะแชร์กับทีม พวกเขาได้กำหนดการประชุม kickoff เพื่อนำเสนอทีมเกี่ยวกับการเปลี่ยนแปลงที่เสนอและหารือเกี่ยวกับระยะเวลา ตั้งแต่นั้นมา เป็นเรื่องสำคัญที่ทุกคนที่เกี่ยวข้องในโครงการจะสามารถเข้าถึงเอกสารที่เกี่ยวข้องทั้งหมด รวมถึงข้อกำหนดโครงการ การออกแบบ เอกสารการเรียกเก็บเงินที่เกี่ยวข้อง และอื่นๆ
เนื่องจากเอกสารเหล่านี้มีการเปลี่ยนแปลงบ่อย และอาจมีการเพิ่มบ่อยตลอดช่วงเริ่มต้นของโครงการ จึงสำคัญที่มีแหล่งข้อมูลที่เชื่อถือได้ที่ทีมจะกลับไปดูได้ เพื่อให้แน่ใจว่าทุกคนมีสถานที่เดียวสำหรับแบ่งปันและเข้าถึงทรัพยากรเหล่านี้ เราจึงสร้าง Active Project Resources Card เพื่อแชร์กับทีม เราวางสิ่งนี้ไว้ใน Monetization Pod Board ซึ่งผู้มีส่วนได้ส่วนเสียที่เหมาะสมทั้งหมดมีสิทธิ์ในการเขียน
ตลอด กระบวนการพัฒนา วิศวกรของเราไม่ต้องกังวลเกี่ยวกับการบุ๊กมาร์กไฟล์การออกแบบหรือการตรวจสอบซ้ำว่าข้อความที่ได้รับในสัปดาห์ที่แล้วยังคงปัจจุบันอยู่หรือไม่ แทนที่จะทำเช่นนั้น พวกเขาสามารถอ้างอิงกลับไปที่ Active Project Resources Card ขณะที่พวกเขาทำงาน ทำให้มั่นใจว่าพวกเขากำลังสร้างจากข้อมูลที่เป็นปัจจุบันที่สุด ดูว่าทีมวิศวกรรมใช้ Guru อย่างไร
ขั้นตอนที่ 2: การเตรียมการเปิดตัว เรามองว่าการเปิดตัวฟีเจอร์เป็นกีฬาทีมที่ Guru เมื่อใกล้ถึงวันสิ้นสุดการพัฒนา เราต้องมั่นใจว่าเราได้ตอบสนองความต้องการทั้งหมด ทดสอบสอบแหล่งข้อมูลที่อาจเป็นจุดเจ็บปวดสำหรับลูกค้า และสื่อสารการเปลี่ยนแปลงที่กำลังจะมาถึงกับทีมที่ติดต่อกับลูกค้าอย่างถูกต้อง เนื่องจากนี่คือขั้นตอนที่ข้อมูลอาจเปลี่ยนแปลงได้อย่างรวดเร็ว การตรวจสอบให้แน่ใจว่าความรู้ทั้งหมดได้รับการตรวจสอบโดยผู้เชี่ยวชาญที่เกี่ยวข้องเป็นสิ่งสำคัญที่สุด
สำหรับโครงการการเรียกเก็บเงินล่าสุด เราได้จัดสรรเวลา 1 สัปดาห์ให้กับทีมและผู้มีส่วนได้ส่วนเสียในการดำเนินการควบคุมคุณภาพ (QA) และทดสอบประสบการณ์ใหม่ของลูกค้าก่อนที่จะเปิดให้บริการ เนื่องจากนี่เป็นโครงการที่เกี่ยวข้องกับเทคนิคโดยเฉพาะ มีขั้นตอนหลายอย่างในการตั้งค่าสิ่งแวดล้อมและเตรียมพร้อมสำหรับการทดสอบ รวมถึงการเปิดใช้งานฟีเจอร์และการทำงานผ่านชุดขั้นตอนตรวจสอบซ้ำเฉพาะ เพื่อให้แน่ใจว่าทุกคนมีข้อมูลทั้งหมดที่จำเป็นในการเข้าร่วมการทดสอบ ทีมวิศวกรรมของเราได้สร้าง Card พร้อมคำแนะนำโดยละเอียดสำหรับการเข้าร่วม QA เราได้ส่ง Card นี้ไปยัง Pod และผู้มีส่วนได้ส่วนเสียผ่าน การประกาศ เพื่อให้แน่ใจว่าพวกเขาได้อ่านก่อนที่พวกเขาจะเริ่มการทดสอบ
ในขณะที่ QA กำลังดำเนินการอยู่ สิ่งสำคัญอีกครั้งคือการแจ้งเตือนทีมที่ติดต่อกับลูกค้าของเราถึงการเปลี่ยนแปลงที่กำลังจะเกิดขึ้นเพื่อเตรียมพวกเขาสำหรับคำถามที่ผู้มีโอกาสเป็นลูกค้าหรือทางลูกค้าอาจมี ในขณะที่การเปลี่ยนแปลงเหล่านี้มีแนวโน้มที่จะมุ่งเน้นไปที่ความสามารถในการใช้งานและความเชื่อถือได้ (ซึ่งต่างจากการเปลี่ยนแปลงอินเทอร์เฟซขนาดใหญ่) บางส่วนของ ประสบการณ์การเรียกเก็บเงิน แบบเก่าจะมีการปรับเปลี่ยนในโครงการนี้ เพื่อสื่อสารการเปลี่ยนแปลงเหล่านี้ด้วยเวลามากพอที่จะแนะนำและถามคำถาม เราจึงปรับปรุง Card ข้อมูลการชำระเงินของเราให้เป็นรุ่นใหม่
คุณจะสังเกตเห็นว่านี่คือครั้งแรกในกระบวนการที่เราใช้คำว่า refresh แทนที่จะเป็น create, และนี่คือการตั้งใจ เราจะใช้ Card ข้อมูลการชำระเงิน เป็นแหล่งข้อมูลที่เป็นปัจจุบันสำหรับฟีเจอร์ที่ทีมติดต่อกับลูกค้าใช้ ซึ่งหมายความว่ามีอยู่ตลอดเวลาสำหรับฟีเจอร์ที่ใช้งานทั้งหมด
เมื่อเราอัปเดตและปรับปรุงฟีเจอร์ที่มีอยู่ เราจะอัปเดตและปรับปรุง Card ฟีเจอร์ตามที่จำเป็น นี่ช่วยป้องกันปัญหาเก่าที่ผู้แทนการขายไม่แน่ใจว่ากำลังดูเอกสารที่ล้าสมัยเกี่ยวกับฟีเจอร์และกส่งข้อความไปยังวิศวกรอย่างตื่นตระหนกในขณะที่อยู่บนสายโทรศัพท์ พวกเขาสามารถมั่นใจได้ว่า Card เกี่ยวกับหน้าใบเรียกเก็บเงินที่พวกเขาอิงจากเมื่อปีที่แล้วจะยังคงถูกต้องในปีนี้ เนื่องจากได้รับการตรวจสอบโดยทีมที่ทำการส่งเสริม
ขั้นตอนที่ 3: การเปิดตัวและหลังจากนั้น การใช้งานที่เห็นได้ชัดเจนที่สุดของการพัฒนาผลิตภัณฑ์อาจเกี่ยวข้องกับการเปิดตัวฟีเจอร์ใหม่หรือที่ปรับปรุง จากภาพรวมเช่น Card สรุปฟีเจอร์ที่กล่าวถึงข้างต้นไปจนถึงคำถามและคำตอบเฉพาะทางด้านเทคนิค มีข้อวางแผนมากมายที่ใช้เพื่อให้ทีมติดต่อกับลูกค้ามีสิ่งที่ต้องการเพื่อขายและสนับสนุนการเปิดตัวแต่ละครั้ง และเมื่อฟีเจอร์มีการเปลี่ยนแปลงและปรับปรุงตามเวลา เอกสารทั้งหมดจะต้องได้รับการอัปเดตและสะท้อนสถานะปัจจุบันของผลิตภัณฑ์ให้ถูกต้อง
ไม่ใช่เรื่องแปลกที่หน้าใบเรียกเก็บเงินจะซับซ้อนและมีมิติมาก ทำให้มีคำถามที่อาจเกิดขึ้นนานนับไม่ถ้วนที่ลูกค้าอาจมีเมื่อพวกเขาจบบริการซื้อสินค้า ในขณะที่ประสบการณ์การเรียกเก็บของเราไม่ได้เป็นสิ่งที่ทีมขายของเราต้องพูดคุยในรายละเอียดมากนัก แต่เป็นพื้นที่ที่ทีมสนับสนุนของเรามักช่วยเหลือลูกค้าในการนำทาง เพื่อเตรียมความพร้อมสำหรับการเปิดตัวนี้และการปรับปรุงเพิ่มเติมที่จะเกิดขึ้นกับประสบการณ์การชำระเงิน ทีมวิศวกรรมของเราได้ทำงานร่วมกับแชมป์ทีมสนับสนุนลูกค้าเพื่อรวบรวมรายการคำถามที่พบบ่อยทางเทคนิค ซึ่งจะมีการเพิ่มเติมให้เมื่อมีคำถามใหม่เกิดขึ้น นี่ไม่เพียงแต่จะช่วยให้ทีมสนับสนุน แต่ยังช่วยใครก็ตามที่ตอบคำถามจากลูกค้าเกี่ยวกับการเรียกเก็บเงินให้มีสถานที่ที่ชัดเจนในการตรวจสอบก่อนที่จะติดต่อกับทีมของเรา (และจากนั้นจึงช่วยเพิ่มไปยัง Card คำถามที่พบบ่อยด้านเทคนิค !)
นอกเหนือจากการรักษา Card คำถามที่พบบ่อยให้เป็นปัจจุบันเมื่อมีการพัฒนา ฟีเจอร์บล็อกข้อมูลจะต้องได้รับการดูแลให้มีความสดใหม่เช่นกัน นอกเหนือจากการระบุวันที่เปิดตัวอย่างเป็นทางการและประเด็นการพูดคุยที่สำคัญเกี่ยวกับประสบการณ์การเรียกเก็บเงินใหม่ เราจะมีลิงก์ไปยัง Card และทรัพยากรที่เกี่ยวข้องอื่น ๆ เช่นโพสต์บล็อกนี้ โดยการสร้างแหล่งข้อมูลครบวงจรในการเข้าถึงข้อมูลทั้งหมดเกี่ยวกับฟีเจอร์ เราสร้างความมั่นใจให้กับทีมที่ติดต่อกับลูกค้าเพื่อพูดคุยกับลูกค้าและผู้มีโอกาสเป็นลูกค้าด้วยมุมมองที่ได้รับข้อมูลอย่างเต็มที่
เพื่อปิดการวนรอบนี้ เราไม่สามารถลืมว่า ข้อเสนอแนะแบบตลาดและลูกค้าเล่นบทบาทสำคัญในวงจรการพัฒนาผลิตภัณฑ์ ทีมของเรานำนวัตกรรมฟีเจอร์ใหม่และที่ปรับปรุงไปยังลูกค้าเดิมและตลาดของเรา เราจะรวบรวมข้อมูลเชิงลึกที่มีค่าสำหรับสิ่งที่ช่วยให้พวกเขาทำงานได้ดีขึ้น และสิ่งที่พวกเขาหวังว่าจะให้เรามุ่งเน้น การบันทึกและแชร์ข้อมูลนี้กับทีมผลิตภัณฑ์ของเราเป็นส่วนสำคัญของกระบวนการพัฒนาที่วนเวียน และช่วยให้เราส่งมอบคุณค่าสูงสุดให้กับลูกค้าของเรา และเอกสารเกี่ยวกับวิธีการแชร์รูปแบบการตอบกลับที่แตกต่างกัน (การบันทึกการโทร อีเมล เป็นต้น) จะถูกเก็บใน—คุณเดาได้เลย—Guru
ความเชี่ยวชาญในผลิตภัณฑ์ไม่ได้เกิดขึ้นในทันที กระบวนการพัฒนาผลิตภัณฑ์ทั้งหมดคือสิ่งที่สร้าง “ผู้เชี่ยวชาญ” รอบฟีเจอร์และฟังก์ชันการทำงานบางอย่าง และเป็นพื้นฐานสำหรับเอกสารทั้งหมดที่มีมาก่อนและตามมาหลังการเปิดตัวของพวกเขา
ทีมที่ใช้ Guru เพื่อการพัฒนาผลิตภัณฑ์ ตระหนักถึงความสำคัญของการมีแหล่งข้อมูลที่เชื่อถือได้เพียงแห่งเดียวเกี่ยวกับความรู้ที่ครอบคลุมทั่วทั้งวงจรการเปิดตัวผลิตภัณฑ์—ตั้งแต่การพัฒนาตั้งแต่เริ่มต้นจนถึงการสนับสนุนและการบำรุงรักษาอย่างต่อเนื่อง โดยการให้ทุกแผนกมีสถานที่ที่ทุกคนตกลงกันไว้อย่างเชื่อถือได้ในการเก็บข้อมูลที่ได้รับการตรวจสอบโดยผู้เชี่ยวชาญ ทุกคนที่เกี่ยวข้องในกระบวนการข้ามฟังก์ชันเหล่านี้สามารถทำงานได้ดีขึ้น มาเดินผ่านการเปิดตัวฟีเจอร์ล่าสุดที่ Guru เป็นตัวอย่างของการพัฒนาผลิตภัณฑ์ในสถานการณ์จริงกันเถอะ
ตลอดเดือนมกราคม ทีม Monetization ที่สร้างขึ้นใหม่ของเรา pod ได้ทำงานในส่วนแรกของการปรับปรุงประสบการณ์การเรียกเก็บเงินใน Guru โครงการนี้เกี่ยวข้องกับทีมพัฒนาผลิตภัณฑ์ตามปกติ—การจัดการผลิตภัณฑ์ การออกแบบ วิศวกรรม และการตลาดผลิตภัณฑ์—รวมถึงผู้มีส่วนได้ส่วนเสียอื่นๆ อีกหลายคน รวมถึงการเงิน การสนับสนุน และการดำเนินงานขาย นี่คือการอัปเดตทางเทคนิคที่ต้องการการสื่อสารและการประสานงานที่แน่นแฟ้นระหว่างทีมที่มีส่วนร่วมทั้งหมด รวมถึงการเตรียมการอย่างมากมายเพื่อให้ฝ่ายที่ติดต่อกับลูกค้าของเราได้พูดคุยเรื่องการเปลี่ยนแปลงนี้ได้อย่างมั่นใจ สามขั้นตอนต่อไปนี้อธิบายวิธีหลักที่เราจะใช้ Guru สำหรับการพัฒนาผลิตภัณฑ์รอบการเปิดตัวฟีเจอร์เช่นนี้
ขั้นตอนที่ 1: การวางแผนฟีเจอร์และการพัฒนา การพัฒนาผลิตภัณฑ์เริ่มต้นขึ้นในทันทีที่โครงการของทีมผลิตภัณฑ์ได้รับไฟเขียว นี่อาจเป็นการปรับปรุงฟังก์ชันการทำงานเล็กน้อย การออกแบบหน้าใหม่ หรือฟีเจอร์ใหม่ทั้งหมด ตั้งแต่ช่วงเวลาที่มีการร่างข้อกำหนดโครงการโดยผู้จัดการผลิตภัณฑ์ (PM) และแชร์กับวิศวกร นักออกแบบ และผู้มีส่วนได้ส่วนเสียคนอื่นๆ ทุกคนจำเป็นต้องเข้าถึงเอกสารที่เชื่อถือได้และทันสมัยจากผู้แต่งหลายคน
การวางแผนของเราเริ่มต้นขึ้นในเดือนธันวาคม โดยที่ผู้จัดการผลิตภัณฑ์ของเราระบุสถานที่สำคัญบางแห่งทั่วทั้งประสบการณ์การเรียกเก็บเงินและการชำระเงินที่ต้องการปรับปรุง จากจุดนั้น พวกเขาจึงหมุนแผนโครงการและเริ่มร่างข้อกำหนดฟีเจอร์พื้นฐานสำหรับโครงการแรกในชุด เมื่อพวกเขาพร้อมที่จะแชร์กับทีม พวกเขาได้กำหนดการประชุม kickoff เพื่อนำเสนอทีมเกี่ยวกับการเปลี่ยนแปลงที่เสนอและหารือเกี่ยวกับระยะเวลา ตั้งแต่นั้นมา เป็นเรื่องสำคัญที่ทุกคนที่เกี่ยวข้องในโครงการจะสามารถเข้าถึงเอกสารที่เกี่ยวข้องทั้งหมด รวมถึงข้อกำหนดโครงการ การออกแบบ เอกสารการเรียกเก็บเงินที่เกี่ยวข้อง และอื่นๆ
เนื่องจากเอกสารเหล่านี้มีการเปลี่ยนแปลงบ่อย และอาจมีการเพิ่มบ่อยตลอดช่วงเริ่มต้นของโครงการ จึงสำคัญที่มีแหล่งข้อมูลที่เชื่อถือได้ที่ทีมจะกลับไปดูได้ เพื่อให้แน่ใจว่าทุกคนมีสถานที่เดียวสำหรับแบ่งปันและเข้าถึงทรัพยากรเหล่านี้ เราจึงสร้าง Active Project Resources Card เพื่อแชร์กับทีม เราวางสิ่งนี้ไว้ใน Monetization Pod Board ซึ่งผู้มีส่วนได้ส่วนเสียที่เหมาะสมทั้งหมดมีสิทธิ์ในการเขียน
ตลอด กระบวนการพัฒนา วิศวกรของเราไม่ต้องกังวลเกี่ยวกับการบุ๊กมาร์กไฟล์การออกแบบหรือการตรวจสอบซ้ำว่าข้อความที่ได้รับในสัปดาห์ที่แล้วยังคงปัจจุบันอยู่หรือไม่ แทนที่จะทำเช่นนั้น พวกเขาสามารถอ้างอิงกลับไปที่ Active Project Resources Card ขณะที่พวกเขาทำงาน ทำให้มั่นใจว่าพวกเขากำลังสร้างจากข้อมูลที่เป็นปัจจุบันที่สุด ดูว่าทีมวิศวกรรมใช้ Guru อย่างไร
ขั้นตอนที่ 2: การเตรียมการเปิดตัว เรามองว่าการเปิดตัวฟีเจอร์เป็นกีฬาทีมที่ Guru เมื่อใกล้ถึงวันสิ้นสุดการพัฒนา เราต้องมั่นใจว่าเราได้ตอบสนองความต้องการทั้งหมด ทดสอบสอบแหล่งข้อมูลที่อาจเป็นจุดเจ็บปวดสำหรับลูกค้า และสื่อสารการเปลี่ยนแปลงที่กำลังจะมาถึงกับทีมที่ติดต่อกับลูกค้าอย่างถูกต้อง เนื่องจากนี่คือขั้นตอนที่ข้อมูลอาจเปลี่ยนแปลงได้อย่างรวดเร็ว การตรวจสอบให้แน่ใจว่าความรู้ทั้งหมดได้รับการตรวจสอบโดยผู้เชี่ยวชาญที่เกี่ยวข้องเป็นสิ่งสำคัญที่สุด
สำหรับโครงการการเรียกเก็บเงินล่าสุด เราได้จัดสรรเวลา 1 สัปดาห์ให้กับทีมและผู้มีส่วนได้ส่วนเสียในการดำเนินการควบคุมคุณภาพ (QA) และทดสอบประสบการณ์ใหม่ของลูกค้าก่อนที่จะเปิดให้บริการ เนื่องจากนี่เป็นโครงการที่เกี่ยวข้องกับเทคนิคโดยเฉพาะ มีขั้นตอนหลายอย่างในการตั้งค่าสิ่งแวดล้อมและเตรียมพร้อมสำหรับการทดสอบ รวมถึงการเปิดใช้งานฟีเจอร์และการทำงานผ่านชุดขั้นตอนตรวจสอบซ้ำเฉพาะ เพื่อให้แน่ใจว่าทุกคนมีข้อมูลทั้งหมดที่จำเป็นในการเข้าร่วมการทดสอบ ทีมวิศวกรรมของเราได้สร้าง Card พร้อมคำแนะนำโดยละเอียดสำหรับการเข้าร่วม QA เราได้ส่ง Card นี้ไปยัง Pod และผู้มีส่วนได้ส่วนเสียผ่าน การประกาศ เพื่อให้แน่ใจว่าพวกเขาได้อ่านก่อนที่พวกเขาจะเริ่มการทดสอบ
ในขณะที่ QA กำลังดำเนินการอยู่ สิ่งสำคัญอีกครั้งคือการแจ้งเตือนทีมที่ติดต่อกับลูกค้าของเราถึงการเปลี่ยนแปลงที่กำลังจะเกิดขึ้นเพื่อเตรียมพวกเขาสำหรับคำถามที่ผู้มีโอกาสเป็นลูกค้าหรือทางลูกค้าอาจมี ในขณะที่การเปลี่ยนแปลงเหล่านี้มีแนวโน้มที่จะมุ่งเน้นไปที่ความสามารถในการใช้งานและความเชื่อถือได้ (ซึ่งต่างจากการเปลี่ยนแปลงอินเทอร์เฟซขนาดใหญ่) บางส่วนของ ประสบการณ์การเรียกเก็บเงิน แบบเก่าจะมีการปรับเปลี่ยนในโครงการนี้ เพื่อสื่อสารการเปลี่ยนแปลงเหล่านี้ด้วยเวลามากพอที่จะแนะนำและถามคำถาม เราจึงปรับปรุง Card ข้อมูลการชำระเงินของเราให้เป็นรุ่นใหม่
คุณจะสังเกตเห็นว่านี่คือครั้งแรกในกระบวนการที่เราใช้คำว่า refresh แทนที่จะเป็น create, และนี่คือการตั้งใจ เราจะใช้ Card ข้อมูลการชำระเงิน เป็นแหล่งข้อมูลที่เป็นปัจจุบันสำหรับฟีเจอร์ที่ทีมติดต่อกับลูกค้าใช้ ซึ่งหมายความว่ามีอยู่ตลอดเวลาสำหรับฟีเจอร์ที่ใช้งานทั้งหมด
เมื่อเราอัปเดตและปรับปรุงฟีเจอร์ที่มีอยู่ เราจะอัปเดตและปรับปรุง Card ฟีเจอร์ตามที่จำเป็น นี่ช่วยป้องกันปัญหาเก่าที่ผู้แทนการขายไม่แน่ใจว่ากำลังดูเอกสารที่ล้าสมัยเกี่ยวกับฟีเจอร์และกส่งข้อความไปยังวิศวกรอย่างตื่นตระหนกในขณะที่อยู่บนสายโทรศัพท์ พวกเขาสามารถมั่นใจได้ว่า Card เกี่ยวกับหน้าใบเรียกเก็บเงินที่พวกเขาอิงจากเมื่อปีที่แล้วจะยังคงถูกต้องในปีนี้ เนื่องจากได้รับการตรวจสอบโดยทีมที่ทำการส่งเสริม
ขั้นตอนที่ 3: การเปิดตัวและหลังจากนั้น การใช้งานที่เห็นได้ชัดเจนที่สุดของการพัฒนาผลิตภัณฑ์อาจเกี่ยวข้องกับการเปิดตัวฟีเจอร์ใหม่หรือที่ปรับปรุง จากภาพรวมเช่น Card สรุปฟีเจอร์ที่กล่าวถึงข้างต้นไปจนถึงคำถามและคำตอบเฉพาะทางด้านเทคนิค มีข้อวางแผนมากมายที่ใช้เพื่อให้ทีมติดต่อกับลูกค้ามีสิ่งที่ต้องการเพื่อขายและสนับสนุนการเปิดตัวแต่ละครั้ง และเมื่อฟีเจอร์มีการเปลี่ยนแปลงและปรับปรุงตามเวลา เอกสารทั้งหมดจะต้องได้รับการอัปเดตและสะท้อนสถานะปัจจุบันของผลิตภัณฑ์ให้ถูกต้อง
ไม่ใช่เรื่องแปลกที่หน้าใบเรียกเก็บเงินจะซับซ้อนและมีมิติมาก ทำให้มีคำถามที่อาจเกิดขึ้นนานนับไม่ถ้วนที่ลูกค้าอาจมีเมื่อพวกเขาจบบริการซื้อสินค้า ในขณะที่ประสบการณ์การเรียกเก็บของเราไม่ได้เป็นสิ่งที่ทีมขายของเราต้องพูดคุยในรายละเอียดมากนัก แต่เป็นพื้นที่ที่ทีมสนับสนุนของเรามักช่วยเหลือลูกค้าในการนำทาง เพื่อเตรียมความพร้อมสำหรับการเปิดตัวนี้และการปรับปรุงเพิ่มเติมที่จะเกิดขึ้นกับประสบการณ์การชำระเงิน ทีมวิศวกรรมของเราได้ทำงานร่วมกับแชมป์ทีมสนับสนุนลูกค้าเพื่อรวบรวมรายการคำถามที่พบบ่อยทางเทคนิค ซึ่งจะมีการเพิ่มเติมให้เมื่อมีคำถามใหม่เกิดขึ้น นี่ไม่เพียงแต่จะช่วยให้ทีมสนับสนุน แต่ยังช่วยใครก็ตามที่ตอบคำถามจากลูกค้าเกี่ยวกับการเรียกเก็บเงินให้มีสถานที่ที่ชัดเจนในการตรวจสอบก่อนที่จะติดต่อกับทีมของเรา (และจากนั้นจึงช่วยเพิ่มไปยัง Card คำถามที่พบบ่อยด้านเทคนิค !)
นอกเหนือจากการรักษา Card คำถามที่พบบ่อยให้เป็นปัจจุบันเมื่อมีการพัฒนา ฟีเจอร์บล็อกข้อมูลจะต้องได้รับการดูแลให้มีความสดใหม่เช่นกัน นอกเหนือจากการระบุวันที่เปิดตัวอย่างเป็นทางการและประเด็นการพูดคุยที่สำคัญเกี่ยวกับประสบการณ์การเรียกเก็บเงินใหม่ เราจะมีลิงก์ไปยัง Card และทรัพยากรที่เกี่ยวข้องอื่น ๆ เช่นโพสต์บล็อกนี้ โดยการสร้างแหล่งข้อมูลครบวงจรในการเข้าถึงข้อมูลทั้งหมดเกี่ยวกับฟีเจอร์ เราสร้างความมั่นใจให้กับทีมที่ติดต่อกับลูกค้าเพื่อพูดคุยกับลูกค้าและผู้มีโอกาสเป็นลูกค้าด้วยมุมมองที่ได้รับข้อมูลอย่างเต็มที่
เพื่อปิดการวนรอบนี้ เราไม่สามารถลืมว่า ข้อเสนอแนะแบบตลาดและลูกค้าเล่นบทบาทสำคัญในวงจรการพัฒนาผลิตภัณฑ์ ทีมของเรานำนวัตกรรมฟีเจอร์ใหม่และที่ปรับปรุงไปยังลูกค้าเดิมและตลาดของเรา เราจะรวบรวมข้อมูลเชิงลึกที่มีค่าสำหรับสิ่งที่ช่วยให้พวกเขาทำงานได้ดีขึ้น และสิ่งที่พวกเขาหวังว่าจะให้เรามุ่งเน้น การบันทึกและแชร์ข้อมูลนี้กับทีมผลิตภัณฑ์ของเราเป็นส่วนสำคัญของกระบวนการพัฒนาที่วนเวียน และช่วยให้เราส่งมอบคุณค่าสูงสุดให้กับลูกค้าของเรา และเอกสารเกี่ยวกับวิธีการแชร์รูปแบบการตอบกลับที่แตกต่างกัน (การบันทึกการโทร อีเมล เป็นต้น) จะถูกเก็บใน—คุณเดาได้เลย—Guru
ได้สัมผัสพลังของแพลตฟอร์ม Guru โดยตรง - เข้าร่วมทัวร์ผลิตภัณฑ์ของเราอย่างแบบอินเทอร์แอคทีฟ
ไปทัวร์