İş fikrinden müşteri problemine: Doğru başlangıç sorularını sormak

İş fikrinden müşteri problemine geçmek için önce yapmak istediğiniz ürünü değil, belirli bir kişinin hangi işi yaparken nerede zorlandığını tarif etmelisiniz. İyi başlangıç soruları, genel beğeni veya geleceğe ilişkin tahmin toplamak yerine yakın geçmişte yaşanan olayı, mevcut çözümü ve sorunun sonuçlarını anlamaya yönelir. Bu yaklaşım fikrinizi hemen doğrulamaz; hangi varsayımı sınamanız gerektiğini daha açık hale getirir. İlk hedef ürününüzün övülmesi değil, müşterinin dünyasını daha doğru okuyabilmektir.

Ürün cümlesini problem cümlesine çevirmek

“Ekipman rezervasyonu için bir uygulama yapıyoruz” cümlesi, ne geliştireceğinizi anlatır; fakat kimin neden buna ihtiyaç duyduğunu açıklamaz. Problem cümlesinde kişi, yapılan iş, zorlanılan koşul ve sonuç bulunmalıdır. Örneğin belirli bir ekip, yoğun teslim günlerinde hangi parçanın nerede olduğunu anlayamıyor olabilir. Bu ifade hâlâ sınanacak bir varsayımdır; gerçek müşteri bilgisiyle desteklenmelidir.

Problem cümlesini ürününüzün zorunlu olduğu biçimde yazmayın. “İnsanların bizim uygulamamıza ihtiyacı var” ifadesi, araştırmayı baştan çözüme kilitler. Aynı iş başka araçlar, insan desteği veya süreç değişikliğiyle de yapılabilir. Bu alternatifleri görebilmek, daha iyi ürün kararı vermeye yardımcı olur.

İlk taslak kısa olsun. Kim, hangi durumda, hangi işi yaparken, nasıl bir sonuçla karşılaşıyor? Her bölüme ayrı güven düzeyi verin. Kişiyi tanıyor fakat yaşadığı sorunu bilmiyor olabilirsiniz. Sorunu biliyor fakat ne sıklıkta oluştuğunu öğrenmemiş olabilirsiniz. Bu ayrım, araştırmayı belirsiz bir pazar sohbetinden somut bilgi arayışına dönüştürür.

Müşteri keşfi neden başlangıç işidir?

NSF I-Corps açıklaması, teknolojilerin pazar potansiyelini değerlendirmede müşteri keşfi ve deneyim yoluyla öğrenmeye yer verir. Bu yaklaşım, geliştirme çalışmasının yalnızca teknik imkân üzerinden yürümemesi gerektiğini hatırlatır. Kullanım ihtiyacını anlamak, ürün tamamlandıktan sonra yapılacak süsleyici bir faaliyet değildir.

Y Combinator’ın Startup School yayını, kullanıcı görüşmelerinde somut geçmiş deneyimlere odaklanmayı ve görüşmeyi ürün sunumuna dönüştürmemeyi ele alır. Bu kaynakta anlatılan düşünceler, her görüşmenin satışa dönüşeceği veya belirli sayıda görüşmenin yeterli olacağı anlamına gelmez.

Bu rehberdeki çalışma araçları, söz konusu kaynakların bütün yöntemlerini aktarmıyor. Girişimcinin kendi sorusunu kurması, bilgiyi kaydetmesi ve sonraki denemeyi seçmesi için özgün bir uygulama düzeni öneriyor. Kullanıcıdan gelen bilgi önemlidir; ancak tek başına pazar büyüklüğünü, teknik yapılabilirliği veya işletmenin sürdürülebilirliğini kanıtlamaz.

Görüşeceğiniz kişiyi unvan yerine yaptığı işle tanımlayın

“Ajanslarla konuşacağız” veya “KOBİ’leri araştıracağız” gibi geniş gruplar, farklı sorunları aynı başlık altında toplayabilir. Başlangıçta görüşeceğiniz kişinin günlük işini ve karar içindeki rolünü açıklayın. Aynı şirkette ürünü kullanan, satın alma kararını veren ve sonuçtan etkilenen kişiler farklı olabilir.

Örneğin bir üretim dosyasını hazırlayan çalışan, onaylayan yönetici ve bütçeyi yöneten kişi aynı sorunu farklı biçimde yaşayabilir. Sadece yöneticinin görüşünü almak, günlük işteki küçük fakat tekrar eden yükleri kaçırabilir. Sadece kullanıcıyla konuşmak ise satın alma sürecini anlamaya yetmeyebilir.

