Kod Yazmadan Önce Fikri Doğrulamak: Boşa Giden Haftaları Kurtarır

Geçen yıl, 2024’ün Mart ayında İstanbul’da bir startup toplantısında tam bu mevzuya yine denk geldim: ekipte herkes heyecanlı, fikir “çok iyi”, kahve soğumuş. Kimse tek bir gerçek kullanıcı konuşması yapmamış. Açık konuşayım, bu tabloyu o kadar çok gördüm ki artık refleks gibi geliyor. İnsanlar kod yazmayı seviyor; ben de seviyorum. Ama işin aslı şu ki, klavyeye abanmak bazen üretkenlik değil, zarifçe paketlenmiş bir zaman kaybı oluyor.

Şahsen, Bak şimdi… sorun hız değil. Sorun yön. Bir fikri iki günde ayağa kaldırabilirsiniz — hatta bunu bayağı iyi de yaparsınız — ama yanlış problemi çözüyor olursanız, ortaya çıkan şey sadece hızlı yapılmış bir hayal kırıklığı olur, başka bir şey değil. Bunu 2023 yazında Kadıköy’de küçük bir yan proje için birebir yaşadım: üç gün boyunca özellik ekledim, durmadan commit attım, sonra fark ettim ki kimsenin gerçekten aradığı şey o değilmiş. O an biraz moral bozuluyor tabi.

Neden “hemen kod” refleksi çoğu zaman ters teper?

Yazılımcılar olarak elimiz doğal biçimde çözüme gidiyor. Bir sorun duyunca akla gelen ilk şey genelde ekran açmak, repo oluşturmak ve ilk commit’i atmak oluyor. Güzel hissettiriyor mu? Evet. Ama bu his biraz kandırıcı, dürüst olmak gerekirse. Çünkü daha ortada problem netleşmeden çözüm üretmeye başlarsanız, aslında kendi kendinize iş çıkarıyorsunuz — hani boş yere terleyen biri gibi.

Hmm, bunu nasıl anlatsamdı…

Ben bunu özellikle side project tarafında çok gördüm (ciddiyim). Bir arkadaşımın 2024 başında Ankara’da başlattığı küçük SaaS denemesi vardı; fikri anlatırken herkes “süper ya” dedi ama hiçbir kullanıcı “Buna ihtiyacım var” demedi. Sonra iki hafta geçti. Trafik geldi ama kayıt yoktu. O noktada insan anlıyor işte: alkış başka şeydir, ihtiyaç başka şey. Arada dağlar var.

Şunu da dürüstçe söyleyeyim: bazen geliştiriciler olarak biz de doğrulama kısmını sıkıcı buluyoruz çünkü kod kadar somut gelmiyor. Halbuki o birkaç görüşme, birkaç forum taraması — en azından ben öyle düşünüyorum — veya Discord mesajı size haftalar kazandırabiliyor. Hani marangozlukta önce ölçüp biçersiniz ya — burada da durum neredeyse tamamen aynı.

Doğrulama ne demek, ne demek değil?

Şöyle söyleyeyim, Burada ince ama önemli bir ayrım var. İnsanlara fikrinizi anlatıp “Nasıl olmuş?” diye sormak doğrulama sayılmaz. Sayılmaz, gerçekten. Çünkü çoğu kişi kırmamak için güzel konuşur — size samimi geri bildirim değil, sosyal nezaket verirler. Kötü niyetli oldukları anlamına gelmiyor; sadece insan doğası böyle çalışıyor, ne yaparsınız.

Gerçek doğrulama ise daha serttir: “Bu acıyı zaten yaşıyor musun?” İşte aradığınız cümle bu civarda dönmeli. Mesela biri size “Evet ya, bunu her hafta Excel’le hallediyorum ve nefret ediyorum” diyorsa — orada kıvılcım vardır. Kesinlikle. Ama “Fena fikir değil” dediyse… eh, o pek yetmez.

İnsanlar çoğu zaman fikrinizi beğendiklerini söyler; siz ise onların gerçekten acı çekip çekmediğini anlamaya çalışmalısınız.

“Beğeni” ile “ihtiyaç” arasındaki uçurum

Kendi not defterimde yıllardır aynı cümle duruyor: Beğenilen ürün satmaz; ihtiyaç karşılayan ürün tutar. Sert mi? Biraz sert. Ama doğruya yakın duruyor işte — özellikle geliştirici kitlesine yönelik araçlarda insanlar önce merak eder, sonra dener, sonra unuturlar, eğer ortada tekrar eden gerçek bir dert yoksa tabii.

