Pitch Deck'imdeki 5 Hata (Türk SaaS Kurucu Notları)
18 sayfalık bir pitch deck hazırladım, sonra tek tek elden geçirip 8 sayfaya indirdim. Teknik mimari slaytı, top-down TAM klişesi, boş rakip slaytı, sondaki ask ve CV odaklı ekip slaytı — beş hata, gerekçeleri ve şu an kullandığım 8 sayfalık şablon.
📅 Not: Bu yazının önceki sürümü belirli bir yatırımcı görüşmesinin anlatısı olarak yazılmıştı; içinde yatırımcıya atfedilen sözler, kendi traksiyon rakamlarımız, bir rekabet matrisi ve süreç sonucuna dair ifadeler vardı. Bunları çıkardık — ne o rakamları ne o görüşme anlatısını destekleyecek verimiz var, ayrıca başka ürünler hakkında o matriste yer alan yargıları savunamayız. Kalan şey deck'in kendisi üzerine yaptığımız değerlendirme.
TL;DR: İlk pitch deck'imiz 18 sayfaydı ve baştan sona yanlış kurgulanmıştı. Beş hata: (1) müşteri hikâyesi yerine teknik mimari slaytı, (2) top-down TAM/SAM/SOM klişesi, (3) "rakip yok" yazan boş bir rakip slaytı, (4) yatırım talebinin en sonda olması, (5) problem yerine CV listeleyen ekip slaytı. Aşağıda her birinin neden yanlış olduğu, yerine ne koyduğumuz ve şu an kullandığımız 8 sayfalık şablon var — kendi sayılarınızla dolduracağınız boş bir iskelet olarak.
Bir pitch deck'i hazırlarken kendinize mantıklı görünen her şey, dışarıdan bakan birine bambaşka görünüyor. Bizim ilk deck'imiz 18 sayfaydı ve şu an geriye dönüp baktığımda ilk dört slayttan sonrasının çoğu gereksizdi.
Bu yazıda o beş hatayı ve her birinin yerine ne koyduğumuzu yazıyorum. Deck hazırlıyorsanız işinize yarayabilir.
Bu yazı Erken Aşamada Kullanıcı Nerede Kaybedilir ve Türk SaaS'ta Yanlış Çıkan 5 Yabancı Best Practice yazılarımızın yatırım tarafındaki karşılığı.
Pitch deck'imizin ilk hali
18 sayfa, planlanan anlatım süresiyle:
| # | Slayt | Planlanan süre |
|---|---|---|
| 1 | Cover (logo + tagline) | 30 sn |
| 2 | Problem | 2 dk |
| 3 | Problem detayı (3 alt-problem) | 2 dk |
| 4 | Çözüm | 2 dk |
| 5 | Demo ekran görüntüsü | 1 dk |
| 6 | Demo akışı (3 adım) | 2 dk |
| 7 | Teknik mimari diyagramı | 3 dk |
| 8 | Pazar büyüklüğü (TAM/SAM/SOM) | 2 dk |
| 9 | Pazar trendleri | 1 dk |
| 10 | İş modeli | 1 dk |
| 11 | Müşteri segmentleri | 2 dk |
| 12 | Rakip analizi ("yok") | 30 sn |
| 13 | Roadmap | 2 dk |
| 14 | Traksiyon | 1 dk |
| 15 | Finansal projeksiyon (3 yıl) | 2 dk |
| 16 | Ekip (5 kişi profili) | 2 dk |
| 17 | Vizyon (5 yıl) | 1 dk |
| 18 | Ask + iletişim | 1 dk |
Toplam plan: 25 dakika anlatım + 15 dakika soru-cevap.
Sorun şu ki bir yatırımcı deck'i sizin anlattığınız hızda okumuyor. Slaytları hızla geçip kafasında kendi senaryosunu kuruyor. Yani 18 slaytlık bir anlatım planı, gerçekleşmeyecek bir plan.
Hata #1 — Müşteri hikâyesi yerine teknik mimari
- slayt bir mimari diyagramıydı: AWS, Next.js, Supabase, OpenAI kutuları ve aralarında oklar.
Bu slaytın sorunu şu: erken aşama yatırımcısı için önemli olan hangi problemi kimin için çözdüğünüz ve bunun bir işe dönüp dönmediği. Kullandığınız veritabanı, o sorulara cevap vermiyor. Mimari diyagramı teknik due diligence aşamasının konusu, ilk sunumun değil.
Yerine ne koyduk
Somut bir kullanım anı:
Yanlış:
[ AWS ─ Vercel ─ Next.js ]
↓ ↓
[ Supabase OpenAI ]
Doğrusu:
"Müşteri gece 23:00'te DM yazıyor: 'Fiyatınız?'
İşletme sahibi uyuyor.
FendyChat saniyeler içinde marka tonunda yanıtlıyor.
Sabah sahibin önünde onaya düşmüş 3 hassas mesaj var,
gerisi hallolmuş."
Ders: Yatırımcı için "ne işe yarıyor" > "nasıl çalışıyor".
Bir uyarı: bu slaytta bir sonuç oranı yazacaksanız (dönüşüm arttı, şu kadar zaman kazandırdı) o oranın arkasında gerçek bir ölçüm olsun. Kaynağı olmayan bir yüzde, soru-cevap kısmında sizi zor duruma düşürüyor — çünkü ilk sorulan şey "bunu nasıl ölçtünüz?" oluyor.
Hata #2 — Top-down pazar büyüklüğü (TAM klişesi)
- slaytta klasik üçlü vardı: TAM, SAM, SOM — büyük bir pazar rakamı ve ondan alınacak küçük bir dilim.
Niye yanlış?
Çünkü her sunumda aynı yapı var ve hepsi aynı örtük iddiaya dayanıyor: "bu koca pazarın %1'ini alsam yeter." Bu iddia hiçbir şey açıklamıyor; o %1'e nasıl ulaşacağınızı anlatmıyor.
Yerine ne koyduk: bottom-up
Bottom-up hesap, ulaşılabilir müşteri sayısından başlayıp yukarı doğru gidiyor. İskeleti şöyle:
Türkiye'de Instagram üzerinden aktif satış yapan işletme sayısı:
[kaynak göstererek sayı]
Bunlardan aylık 100+ DM/yorum alan kesim:
[oranı gerekçesiyle daralt]
Bu segment × aylık plan ücreti = ulaşılabilir aylık pazar
Hedef: ilk 24 ayda bu segmentin %X'i
= ... müşteri = ... MRR
Burada kritik nokta ilk satır: o sayıyı nereden aldığınız. Biz ilk versiyonda buraya kaynağı olmayan bir tahmin yazmıştık ve bu, hesabın tamamını çürütülebilir hale getiriyordu. Kullanacağınız her taban sayının yanına kaynağını yazın — resmî istatistik, platformun kendi yayınladığı rapor, sektör derneği verisi. Kaynak bulamıyorsanız o sayıyı bir varsayım olarak etiketleyip aralık verin.
Ders: Bottom-up + kaynaklı sayı > top-down klişe. Kaynağı olmayan bottom-up ise top-down'dan daha kötü, çünkü kesinlik iddiası taşıyor.
Hata #3 — Boş rakip slaytı
- slaytta tek bir cümle vardı: "Türkiye'de doğrudan rakip yok."
Bu cümlenin iki sorunu var. Birincisi doğru olmaması: global araçlar Türkiye'de kullanılıyor, dolayısıyla rakip var. İkincisi ve daha ciddisi, bunu yazdığınızda karşı taraf pazarı sizden iyi tanıdığını fark ediyor ve o noktadan sonra söylediğiniz her şeyi bir kere daha süzüyor.
Yerine ne koyduk
Bir rekabet slaytı hazırlarken bizim kendimize koyduğumuz kural şu oldu: karşı taraf hakkında yalnızca savunabileceğimiz şeyi yazmak.
Yazılabilecek şeyler:
- Kaç kanalı desteklediği (kendi ürün sayfasından doğrulanabilir)
- Bir özelliğin üründe olup olmadığı
- Arayüz ve destek dili
- Kendi ürünümüzün doğrulanabilir özellikleri ve fiyatı
Yazmadığımız şeyler ve nedenleri:
- Rakip fiyatı ve ondan türetilen çarpanlar — fiyatlar değişiyor, döviz varsayımı tartışmaya açık ve karşılaştırmalı reklamda ispat yükü bizde
- Rakibin mevzuata uyumu hakkında hüküm — bir şirketin uyumsuz olduğunu ima etmek, elinizde kanıt yoksa haksız rekabet
- Yıldızlı kalite puanları — bir ölçüm yapmadıysanız "⭐⭐ vs ⭐⭐⭐⭐⭐" bir ölçüm iddiası
- Rakibin müşteri sayısı — kamuya açık değilse tahmin
Bunları çıkardığınızda slayt zayıflamıyor; savunulabilir hale geliyor. Farkınızı kendi ürününüzün ne yaptığıyla anlatıyorsunuz: Türkçe için baştan yazılmış prompt mimarisi, imzalı Türkçe DPA, TR/AB sunucu, sektör template'leri, ₺ bazlı sabit fiyat.
Ders: "Rakip yok" demeyin. Ama rakip hakkında ispatlayamayacağınız şeyi de yazmayın — soru-cevapta ilk çöken slayt o olur.
Hata #4 — Yatırım talebi en sonda
- slayt "Ask" idi — yani yatırımcının en çok merak ettiği bilgi, sunumun sonunda.
Oysa karşı taraf ilk dakikalarda kafasında bir çerçeve kuruyor: "Bu hangi büyüklükte bir konuşma?" O çerçeve olmadan dinlediği her şeyi nereye yerleştireceğini bilmiyor.
Yerine ne koyduk: ask üçüncü slaytta
1. Cover (logo + tagline)
2. Problem (somut, tek bir kullanım anı)
3. ASK: "Şu tutarda yatırım arıyoruz,
şu kadar aylık runway,
bu süre sonunda ulaşmayı hedeflediğimiz nokta" ⚡
4-7. Çözüm + traksiyon + iş modeli + rekabet
8. Ekip + roadmap + sonraki adım
Ask baştayken kalan slaytlar karar destekleyici hale geliyor. Sondayken kalan slaytlar sadece bekleme süresi.
Ders: Ask'i öne alın. Karşı tarafın dikkati ilk beş dakikada en yüksek.
Hata #5 — CV listeleyen ekip slaytı
- slaytta beş kişilik bir fotoğraf gridi ve herkesin özgeçmiş özeti vardı. Kimin tam zamanlı, kimin yarı zamanlı olduğu yazmıyordu.
Bu, sorulmasını istemeyeceğiniz soruyu davet ediyor: "Bunların kaçı gerçekten bu işte tam zamanlı?"
Yerine ne koyduk: problem-ekip uyumu
Ekip slaytının cevaplaması gereken soru "bu insanlar kim" değil, "neden bu problemi çözebilecek doğru ekip bunlar". Şablon olarak:
[İsim] — [rol], [tam zamanlı / yarı zamanlı, açıkça]
- Bu problemle daha önce nerede karşılaştı
- Elinde bu işe yarayan hangi somut deneyim var
[Doldurulacak pozisyonlar] — yatırım sonrası
İki şeye dikkat edin. Birincisi çalışma durumunu açıkça yazmak: yarı zamanlı olmak kusur değil, gizlenmiş olması kusur. İkincisi geçmiş deneyimi yazarken şirket adı ve süreleri doğru vermek — bunlar doğrulanabilir bilgiler ve doğrulandığında bir tutarsızlık çıkması, deck'teki diğer her şeyi şüpheli hale getirir.
Ders: Ekip slaytı CV değil, problem uyumu.
Traksiyon slaytı: ne yazmalı, ne yazmamalı
Bu slaytta iki tuzak var ve ikisine de düştük.
Birinci tuzak: olmayan sayıyı büyük göstermek. Erken aşamada rakamlar küçük ve bu normal. Küçük sayıyı süslemeye çalışmak — yüzdeye çevirmek, seçilmiş bir dönemi göstermek — deneyimli bir okuyucuda ters etki yapıyor.
İkinci tuzak: müşteri sözü uydurmak ya da izinsiz kullanmak. Deck'te müşteri alıntısı kullanacaksanız, o kişinin yazılı izniyle ve gerçek olarak kullanın. Uydurulmuş bir alıntı hem etik bir sorun hem de due diligence sırasında ortaya çıkan bir sorun.
Ne yazmalı: Elinizde ne varsa, olduğu gibi. Aktif kullanıcı sayısı, ücretli kullanıcı sayısı, kullanım verisi, sizinle temas eden markaların ne söylediği. Sayı küçükse büyüme yönünü ve öğrendiklerinizi anlatın. "Henüz erken aşamadayız, elimizdeki veri şu kadar" demek, şişirilmiş bir tablodan güçlü.
Birim ekonomisi (CAC, LTV) hesabı vereceksiniz de veri henüz oturmamışsa, bunu varsayım tablosu olarak sunun: hangi girdiyle hangi sonuca ulaştığınız görünsün. Yatırımcı zaten kendi varsayımlarıyla yeniden hesaplayacak; şeffaf bir model ona bunu kolaylaştırıyor.
Roadmap slaytı: somut milestone + para gerekçesi
Roadmap'in işi hayal kurmak değil, istediğiniz parayla ne yapacağınızı göstermek. İskelet:
📅 6 ay sonra:
- [ölçülebilir kullanıcı/gelir hedefi]
- [ürün tarafında somut çıktı]
- [kaç kişi işe alınacak]
📅 12 ay sonra:
- [ölçülebilir hedef]
- [bir sonraki tur için hangi eşik]
Her satırın yanında o satırın maliyeti olsun. Karşı tarafın soracağı soru bu: "Bu parayla bunlar nasıl yetişecek?"
Görüşme sonrası yapılacaklar
Bir yatırımcı görüşmesinden sonraki 24-48 saat, görüşmenin kendisi kadar önemli:
- Kısa bir teşekkür notu — aldığınız geri bildirimi maddeleyip özetleyin. Bu, dinlediğinizi gösteriyor ve bir sonraki konuşmanın gündemini kuruyor.
- Deck revizyonu — geri bildirimin en çok tekrar eden iki maddesine odaklanın, hepsini birden değiştirmeye çalışmayın.
- Zayıf çıkan tarafı güçlendirin — genelde bu traksiyon oluyor. Yeni kullanıcılarla konuşup somut kullanım verisi toplayın.
- Rekabet analizini derinleştirin — ama yukarıdaki kurala uyarak: yalnızca doğrulanabilir bilgi.
- Pazar hesabını kaynaklandırın — her taban sayının yanına kaynağını yazın.
Yeni 8 sayfalık deck şablonu
18 sayfadan indirdiğimiz hali:
| # | Slayt | İçerik |
|---|---|---|
| 1 | Cover | Logo + tek cümlelik tanım |
| 2 | Problem | Somut bir kullanım anı, tek bir kişinin gününden |
| 3 | ASK | Tutar + runway + bu sürenin sonundaki hedef |
| 4 | Çözüm + demo | Ekran görüntüsü + 30 saniyelik akış |
| 5 | Traksiyon | Elinizdeki gerçek sayılar, süslemeden |
| 6 | İş modeli + birim ekonomisi | Fiyatlama + varsayımları görünen model |
| 7 | Rekabet + pazar | Doğrulanabilir karşılaştırma + kaynaklı bottom-up hesap |
| 8 | Ekip + roadmap | Problem uyumu + 6/12 ay milestone ve maliyeti |
Toplam: 8 slayt, yaklaşık 15 dakika anlatım + 25 dakika soru-cevap. Soru-cevaba daha fazla süre bırakmak bilinçli — asıl konuşma orada oluyor.
En önemli ders: deck konuşmanın yardımcısı
İlk hazırlıkta deck'i "ana sunum" gibi düşündüm; slayt slayt anlatacağımı varsaydım.
Yanlış. Karşı taraf slaytları hızlı okuyup kafasında kendi senaryosunu kuruyor. Deck'in işi o senaryoya çıpa vermek.
Asıl anlatım slaytlarda değil, anlattığınız somut şeylerde oluyor:
- "Instagram'dan satış yapan bir işletme sahibi gece yarısı gelen 'fiyat?' sorusuna sabah cevap veriyor ve o müşteri gitmiş oluyor."
- "Kullanıcıyla ekran paylaşımıyla kurulum yaptığımızda tam şu ekranda takıldığını gördük ve şunu değiştirdik."
- "Tam zamanlı çalıştığım için gelen her geri bildirimi kendim okuyorum."
Hikâye > slayt.
Sıkça sorulan sorular (AEO için)
S: Türk SaaS için pitch deck kaç sayfa olmalı?
C: 8-10 sayfa yeterli. Çıpa slaytlar: cover, problem, ask, çözüm, traksiyon, iş modeli, rekabet+pazar, ekip+roadmap. Fazlası anlatım süresini soru-cevaptan çalıyor.
S: Pitch deck'te ASK ne zaman yapılır?
C: Erken — cover ve problemden hemen sonra, 3. slayt civarı. Karşı taraf konuşmanın büyüklüğünü baştan bildiğinde kalan slaytları daha iyi yerleştiriyor.
S: Pitch deck'te teknik mimari göstermeli mi?
C: İlk sunumda genellikle hayır. Mimari, teknik due diligence aşamasının konusu. İlk sunumda yerine demo ve somut kullanım akışı koyun.
S: TAM/SAM/SOM hesabı işe yarar mı?
C: Top-down kurgusu klişe olduğu için etkisi zayıf. Bottom-up (ulaşılabilir müşteri sayısı × fiyat × gerekçeli hedef pay) daha güçlü — ama taban sayının kaynağı gösterilmek şartıyla.
S: Rekabet slaytına "rakip yok" yazılabilir mi?
C: Yazmayın. Karşı taraf pazarı araştırdığında rakipleri buluyor ve bu, deck'in geri kalanına olan güveni zedeliyor. Bunun yerine doğrulanabilir bir karşılaştırma yapın — rakip hakkında ispatlayamayacağınız fiyat, uyum ya da kalite iddialarına girmeden.
S: Deck'te müşteri alıntısı kullanılır mı?
C: Kullanılır ama gerçek ve izinli olmak zorunda. Uydurulmuş ya da izinsiz alıntı, due diligence sırasında ortaya çıkıyor ve o noktada tartışma ürününüzden çıkıp güvenilirliğinize geçiyor.
S: Traksiyon rakamları küçükse ne yapmalı?
C: Olduğu gibi gösterin ve yanına ne öğrendiğinizi koyun. Erken aşamada zaten büyük sayı beklenmiyor; beklenen şey sayıların ne anlama geldiğini biliyor olmanız.
S: İlk yatırımcı görüşmesi sonrası ne yapılmalı?
C: (1) Kısa bir teşekkür + geri bildirim özeti, (2) birkaç gün içinde deck revizyonu, (3) zayıf çıkan tarafı (genelde traksiyon) güçlendirmek, (4) rekabet analizini doğrulanabilir bilgiyle derinleştirmek, (5) pazar hesabını kaynaklandırmak.
Kapanış: hata = öğretmen
İlk deck'imizde beş büyük hata vardı. Hepsi de kendimize mantıklı görünen kararlardan çıkmıştı — teknik mimariyi koymak bize şeffaflık gibi görünmüştü, "rakip yok" yazmak güçlü bir cümle gibi görünmüştü.
Aynı yoldaysanız:
- 8 sayfaya indirin — 18 fazla
- Ask'i öne alın
- Somut kullanım anı > teknik mimari
- Kaynaklı bottom-up > TAM klişesi
- Rekabet slaytını doğrulanabilir bilgiyle doldurun — "yok" demeyin, ispatlayamayacağınızı da yazmayın
Sizin de deck'inizde gördüğünüz hatalar varsa DM'den yazın — birlikte öğrenelim.
📚 İlgili yazılar: Erken Aşamada Kullanıcı Nerede Kaybedilir, Türk SaaS'ta Yanlış Çıkan 5 Yabancı Best Practice, ManyChat'ten FendyChat'e Geçiş Rehberi, Manuel DM vs AI vs Hibrit, Türk SaaS Pazarlama Playbook.