İlk görüşme grubunu seçerken hangi bakış açısını öğrenmek istediğinizi yazın. Sonra eksik kalan rolleri belirleyin. Bu bir sayısal temsil araştırması olmak zorunda değildir; fakat görüştüğünüz kişilerin kapsamını bilmeniz gerekir. Yakın çevrenizde kolay ulaşabildiğiniz kişiler, hedeflediğiniz müşterinin tamamını temsil etmeyebilir. Kolaylık ile uygunluğu birbirine karıştırmayın.

Genel kanaat yerine bir olayın akışını açın

İnsanlar işlerinin genel olarak nasıl yürüdüğünü anlatırken aksaklıkları sadeleştirebilir. Belirli bir olay üzerinden konuşmak, sürecin adımlarını daha somut görmeye yardımcı olur. Olayın ne zaman başladığını, hangi bilgiyle harekete geçildiğini ve hangi noktada başka bir kişiye ihtiyaç duyulduğunu anlamaya çalışın.

Burada amaç görüşülen kişiyi sorguya çekmek değildir. Anlattığı olayın bağlamını öğrenmek için açık ve sakin bir görüşme yürütülmelidir. Kişi ayrıntıyı hatırlamıyorsa bunu eksik bilgi olarak kaydedin. Boşluğu kurucunun tahminiyle doldurmak, sonradan yanlış bir kesinlik yaratabilir.

Olayı başlangıç, geçiş ve sonuç olmak üzere üç parçaya ayırabilirsiniz. Başlangıçta işi tetikleyen durum; geçişte bekleme, tekrar veya karar noktaları; sonuçta ise işin tamamlanma biçimi incelenir. Bu düzen, çözüm fikrinize uygun cümleler aramak yerine müşterinin iş akışını anlamanızı sağlar. Sorunun tam olarak hangi noktada oluştuğu daha görünür hale gelir.

Mevcut çözümü rakip olarak ciddiye alın

Müşteri bugün problemi bir biçimde yönetiyor olabilir. Bu yöntem bir yazılım, kâğıt liste, mesajlaşma grubu, deneyimli çalışan veya hiçbir şey yapmamak olabilir. Yeni ürününüz yalnızca benzer uygulamalarla değil, bu mevcut düzenle de karşılaştırılacaktır. Yöntemin size eski görünmesi, müşteri açısından değersiz olduğu anlamına gelmez.

Mevcut çözümün neden korunduğunu anlamaya çalışın. Alışılmış olması, kolay paylaşılması, düşük hazırlık gerektirmesi veya sorumluluğu açık tutması önemli olabilir. Girişimci yalnızca eksikleri dinlerse, müşterinin değiştirmek istemediği güçlü tarafları kaçırabilir. Yeni çözümün benimsenmesi için bu tarafların da hesaba katılması gerekir.

Araştırma notunda mevcut yöntemin yaptığı işi, yarattığı yükü ve sağladığı rahatlığı ayrı yazın. Örneğin bir mesaj grubu bilgi aramayı zorlaştırırken herkesin zaten kullandığı bir kanal olması nedeniyle tercih edilebilir. Bu ikili durumu anlamak, ürününüzün sadece özelliklerini değil, kullanım ve geçiş koşullarını da düşünmenizi sağlar.

Sorunun önemini sonuçları üzerinden değerlendirin

Bir problemden söz edilmesi, müşterinin onu öncelikli gördüğünü göstermez. Bazı aksaklıklar can sıkıcıdır fakat başka ihtiyaçların gerisinde kalır. Sorunun neye yol açtığını anlamak gerekir: işin gecikmesi, yeniden çalışma, kararın ertelenmesi veya başka bir görevin aksaması gibi sonuçlar olabilir.

Bu sonuçları doğrudan para tutarına çevirmek zorunda değilsiniz. Kişinin güvenilir biçimde ölçemediği bir kaybı kesin rakam gibi yazmayın. Önce kullanılan zaman, tekrar sıklığı ve iş akışındaki etkisi hakkında somut bilgi arayın. Hesap yapılacaksa varsayımlar ayrı gösterilmeli ve gözlenen veriyle karıştırılmamalıdır.

Ayrıca aynı sorun farklı koşullarda farklı önem taşıyabilir. Sakin dönemde kolay yönetilen bir aksaklık, yoğun teslim gününde ciddi yük oluşturabilir. Problem cümlesine bu koşulu eklemek, müşteri grubunu daha anlamlı biçimde daraltabilir. Böylece “herkes için yararlı” görünen fikir, belirli bir durumda gerçekten değer üretebilecek bir çözüme dönüşebilir.