Bence burada en büyük tuzak şu: geliştirici topluluğu yeni araçlara aşırı açık görünüyor diye her olumlu tepkiyi sinyal sanıyoruz. Halbuki ilgiyle kullanım arasında bayağı mesafe var. Ciddi mesafe.

Sinyal	Anlamı	Ağırlığı
“Güzel fikir”	Kibar onay	Düşük
Soru sormaları	Merak başladı	Orta
“Bunu bugün kullanırım” demeleri	Gerçek ihtiyaç var	Yüksek
Erişim istemeleri / deneme talebi	Tam sinyal burada gelir	Çok yüksek

Kırk sekiz saatte yapılabilen doğrulama planı nasıl işler?

Evet, abartmıyorum. Çoğu fikir için iki gün yeterli olabilir. Tabii bu “ürünü bitirirsiniz” anlamına gelmiyor — zaten mesele de o değil. Mesele şunu anlamak: Bu problem gerçek mi? İnsanlar bunu çözerken hangi yöntemi kullanıyor? Mevcut çözümden neden memnun değiller, ne eksik? (ki bu çoğu kişinin gözünden kaçıyor)

Bence, İlk gün: problemin izini sürün.
İkinci gün: çözümünüzü basitçe test edin.

Birinci gün: problemi insanların olduğu yerde bulun

Kullanıcıların toplanma noktaları belli aslında: GitHub tartışmaları, Reddit başlıkları, Slack grupları, Discord kanalları, sektör forumları… Oralarda insanlar filtreyi kapatıp derdini döküyorlar — biraz kulak kabartmanız yeterli oluyor yani.

• sürekli tekrar eden şikâyetler arayın;
• birebir aynı işi elle yapan workaround’lara bakın;
• bunun daha kolay yolu yok mu?” tarzı cümleleri not edin; (bence en önemlisi)
• aşırı övgü yerine sinir tonu taşıyan mesajları ayıklayın.

Bir şey dikkatimi çekti: Bunu geçen sene Berlin’deki bir online community’de test ettiğimde net gördüm: insanlar özelliği istemiyordu aslında; mevcut aracın karmaşıklığından kaçmak istiyorlardı (bizzat test ettim). Yani çözülmesi gereken şey parlak yeni teknoloji değildi… sürtünmeydi. Tamamen sürtünme.

İkinci gün: çözümü satmaya çalışmadan anlatın

Bakın, bir şey dikkatimi çekti: Bence en temiz yöntem şu cümleyle başlamak: “Şöyle bir araç yapmayı düşünüyorum…” Ardından tek paragrafta problemi (evet, doğru duydunuz). Öneriyi anlatın. Uzun demo metinlerine gerek yok — erken aşamada kimse roman okumuyor zaten.

Kısa bir not düşeyim buraya.

I'm thinking of building a tool that helps you X.
Would this solve a problem you already have?
If yes — what do you use today instead?
If no — what's missing?

Dikkat edin; burada amaç satış yapmak değil etkiyi ölçmek. Eğer biri detay soruyorsa iyi işaret var demektir. Eğer biri “can I try it?” diyorsa tamamdır — orada sıcaklık yükselmiştir. Sessizlik ise genelde sessizliktir. Fazla romantize etmeye gerek yok. Daha fazla bilgi için Manticore Search’ü Grafana ile Tek Komutla İzle yazımıza bakabilirsiniz.

Neyi takip etmeli? Alkışı mı, ilgiyi mi?

Bi saniye — Kısacası alkış peşinde koşmayın. Ben buna birkaç projede düştüm — özellikle de build-in-public hevesinin zirvede olduğu dönemlerde. Paylaşım geliyor, beğeni geliyor, yorum geliyor ama kayıt yoksa… mesele bitmiştir diyemiyorsunuz tabii, ama ortada ciddi bir sorun var. Bu konuyla ilgili RAG’de Asıl Kahraman Retrieval: LLM Sadece Ses Veriyor yazımıza da göz atmanızı tavsiye ederim. Daha fazla bilgi için Claude Code Ayarları Makinenizle Birlikte Kaybolmasın yazımıza bakabilirsiniz.

Durun, bir saniye. PyTorch ile Kenar Algılama Paketi Yazmak: Küçük Ama Şaşırtıcı İş yazımızda da bu konuya değinmiştik. Türk Telekom’un TurboBox Hamlesi: 5G Cebinize Geliyor yazımızda da bu konuya değinmiştik.

Açık konuşayım, ben artık üç şeyi ayrı ayrı okuyorum: İlgi var mı? Soru geliyor mu? İnsanlar spesifik örnek veriyor mu? Bunlar varsa yol açılıyor demektir. Hatta bazen negatif yorum bile pozitiftir — çünkü gerçek kullanımı gösterir, en azından birisi umursuyor demektir.

