Prototip ve Ürün: Yapay Zeka ile Geliştirdiğin Uygulamanın Gerçekten Bitip Bitmediğini Nasıl Anlarsın

Birkaç hafta önce tanıdığım bir kurucu, terapistler için bir randevu uygulaması geliştirdi. Her şey, bir yapay zeka uygulama oluşturucu ile dört gününü aldı. İhtiyacı olanı yapıyor: terapistler takvimlerini görebiliyor, müşteriler randevu alabiliyor, onaylar e-postayla gidiyor. Çalışıyor.

İki haftadır ona bakıyor ve yayınlamadı.

Neden diye sorduğumda şöyle dedi: “Çalışıyor, ama… bitmiş gibi hissettirmiyor.”

Ne değiştireceğini sordum. “Bilmiyorum. Sorun da bu” dedi.

Bu, bir yapay zeka uygulama oluşturucu ile geliştirmenin en zor anıdır. Şey işlevsel, ama “işlevsel” ile “gerçek insanlardan bunu kullanmalarını istemekten rahat olurdum” arasında bir boşluk var. O boşluğu anlamak — ve gerçekte hangi tarafında olduğunu bilmek — yayınlamak ile sonsuza dek kafandaki sesin aşamasında takılı kalmak arasındaki farktır.

”Bitmiş” gerçekte ne demek

İşte önemli olan ayrım: prototip, bir fikri test etmek için kullandığın şeydir. Ürün, bir sorunu çözmek için kullandığın şeydir.

Terapist randevu uygulaması bir prototiptir. Konseptin işe yaradığını kanıtlar. Bir terapist onu kullanabilir. Ama onu kaba hissettiren on yedi küçük şey var:

E-posta onayları çıplak. Logo yok, özel marka yok, jenerik metin.
İptaller bildirim göndermiyor. Müşteriler sadece gelmiyor.
Bir terapistin tüm randevuları doluysa bekleme listesi yok.
Kayıt akışı terapistin uzmanlık alanlarını toplamıyor, bu yüzden uygulama türüne göre filtreleme yolu yok.
Randevudan 24 saat önce gönderilen bir hatırlatma e-postası yok.

Bu şeylerin hiçbiri uygulamayı bozmuyor. Hepsi gerçek bir terapiste şunu düşündürüyor: “Bu, birinden para aldığım bir şey gibi değil, bir hafta sonunda derme çatma yaptığım bir şey gibi geliyor.”

O his gerçektir ve önemlidir. Bir prototip sorunu teoride çözer. Bir ürün, onu kullanan gerçek insan için, pratikte çözer.

Prototipi üründen ayıran üç soru

İşte zor kısım: neyin eksik olduğunu tam olarak bilemezsin. Yapay zeka oluşturucun da bilemez. Bu yüzden, çizginin hangi tarafında olduğunu anlamak için üç hızlı soruya ihtiyacın var.

1. Kendi sorununu çözmek için bunu kullanır mıydın?

Bu soru dürüsttür, çünkü kendi ürününle gerçekten yaşamak zorundasın.

O terapist randevu uygulamasının kurucusu olsaydın, kendi terapi randevularını ayarlamak için onu kullanır mıydın? “Kullanabilir miydin” değil — bir e-posta zinciri ya da paylaşılan bir Google Dokümanı yerine gerçekten kullanır mıydın?

Cevap hayırsa, bitmemiş demektir. Neyin yanlış olduğunu tam olarak biliyorsun — uygulamayı her açtığında hissediyorsun. Cevap evetse, daha yakınsın.

Bahsettiğim kurucu, kendi terapist kaydından geçti. Formda takıldı (randevu almasına izin vermeden önce çok fazla bilgi istiyordu). Onay e-postasını gördü ve amatörce göründüğünü düşündü. Terapistinin e-postayı nasıl alacağını ve spam’e düşüp düşmeyeceğini düşünmeye başladı.

Kendi ürününü, ödeme yapan bir müşterinin kullanacağı şekilde kullanmıyordu. Kullandığında, düzeltecek on şey buldu.

2. Onu senin olmayan üç kişiye gösterdin mi?