Müşterinin geçmiş çabasını bir kanıt olarak okuyun

Kişinin sorunu çözmek için daha önce ne yaptığı, konunun önemini anlamaya yardımcı olabilir. Başka araç denemiş, iş bölümünü değiştirmiş veya belirli bir kişiden destek istemiş olabilir. Bu çabalar, yalnızca sözlü ilgiden farklı bir bilgi türüdür. Yine de otomatik satın alma isteği olarak yorumlanmamalıdır.

Hiç çözüm aranmamış olması da tek bir anlama gelmez. Sorun önemsiz olabilir; fakat uygun seçenek bilinmiyor, karar yetkisi bulunmuyor veya değişiklik maliyeti yüksek görülüyor olabilir. Araştırmanın görevi bu olasılıkları ayırmaktır. “Bir şey yapmamış, demek ki ihtiyacı yok” sonucuna hızla varmak da yanıltıcı olabilir.

Geçmiş çabayı zaman çizelgesine yerleştirin. Hangi deneme ne zaman yapılmış, neden bırakılmış, hangi tarafı işe yaramış? Bu bilgi, ürün fikrinize doğrudan özellik eklemekten önce müşterinin karar mantığını anlamanızı sağlar. Aynı denemeyi yeni isimle sunmak yerine, gerçekten farklılaştırmanız gereken noktayı görebilirsiniz.

Özellik talebinin arkasındaki işi araştırın

Görüşülen kişi doğrudan bir özellik isteyebilir: bildirim, rapor veya yeni ekran gibi. Bu talebi hemen geliştirme listesine eklemek yerine hangi işi kolaylaştırmak istediğini sorun. Özelliğin adı, sorunun kendisi değildir. Aynı sonuç farklı tasarımlarla veya mevcut ürünün daha basit kullanımıyla sağlanabilir.

Örneğin ayrıntılı bir rapor isteyen kişi, aslında belli bir anda kimin sorumlu olduğunu anlamaya çalışıyor olabilir. Bu durumda daha çok veri göstermek yerine sorumluluk bilgisini doğru yerde sunmak yararlı olabilir. Bu yalnızca bir ihtimaldir; kullanıcıdan alınan bilgiyle sınanmalıdır.

Araştırma kaydında talep edilen çözüm ile alttaki ihtiyacı ayrı alanlarda tutun. Böylece ekip, müşterinin söylediği her özelliği eşit öncelikli kabul etmez. Talebin gerekçesi bilindiğinde farklı çözüm seçeneklerini karşılaştırmak mümkün olur. Kullanıcının deneyimi temel girdidir; ürün tasarımının sorumluluğu ise girişimin kendi değerlendirmesinde kalır.

Gözlem, ifade ve yorum için üç ayrı kayıt alanı açın

Görüşme sonrasında notlar hızla birbirine karışabilir. Kişinin söylediği, sizin gözlediğiniz ve ekipçe çıkardığınız sonuç aynı paragrafta yer alıyorsa daha sonra kanıtın gücünü anlamak zorlaşır. Üç ayrı alan kullanmak bu sorunu azaltabilir: doğrudan ifade, gözlenen davranış ve kurucunun yorumu.

Örneğin kişi teslim takibini zor bulduğunu söylemiş olabilir. Görüşme sırasında dosyayı bulmak için birden fazla kanala baktığını gözlemiş olabilirsiniz. Bundan bütün ekiplerin aynı sorunu yaşadığı sonucunu çıkarmak ise sizin yorumunuzdur. İlk iki bilgi belirli kişiye aittir; üçüncüsünün daha fazla araştırmaya ihtiyacı vardır.

Kayda tarih ve bağlam ekleyin. Aynı kişinin yoğun dönem ve sakin dönem deneyimi farklı olabilir. Gereksiz kişisel veya ticari ayrıntıları toplamadan araştırma amacına uygun bilgi tutun. Görüşmeyi kaydetmek ya da belge incelemek istiyorsanız ilgili kişinin bilgisi ve uygun koşullar olmadan hareket etmeyin. Araştırmanın kalitesi, güven ilişkisinin korunmasına da bağlıdır.

Varsayımsal örnek: Film ekipmanı teslim sürecini anlamak

Bu senaryo tamamen kurgusaldır; gerçek bir şirketin veya Orion girişiminin verisini içermez. İki kurucu, küçük film ekiplerinin ekipman rezervasyonunu yönetmek için ürün düşünür. İlk varsayımları, asıl sorunun hangi ekipmanın boş olduğunu bulmak olduğudur. Bu yüzden takvim ve arama ekranlarına odaklanmayı planlarlar.

