Product

✍🏼 ไม่เคยมากเกินไป?

บางคนคิดว่าฟีเจอร์ยิ่งมากยิ่งดี ฟีเจอร์ช่วยให้เราขายได้ ฟีเจอร์ช่วยให้เรานำหน้าคู่แข่ง ฟีเจอร์ดึงดูดฟีดแบคดีๆ จริงหรือ? 🤔

✍🏼 ยิ่งบั๊กมาก 🐞 ยิ่งได้กำไรมาก 💰

“ถ้าเธอไม่ซื้อซัพพอร์ตรายปีจากฉัน อะไรเสียหรือเจอปัญหาอะไรขึ้นมาฉันไม่รับโทรศัพท์จากเธอนะ” … คำขู่ที่ได้ผลเพราะบั๊กในซอฟต์แวร์ช่วยให้เราขายซัพพอร์ตรายปีได้ อืมมม 🐞🤔

✍🏼 ทางเลือกไหนดีกว่ากัน?

การตัดสินใจด้วยข้อมูลที่น้อยเกินไปคือความเสี่ยง เมื่อเรายังมีเวลาการทดลองหลายๆแนวทางพร้อมกันเพื่อเปรียบเทียบเป็นเรื่องที่คุ้มค่าแก่การลงทุน

✍🏼 เค้กคละรส 🎂

ถ้าเราต้องทำเค้ก 1 ปอนด์เพื่อขายแค่ 1 ชิ้นเล็ก 🍰 ที่เหลือคือเสียทิ้ง เหมือนฟีเจอร์ซอฟต์แวร์ที่เราต้องพยายามทำให้มันคุ้มค่าที่สุด ให้มีคนใช้เยอะที่สุด

✍🏼 การสร้างโปรดักท์ด้วยขอบเขต, จุดสำคัญ และเส้นทาง

โปรดักท์ที่ดีจะมีขอบเขตที่ชัดเจน มีจุดสำคัญที่มองเห็นง่าย และมีเส้นทางเชื่อมระหว่างจุดเหล่านั้นที่หลากหลาย – ความยืดหยุ่นคือสิ่งที่เราต้องค้นหาให้เจอ 🕵🏼‍♂️

✍🏼 การทดสอบแนวคิด (Proof of Concept)

Proof of Concept ที่ดีควรต้องเริ่มต้นจากสมมติฐานและเป้าหมายเสมอ ไม่ใช่ลุยแหลก ไม่ใช่เร่งรีบ และไม่ใช่เรื่องของเทคนิคเพียงอย่างเดียว 👩🏻‍🔬🧫

✍🏼 ค่าเสียเวลา

เมื่ออุปสรรคมันมากไป การที่เรายังก้มหน้าก้มตาทำโปรเจกต์นี้ต่อคือการเสียเวลา เสียโอกาสที่จะช่วยเหลือคนที่เห็นคุณค่าเราอย่างแท้จริง 🦁🐯