← Tüm yazılar
AIProduct Management
🌐 Read in English

Demo Çalışır, Üretim Çöker

25 Nisan 2026·5 dk

Geçen ay bir potansiyel müşteriye ürün demosu yaptık. Her şey pürüzsüz ilerledi. Hastanın randevusu sisteme girildi, anamnez formu otomatik dolduruldu, reçete tek tıkla oluştu. "Mükemmel" dedi karşıdaki hekim. "Hemen başlamak istiyoruz."

İki hafta sonra onboarding sürecinde aradılar. "Bu alanlar bizim sistemde yok." "Bu adım biz için farklı çalışıyor." "Doktorlarımız böyle doldurmak istemiyor."

Demo çalışmıştı. Gerçek dünya çalışmıyordu.


Bu benim yaşadığım hikaye. Ama aynı zamanda son derece yaygın bir hikaye.

MIT araştırmasına göre kurumsal generative AI pilotlarının yüzde doksan beşi ölçülebilir ROI sağlayamıyor. Bir kez daha söyleyelim: yüzde doksan beş. Demolar mükemmel görünüyor. Üretim çöküyor.

Neden?

Çünkü demoyu biz tasarladık.

Temiz veri kullandık. Kontrollü senaryo kurduk. "Eğer kullanıcı şunu yaparsa..." diye başlayan soruları bir kenara bıraktık. En doğal akışı gösterdik. En az hata çıkan path'i seçtik. Demo bir ürünün en iyi günüdür. İş ilanı değil.

Ama gerçek dünya böyle işlemiyor.

Gerçek bir klinik yazılımında veriler dağınıktır. Kimi hekim her şeyi sisteme girer, kimi sadece reçeteyi. Kimi asistan randevu saatini beş dakika yanlış yazar, sistem patlar. Kimi kullanıcı formu başa sarar, ortadan doldurur, sonra geri gelir. AI modeli "ideal input" beklerken gerçek dünyada ideal diye bir şey yoktur.


Şunu sormak lazım: bu sadece teknik bir sorun mu?

Hayır.

Teknik kısım aslında çözülebilir — veri temizleme, edge case handling, fallback mekanizmaları. Asıl sorun organizasyonel.

Enterprise AI dağıtımlarının büyük çoğunluğu neden tökezliyor? Governance eksikliği. Veri politikası yok. Kim onaylayacak? Hangi ekip sorumlu? Uyumluluk süreci ne kadar sürer? Bu sorular demo sırasında yoktur çünkü demo sırasında gerçek bir organizasyon yoktur. Sahne kurulmuş, aktörler hazır, seyirci etkilendi. Sonra perde kapanıyor ve gerçek başlıyor.

Ve PM'ler olarak bu kısmı çok geç fark ediyoruz.


Benim öğrendiğim şey şu: başarıyı demoda değil, demoya başlamadan önce tanımlamak gerekiyor.

Yani şu soruları sormak lazım:

  • Başarının neye benzediğini altı ay sonra nasıl ölçeceğiz?
  • Hangi veri bu sisteme girecek ve o veri şu an gerçekte nasıl görünüyor?
  • Bunu kullanacak olan kişi en son ne zaman yeni bir araç öğrendi?

Son soru önemli. Çünkü AI ürünleri öğrenme eğrisi gerektiriyor. Ama bunu kullanacak hekim sabah dokuzda yirmi hastasını karşılayacak. Öğrenme zamanı yok. Onboarding süreci, alışkanlık değişimi, motivasyon — bunlar ürün tasarımının parçası olmak zorunda. Sonradan eklenen bir şey değil.

"Çalışıyor mu?" sorusu yetmiyor. "Gerçek ortamda, gerçek kullanıcıyla, gerçek baskı altında çalışıyor mu?" sorusunu sormak lazım.


Demo göreve değil, satışa hizmet eder. Bu yanlış değil — satış önemli. Ama PM olarak demo-karşıtı olmayı da sevmeliyiz: yani ürünün zor koşullarda nasıl davrandığını izlemeyi, ilk gerçek kullanıcı verilerini düzensiz halde görmeyi, bir şeyin beklediğimiz gibi çalışmadığını early adopter aşamasında öğrenmeyi.

MIT verisine geri dönelim. Yüzde doksan beş başarısızlık, ölçülebilir ROI eksikliği — bu PM'lerin demo öncesi başarı kriterleri koymadığını söylüyor. "Zamanla anlayacağız" diye başlayan projeler asla ölçülemiyor. Çünkü ölçüm kasıtlı bir tasarım gerektiriyor.

Başarıyı sonradan bulmaya çalışmak, olta atmadan önce balığı yakalamaya benziyor.


Şimdi ne yapıyorum?

Yeni bir özelliği demolamadan önce şunu soruyorum: "Bu özelliği nasıl test ederiz ki demo başarısını değil, gerçek başarıyı ölçelim?"

Cevap çoğu zaman rahatsız edici oluyor.

Ama o rahatsızlık, sonradan üretimde yaşayacağımız çöküşten çok daha ucuz.