Görüşmelerde yakın tarihli teslim süreçlerini inceleyince farklı bir olasılık ortaya çıkar. Bazı ekipler rezervasyonu zaten yönetebilmektedir; zorluk, teslim sırasında paket içindeki küçük parçaların ve sorumluluğun netleşmesidir. Bu kurguda sorun bütün sektöre genellenmez. Belirli çalışma biçimindeki ekipler için yeni bir araştırma sorusu oluşur.

Kurucular hemen kapsamlı envanter yazılımı geliştirmeye başlamaz. Önce teslimden sorumlu kişi, ekipmanı kullanan kişi ve geri alan kişinin aynı olayı nasıl anlattığını karşılaştırırlar. Her rolün farklı bilgiye ihtiyaç duyduğunu görürler. İlk ürün fikri böylece daha dar bir teslim teyidi problemini araştırmaya dönüşür. Örneğin amacı doğru ürünü ilan etmek değil, başlangıç varsayımının müşteri olayıyla nasıl değişebileceğini göstermektir.

Çelişen görüşleri ortalamada kaybetmeyin

Bir müşteri sorunu önemli bulurken diğeri hiç yaşamamış olabilir. Bu farkı ortalama bir ilgi puanına dönüştürmek, önemli ayrımları gizleyebilir. Önce kişilerin çalışma koşullarını karşılaştırın. İş hacmi, ekip yapısı, kullanılan yöntem veya karar sorumluluğu farklı olabilir. Çelişki, araştırmanın bozuk olduğundan çok müşteri grubunun fazla geniş olduğunu gösterebilir.

Kayıtları benzer olaylar etrafında gruplayın. Aynı unvana sahip kişiler yerine aynı işi benzer koşulda yapan kişiler arasında ortaklık aramak yararlı olabilir. Fakat küçük örneklerden kesin pazar bölümleri çıkarmayın. Gruplama, bir sonraki görüşme turunda sınanacak çalışma varsayımı olarak kalmalıdır.

Ayrıca kurucunun hoşuna gitmeyen görüşleri “yanlış müşteri” diye hemen dışlamayın. Belki gerçekten farklı gruptadır; belki de ürün fikrinizin zayıf tarafını gösteriyordur. Bu iki ihtimali ayırmak için neden uygun görülmediğini yazın. Araştırma kaydı, sadece olumlu örneklerin biriktirildiği bir tanıtım dosyası haline gelmemelidir.

Problem tanımını karar verebilecek kadar daraltın

Araştırma sonunda uzun bir sorun listesi çıkabilir. Hepsini aynı üründe çözmeye çalışmak kapsamı hızla büyütür. Önce hangi problem üzerinde bir sonraki denemeyi yapabileceğinizi seçin. Seçimde önem, tekrar eden bağlam, müşteriye erişim ve ekibin çözüm geliştirme kapasitesi birlikte düşünülebilir.

Daraltılmış problem tanımı, “küçük işletmelerin verimliliğini artırmak” kadar geniş olmamalıdır. Kişiyi, işi ve kritik koşulu açıklamalıdır. Aynı zamanda ürünün teknik biçimini zorunlu kılmamalıdır. Problem netleştiğinde birden fazla çözüm düşünmek hâlâ mümkün olmalıdır. Aksi halde araştırma, başlangıç fikrine yeni kelimeler eklemekle sınırlı kalabilir.

Tanımın yanına henüz bilinmeyenleri yazın. Sorun anlaşılmış olabilir; fakat çözüm için ödeme kararı, kullanım sıklığı veya mevcut düzenden geçiş isteği belirsiz kalabilir. Bu açıklık, ilerlemeyi küçültmez. Tam tersine, bir sonraki denemenin hangi iddiayı sınayacağını belirler ve gereksiz geliştirme işini azaltmaya yardımcı olur.

Sonraki adımı görüşme sayısına değil, açık soruya bağlayın

Belirli sayıda görüşme yapmak, problemin doğrulandığı anlamına gelmez. Görüşmeler aynı çevreden kişilerle yapılmış veya aynı yönlendirici sorularla yürütülmüş olabilir. Önemli olan, karar için hangi bilginin oluştuğu ve hangi belirsizliğin kaldığıdır. Sayı, yapılan işin hacmini gösterir; kanıtın niteliğini tek başına göstermez.

Bir sonraki adım yeni görüşme, iş akışı gözlemi veya sınırlı çözüm denemesi olabilir. Henüz sorunun koşullarını anlamadıysanız prototip göstermek erken olabilir. Sorun yeterince netleşmişse yalnızca görüşme yapmaya devam etmek de öğrenmeyi yavaşlatabilir. Yöntem, açık kalan soruya göre değişmelidir.