Potansiyel kullanıcılarla konuşmak, geliştirmekten daha zordur ve çoğu kurucu bunu atlar çünkü insanları lansmanda şaşırtmak ister. Bu bir hatadır.

Bir odak grubuna ihtiyacın yok. Müşterin olduğunu düşündüğün kişiye benzeyen üç kişiye ihtiyacın var. Terapist uygulaması için bu, üç gerçek terapist demektir.

İşte aradığın şey: nerede kafaları karışıyor? Nerede tereddüt ediyorlar? Ne soruyorlar? “Onlar hakkında ne düşünüyorlar?” değil (insanlar fazla naziktir). Onlardan o şeyi gerçekten yapmalarını iste — bir randevu al, bir onay e-postası gönder, bir şey iptal et.

Kurucu terapist uygulamasını üç terapiste gösterdiğinde, ikisi şunu sordu: “Ne zaman müsait olduğumla ilgili kurallar koyabilir miyim? Mesela, yeni müşterileri yalnızca perşembe günleri görürüm ve öğleden önce çift randevu almam.” Uygulamanın bir takvimi vardı, ama kuralları yoktu. Prototipi, kendisinin randevulaşmanın nasıl işlediğini düşündüğü şekle göre geliştirmişti, terapistlerin gerçekte nasıl çalıştığına göre değil.

İşte bu ürün bilgisidir. Bunu bir spesifikasyondan tahmin edemezdin.

3. Bunu on gerçek kullanıcıya verseydin ne bozulurdu?

Bu en zor sorudur çünkü uç durumların hakkında gerçekten düşünmeni gerektirir.

Terapist uygulaması için:

Bir müşteri aynı anda iki randevu almaya çalışırsa ne olur? (Uygulama kontrol etmiyor.)
Bir terapist bir randevuyu iptal ederse ne olur? Müşteriler otomatik olarak haberdar ediliyor mu? (Hayır.)
Bir müşterinin e-posta adresi yanlışsa ne olur? Baştan başlamadan onu düzeltmenin bir yolu var mı? (Hayır.)
Bir terapistin hasta olduğu bir gün varsa ve takvimini bir haftalığına kapatması gerekirse? (Her randevuyu elle silmesi gerekirdi.)

Bunlar hata değil. Uygulama çökmüyor. Ama bunlar kâğıt kesikleri. On gerçek kullanıcı ve gerçek uç durumlarla, ilk haftada hepsine çarparsın.

Bir ürün uç durumları idare eder. Hepsini değil — bazı şeyler bekleyebilir. Ama gerçek kullanıcılarla ilk iki haftada olanlar, işte onların çalışması gerekir.

Nasıl karar verilir: üç katmanlı test

Nerede olduğunu anlamak için bunu kullan:

Katman 1: Çekirdek akış — Mutlu yol çalışıyor mu? Bir kullanıcı, uygulamanın tasarlandığı asıl şeyi yapabiliyor mu?

Terapist randevu uygulaması için: evet. Biri kaydolabilir, randevu alabilir, onay alabilir. Çalışıyor.

Katman 2: Gerçek kullanımdan gelen uç durumlar — Onu üç gerçek kullanıcıya gösterdin. Geliştirmediğin bir şeye çarptılar mı? Bir yerde kafaları karıştı mı?

Terapist randevu uygulaması için: evet. Üç terapist, kurala dayalı müsaitlik istedi. Biri, onay e-postası fazla jenerik göründüğü için kafası karıştı. Biri randevuları toplu silmeye çalıştı ve yapamadı.

Katman 3: İncelik ve profesyonellik — Önemsediğin hissettiriyor mu? Yoksa derme çatma birleştirmişsin gibi mi hissettiriyor?

Terapist randevu uygulaması için: derme çatma hissettiriyor. E-posta onayları çıplak. Özel marka yok. Bir şey ters giderse hata mesajı yok, bu yüzden bir şey bozulursa kullanıcının ne olduğuna dair hiçbir fikri yok.

İşte sezgisel kural:

Üç katman da çalışıyor mu? Bir ürünsün. Yayınla.
Katman 1 ve 2 çalışıyor, 3 çalışmıyor mu? %80 bitirdin. Bir gününü inceliğe ayır.
Katman 1 çalışıyor, katman 2 ve 3 çalışmıyor mu? Bir prototipsin. Henüz yayınlama.
Katman 1 sağlam değil mi? Bitmemiş demektir. Geliştirmeye devam et.

Terapist uygulaması, Katman 1 ile Katman 2 arasındaki sınırda takılı kalmıştı. Çekirdek akış çalışıyordu, ama gerçek terapistler eksik parçalar buldu. Yani kurucunun bir seçeneği vardı: yapay zeka oluşturucusuyla bir hafta daha geçirip terapistlerin gerçekten ihtiyaç duyduğu özellikleri eklemek ya da elindekiyle yayınlayıp onları sonra eklemek.

(Ekledi. Üç gün sürdü. Şimdi bir ürün.)

Bunu zorlaştıran şey

Bu kadar çok kurucunun burada takılmasının nedeni, geliştirmenin eğlenceli, yayınlamanın korkutucu olmasıdır.

Geliştirmek, yapay zeka aracınla bir sohbettir. Bir fikrin olur, anlatırsın, araç onu yürütür. Dakikalar süren bir geri bildirim döngüsü vardır. Yayınlamak farklıdır. Yayınla’ya basarsın ve bir şey yanlışsa, gerçek insanlar öğrenir. Geri alma yoktur.

Bu yüzden yayınlamamak için nedenler buluruz. “Yeterince incelikli değil.” “Bir özellik daha eklemeliyim.” “Ya yazı tipleri yanlışsa?” Ve altı hafta sonra hâlâ çalışan ama bitmiş hissettirmeyen bir şeyin üzerinde oturuyorsundur ve bunun yazı tipleri yüzünden olduğuna kendini ikna etmişsindir.

Sorun yazı tipleri değil.

Genellikle sorun, gerçek bir kullanıcıyla zaman geçirmemiş olman ya da kafanda mantıklı gelen ama gerçek insanların çalışma şekline tam oturmayan bir şey geliştirmiş olmandır. Bu düzeltilebilir. Sadece neyi bilmediğini bilmediğini kabul etmeyi ve sonra bilen biriyle konuşmaya gitmeyi gerektirir.

Lansman hazırlık kontrol listesi

Bunu kullan. Kısa ve dürüst.

Gerçek görevi yapmak için onu kendim kullandım ve çalıştı (demo modunda değil, gerçekten).
Onu gerçekten kullanacak üç kişiye gösterdim ve kafalarının karıştığı şeyleri düzelttim.
Olabilecek her hatanın, kullanıcıya ne yapması gerektiğini söyleyen bir mesajı var (“hata” değil, gerçek bir yönlendirme).
Bu, altı ay boyunca son versiyon olsaydı sorun olmazdı (yani: bir daha hiç dokunmasam bile yararlı olacak kadar eksiksiz).
Gerçek kullanıcılardan öğreneceklerim için, boşlukta daha fazla özellik eklemekten daha heyecanlıyım.

Beş kutuyu da işaretleyebiliyorsan, bitti. Yayınla.

Edemiyorsan, yayınlama. Ama nedeni konusunda spesifik ol. “Bitmiş gibi hissettirmiyor” bir neden değil. “Gerçek terapistlerin müsaitlik kurallarına ihtiyacı var ve ben onu henüz geliştirmedim” bir nedendir. Bu eyleme dönüştürülebilir. Bu düzeltilebilir. Takılı kalmak ile bir yolda olmak arasındaki fark budur.

Terapist uygulamasının kurucusu onu dün yayınladı. İlk ödeme yapan müşterisi var. Ürün kusursuz değil, ama gerçek ve müşterisi ona şimdiden sonra ne geliştireceğini söylüyor. İşte o zaman bitmiş olduğunu anlarsın: uygulama kusursuz olduğunda değil, onu kullanan insanlar için kusursuzun gerçekte ne anlama geldiğini öğrenmeye hazır olduğunda.