"Jika Anda tidak malu dengan versi pertama produk Anda, Anda telah meluncurkannya terlambat." — Reid Hoffman Di Splits, kami mengikuti pendekatan ini untuk membangun perangkat lunak: membuatnya berfungsi → membuatnya benar → membuatnya cepat. Perintah itu penting. Inilah yang telah kami pelajari saat pengiriman setiap fase:

Buat bekerja = prototipe fungsional. Itu harus kasar. Itu harus janky. Dapatkan di depan pengguna dengan cepat. Bagaimana kami mencakupan MVP: 1) Buat daftar semua yang menurut kami mungkin penting atau relevan dengan proyek. 2) Berapa *minimum mutlak* dari daftar ini yang dapat kita selesaikan dan memiliki prototipe fungsional?

Perbaiki = perbaiki semua bit yang rusak. Masuki fase ini dengan sinyal yang jelas dari pasar: umpan balik yang konsisten, penggunaan yang meningkat meskipun ada kekurangan yang jelas. Sekarang Anda telah mendapatkan hak untuk menginvestasikan lebih banyak sumber daya.

Buat cepat = optimalkan kinerja. Sejujurnya, kami masih belajar tentang fase ini. Sebagian besar Teams saat ini dalam mode 🤷 ♂️ "perbaiki" Tapi inilah inspirasi yang mendorong kami:

Mengapa pendekatan ini berhasil: Pengurutan adalah strategi. Apa yang Anda pelajari hari ini membentuk apa yang Anda bangun besok. Lewati dan Anda tidak memiliki informasi yang diperlukan untuk memecahkan masalah dengan benar. Tindakan menghasilkan informasi. Tetapi tindakan *disengaja* menghasilkan informasi *lebih berguna*.

Jebakan adalah mencoba memperbaikinya pada saat yang sama ketika Anda membuatnya berhasil. NOPE. "Beri diri Anda izin untuk mengirimkan sesuatu yang Anda tahu tidak benar." — @wminshew