Version ที่สมบูรณ์แบบอยู่ในอนาคตเสมอ
ผมคิดเกี่ยวกับว่าทำไมสิ่งต่างๆ ถูกสร้าง ไม่ใช่ว่าทำไมมันล้มเหลว — ทำไมมันไม่เคยเริ่ม
เหตุผลคือเดียวกันเสมอ: ใครบางคนตัดสินใจรอจนทำได้อย่างถูกต้อง จนเงื่อนไขถูกต้อง จนไอเดียก่อตัวอย่างสมบูรณ์ จนมั่นใจว่ามันจะดี
ปัญหาคือ “ดีพอที่จะ publish” และ “สมบูรณ์แบบ” ไม่ใช่จุดหมายเดียวกัน สมบูรณ์แบบคือทิศทาง ดีพอที่จะ publish คือที่
ความสมบูรณ์แบบทำให้สูญเสียอะไรจริงๆ
ทุกวันที่คุณ delay shipping คือวันที่คุณไม่ได้เรียนรู้จาก feedback จริง version ที่สมบูรณ์แบบในหัวของคุณถูกปกป้องจากตลาด มันไม่เคยเจอใครที่ใช้มันจริง มันไม่เคยได้ email ที่บอกว่า “ผมพยายามทำ X แต่สับสนตรงนี้”
feedback นั้นคือข้อมูล โดยไม่มีมัน คุณสร้างในสุญญากาศ ยิ่งคุณอยู่ในสุญญากาศนานเท่าไหร่ product ยิ่งถูกตัดขาดจากสิ่งที่มันควรจะทำมากขึ้น
คณิตศาสตร์ง่าย:
- สมบูรณ์แบบใน 6 เดือน = 0 feedback
- ส่งใน 2 เดือน, iterate = feedback ในเดือน 2, ปรับปรุงในเดือน 3-6
version ที่ไม่สมบูรณ์แบบที่ได้ feedback จะอยู่ไกลกว่าในเดือน 6 กว่า version ที่สมบูรณ์แบบที่อยู่ใน development
กลไกจริง
ความสมบูรณ์แบบไม่ใช่มาตรฐานสูง มาตรฐานสูงหมายถึงทำงานที่ดีภายใน constraints ความสมบูรณ์แบบหมายถึง delay จน constraints ไม่มีอยู่อีกต่อไป — ซึ่งมันจะไม่มีวัน
reframe ที่ช่วยผม:
ส่งเพื่อเรียน ไม่ใช่เพื่อพิสูจน์
เมื่อคุณส่ง คุณไม่ได้ประกาศว่างานเสร็จ คุณกำลัง run experiment feedback บอกคุณว่าทิศทางถูกไหม ถ้าไม่ คุณเปลี่ยนทิศทาง ถ้าใช่ คุณ continue
perfectionist mindset ปฏิบัติ shipping เป็น verdict shipping-to-learn mindset ปฏิบัติมันเป็นการเก็บข้อมูล
อะไรช่วยได้จริง
กำหนดวัน ไม่ใช่มาตรฐาน แทนที่จะ “ผมจะ ship เมื่อมันพร้อม” กำหนดวันในปฏิทิน พฤศจิกายน 1 สิ้นสุดไตรมาส อะไรก็ได้ งานขยายเติมเวลาที่คุณให้ วันตายสร้าง constraints constraints สร้าง focus
กฎ 80% ถ้าคุณทำ core work แล้ว 20% ที่เหลือคือ polish, ส่ง 20% จะไม่มีวันรู้สึกเสร็จ มันจะรู้สึกเสร็จมากขึ้นถ้าคนใช้มันและให้ feedback เกี่ยวกับ 80% ที่สำคัญ
หาผู้ชมที่เล็กที่สุด คุณไม่ต้องการทุกคน คุณต้องการคนสามคนที่ใช้สิ่งที่คุณสร้างจริงๆ สมบูรณ์แบบสำหรับพวกเขา, เรียนรู้จากพวกเขา, ขยายจากตรงนั้น
แยก building ออกจาก launching building คือส่วนสร้างสรรค์ launching คือส่วนปกครอง คุณหยุด building ได้เมื่อทำเพียงพอ launching คือกระบวนการของตัวเองพร้อม timeline ของตัวเอง
ประเด็นจริง
ใต้ความสมบูรณ์แบบมักจะเป็นความกลัว กลัวถูกมองว่าไม่เพียงพอ กลัว email ที่บอก “นี่ไม่ดี” กลัวต้องยอมรับว่างานไม่ดีพอ
แต่นี่คือสิ่งที่ผมเรียนรู้: คนที่สำคัญไม่ตัดสินคุณเพราะงานที่ไม่สมบูรณ์ พวกเขาตัดสินคุณเพราะไม่ส่ง สิ่งที่ไม่สมบูรณ์ที่มีอยู่สอนมากกว่าสิ่งที่สมบูรณ์แบบที่ไม่มี
ต้นทุนจริงของความสมบูรณ์แบบไม่ใช่คุณภาพที่คุณไม่ได้บรรลุ มันคือการเรียนรู้ที่คุณไม่ได้
นี่ไม่ใช่ข้อโต้แย้งให้ส่งงานที่เลว มันคือข้อโต้แย้งให้ส่งงานที่มีอยู่, ได้ feedback, และปรับปรุงจากข้อมูลจริงแทนข้อมูลที่จินตนาการ