24 poin oleh GN⁺ 18 jam lalu | 1 komentar | Bagikan ke WhatsApp
  • Ide produk perlu lebih dulu diberi batasan agar ruang eksplorasi menyusut dan mencegah hasil yang terlalu rumit atau tanpa identitas
  • Semua ide harus dirangkum dalam one pager satu halaman, dan jika belum bisa dimuat di dalamnya maka itu berarti masih perlu riset, perencanaan, dan prototipe tambahan
  • Bersamaan dengan produknya, kita juga harus membangun core tech yang bisa bertahan hidup terlepas dari produk tersebut, sehingga tetap menjadi aset akumulatif yang terus menumpuk meski terjadi perubahan arah
  • Di pusat produk harus ada satu defining constraint yang terus terlihat oleh pengguna, dan batasan ini secara alami menentukan feel serta identitas produk
  • Jika salah satu dari tiga kriteria ini tidak lolos, sikap untuk tidak membuatnya penting untuk mengendalikan cakupan dan mengamankan leverage jangka panjang

Tiga Batasan yang Dipasang Sebelum Membuat

  • Dengan menetapkan batasan sebelum membuat produk, ruang eksplorasi mengecil dan kita bisa mencegah hasil yang menjadi rumit atau kehilangan identitas
  • Selama 10 tahun membuat berbagai produk, produk yang terlalu rumit atau tanpa identitas berujung pada kegagalan, dan dari trial-and-error itu akhirnya diringkas menjadi tiga kriteria
  • Jika Melewati Satu Halaman, Jangan Dibuat

    • Semua ide harus dirangkum dalam one pager, dan dokumen ini berfungsi sebagai north star
    • one pager harus tidak bisa ditawar, akurat, ambisius, namun tetap ringkas tanpa hal yang tidak perlu
    • Dokumen yang sama dapat dipakai untuk berkomunikasi dengan berbagai pihak seperti investor, kontributor, anggota tim, teman, dan keluarga
    • Saat terjadi konflik dalam kolaborasi, hal yang tidak ada di one pager tidak layak diperdebatkan, dan jika benar-benar penting maka dokumennya harus diperbaiki untuk mencerminkannya
    • Jika satu halaman belum terisi penuh, itu bukan berarti isinya perlu dipaksa menjadi lebih panjang, melainkan menandakan bahwa idenya belum siap untuk dibuat
    • Dalam kasus seperti itu, perlu lebih dulu melalui riset, perencanaan, dan prototipe, lalu menulis ulang one pager
    • Jika sampai melewati satu halaman, berarti terlalu rumit sehingga tidak dibuat
  • Teknologi Inti Harus Terpisah dari Produk

    • Terlepas dari produk itu sendiri, kita harus membangun core tech yang menopang produk tersebut
    • core tech bisa berupa metodologi, teknologi, alat, atau produk terpisah, dan harus bisa tetap hidup meski produk saat ini sudah tidak ada
    • Pemisahan seperti ini mencegah kita terkurung dalam satu produk dan memungkinkan akumulasi tetap berlanjut walau arah berubah
    • Produk sering berganti arah, tetapi core tech tetap menjadi aset yang berkelanjutan dan akumulatif
    • Dalam jangka panjang, akumulasi semacam ini bisa menghasilkan keuntungan yang nonlinier
    • Contohnya adalah git dari Linus Torvalds, HCL dari HashiCorp, dan Kubernetes dari Google
    • Ini tidak selalu membutuhkan sumber daya setingkat perusahaan besar; pustaka yang dipisahkan dari codebase atau metodologi yang terus disempurnakan juga bisa menjadi bentuknya
    • core tech harus independen dari arah produk, tetapi tetap selaras dengan visi jangka panjang individu atau perusahaan
    • Jika sebuah ide tidak memungkinkan lahirnya core tech, maka leverage yang didapat tidak cukup besar
  • Satu Batasan Penentu Harus Mendefinisikan Produk

    • Di pusat produk harus ada defining constraint yang selalu terlihat oleh pengguna
    • Batasan ini harus menjadi elemen yang terus ditemui dan diajak berinteraksi oleh pengguna, sehingga membentuk identitas produk
    • Batasan yang baik menciptakan feel produk dan meresap ke seluruh pengalaman pengguna
    • Minecraft tersusun hanya dari blok, dan IKEA memiliki identitas sebagai furnitur flat-pack rakit sendiri; identitasnya langsung terlihat dari batasannya
    • Batasan seperti ini mengurangi ruang pengambilan keputusan, membatasi cakupan, dan membantu fokus pada masalah yang benar-benar penting
    • Jika tidak memilih batasan, atau memilihnya dengan buruk, produk akan mengembang menjadi sesuatu yang ingin melakukan segalanya
    • Jika batasannya dirancang dengan baik, desain produk akan mengikuti batasan itu secara alami
    • Batasan ini juga harus ditempatkan di bagian paling depan one pager

Kriteria Penutup

  • Jika salah satu dari tiga batasan ini tidak lolos, jangan dibuat

