Amazon.com เวปไซต์อีคอมเมิร์สระดับยักษ์ใหญ่ของโลกให้คุณค่าและความสำคัญกับลูกค้ามาก … Core Value ข้อแรกของบริษัทนี้พูดถึงลูกค้าไว้ว่า
Customer Obsession: We start with the customer and work backwards.
อืม คำว่า “ทำงานถอยหลัง” หรือ “Work Backwards” นี่คือหลักคิดสำคัญในการทำ Product Development ที่ Amazon เค้าเริ่มต้นที่ลูกค้าและทำงานถอยหลัง แทนที่จะเริ่มต้นจากไอเดียทำโปรดักส์ของคนคนเดียวแล้วพยายามชักจูง (ตบตา หลอกลวง) ลูกค้าให้มาใช้งาน … ซึ่งมักจะยากกว่าและไม่สำเร็จ
Product Manager ของ Amazon ส่วนใหญ่จึงเริ่มต้นการทำโปรดักส์ด้วยการเขียน Press Release (คล้ายๆ Product Marketing Roadmap) ที่ใช้ในการประกาศกับสื่อหรือลูกค้าสำหรับโปรดักส์นั้นๆ Press Release นี้ถูกเขียนโดยใช้ปัญหาที่ลูกค้าเจอ (Customer Problems/Pain Points) เป็นศูนย์กลาง บวกกับการวิเคราะห์ว่าโซลูชั่นที่มีอยู่ปัจจุบันไม่ว่าจะของ Amazon เองหรือของคนอื่นมันล้มเหลวในการแก้ปัญหาให้ลูกค้าอย่างไร และโปรดักส์ใหม่นี้จะเอาชนะโซลูชั่นที่มีอยู่พวกนั้นได้อย่างไร … เน้นหนักไปที่ลูกค้า
ถ้าประโยชน์ที่ลูกค้าจะได้รับมันดูไม่น่าสนใจหรือไม่น่าตื่นเต้นสำหรับลูกค้า ไม่แน่มันอาจจะไม่ใช่สิ่งที่เราควรทำก็เป็นได้ Product Manager จึงมีหน้าที่ในการปรับปรุง Press Release ตัวนี้ให้ดูดีขึ้นจนลูกค้ารับรู้ได้ถึงประโยชน์ที่จะได้รับ นี่คือการประยุกต์ใช้หลักการ Minimum Viable Product (MVP), Fail Fast, และ Validated Learning ได้อย่างยอดเยี่ยม … การแก้ไขข้อความในกระดาษมันง่ายกว่าการแก้ไขซอฟต์แวร์เป็นร้อยเท่า!!!
ตัวอย่างเนื้อหาใน Press Release มีดังนี้
- Heading: ชื่อของโปรดักส์ที่ผู้อ่าน (หรือลูกค้าตัวจริง) จะเข้าใจ
- Sub-Heading: อธิบายถึงกลุ่มลูกค้าและประโยชน์ที่เค้าจะได้รับจากการใช้โปรดักส์นี้ สั้นๆแค่หนึ่งบรรทัดใต้ Heading
- Summary: ย่อหน้าสรุปเรื่องโปรดักส์และประโยชน์ที่ลูกค้าจะได้รับ ตั้งสมมติฐานว่าลูกค้าจะไม่อ่านข้อความอื่นๆด้านล่าง เพราะฉะนั้นเขียนย่อหน้านี้ให้เริ่ดเลย
- Problem: อธิบายถึงปัญหาที่โปรดักส์ของคุณพยายามจะแก้ไข
- Solution: อธิบายถึงแนวทางการแก้ปัญหาอย่างมีสไตล์ของโปรดักส์คุณ
- How to Get Started: อธิบายการเริ่มต้นใช้งานโปรดักส์คุณว่ามันง่ายขนาดไหน
- Quote from You: คำพูดสั้นๆถึงโปรดักส์นี้จากโฆษกในบริษัทคุณ อาจจะเป็นทีม Marketing หรือ PR ก็ได้ หรือแม้แต่จะเป็นตัวคุณเองก็ได้
- Quote from Customer: คำพูดหรือคำชื่นชมจากลูกค้าตัวจริง (Lead User หรือ Focus Group) หลังจากได้รับประสบการณ์การใช้โปรดักส์ของคุณ
- Closing and Call to Action: ย่อหน้าสรุปและบอกขั้นตอนต่อไปในการเข้าถึงโปรดักส์ของคุณ อาจจะเป็น Call Now, Download Now, Read More, อื่นๆ
ถ้า Press Release ฉบับนี้ยาวกว่าหนึ่งหน้าครึ่งให้ตระหนักว่ามันยาวไปล่ะ ตัดข้อความไม่จำเป็นทิ้งไปให้มากๆ อย่าคิดว่ากำลังเขียน Spec อยู่ กฎเหล็กของ Product Manager ที่ Amazon คือถ้า Press Release เขียนยากมีโอกาสสูงทีเดียวที่โปรดักส์ที่ทำออกมาจะห่วยแตก (แค่เขียนในกระดาษยังยากเล้ยยยย)
เมื่อเริ่มทำงาน Software Development จริงๆ Press Release จะถูกหยิบมาใช้เป็นเอกสารอ้างอิง เป็นเอกสารนำทางที่ทีมต้องถามตัวเองเรื่อยๆว่า “เรากำลังสร้างสิ่งที่ระบุไว้ใน Press Release หรือไม่?” ถ้าไม่ก็ต้องถามตัวเองว่า “ทำไม” มันเป็นการสร้างโฟกัสให้กับการทำงานของเรา มันเป็นการลดโอกาสทำสิ่งที่ไม่จำเป็น (ไม่มีอยู่ใน Press Release) ซึ่งเป็นการเสียเวลาและเสียพลังงานไปโดยใช่เหตุ
นอกจาก Press Release แล้วยังมีเอกสารอีกสองสามฉบับที่ Product Manager ที่ Amazon ทุกคนมักจะเขียนคือ
- Frequently Asked Question (FAQ): เป็นเอกสารที่รวบรวมคำถามที่ถูกถามบ่อยๆในเรื่องของโปรดักส์ คำถามเหล่านี้ถูกรวบรวมตอน Product Manager เอา Press Release ไปเล่าให้เพื่อนๆต่างทีมหรือแม้แต่ลูกค้าตัวจริงฟัง มุมมองที่ได้จากคำถามเหล่านั้นจะถูกนำมาพิจารณาในการปรับปรุง Press Release และโปรดักส์ให้ดีขึ้น
- Customer Experience: เป็นเอกสารที่อธิบายประสบการณ์ที่ลูกค้าจะได้รับจากโปรดักส์นี้อย่างละเอียด ถ้าเป็นโปรดักส์ที่มี User Interface เราต้องทำ Screen และ User Flow ออกมาให้ชัดเจน ถ้าเป็นโปรดักส์ที่เป็น API เราต้องเขียน User Case พร้อมตัวอย่าง Code ในการเรียกใช้งาน API ของเราจริงๆ วัตถุประสงค์ของเอกสารฉบับนี้คือเล่าเรื่องว่าลูกค้าใช้โปรดักส์ของเราแก้ปัญหาที่ระบุไว้ใน Press Release อย่างไร
- User Manual: เอกสารคู่มือการใช้งานโปรดักส์สำหรับลูกค้า ข้างในอธิบายอย่างละเอียดว่าโปรดักส์นี้คืออะไร มีประโยชน์อย่างไร ใช้งานยังไง เขียนแล้วจะรับรู้ได้ว่าโปรดักส์เรามันซับซ้อนหรือวุ่นวายมากมั้ย ถ้ามาก ก็แก้ซะก่อนจะไม่มีคนใช้
เมื่อเขียนเอกสารสี่ฉบับนี้เสร็จแล้ว เราจะให้ภาพโปรดักส์ของเราได้อย่างชัดเจนขึ้นมากว่ามันคืออะไรและเราต้องทำอะไรบ้าง (Product Backlog ค่อยตามมา) เราสามารถใช้เอกสารทั้งหมดนี้เล่าเรื่องราวให้คนอื่นฟังได้อย่างมั่นใจ เราจะแบ่งปันวิสัยทัศน์ที่เรามีต่อโปรดักส์ของเราให้กับทีมงานให้กับบริษัทและให้กับลูกค้าได้อย่างชัดเจน … ซึ่งนั่นสำคัญมากในการทำโปรดักส์ดีๆขึ้นมาสักหนึ่งตัว 😊