ข้อจำกัดสามข้อที่ต้องตั้งไว้ก่อนลงมือสร้าง

 (jordanlord.co.uk)
45 คะแนน โดย GN⁺ 2 일 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ไอเดียผลิตภัณฑ์ควรตั้ง ข้อจำกัด ไว้ก่อน เพื่อให้พื้นที่ในการสำรวจแคบลง และป้องกันไม่ให้ไหลไปสู่ผลลัพธ์ที่ซับซ้อนเกินไปหรือ ไม่มีอัตลักษณ์
  • ทุกไอเดียต้องสรุปเป็น one pager ความยาวหนึ่งหน้า และถ้ายังใส่ลงไปไม่ได้ ก็ควรมองว่ายังต้องทำการค้นคว้า วางแผน และทำต้นแบบเพิ่ม
  • นอกจากตัวผลิตภัณฑ์แล้ว ควรสร้าง core tech ที่อยู่รอดได้ด้วยตัวเองไปพร้อมกัน และต้องเป็น สินทรัพย์ที่สั่งสมต่อเนื่อง ได้แม้จะมีการเปลี่ยนทิศทาง
  • ที่ศูนย์กลางของผลิตภัณฑ์ควรมี defining constraint เพียงหนึ่งข้อที่ผู้ใช้มองเห็นอยู่เสมอ และข้อจำกัดนี้จะกำหนด feel และอัตลักษณ์ของผลิตภัณฑ์อย่างเป็นธรรมชาติ
  • หากไม่ผ่านแม้แต่ข้อเดียวจากสามเกณฑ์นี้ ก็ควรไม่สร้าง เพราะท่าทีแบบนี้สำคัญต่อ การควบคุมขอบเขต และการสร้าง leverage ระยะยาว