1 komentar

 
GN⁺ 18 jam lalu
Komentar Hacker News
  • Saya menyebut hal seperti ini sebagai product primitives
    Misalnya blocks milik Notion, messages/conversations di Telegram, frames/layers di Figma, tweets di Twitter, cells/sheets di Excel, tools/layers di Photoshop, dan commands di CLI

    Menurut saya, desain produk yang bagus muncul saat jumlah primitive seperti ini sangat sedikit
    Produk yang buruk biasanya tidak tahu apa primitive-nya, atau jumlahnya terlalu banyak sehingga semua elemen di dalam produk terasa berjalan sendiri-sendiri
    Akibatnya, pengguna harus mempelajari banyak konsep tingkat atas yang berbeda, jadi bingung, terintimidasi, dan sulit diajarkan
    Idealnya, satu, dua, atau tiga primitive inti sudah cukup

    Kompleksitas dan kekuatan aplikasi datang dari memilih primitive yang bisa dikombinasikan dan punya kedalaman
    Seperti Notion block, Excel cell, CLI command, atau Minecraft block, satuan yang kecil seharusnya bisa dipakai untuk melakukan banyak hal

    • Ini terlihat mirip dengan Alexandrian Pattern Language, tetapi sebenarnya rasanya lebih dekat ke gagasan Centers yang dibicarakan Alexander belakangan

      Sejauh yang saya pahami, industri software banyak menerima pattern-nya, tetapi di akhir hidupnya Alexander melihat unit penyusun paling mendasar dari sistem sebagai Center
      Hal-hal seperti halaman dalam yang terang, tempat duduk di dekat jendela, atau perapian; sesuatu yang menjadi fokus kegunaan lokal dan kohesi
      Center yang kuat secara alami bisa dikombinasikan, meredakan ketegangan lokal, tersusun dari center-center yang lebih kecil, dan berperan sebagai blok bangunan yang menghasilkan center yang lebih besar

      Produk biasanya menjadi kacau dan membengkak bukan karena niatnya buruk
      Kebutuhan pengguna relatif bisa ditemukan secara empiris, tetapi struktur inti yang benar-benar bisa menyerap kebutuhan itu dengan anggun sangat halus dan sulit ditemukan
      Karena itu, jalur termudah hampir selalu adalah menempelkan satu antarmuka yang kaku dan khusus untuk setiap kebutuhan yang muncul di depan mata
      Untuk menemukan primitive inti yang bisa menyerap kebutuhan semacam itu secara alami, dibutuhkan kerja arsitektur yang mendalam

      Mungkin karena itu akhirnya kita terus membuat faster horses

    • Dulu saya menyebut ini concept count
      Biasanya lebih baik meminimalkan jumlah konsep inti yang membentuk produk, dan kadang ini juga disebut nouns and verbs dari produk

    • Filosofi ini terasa agak terlalu menyederhanakan
      Tana pada dasarnya hanya punya dua primitive, yaitu bullets dan supertags, tetapi tetap sangat rumit dipakai sampai-sampai untuk pekerjaan yang sangat sederhana pun orang harus menonton tutorial berjam-jam
      Sebaliknya, Google Maps punya cukup banyak primitive, tetapi untuk 90% kasus penggunaan, UX-nya tetap terasa sangat solid

    • Saya juga memakai ukuran yang mirip saat melihat bahasa pemrograman
      Walaupun ukuran bahasanya besar, kalau secara konseptual kecil, setelah dipelajari sisanya akan mengikuti seiring pengalaman bertambah; sedangkan bahasa yang besar secara konseptual punya hambatan masuk yang tinggi
      Contoh yang paling kuat saya rasakan adalah perl

    • Harus kecil, tetapi tidak boleh terlalu kecil
      Contoh klasiknya shell script (POSIX shell, bash), yang mencoba memodelkan bahkan scripting pun sebagai command agar tidak perlu memperkenalkan konsep baru, dan hasilnya, seperti yang kita tahu, menjadi campuran yang panas, lambat, dan berantakan

  • Saya suka ketiga batasan itu, tetapi saya rasa dokumen 1 halaman harus menyesuaikan kompleksitas proyek
    Untuk proyek kecil sampai menengah, satu halaman mungkin cukup, tetapi untuk software kendali penerbangan ke Mars, mungkin dibutuhkan one-pager yang menaut ke banyak subspesifikasi sebelum implementasi dimulai

    Memisahkan teknologi dan produk benar-benar bijak
    Ambil contoh Skype: ada teknologi komunikasi P2P di backend dan ada aplikasi panggilan di frontend, dan para pendiri yang cerdas menempatkan keduanya di perusahaan yang berbeda
    Jadi bahkan setelah aplikasi frontend Skype dijual ke Microsoft, perusahaan yang memiliki IP inti dan teknologi backend P2P tetap bisa dipertahankan secara terpisah

    Menaruh satu batasan di pusat juga masuk akal, tetapi kadang menurut saya lebih baik punya beberapa batasan atau daftar prioritas
    Jika prinsip tertinggi sulit dikomersialisasikan, memperlakukannya sebagai doktrin yang tak boleh diganggu gugat bisa mendorong bisnis menuju kebangkrutan
    Jika ada ide di dalam tim untuk pivot besar ke arah yang jauh lebih mudah dijual, jalan keluar bisa terbuka meski hasilnya cukup berbeda dari rencana awal
    Twitter juga awalnya hendak melakukan hal lain, lalu public status update muncul dari proyek sampingan

  • Tulisan ini merangkum dengan sangat baik cara saya dulu membangun bisnis bersama mentor riset saya

    Kami memulai dari dua hal terakhir lebih dulu, yaitu teknologi inti dan batasan
    Teknologi intinya adalah sampler yang memungkinkan arbitrary hierarchical Bayesian graph model untuk sparse data, dan batasannya adalah semua itu harus bisa dihitung dalam kondisi CPU-bound
    Yang paling lama justru menyadari bahwa produk akhirnya harus dipisahkan dari teknologi dasarnya

    Saya mendapat nasihat yang mirip dari banyak orang bahkan sebelum memulai, tetapi ada pelajaran yang memang baru melekat setelah mengalaminya sendiri

    • Yang benar tenets, bukan tenants
  • Ide one-pager ini sangat bagus
    Kalau kita bahkan tidak bisa meluangkan waktu untuk menuliskan batasan dengan jelas dalam satu halaman, pada akhirnya kita akan kelabakan dan baru menemukan batasan itu di tengah jalan
    Dan itu bukan bug, melainkan cacat pada tingkat kita sedang membuat hal yang salah

    Saya tidak bisa membuktikannya dengan data, tetapi dari pengalaman saya, proyek yang secara konseptual menempatkan semua orang di halaman yang sama jauh lebih sering berhasil
    Bahkan dokumen tingkat tinggi satu lembar yang menjelaskan dengan jelas apa yang kita lakukan dan apa yang tidak kita lakukan bisa sangat efektif
    Sebaliknya, proyek yang didorong secara improvisasi pada akhirnya membuat semua orang kecewa, termasuk mereka yang sejak awal tidak pernah menyatakan pikirannya dengan jelas

  • Saya berharap penulis menunjukkan satu contoh lengkap di mana batasan benar-benar bekerja
    Khususnya, saya masih belum terlalu bisa membayangkan seperti apa butir ketiga dalam praktik

    • Rasanya juga agak seperti hook yang dibuat-buat
      Pada akhirnya kita seolah tetap harus menemukan sesuatu sendiri
      Saya rasa ide seperti everything's a file di Linux itu bagus
      Dengan satu konsep kuat seperti itu saja, kita sudah bisa melangkah cukup jauh
  • Batasan itu diremehkan

    Solusi yang paling elegan biasanya tidak muncul dari kebebasan tak terbatas, tetapi dari membuat sesuatu dengan batasan yang jelas
    Dan ini juga terhubung dengan poin nomor 1
    Proses menulis one-pager itu sendiri membantu mendefinisikan batasan-batasan tersebut

  • Alasan Google memiliki Kubernetes tampaknya, lebih dari apa pun, adalah melumpuhkan pesaing

  • Kalau ini solo SaaS, batasan yang akan saya tambahkan adalah bisakah saya mendapatkan satu pengguna beta minggu ini
    Waktu, cakupan, dan teknologi bisa terlihat masuk akal di one-pager, tetapi kalau tidak ada yang datang, proyeknya langsung mati
    Jadi sejak awal saya menambahkan batasan distribusi/go-to-market, sehingga saya memvalidasi ada tidaknya permintaan sebelum menggali fitur terlalu dalam

    • Itu secara ketat tampaknya lebih dekat ke tujuan atau metrik daripada batasan
  • Saya khawatir pernyataan teknologi inti harus bisa dipisahkan dari produk akan mendorong abstraksi yang terlalu dini dan penggunaan design pattern yang berlebihan

    Tentu, memisahkan concern dan membagi business domain layer dengan rapi dari persistence/network/UI itu benar
    Tetapi domain layer pada akhirnya tetap akan sangat terikat dengan produknya
    Menurut saya, tidak ada cara untuk menghindari itu

    • Mungkin maksudnya ada lapisan luar yang menarik pembeli, sedangkan yang benar-benar menjalankan bagian dalam bukanlah perhatian pembeli

      Bisa jadi memang ada beberapa konsep yang menjadi antarmuka antara dua lapisan itu, tetapi cara bagian dalam berevolusi seharusnya tetap terpisah dari lapisan produk di luar

  • Saya sedang mendesain renovasi dapur sekarang, dan saya merasa tiga batasan ini akan cukup berguna juga untuk pekerjaan desain yang lebih umum, bukan hanya software

    Saya juga ingin langsung mencobanya

    • Mungkin bisa dibingkai sebagai everything's a space, seperti ruang untuk orang, ruang penyimpanan, dan ruang kerja
      Mungkin terdengar terlalu sederhana, tetapi kalau dilihat sebagai ruang dan aliran jadinya jauh lebih menarik
      Kita bisa memikirkan aliran orang, aliran cahaya, aliran makanan, dan transisi, jadi terasa cukup menarik