Karar notunda üç satır kullanabilirsiniz: şu anda bildiğimiz, hâlâ bilmediğimiz ve bunu öğrenmek için yapacağımız iş. Bu basit düzen araştırmayı sürekli devam eden sohbetten çıkarır. Her çalışma bir sonraki kararı hazırlamaya hizmet eder. İlerleme, daha fazla not biriktirmekten çok daha açık bir soru ve daha uygun bir deneme seçebilmekle anlaşılır.

THK & Orion TEKMER ile görüşmeye problem dosyasıyla hazırlanmak

THK & Orion TEKMER hizmetler sayfasındaki iş geliştirme ve mentörlük başlıklarını incelerken, kendi problem dosyanızı da hazırlayabilirsiniz. Dosyada ürününüzün bütün özellikleri yerine hedef kişi, gözlenen olay, mevcut çözüm ve açık sorular bulunsun. Böyle bir hazırlık, talep ettiğiniz katkının anlaşılmasını kolaylaştırabilir.

Ön başvuru alanında projenizi ve ihtiyacınızı anlatırken doğrulanmış bilgi ile varsayımı ayırın. Birkaç kişinin olumlu yorumunu pazarın tamamından gelen talep gibi sunmayın. Henüz araştırılmamış konuları açıkça belirtmek, görüşmenin gerçek ihtiyaca odaklanmasına yardımcı olur. Başvuru veya görüşme, belirli hizmete erişim ve ticari sonuç garantisi oluşturmaz.

İş fikrinden müşteri problemine geçiş, yaratıcılığı bırakmak anlamına gelmez. Yaratıcılığın hangi gerçek iş üzerinde kullanılacağını netleştirir. Girişimci, güçlü fikrini savunurken müşterinin yaşadığını duyamıyorsa önemli bilgiyi kaçırabilir. Daha iyi başlangıç soruları, ürün fikrini küçültmek için değil, onu daha doğru bir zeminde sınamak için kullanılır.

Sık sorulan sorular

Ürünümü hiç anlatmadan görüşme yapmak mümkün mü?

Görüşmenin amacını ve hangi iş alanını araştırdığınızı açıklayabilirsiniz. Ayrıntılı çözüm sunumunu başlangıca koymak, cevapları fikrinize göre şekillendirebilir. Önce kişinin mevcut deneyimini anlamak, sonrasında gerekiyorsa ayrı bir çözüm değerlendirmesi yapmak daha açık bilgi sağlayabilir.

Müşteri fikri beğeniyorsa bu yeterli kanıt mıdır?

Beğeni bir görüşü gösterir; kullanım, satın alma veya değişim kararını tek başına göstermez. Kişinin yaşadığı somut sorun, mevcut davranışı ve sonraki adım için ayırdığı kaynak ayrıca değerlendirilmelidir. Olumlu yorumu, taşıdığından daha güçlü bir kanıt gibi sunmayın.

Kaç görüşmeden sonra problem doğrulanmış sayılır?

Herkes için geçerli sihirli sayı yoktur. Görüştüğünüz kişilerin uygunluğu, soruların niteliği ve çelişen bilgilerin açıklanması önemlidir. Karar vermek için hangi bilginin eksik kaldığını yazın; sonraki görüşmeleri yalnızca sayıyı artırmak için yapmayın.

Müşteri çözüm öneriyorsa onu uygulamalı mıyım?

Önerinin arkasındaki işi ve gerekçeyi anlamalısınız. Aynı ihtiyacı karşılayabilecek başka yollar olabilir. Kullanıcı deneyimi önemli girdidir; ürün önceliği, teknik olanaklar ve diğer müşterilerin bağlamıyla birlikte değerlendirilir. Her öneriyi otomatik görev listesine eklemek kapsamı dağıtabilir.

Problem önemli görünmüyorsa fikirden vazgeçmek gerekir mi?

Önce doğru kişiyle ve doğru bağlamda görüşüp görüşmediğinizi değerlendirin. Sorun belirli koşullarda önemli olabilir veya başlangıç varsayımınız zayıf kalmış olabilir. Yeni bilgiye göre hedefi daraltmak, farklı soruyu araştırmak ya da fikri bırakmak seçenekler arasındadır.

Kaynaklar 29 Ekim 2026 tarihinde incelenmiştir. Problem dosyası, kayıt yöntemi ve film ekipmanı örneği editoryal çalışmadır; pazar doğrulaması veya satış sonucu garantisi içermez.