ข้อจำกัดสามข้อที่ต้องตั้งไว้ก่อนลงมือสร้าง

  • หากตั้ง ข้อจำกัด ไว้ก่อนสร้างผลิตภัณฑ์ จะช่วยลดพื้นที่ในการสำรวจ และป้องกันไม่ให้ลงเอยด้วยผลลัพธ์ที่ซับซ้อนหรือไร้อัตลักษณ์
  • ตลอด 10 ปีที่สร้างผลิตภัณฑ์มาหลายตัว พบว่าผลิตภัณฑ์ที่ซับซ้อนเกินไปหรือไม่มีอัตลักษณ์มักนำไปสู่ความล้มเหลว และหลังจากลองผิดลองถูกจึงสรุปออกมาเป็นสามเกณฑ์นี้

  • ถ้าเกินหนึ่งหน้า ก็ไม่สร้าง

    • ทุกไอเดียต้องถูกสรุปเป็น one pager และเอกสารนี้ทำหน้าที่เป็น north star
    • one pager ต้อง ต่อรองไม่ได้, แม่นยำ, ทะเยอทะยาน แต่ไม่มีส่วนเกิน
    • สามารถใช้เอกสารเดียวกันนี้สื่อสารกับผู้ลงทุน ผู้มีส่วนร่วม สมาชิกทีม เพื่อน หรือครอบครัวได้
    • หากเกิดความขัดแย้งระหว่างการทำงานร่วมกัน เรื่องที่ไม่ได้อยู่ใน one pager ก็ไม่คุ้มจะเถียงกัน และถ้ามันสำคัญจริง ก็ควรแก้เอกสารให้สะท้อนสิ่งนั้น
    • ถ้ายังเขียนให้ครบหนึ่งหน้าไม่ได้ ก็ไม่ควรยัดเนื้อหาให้เต็ม แต่ควรมองว่ายังไม่พร้อมจะสร้าง
    • ในกรณีนั้นควรเริ่มจาก การค้นคว้า การวางแผน และการทำต้นแบบ ก่อน แล้วค่อยกลับมาเขียน one pager ใหม่
    • ถ้ายาวเกินหนึ่งหน้า แปลว่าซับซ้อนเกินไป จึงไม่สร้าง

  • เทคโนโลยีแกนหลักต้องแยกออกจากผลิตภัณฑ์ได้

    • นอกเหนือจากตัวผลิตภัณฑ์เอง ควรสร้าง core tech ที่ค้ำจุนผลิตภัณฑ์เอาไว้
    • core tech อาจเป็นวิธีการ เทคโนโลยี เครื่องมือ หรือแม้แต่ผลิตภัณฑ์แยกต่างหาก และควรอยู่รอดได้แม้ไม่มีผลิตภัณฑ์ปัจจุบัน
    • การแยกแบบนี้ช่วยไม่ให้ติดอยู่กับผลิตภัณฑ์เพียงตัวเดียว และทำให้การสั่งสมยังเดินหน้าต่อได้แม้จะเปลี่ยนทิศทาง
    • ผลิตภัณฑ์มักเปลี่ยนทิศทางบ่อย แต่ core tech จะคงอยู่เป็นสินทรัพย์ที่ ต่อเนื่องและสะสมเพิ่มได้
    • ในระยะยาว ความพยายามที่สั่งสมเช่นนี้อาจสร้างผลลัพธ์แบบไม่เป็นเส้นตรงได้
    • ตัวอย่างที่ยกมาคือ git ของ Linus Torvalds, HCL ของ HashiCorp และ Kubernetes ของ Google
    • สิ่งนี้ไม่จำเป็นต้องใช้ทรัพยากรระดับบริษัทยักษ์ใหญ่เสมอไป จะเป็นไลบรารีที่แยกออกจาก codebase หรือวิธีการที่ค่อย ๆ ขัดเกลาอย่างต่อเนื่องก็ได้
    • core tech ควรเป็นอิสระจากทิศทางของผลิตภัณฑ์ แต่ต้องสอดคล้องกับวิสัยทัศน์ระยะยาวของบุคคลหรือบริษัท
    • หากไอเดียนั้นไม่เอื้อให้เกิด core tech ก็แปลว่ายังมี leverage ไม่มากพอ

  • ต้องมีข้อจำกัดชี้ขาดเพียงข้อเดียวที่กำหนดตัวผลิตภัณฑ์

    • ที่ศูนย์กลางของผลิตภัณฑ์ต้องมี defining constraint ที่ผู้ใช้มองเห็นได้ตลอดเวลา
    • ข้อจำกัดนี้ต้องเป็นองค์ประกอบที่ผู้ใช้พบเจอและโต้ตอบด้วยอย่างต่อเนื่อง และมันจะสร้างอัตลักษณ์ของผลิตภัณฑ์
    • ข้อจำกัดที่ดีจะสร้าง feel ของผลิตภัณฑ์ และแทรกซึมอยู่ทั่วทั้งประสบการณ์ผู้ใช้
    • Minecraft สร้างขึ้นจากบล็อกเท่านั้น ส่วน IKEA มีอัตลักษณ์เป็นเฟอร์นิเจอร์ flat-pack ที่ให้ลูกค้าประกอบเอง ซึ่งเป็นตัวอย่างของอัตลักษณ์ที่เผยออกมาจากข้อจำกัดโดยตรง
    • ข้อจำกัดแบบนี้ช่วยลดพื้นที่ในการตัดสินใจ จำกัดขอบเขต และทำให้โฟกัสกับปัญหาที่สำคัญจริง ๆ ได้
    • หากไม่เลือกข้อจำกัด หรือเลือกผิด ผลิตภัณฑ์ก็จะพองตัวจนกลายเป็นสิ่งที่พยายามทำทุกอย่าง
    • หากออกแบบข้อจำกัดมาอย่างดี การออกแบบผลิตภัณฑ์ก็จะไหลตามข้อจำกัดนั้นอย่างเป็นธรรมชาติ
    • ข้อจำกัดนี้เองก็ควรถูกวางไว้ด้านหน้าของ one pager เช่นกัน

