เรื่องราวจากหนังสือ The Product-led Organization EP.1
สวัสดีค่ะทุกคน พอดีได้หนังสือเล่มนี้เป็นของขวัญปีใหม่จากพี่เต๋า ด้วยความที่อ่านแล้วชอบมาก ซึ่งเล่มนี้ก็อ่านซ้ำถึง 2 รอบด้วยกัน แต่ด้วยเวลาที่ผ่านไปและประสบการณ์ที่พบเจอนั้นแปลกใหม่อยู่เรื่อยๆ ทำให้บริบทของหนังสือที่เราตีความก็ต่างออกไป ก็เลยอยากจะนำมาแบ่งปันให้ทุกคนได้อ่านเรื่องราวนี้ไปด้วยกันค่ะ
หนังสือเล่มนี้ได้ถูกเรียบเรียงโดย Todd Olson ( CEO/Co-Founder of Pendo ) เขาเป็นผู้พัฒนาซอฟต์แวร์ที่นำเอากระบวนท่าต่างๆมาช่วยในการบริหารจัดการ หนังสือเล่มนี้จะรวบรวมประสบการณ์ที่เขามีจากการ Management และนำเสนอเครื่องมือที่จะช่วยให้คุณได้นำมาวางแผนพัฒนา Product โดยยึดคำมั่นที่ว่า
“ Drive growth by putting product at the center of your customer experience ”
หนังสือเล่มนี้จะแบ่งเป็น 3 บทใหญ่ๆ คือ
- Leveraging Data to Create a Great Product
- Product is the Center of the Customer Experience
- A New Way of Delivery Product
โดยใน Ep.1 นี้เราจะมาเริ่มกันที่บทแรก Leveraging Data to Create a Great Product
บทแรกนั้นได้แรงบันดาลใจมาจากประสบการณ์ที่เขาและทีมทำงานกันอย่างหนักหน่วงโดยใช้เวลากว่า 9 เดือนในการปล่อยผลิตภัณฑ์ที่มั่นใจแล้วว่า Pain point ของลูกค้านั้นคืออะไร โดยกระแสตอบรับผลิตภัณฑ์จากลูกค้า พนักงานขายและนักวิเคราะห์ก็เป็นไปด้วยดี แต่หลังจากนั้น 6 เดือน กลับพบว่าจากข้อมูลการใช้งาน ( Usage Data ) มีเพียงลูกค้าไม่กี่คนเท่านั้นที่ยังคงใช้งานอยู่ ยิ่งไปกว่านั้นข้อมูลการเพิ่มขึ้นของผู้ใช้ใหม่ ( Retention of new user ) ก็มีค่าต่ำมากๆ กล่าวอีกนัยหนึ่งก็คือ ผลิตภัณฑ์นี้มันล้มเหลวนั่นเอง
เป็นเหตุให้เขาเรียนรู้ว่า เราต้องประกาศชัยชนะโดยการอ้างอิงจากหลักฐานชิ้นเล็กชิ้นน้อย ไม่ใช่จากการวัดผลเชิงปริมาณที่ชัดเจน ( Quantitative ) การที่เราปรบมือและประโคมแตรฉลองไม่ได้แปลว่าผลิตภัณฑ์จะดีเสมอไป เราต้องวัดผลจากมูลค่า ( Value ) ของผลิตภัณฑ์ที่ส่งไปยังลูกค้าจริงๆ เป็นเหตุให้เราต้องเลือกตัวชี้วัดที่ถูกเหมาะ โดยคุณควรจะเริ่มต้นด้วยการสร้างเป้าหมาย ( Goal ) ในใจ ด้วยคำถามว่าทำไม ?( Why )
Chapter.1 Start with the End in Mind
การเริ่มต้นจากคำถามว่า ทำไม ก็เพื่ออยากจะให้เราตั้งเป้าหมายที่ชัดเจนว่า อะไรคือสิ่งที่คุณหวังว่าจะทำให้สำเร็จ ต่อจากนั้นคุณจึงจะนึกภาพออก ( visualize ) ว่าความสำเร็จของคุณหน้าตาอย่างไร และจะทราบได้ว่าเราอยู่ตรงไหนแล้วของเส้นทางที่จะไปสู่ความสำเร็จ
ผู้เขียนได้แนะนำเครื่องมือที่ชื่อว่า SMART มาใช้ในการตั้งเป้าหมาย
Specific ( เจาะจง ) : อะไรที่จะต้องทำให้สำเร็จ และ เราจะต้องทำกิจกรรมอะไรบ้าง ?
Measurable ( วัดผลได้ ) : เราจะได้รับแหล่งข้อมูลที่บอกว่างานกำลังดำเนินการอยู่ได้อย่างไร ? เราจะวัดผลการดำเนินการได้อย่างไร ?
Attainable ( บรรลุผลได้ ) : เป้าหมายเป็นไปได้จริงไหม ? เราไม่ปกปิดความจริงแต่ก็ไม่ตั้งเป้าหมายว่าจะล้มเหลวเสมอไป
Relevant ( เกี่ยวข้อง ) : เป้าหมายที่ตั้งไว้เป็นบันไดไปสู่กลยุทธ์เป้าหมายทางธุรกิจหรือไม่ ?
Time-bound ( กำหนดเวลา ) : คุณมีการระบุกรอบเวลาเพื่อจะบรรลุเป้าหมายหรือยัง ?
SMART เป็นเพียงหนึ่งในเครื่องมือที่ช่วยในการสร้างเป้าหมายของงานที่จะไม่นำไปสู่ความผิดพลาด เราจะพาคุณไปรู้จักเครื่องมืออื่นๆที่จะช่วยคุณได้ในบทต่อจากนี้
SETTING STRATEGIC GOALS
Making a Business Case
การกำหนดกรณีที่จะเกิดขึ้นจะช่วยให้เราอธิบายเหตุผลของงานแต่ละชิ้นได้ โดยทั่วไปมักจะเขียนออกมาเป็นประโยคยาวๆ หรือ กระบวนการที่ยุ่งยาก ตัวอย่างเช่น Powerpoint 100 หน้า ที่ถูกสร้างขึ้นโดยทีมผู้บริหาร เป็นต้น ซึ่งมันไม่จำเป็นเสมอไปว่าคุณต้องเขียนออกมาเป็นกรณีย่อยๆ คุณอาจจะเขียนออกมาเพียง 1 หน้ากระดาษนั่นก็ยังดีกว่าการไม่มีอะไรสักอย่างเลย
คำพูดของ Mark Twain ( นักเขียนชื่อดังชาวอเมริกัน ) ที่ว่า
“ If I had more time , I would have written a shorter letter.”
ถ้าผมมีเวลามากกว่านี้ ผมจะเขียนจดหมายที่สั้นกว่านี้
การที่เราให้ความความสนใจกับ Business case มากขึ้นจะทำให้เป้าหมายของเราชัดเจนและมีความคิดที่เฉียบแหลมยิ่งขึ้น อย่าเสียเวลาไปกับ phase นี้มากเกินไปแต่ก็อย่าละเลยอีกเช่นกัน เพื่อความมั่นใจว่าคุณกำลังตอบคำถามหลักๆอยู่ งั้นลองเช็คกับคำถามเหล่านี้ดูนะ
Who is the Target Audience ?
- ใครคือกลุ่มที่คุณสร้างสินค้าหรือบริการเพื่อพวกเขาเหล่านั้น
- เขาอยู่ในตำแหน่งไหนของห่วงโซ่คุณค่า ( Value chain ) และกระบวนการตัดสินใจ ( Decision-making process )
- เขาคือผู้ซื้อของเราจริงๆใช่หรือไม่
หรือคุณอาจจะกำลังสร้างสิ่งหนึ่งเพื่อคนกลุ่มหนึ่งด้วยความคาดหวังที่ว่าจะถูกซื้อโดยบุคคลอีกกลุ่มก็เป็นได้ เช่น การสร้างสินค้าสำหรับเด็กในขณะที่คนซื้อคือพ่อแม่ของเขา หรือ การสร้างโฆษณามาเพื่อผู้ชมแต่นักโฆษณาเป็นคนซื้อ ในโลกของธุรกิจแบบ B2B ( Business to Business ) กลุ่มธุรกิจประเภทไหนที่อยู่ในเป้าหมายของคุณ ? ลักษณะของธุรกิจพวกเขาเป็นอย่างไร ?
ค่อนข้างยากที่จะระบุเอกสารว่า “ใคร” ในช่วงแรกของการพัฒนาผลิตภัณฑ์ อาจจะทำให้คุณวัดผลที่ผิดพลาดได้ การนำ Persona poster เข้ามาใช้ระบุลักษณะของกลุ่มผู้ใช้งาน ด้วยการระบุภาพ รายละเอียดที่เจาะจงจะช่วยสรุปข้อมูลผู้ใช้งานให้มีความสมจริงมากขึ้น ประกอบกับข้อมูลที่พอจะทำให้ทีมพัฒนารู้สึกเหมือนว่าเขารู้จักกลุ่มผู้ใช้งานนั้นๆ
What Pain is it Addressing ?
ผลิตภัณฑ์ที่ไม่ได้แก้ปัญหาสำคัญก็คงจะถูกลิขิตมาเป็นถังขยะดีๆนี้เอง ไม่บ่อยนักที่เราจะเห็นว่าทีม commit ว่าจะพัฒนาผลิตภัณฑ์โดยปราศจากความเชื่อที่ว่าพวกเขากำลังแก้ปัญหาบางอย่างอยู่ อย่างไรก็ตาม จำนวนและความถี่ของปัญหาอาจส่งผลโดยตรงกับความเหมาะสม
ลองคิดตามว่าการตอบ Value of the Problem คืออะไร จากการถามว่าต้องการแอสไพริน ( เจ็บปวดน้อยๆ ) หรือจะมอร์ฟีน ( เจ็บปวดมากๆ ) อีกทางหนึ่งของการถามก็คือ นี้คือสิ่งที่ ต้องมี ( Must have ) หรือ มีก็ดี ( Nice to have )
จากที่เล่ามานั้น คุณจะเห็นว่าผู้เขียนให้ความสำคัญกับ Who ( ใครคือผู้ใช้งานตัวจริง ) และ Pain ( ความเจ็บปวดและปัญหา ) โดยที่ยังไม่ไปแตะในส่วนของ Solution ( วิธีการแก้ปัญหา ) สองสิ่งนี้สำคัญมากกับเป้าหมายของเราและจะทำให้ตอบได้ว่าทำไมถึงไม่สร้างมันขึ้นมาง่ายๆตามที่มีคนร้องขอหรือสร้างมันเหมือนกับที่คนอื่นๆเขามีกัน คุณต้องเข้าใจอย่างลึกซึ้งในปัญหาที่ส่งผลต่อผู้ใช้งานโดยตรง อีกนัยหนึ่ง การที่รับคำสั่งจากลูกค้าหรือการทำตามขนบธรรมเนียมแบบคู่แข่งไม่ใช่ทางที่จะนำไปสู่การนวัตกรรม ( Innovation )
นวัตกรรม หรือ การเปลี่ยนแปลง จะมาจากการเข้าใจในข้อมูลเชิงลึก ( Deep Insight ) และความเห็นอกเห็นใจในตัวผู้ใช้งาน ( Empathy )
จากบทวิเคราะห์ของ Christopher Condo ใน Forrester Research
“ Sync Developers with Business Needs”
ณ ปัจจุบัน ลูกค้าคาดหวังว่าคุณจะนำเสนอผลิตภัณฑ์และบริการที่เสมอเหมือนระบบดิจิตอลครบวงจรที่จะมาพร้อมกับช่องทางการเชื่อมต่อที่หลากหลายบน เว็ปไซต์ , มือถือ , อุปกรณ์สวมใส่ได้ , มีหน้าร้าน และสามารถใช้งานในรถยนต์ แต่ทีม ( Application development & Delivery team ) มักจะหลงทางในขณะที่มุ่งมั่นว่าจะส่งงานให้ถึงฝั่งเพราะพวกเขาไม่มีภาพของวัตถุประสงค์ทางธุรกิจ ( Business objective ) ที่ชัดเจน พวกเขาคาดเดาว่าอะไรคือ Feature ที่สำคัญที่สุดและบ่อยครั้งที่เขาจะคาดเดาว่าอะไรคือสิ่งที่ดีที่สุดโดยใช้ใจนำพาเหนือกระบวนการขับเคลื่อนด้วยข้อมูล ( Data-driven approach )
ดังนั้น การนำเอาข้อมูลและการวัดผลเข้ามา จะช่วยชี้แนะและช่วยแสวงหาว่าอะไรคือสิ่งที่ลูกค้าต้องการจริงๆ
What is the Desired Outcome ?
ถ้าหากเราทราบอยู่แล้วว่าปัญหาคืออะไร ก็มักจะมีวิธีแก้ปัญหามาคู่กันอยู่แล้วเสมอ วิธีการแก้ปัญหาของคุณต้องดีกว่าอย่างมากเพื่อที่จะแก้ปัญหานี้ให้สำเร็จได้ แล้วเราจะรู้ได้ยังไงละว่าวิธีนี้ดีกว่าวิธีอื่นๆ คุณลองถามตัวเองดูหากวิธีนี้ดีกว่าวิธีอื่นๆแล้วจะเกิดความไม่เรียบร้อยอะไรขึ้นได้บ้างจากวิธีที่คุณเลือก ? วิธีนี้ดีกว่า 2เท่า 5เท่า เลยไหม ? วัดผลลัพธ์ที่ต้องการนี้ได้อย่างไร ?
ในโลกของการพัฒนาซอฟต์แวร์แบบ B2B เรามักจะให้ความสนใจกับ 3 สิ่งนี้ที่จะพาเราไปสู่เป้าหมาย
- รายได้ ( Revenue ) : ผลิตภัณฑ์นี้จะช่วยในการเพิ่มรายได้จากส่วนแบ่งทางการตลาดหรือจากการการรักษาลูกค้าไว้ได้อย่างไร ?
- ต้นทุน ( Cost ) : ผลิตภัณฑ์นี้ช่วยลดต้นทุนได้โดยการเพิ่มประสิทธิภาพขึ้นอีก ?
- ความเสี่ยง ( Risk ) : ผลิตภัณฑ์นี้ช่วยบรรเทาผลกระทบจากความเสี่ยงเชิงธุรกิจ เศรษฐกิจ หรือตลาด หรือไม่ ?
Show Me The Money
สำหรับผู้เขียนนั้น เขามองว่ารายได้เป็นส่วนที่สำคัญที่สุดในการเขียน Business case ซึ่งแน่นอนละก็การวัดผลจากรายได้นั้นค่อนข้างเป็นนามธรรม ( จับต้องได้ )
นี้จะเป็นตัวอย่างคำถามที่คุณอาจจะใช้ได้
- รายได้นี้มาจากผลิตภัณต์ใหม่ในตลาดที่มีความต้องการ ( Demand ) อยู่แล้วใช่ไหม ?
- Feature ใหม่ที่เกิดขึ้นจะทำให้ผลิตภัณฑ์เดิมมีมูลค่ามากขึ้นหรือมีความแตกต่างใช่ไหม ?
- นี้คือการเพิ่มยอดขาย ( Upsell ) จากลูกค้าเก่าใช่ไหม ?
- จะทำให้เกิดลูกค้ากลุ่มใหม่ๆใช่หรือไม่
- เป็นการเพิ่มรายได้โดยการลดการสูญเสียลูกค้าใช่ไหม ?
ผู้เขียนไม่ค่อยเห็นด้วยกับการตั้งผลลัพธ์ที่ต้องการในเชิงการเพิ่มรายได้ของ New Feature ที่ปราศจากการกระทำที่รอบคอบ โดยคุณอาจจะนำคำถามนี้ไปประกอบการพิจารณาได้
- คุณพัฒนาสิ่งนี้ขึ้นมาเพราะคุณพบว่าคุณกำลังสูญเสียลูกค้าให้กับคู่แข่งในมุมของความสามารถของผลิตภัณฑ์หรือเปล่า ?
- การพัฒนาสิ่งนี้จะมีตอบสนองต่อเป้าหมายทางธุรกิจและจะนำไปสู่การเพิ่มขึ้นของรายได้ใช่หรือไม่ ?
การเพิ่มขึ้นของรายได้เป็นเพียงส่วนหนึ่งของการกำหนดผลลัพธ์ที่เราต้องการ เราควรจะโยงมันกลับไปที่กลุ่มเป้าหมาย ( Target Audience ) และ ความเจ็บปวดของผู้ใช้งาน ( Pain ) และยังต้องเติมเต็มกลยุทธ์ทางธุรกิจที่คุณตั้งไว้ด้วย
การที่ PM ( Product Manager ) เรียงความสำคัญของงานโดยการยึดเอารายได้เป็นหลักนั้นทำให้เรามี Feature ที่แสนธรรมดาเพื่อตอบโจทย์กลุ่มลูกค้าส่วนใหญ่ ทำให้เราได้ตัวเลขใหญ่ๆมา ยิ่งทำให้ยากต่อการตัดสินใจว่าอะไรละที่สำคัญที่สุด ยิ่งไปกว่านั้น PM คงไม่ไปถามลูกค้าตรงๆว่าพวกเขาต้องการอะไร ถ้าหากมีกำลังพัฒนาเพียง 1 สิ่งเท่านั้น ฉะนั้นรายได้จึงไม่ใช่ตัวชี้วัดทางเศรษฐกิจเดียวเท่านั้นที่คุณจะนำมาเป็นหลักในการจัดเรียงความสำคัญของงาน ( prioritize )
จากประสบการณ์อันน้อยนิดของฟ้านั้น ก็มักจะหลงทางไปกับตัวเลขที่สูงและดึงดูดใจเหล่านี้เช่นกัน จนทำให้หลายครั้งที่เรามักจะโอนอ่อนไปตามสิ่งใดสิ่งหนึ่งและมองข้ามมุมอื่นๆไปโดยปริยาย การได้อ่านหนังสือเล่มนี้ สำหรับฟ้านั้นเหมือนเป็นการดึงสติกลับมาให้เรามองมุมอื่นๆบ้างและตัดสินใจกระทำอย่างรอบคอบ แล้วเพื่อนๆละคะเป็นอย่างไรกันบ้าง เรื่องราวทั้งหมดนี้ก็เป็นเพียง 1 ใน 3 ของบทย่อย Start with the End in Mind เท่านั้นเองนะคะ ยังมีเรื่องราวที่น่าสนใจอีกมากมาย เดี๋ยวเอาไว้ฟ้ามาเล่าต่อใน Ep ถัดไปนะคะ ฝากติดตามกันด้วยนะทุกคน 😍