• Zayıf sinyal: güzel sözler, emoji yağmuru, genel destek mesajları;
• Orta sinyal: teknik soru, alternatif isteme, fiyat merakı;
• Güçlü sinyal: “Bende şu sorun var” veya “denemek isterim” çıkışı;

Küçük startup ile kurumsal ekip aynı şeyi yapmaz

Yani, Küçük bir startup’ta hız avantajdır ama kör hız tehlikelidir. Kurumsal tarafta ise karar yavaş ilerler — fakat veri daha bol olur. İkisinde de ortak nokta şu: doğrulamayı erkene almak, sonradan ağlamaktan iyidir (yanlış duymadınız). Her zaman.

Doğrusu, Küçük ekiplerde basit landing page + manuel demo + kullanıcı görüşmesi çoğu zaman yeterli. Enterprise seviyede ise iç paydaşlar, güvenlik gereksinimleri, entegrasyon beklentileri devreye girer; orada doğrulama sadece pazar ihtiyacını değil, uygulama maliyetini de ölçmek zorundadır — bu kısmı atlarsanız sonradan çok pişman olursunuz.

Neden bu yaklaşım vakit kazandırıyor?

Bence en büyük tasarruf para değil, odak kazanımı. Çünkü yanlış projeyi hızlı yapmak yine yanlış projedir. Nokta. Siz kod yazarken zihninizde hep küçük bir şüphe kalıyorsa, o proje sizi içeriden kemiriyor. Mantıklı değil mi? — farkında olsanız da olmasanız da.

Bunu İzmir’de çalışan eski bir ekip arkadaşım bana geçen Şubat’ta anlattı: iki haftalık prototipi çöpe atmışlar ama hiç üzülmemişler, çünkü ilk günden pazar sinyali zayıfmış. Kulağa acımasız geliyor olabilir. Ama dürüst olmak gerekirse sağlıklı olan da bu — erken öğrenmek, geç pişman olmaktan bin kat iyidir.

Neyse uzatmayayım: erken doğrulama size üç şey verir — daha net yön, daha az pişmanlık ve daha iyi önceliklendirme. Kod ikinci sıraya düşüyor diye değersiz olmuyor; tam tersine, doğru anda yazıldığında gerçek değer kazanıyor.

Bazen sorun üründe değil varsayımda olur

Mantık basit gibi duruyor: problem → çözüm → kullanıcı. Gerçekte sıra çoğu kez karışıyor — çünkü biz önce varsayımı seviyoruz. Hatta bazı projelerde varsayım — en azından ben öyle düşünüyorum — öyle baskın oluyor ki kullanıcıyı dinlemek neredeyse dekor gibi kalıyor. Acı ama gerçek.

Bana göre en faydalı soru şu: “Bu problemi şu anda nasıl hallediyorsunuz?” Cevap boşluk bırakıyorsa kötü haber — kağıt üstünde süper görünen fikir pratikte “göreceğiz artık” seviyesine düşüyor. Ve evet, bu biraz hayal kırıklığı yaratabiliyor. Ama daha iyi şimdi öğrenmek, değil mi?

Sıkça Sorulan SorularCoding’e başlamadan önce fikir nasıl doğrulanır？Kullanıcıların bulunduğu yerlerde problem izini sürerek başlayın:forumlar Discord grupları GitHub tartışmaları. Sonra fikrinizi kısa ve sade şekilde anlatıp geri bildirim isteyin. En güçlü sinyal,“bunu deneyebilir miyim？” sorusudur.Birkaç kişiden olumlu yorum almak yeterli mi？Pek sayılmaz. Olumlu yorum güzel başlangıçtır ama asıl önemli olan acının ne kadar sık yaşandığıdır. Tekrar eden sorun ve mevcut çözümden duyulan memnuniyetsizlik varsa iş ciddileşir.MVP yapmadan da test etmek mümkün mü？Evet. Landing page basit mockup manuel demo ile gayet test edebilirsiniz. Erken aşamada amaç tam ürün göstermek değil talep olup olmadığını anlamaktır.Küçük side project’lerde de doğrulama gerekir mi？Evet,hatta belki daha da çok gerekir: Çünkü side project’lerde motivasyon sınırlıdır ve yanlış fikre harcanan hafta can sıkar. Basit testler bile sizi boş yere yorulmaktan kurtarır.Kaynaklar ve İleri OkumaY Combinator Library — Startup Doğrulama İçerikleriThe Lean Startup Resmi Kaynak SayfasıNielsen Norman Group — User Interviews Rehberi!