เกณฑ์สรุปท้าย

  • หากไม่ผ่านแม้แต่ข้อเดียวจากข้อจำกัดทั้งสาม ก็ไม่สร้าง

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2 일 전
ความคิดเห็นจาก Hacker News

  • ฉันเรียกสิ่งแบบนี้ว่า product primitives มาตลอด
    อย่างเช่น blocks ของ Notion, messages/conversations ของ Telegram, frames/layers ของ Figma, tweets ของ Twitter, cells/sheets ของ Excel, tools/layers ของ Photoshop, commands ของ CLI

    ฉันคิดว่าการออกแบบผลิตภัณฑ์ที่ดีมักเกิดขึ้นเมื่อ primitive พวกนี้มีจำนวนน้อยมาก
    ผลิตภัณฑ์ที่แย่มักไม่รู้ว่าตัวเองมี primitive อะไรบ้าง หรือมีมากเกินไปจนทุกองค์ประกอบในผลิตภัณฑ์ดูแยกส่วน ไม่ไปด้วยกัน
    แบบนั้นผู้ใช้ก็ต้องเรียนรู้แนวคิดระดับบนที่ต่างกันเต็มไปหมด เลยทั้งสับสน รู้สึกกดดัน และสอนได้ยาก
    ตามอุดมคติแล้ว primitive หลักมีสักหนึ่ง สอง หรือสามอย่างก็น่าจะพอ

    ความซับซ้อนและพลังของแอปเกิดจากการเลือก primitive ที่ลึกและนำมาประกอบกันได้
    ต้องเป็นหน่วยเล็ก ๆ ที่ทำอะไรได้เยอะ แบบ Notion block, Excel cell, CLI command หรือ Minecraft block

    • มันดูคล้ายกับ Alexandrian Pattern Language แต่จริง ๆ แล้วน่าจะใกล้กับสิ่งที่ Alexander พูดถึงภายหลังอย่าง Centers มากกว่า pattern

      เท่าที่ฉันเข้าใจ วงการซอฟต์แวร์รับเอา pattern ของเขาไปเยอะมาก แต่ช่วงปลายชีวิต Alexander มองว่าองค์ประกอบพื้นฐานสูงสุดของระบบคือ Center
      อย่างเช่นลานสว่าง มุมนั่งริมหน้าต่าง เตาผิง ซึ่งเป็นจุดรวมของประโยชน์ใช้สอยเฉพาะที่และความเป็นเอกภาพ
      center ที่แข็งแรงจะนำมาประกอบกันได้โดยธรรมชาติ คลี่คลายความตึงเครียดในระดับท้องถิ่น ประกอบด้วย center ที่เล็กกว่า และทำหน้าที่เป็นบล็อกตั้งต้นที่ก่อให้เกิด center ที่ใหญ่กว่า

      ผลิตภัณฑ์ที่สับสนและเทอะทะ ส่วนใหญ่ไม่ได้เกิดจากเจตนาที่ไม่ดี
      ความต้องการของผู้ใช้มักพอมองหาได้จากประสบการณ์ แต่โครงสร้างศูนย์กลางที่แท้จริงซึ่งจะดูดซับความต้องการเหล่านั้นได้อย่างสง่างามนั้นละเอียดอ่อนมากจนค้นพบได้ยาก
      เพราะงั้นเส้นทางที่ง่ายที่สุดจึงมักเป็นการติดอินเทอร์เฟซเฉพาะแข็ง ๆ เข้าไปทีละอันตามความต้องการตรงหน้า
      การหา primitive หลักที่จะดูดซับความต้องการเหล่านั้นได้อย่างเป็นธรรมชาติต้องอาศัยงานสถาปัตยกรรมที่ลึกมาก

      บางทีเพราะแบบนี้เราถึงลงเอยด้วยการสร้าง faster horses ซ้ำ ๆ ก็ได้

    • เมื่อก่อนฉันเรียกสิ่งนี้ว่า concept count
      โดยทั่วไปจำนวนแนวคิดหลักที่ประกอบกันเป็นผลิตภัณฑ์ยิ่งน้อยยิ่งดี และบางทีก็เรียกมันว่า nouns and verbs ของผลิตภัณฑ์

    • ปรัชญานี้ดูจะ ลดทอนให้เรียบง่ายเกินไป อยู่หน่อย
      Tana มี primitive อยู่จริง ๆ แค่สองอย่างคือ bullets กับ supertags แต่กลับใช้งานซับซ้อนมากจนแม้แต่งานง่าย ๆ ก็ยังต้องดูทutorialยาวเป็นชั่วโมง
      ในทางกลับกัน Google Maps มี primitive ค่อนข้างเยอะ แต่สำหรับ use case 90% UX ก็ยังแน่นมาก

    • ฉันก็ใช้เกณฑ์คล้ายกันเวลามองภาษาโปรแกรมมิ่ง
      ต่อให้ภาษาจะใหญ่ แต่ถ้า เล็กในเชิงแนวคิด พอเรียนรู้แล้ว ที่เหลือจะตามมาจากประสบการณ์ที่สะสมไป แต่ภาษาที่ใหญ่ในเชิงแนวคิดจะมีอุปสรรคในการเริ่มต้นสูง
      ตัวอย่างที่ฉันรู้สึกแรงมากคือ perl

    • มันต้องเล็ก แต่ก็ เล็กเกินไปไม่ได้
      ตัวอย่างชัด ๆ คือ shell script (POSIX shell, bash) ที่พยายามไม่แนะนำแนวคิดใหม่แม้กระทั่งกับงานสคริปต์ โดยโมเดลทุกอย่างเป็น command สุดท้ายก็อย่างที่รู้กัน กลายเป็นของผสมที่ร้อน ช้า และยุ่งเหยิง

  • ฉันชอบทั้งสามข้อจำกัด แต่คิดว่า เอกสาร 1 หน้า ควรเปลี่ยนตามความซับซ้อนของโปรเจ็กต์
    ถ้าเป็นโปรเจ็กต์ขนาดเล็กถึงกลาง หนึ่งหน้าก็น่าจะพอ แต่ถ้าเป็นซอฟต์แวร์ควบคุมการบินไปดาวอังคาร ก่อนเริ่มลงมืออาจต้องมี one-pager ที่ลิงก์ไปยังสเปกย่อยจำนวนมาก

    การ แยกเทคโนโลยีกับผลิตภัณฑ์ออกจากกัน เป็นความคิดที่ฉลาดมาก
    เช่นกรณี Skype มีทั้งเทคโนโลยีสื่อสาร P2P ฝั่งแบ็กเอนด์ และแอปโทรฝั่งฟรอนต์เอนด์ และผู้ก่อตั้งที่ฉลาดก็แยกสองอย่างนี้ไว้คนละบริษัท
    เพราะงั้นหลังจากที่แอปฝั่งฟรอนต์เอนด์อย่าง Skype ถูกขายให้ Microsoft บริษัทที่ถือ IP หลักและเทคโนโลยี P2P ฝั่งแบ็กเอนด์ก็ยังคงถือไว้แยกต่างหากได้

    การ มีข้อจำกัดหนึ่งข้อเป็นแกนกลาง ก็ฟังดูสมเหตุสมผล แต่บางครั้งฉันคิดว่าการมีหลายข้อจำกัดหรือรายการลำดับความสำคัญน่าจะดีกว่า
    ถ้าหลักการสูงสุดนั้นทำเชิงพาณิชย์ได้ยาก การปฏิบัติต่อมันเหมือนเป็นคำสอนที่แตะต้องไม่ได้อาจพาธุรกิจไปสู่การล้มละลาย
    ถ้าในทีมมีไอเดียที่จะ pivot ครั้งใหญ่ไปในทิศทางที่ขายง่ายกว่ามาก ต่อให้ต่างจากเดิมพอสมควรก็อาจเปิดทางรอดได้
    Twitter เองก็เป็นตัวอย่างที่เดิมตั้งใจทำอย่างอื่น แต่ public status update โผล่มาจากโปรเจ็กต์ข้างเคียง

  • บทความนี้สรุปวิธีที่ฉันเคยสร้างธุรกิจกับอาจารย์ที่ปรึกษางานวิจัยได้ดีมาก

    พวกเราเริ่มจากสองข้อหลัง คือ เทคโนโลยีหลัก กับ ข้อจำกัด ก่อน
    เทคโนโลยีหลักคือ sampler ที่ทำให้สร้าง arbitrary hierarchical Bayesian graph model สำหรับ sparse data ได้ และข้อจำกัดคือมันต้องคำนวณได้ภายใต้สภาวะ CPU-bound
    สิ่งที่ใช้เวลานานที่สุดคือการตระหนักว่าผลิตภัณฑ์สุดท้ายต้องแยกออกจากเทคโนโลยีฐาน

    ก่อนเริ่มก็มีหลายคนให้คำแนะนำคล้าย ๆ กัน แต่บทเรียนบางอย่างต้องเจอเองถึงจะฝังอยู่กับตัว

    • คำที่ถูกคือ tenets ไม่ใช่ tenants

  • ไอเดีย one-pager ดีมากจริง ๆ
    ถ้าคุณยังไม่สามารถใช้เวลาเขียนข้อจำกัดให้ชัดเจนแม้แต่ในกระดาษหน้าเดียว สุดท้ายคุณก็จะลนลานค้นพบข้อจำกัดนั้นระหว่างทางอยู่ดี
    และนั่นไม่ใช่แค่บั๊ก แต่เป็นความบกพร่องระดับ เรากำลังสร้างสิ่งที่ผิดตั้งแต่ต้น

    ฉันพิสูจน์ด้วยข้อมูลไม่ได้ แต่จากประสบการณ์ โปรเจ็กต์ที่ทำให้ทุกคนอยู่บนหน้าเดียวกันในเชิงแนวคิดมักสำเร็จบ่อยกว่ามาก
    ต่อให้เป็นเอกสารระดับสูงแค่หน้าเดียว ถ้ามันทำให้ชัดว่าเรากำลังทำอะไรและไม่ทำอะไร ก็ช่วยได้มาก
    ในทางกลับกัน โปรเจ็กต์ที่เดินหน้าแบบสด ๆ มักลงเอยด้วยการทำให้แม้แต่คนที่ไม่เคยพูดความคิดตัวเองให้ชัดเจนก็ผิดหวังกันหมด

  • ฉันอยากให้ผู้เขียนยก ตัวอย่างที่สมบูรณ์ของข้อจำกัดที่ใช้งานได้จริง สักอัน
    โดยเฉพาะข้อที่สาม ฉันยังนึกภาพไม่ค่อยออกว่าหน้าตามันเป็นอย่างไร

    • มันแอบรู้สึกเหมือนเป็น hook ที่ปรุงแต่งขึ้น
      สุดท้ายก็ดูเหมือนต้องคิดอะไรบางอย่างขึ้นมาเองอยู่ดี
      ฉันว่าคอนเซปต์อย่าง everything's a file ของ Linux ดีมาก
      แนวคิดที่แข็งแรงเพียงอันเดียวแบบนั้นพาไปได้ไกลพอสมควร

  • ข้อจำกัด เป็นสิ่งที่ถูกประเมินค่าต่ำไป

    วิธีแก้ที่สง่างามที่สุดมักไม่ได้เกิดจากอิสระไร้ขอบเขต แต่เกิดจากการสร้างภายใต้ข้อจำกัดที่ชัดเจน
    และนี่ก็เชื่อมกับข้อแรกด้วย
    กระบวนการเขียน one-pager เองช่วยนิยามข้อจำกัดเหล่านั้นได้

  • การที่ Google มี Kubernetes ดูเหมือนจะเป็นเรื่องของ การทำให้คู่แข่งเสียเปรียบ มากกว่าอย่างอื่น

  • ถ้าเป็น solo SaaS ข้อจำกัดที่ฉันจะเพิ่มคือ สัปดาห์นี้หาผู้ใช้เบต้าได้สักคนไหม
    ต่อให้เวลา ขอบเขต และเทคโนโลยีใน one-pager ดูดีแค่ไหน ถ้าไม่มีใครเข้ามา โปรเจ็กต์ก็ตายอยู่ดี
    เพราะงั้นพอใส่ ข้อจำกัดด้านการเผยแพร่/การกระจายตัว ตั้งแต่แรก ฉันก็จะตรวจสอบกลุ่มความต้องการก่อนจะลงลึกกับฟีเจอร์

    • พูดให้เคร่งครัดแล้ว นั่นดูใกล้กับ เป้าหมาย หรือ ตัวชี้วัด มากกว่าจะเป็นข้อจำกัด

  • ฉันสงสัยว่าคำพูดที่ว่า เทคโนโลยีหลักต้องแยกจากผลิตภัณฑ์ได้ อาจทำให้เกิดการนามธรรมเร็วเกินไปและใช้ design pattern พร่ำเพรื่อหรือเปล่า

    แน่นอนว่าการแยก concerns การแยก business domain layer ออกจาก persistence/network/UI อย่างชัดเจนเป็นเรื่องถูกต้อง
    ถึงอย่างนั้น domain layer เองสุดท้ายก็หลีกเลี่ยงไม่ได้ที่จะผูกแน่นกับผลิตภัณฑ์มาก ๆ
    ฉันคิดว่าเรื่องนี้เลี่ยงไม่ได้

    • บางทีอาจหมายถึงมี เปลือกภายนอก ที่เอาไว้ดึงดูดผู้ซื้อ ส่วนสิ่งที่ขับเคลื่อนอยู่ข้างในไม่ใช่เรื่องที่ผู้ซื้อสนใจจริง ๆ

      อาจมีแนวคิดไม่กี่อย่างที่ทำหน้าที่เป็นอินเทอร์เฟซระหว่างสองชั้นนี้ แต่สิ่งที่เขาพูดน่าจะเป็นว่าภายในควรวิวัฒน์ไปโดยแยกจากชั้นผลิตภัณฑ์ภายนอกได้

  • ตอนนี้ฉันกำลังออกแบบรีโมเดลครัวอยู่ และรู้สึกว่า ข้อจำกัดสามข้อ นี้น่าจะใช้ได้ดีทีเดียวกับงานออกแบบทั่วไปที่กว้างกว่าซอฟต์แวร์

    ฉันเองก็ว่าจะลองใช้เดี๋ยวนี้เลย

    • อาจตั้งเป็น everything's a space เช่น พื้นที่คน พื้นที่เก็บของ พื้นที่ทำงาน
      ก็แอบคิดว่าอาจจะง่ายเกินไป แต่พอมองในแง่พื้นที่กับ flow แล้วมันน่าสนใจกว่า
      เพราะจะได้คิดถึงการไหลของคน แสง อาหาร และการเปลี่ยนผ่านต่าง ๆ ซึ่งค่อนข้างสนุกดี