Haftalar İçinde Eskizden Rafa.

Bir ürünün kağıt üzerinde basit görünmesine rağmen mağazaya ulaşması aylar sürebilir. Bir taslak malzeme sınırlarını, tedarikçi kapasitesini, paketleme ihtiyaçlarını, test çalışmalarını veya küçük değişikliklerin maliyetini göstermez. Birçok kurucunun aynı sorunla karşılaştığını gördüm. Net bir fikirle başlıyorlar, bir fabrikayla iletişime geçiyorlar ve kısa sürede bitmiş bir ürün bekliyorlar. Daha sonra sorular başlıyor: - Seçilen malzeme ile tasarım yapılabilir mi? - Ürün beklendiği gibi çalışacak mı? - Tedarikçi küçük bir parti üretebilir mi? - Nihai maliyet ne olacak? - Ürün nasıl paketlenmeli ve sevk edilmelidir? Her aşamanın net bir amacı olduğunda ve kararlar doğru sırayla alındığında eskizden rafa kısa bir yol mümkündür. ### 1. Taslağı kullanışlı bir ürün özetine dönüştürün. Ürünün ne yapması gerektiğini tanımlayarak başlıyorum. Özet genellikle şunları içerir: - Ürünün amacı - Hedef müşteri - Ana boyutlar - Tercih edilen malzemeler - Beklenen miktar - Hedef fiyat aralığı - Güvenlik veya test ihtiyaçları - Paketleme yönü Bir taslak şekli gösterebilir ancak nadiren birinin ürünü nasıl kullanacağını açıklar. Bir ürün özeti bu boşluğu doldurur. Örneğin kurucu, kilitli kapağı olan, yeniden kullanılabilen bir yemek kabı çizebilir. Çizim tamamlanmış gibi görünebilir ancak fabrikanın yine de şunu bilmesi gerekiyor: - Ne kadar yiyecek almalı? - Mikrodalgada çalışmalı mı? - Kapağın sızıntılara karşı dayanıklı olması gerekiyor mu? - Kap şeffaf mı, renkli mi yoksa baskılı mı olacak? - Tek parça mı yoksa takım halinde mi satılmalı? Açık cevaplar daha sonra tasarım değişikliklerini azaltır. ### 2. Numune yapmadan önce tasarımı kontrol edin Numune almak zaman ve para gerektirir, bu nedenle üretim başlamadan önce tasarımı gözden geçirmeyi tercih ederim. Bu inceleme şunları kapsayabilir: - Duvar kalınlığı - Ürün ağırlığı - Hareketli parçalar - Montaj noktaları - Yüzey kalitesi - Üretim yöntemi - Malzeme seçimi - Paketleme boyutu Bazı şekiller çekici görünür ancak üretim sırasında sorun yaratır. Derin bir köşe malzeme toplayabilir. İnce bir sap kullanım sırasında kırılabilir. Sıkı bir açıklık temizliği zorlaştırabilir. Amaç her tasarım detayını ortadan kaldırmak değil. Amaç, henüz düzeltilmesi kolay olan sorunları bulmaktır. ### 3. Gerçek soruları yanıtlayan bir örnek oluşturun İlk örneğin mükemmel olması gerekmez. Ana fikri test etmeme yardım etmesi gerekiyor. Şu tür sorulara bakıyorum: - Ürün rahat hissettiriyor mu? - Kullanıcının eline veya alanına sığıyor mu? - Parçalar düzgün bir şekilde bağlanıyor mu? - Ürün stabil mi? - Seçilen kaplama markayla eşleşiyor mu? - Ürün zarar görmeden paketlenebilir mi? Basit bir örnek, dijital çizimin gösteremeyeceği sorunları ortaya çıkarabilir. Bir şişe ekranda dengeli görünebilir ancak tutulamayacak kadar geniş görünebilir. Bir saklama kutusu planlanan boyutlara sığabilir ancak ambalajında ​​yer kaybına neden olabilir. İlk örneği bitmiş bir öğe olarak değil, bir öğrenme aracı olarak ele alıyorum. ### 4. Ürünü küçük bir grupla test edin. Sadece kendi fikrime güvenmiyorum. Bir ürünün yaratıcısı için kullanımı kolay gelebilir, yeni müşteri içinse kafa karıştırıcı olabilir. Küçük bir kullanıcı testi şunları içerebilir: - Ürünü hedef müşteriyle eşleşen kişilere vermek - Nasıl açıp kullandıklarını izlemek - Neyin zor olduğunu sormak - Tekrarlanan şikayetleri kaydetmek - Paket talimatlarını anlayıp anlamadıklarını kontrol etmek Bir masa aksesuarı için kullanıcılar ürünün pürüzsüz yüzeylerde hareket ettiğini belirtebilir. Bir cilt bakım kabı için, kapağın ıslak ellerle açılmasının zor olduğunu söyleyebilirler. Bu ayrıntılar incelemeleri, iadeleri ve tekrarlanan siparişleri etkileyebilir. Tekrarlanan geri bildirimlere odaklanıyorum. Kişisel bir tercih her zaman tasarım değişikliği gerektirmez. Birkaç kullanıcı arasında ortaya çıkan bir sorun dikkati hak ediyor. ### 5. Maliyet ve üretim sınırlarını doğrulayın İyi bir tasarımın yine de iş planına uyması gerekir. Maliyet şunları içerebilir: - Malzemeler - Aletler - Numune Alma - İşçilik - Baskı - Paketleme - Muayene - Nakliye - Depolama Küçük değişiklikler toplamı etkileyebilir. Metal kaplama beklenenden daha fazla maliyet getirebilir. Özel bir kutu daha büyük bir sipariş gerektirebilir. Özel bir menteşenin ayrı bir tedarikçiye ihtiyacı olabilir. Tedarikçiden her bir ana parçanın maliyetini açıklamasını isterim. Bu bana bütçenin nereye gittiği ve hangi özelliklerin ayarlanabileceği konusunda daha net bir görüş sağlıyor. Kullanışlı bir ürün yalnızca çekici değildir. Aynı zamanda yapımı ve satışı da pratik olmalıdır. ### 6. Bir üretim numunesini onaylayın Daha büyük bir sipariş vermeden önce, onaylanmış numuneyi ürün özetiyle karşılaştırırım. Şunları kontrol ediyorum: - Renk - Boyut - Ağırlık - İşlev - Yüzey kalitesi - Logo konumu - Ambalajın uygunluğu - Etiketler ve talimatlar Yazılı onay, karışıklığın önlenmesine yardımcı olur. Fotoğraflar kaydı destekleyebilir ancak dokuyu, gücü veya rengi tam olarak göstermeyebilir. Mümkün olduğunda, daha sonra karşılaştırmak üzere onaylanmış bir numuneyi saklıyorum. Bu adım yavaş gelebilir ancak birden fazla kişinin veya tedarikçinin dahil olduğu durumlarda ürünü korur. ### 7. Paketi ve ürün sayfasını birlikte hazırlayın Paket ve çevrimiçi ürün sayfası aynı ürünü açıklamalıdır. Aşağıdakiler için eşleşen bilgileri kullandıklarından emin oluyorum: - Ürün boyutu - Malzeme - Bakım talimatları - Miktar - Uyarılar - Garanti koşulları - Teslimat ayrıntıları Açık ifadeler, müşterilerin uygun bir seçim yapmasına yardımcı olur. Ayrıca destek sorularını da azaltır. Bir ürün sayfası, ürünü farklı açılardan göstermeli ve nasıl kullanıldığını açıklamalıdır. Ürünün bir sınırı varsa bunu sade bir dille belirtirim. Örneğin, bir saklama kutusu kuru ürünler için uygun olabilir ancak sıvılar için uygun olmayabilir. Bu detay, müşteri sipariş vermeden önceki sayfada yer alır. ### 8. Fabrikadan rafa kadar olan rotayı planlayın Üretim, programın yalnızca bir parçasıdır. Ayrıca şunları da planlıyorum: - Numune onayı - Malzeme satın alma - Üretim - Denetim - Paketleme - Nakliye - Gerektiğinde gümrükleme - Depo teslim alma - Ürün listeleme Bazı ürünler birkaç hafta içinde hazır tasarımdan küçük bir üretim aşamasına geçebilir. Özel kalıplar, özel malzemeler, testler ve denizaşırı nakliye, programı uzatabilir. Açık bir zaman çizelgesi, hangi görevlerin aynı anda gerçekleşebileceğini ve hangi görevlerin beklemesi gerektiğini gösterir. Ambalaj çizimleri genellikle bir numune test edilirken hazırlanabilir. Seri üretim, ürün ve ambalaj onaylanana kadar beklenmelidir. ### Pratik bir örnek Küçük bir markanın paslanmaz çelikten bir öğle yemeği kabı ürettiğini hayal edin. Orijinal çizimde kapaklı yuvarlak bir kap gösterilmektedir. İnceleme sırasında ekip, kapağın tutulmasının zor olduğunu ve şeklinin genel nakliye kartonlarında kullanılmayan alan bıraktığını tespit etti. Numune, daha geniş bir kavrama alanı ve daha verimli bir taban şekli içerecek şekilde değiştirilir. Kullanıcı testi, kabın kapalı kaldığını ancak contanın etrafını temizlemenin zor olduğunu gösteriyor. Conta ayarlandı. Pakette bakım talimatları yer alıyor ve kabın fırında kullanılmak üzere tasarlanmadığı açıklanıyor. Ürün ilk çizimden farklı bir şekil alıyor ancak kullanımı, paketlenmesi ve anlatılması daha kolay hale geliyor. Açık bir geliştirme sürecinin değeri budur. ### Programı ne yavaşlatabilir? Kısa bir geliştirme süresi her ürüne uygun olmayabilir. Gecikmeler şunlardan kaynaklanabilir: - Belirsiz tasarım dosyaları - Geç geri bildirim - Malzeme kıtlığı - Takım değişiklikleri - Test gereksinimleri - Büyük minimum sipariş miktarları - Paketleme revizyonları - Sevkiyat değişiklikleri Test için yer olan dürüst bir program tercih ederim. Aceleye getirilmiş bir lansman, kusurlar, iadeler ve müşteri şikayetleri nedeniyle daha fazla iş yapılmasına neden olabilir. Ürün tek bir büyük görev olarak değil, bir dizi karar olarak ele alındığında, eskizden rafa giden yol daha kolay hale gelir. Kullanımı tanımlayın, tasarımı test edin, maliyeti onaylayın, numuneyi onaylayın ve ürünü doğru bilgilerle satışa hazırlayın. Hazır tasarıma ve mevcut malzemelere sahip basit bir ürün için birkaç hafta yeterli olabilir. Daha karmaşık ürünler daha fazla zamana ihtiyaç duyar. En iyi program, ürünün gerçekten ihtiyaç duyduğu işe göre oluşturulur.

Büyük bir fikir kafanızda heyecan verici, kağıt üzerinde ise kafa karıştırıcı gelebilir. Müşteriyi, pazarı ve gelecekteki ürünü net bir şekilde görebilirsiniz. Diğer insanlar, onu kullanmak için açık bir neden olmaksızın yalnızca kaba bir açıklama görebilir. Bir ürünün logosu hazır olduğunda ya da web sitesi yayına girdiğinde gerçek olmayacağını öğrendim. Belirli bir kişi onu belirli bir sorunu çözmek için kullanabileceğinde gerçek olur. Bu değişiklik daha küçük bir soruyla başlar: Bu fikrin en basit kullanışlı versiyonu nedir? ## Ürünle değil sorunla başlayın Birçok ürün planı özelliklerle başlar. "Rezervasyon, ödeme, sohbet, raporlar ve yapay zeka içeren bir uygulama geliştirmek istiyorum." Bu ayrıntılı gibi görünse de ürüne kimin ihtiyacı olduğunu veya onu neden kullanacağını açıklamıyor. Daha güçlü bir başlangıç ​​noktası daha çok şuna benziyor: "Bağımsız fitness koçları mesajlar ve elektronik tablolar aracılığıyla randevuları yöneterek zaman kaybediyor." Sorun ürüne yön verir. Ayrıca kullanışlı görünen ancak günlük bir ihtiyacı çözmeyen özellikler geliştirmekten kaçınmama da yardımcı oluyor. Üç noktayı yazıyorum: - Sorun kimde? - Şimdi ne yapıyorlar? - Mevcut süreci yavaş, maliyetli veya sinir bozucu yapan şey nedir? Yararlı bir sorun ifadesi şu şekilde görünebilir: "Küçük fitness stüdyolarının sınıf rezervasyonlarını yönetmek için basit bir yola ihtiyacı vardır çünkü manuel mesajlar sıklıkla kaçırılan randevulara ve program çakışmalarına neden olur." Bu ifade test edilecek kadar dardır. Her işletmeye aynı anda hizmet vermeye çalışmaz. ## Net bir müşteri grubu seçin Herkese yönelik bir ürün çoğu zaman hiç kimseyle alakalı gelmez. Yemek planlama hizmeti ebeveynler, sporcular, öğrenciler ve yaşlı yetişkinler tarafından kullanılabilir. Her grubun farklı alışkanlıkları, bütçeleri ve satın alma nedenleri vardır. Hepsine tek mesaj yazarsam mesaj zayıflıyor. Görünür bir ihtiyacı olan bir grubu seçiyorum. Örneğin: - Basit haftalık yemek planları isteyen meşgul ebeveynler - Stok takibine ihtiyaç duyan küçük çevrimiçi mağazalar - Daha kolay fatura yönetimi isteyen serbest çalışanlar Bu, diğer müşterileri sonsuza kadar görmezden geleceğim anlamına gelmez. Bana başlamam için pratik bir yer sağlıyor. O gruptan beş kişiye şunu sorabilirim: - Şu anda ne kullanıyorsunuz? - Sürecin hangi kısmı en çok sıkıntıya neden oluyor? - Bu sorun ne sıklıkla oluyor? - Daha önce bir çözüm için ödeme yaptınız mı? - Yeni bir ürünü denemenizi sağlayan şey nedir? Cevapları varsayımlarıma meydan okuyabilir. Bu faydalıdır. Bir ürün fikri, kişisel tahminler yerine gerçek davranışlarla şekillendiğinde güçlenir. ## Çok fazla müşteri ilgisi oluşturmadan önce talebi test edin. Müşteri talebi ile aynı şey değildir. Bir kişi “Kulağa yararlı geliyor” diyebilir ve yine de ürünü hiç kullanmayabilir. Daha güçlü sinyaller ararım: - Sorunu çok fazla teşvik etmeden açıklarlar. - Bunu çözmek için zaten zaman veya para harcıyorlar. - Ürünün ne zaman satışa sunulacağını soruyorlar. - Temel bir sürümü test etmeyi kabul ederler. - Gelecekteki güncellemeler için iletişim bilgilerini paylaşırlar. Basit bir açılış sayfası fikrin test edilmesine yardımcı olabilir. Yalnızca şunları açıklaması gerekir: - Müşteri sorunu - Önerilen çözüm - Ürünün nasıl çalışabileceği - Kimin için tasarlandığı - Test grubuna katılmanın açık bir yolu Sayfa, kanıtlanmamış sonuçlar vaat etmemelidir. "Her hafta iki saat tasarruf edin" gibi bir ifadenin kanıta ihtiyacı vardır. "Manuel planlama işini azaltmaya yardımcı olmak için tasarlandı" ifadesi, test başlamadığında daha doğrudur. ## Yararlı bir iş ile bir MVP oluşturun Bir MVP veya minimum uygulanabilir ürün, düşük kaliteli bir ürün değildir. Önemli bir kullanım durumunu test etmek için oluşturulmuş sınırlı bir üründür. Yerel tamir atölyeleri için yazılım oluşturmak istediğimi varsayalım. Tam plan, müşteri hesaplarını, ödeme araçlarını, personel programlarını, otomatik hatırlatıcıları ve iş raporlarını içerebilir. İlk sürüm yalnızca üç şey yapabilir: 1. Onarım siparişi oluşturun 2. Sipariş durumunu güncelleyin 3. Onarım hazır olduğunda mesaj gönderin Bu, mağaza sahiplerinin paylaşılan bir onarım takip sistemine ihtiyaç duyup duymadığını test etmek için yeterli olabilir. İlk versiyonun herkesi etkilemesine gerek yok. Seçilen müşterinin bir görevi daha az çabayla tamamlamasına yardımcı olması gerekiyor. Dropbox, tam dosya senkronizasyon hizmetini oluşturmadan önce kısa bir ürün tanıtımı yaptı. Gösteri, planlanan deneyimin nasıl işe yarayabileceğini gösterdi ve ilginin test edilmesine yardımcı oldu. Bu yaklaşım, insanların onu isteyip istemediğini bilmeden bir ürünü geliştirmek için yıllar harcama riskini azalttı. ## İlk sürüm için doğru formu seçin Her fikrin bir mobil uygulamaya veya karmaşık bir yazılım sistemine ihtiyacı yoktur. Bir fikri şu yollarla test edebilirim: - Tıklanabilir bir tasarım prototipi - Bir elektronik tablo - Basit bir web sitesi - Manuel bir hizmet - Kodsuz bir araç - Küçük, ücretli bir pilot - Kısa bir ürün tanıtımı Ev sahiplerini yerel bahçıvanlarla eşleştiren bir platform oluşturmak istediğimi hayal edin. İlk gün arama filtreleri, çevrimiçi ödeme, inceleme sistemleri ve otomatik planlama oluşturmama gerek yok. Basit bir sayfa oluşturabilir, istekleri toplayabilir, uygun bahçıvanlarla kendim iletişime geçebilir ve eşleşmeleri bir e-tabloda takip edebilirdim. Bu manuel işlem daha az gösterişli görünebilir, ancak ev sahiplerinin hizmeti talep etmeye istekli olup olmadığını ve bahçıvanların bu işi isteyip istemediğini ortaya çıkarabilir. Manuel test aynı zamanda yazılımın gizleyebileceği sorunları da ortaya çıkarır. Müşterilerin arama hızından çok varış zamanlarına ve güvene önem verdiklerini keşfedebilirim. ## Dar bir test hedefi belirleyin Bir ürün testinin bir soruya ihtiyacı vardır. Zayıf hedef: "İnsanların ürünü beğenip beğenmediğine bakın." Yararlı hedefler: - Beş mağaza sahibinin onarım siparişi oluşturup oluşturmayacağını öğrenin. - Kullanıcıların bir rezervasyonu yardım almadan tamamlayıp tamamlayamayacaklarını öğrenin. - Müşterilerin sayfayı okuduktan sonra asıl faydayı anlayıp anlamadığını test edin. - Kullanıcıların aynı hafta içinde ürüne dönüp dönmediğini kontrol edin. Test için bir veya iki ölçü seçiyorum. Bunlar şunları içerebilir: - Kayıt oranı - Tamamlanan görevler - Tekrarlanan kullanım - Ücretli deneme talepleri - Müşteri görüşmesi geri bildirimi - Bir görevi tamamlamak için gereken süre Rakamlar her şeyi açıklamaz. Düşük kayıt oranı, zayıf bir tekliften, belirsiz ifadelerden, kötü sayfa tasarımından veya acil olmayan bir sorundan kaynaklanabilir. Soruları bulmak için sayıları kullanıyorum, ardından nedenleri anlamak için kullanıcılarla konuşuyorum. ## Basit bir ürün akışı oluşturun Kod yazmadan önce kullanıcı yolculuğunun haritasını çıkarırım. Bir rezervasyon ürünü için akış şu şekilde olabilir: 1. Müşteri hizmet sayfasını ziyaret eder. 2. Müşteri bir hizmeti seçer. 3. Müşteri uygun bir tarih seçer. 4. Müşteri iletişim bilgilerini girer. 5. Müşteri bir onay alır. Her ekstra ekran kafa karışıklığı için yeni bir fırsat yaratır. Ana görevi desteklemeyen adımları kaldırıyorum. Ayrıca kullanıcıların göreceği metni de yazıyorum. Açık etiketler, akıllı ifadelerden daha kullanışlıdır: - "Bir tarih seçin" - "Telefon numaranızı ekleyin" - "Rezervasyonu onaylayın" Kullanıcılar harekete geçmeden önce uzun bir açıklamaya ihtiyaç duyuyorsa, ürün akışı çok karmaşık olabilir. ## Yakından geri bildirim alarak geliştirme yapın. Kısa geliştirme döngülerini tercih ederim. Küçük bir parça oluşturup kullanıcıların önüne koyuyorum ve ne olduğunu gözlemliyorum. Şöyle sorular soruyorum: - Burada ne yapmaya çalışıyordun? - Bu düğmeye tıkladıktan sonra ne bekliyordunuz? - Hangi kısım belirsiz geldi? - Neyi değiştirirdin? - Bunu tekrar kullanır mısın? Neden? “Beğendin mi?” diye sormaktan kaçınıyorum. İnsanlar genellikle kibar olmaya çalışırlar. Eylemleri dostane yorumlardan daha güçlü kanıtlar sağlıyor. Eğer kullanıcı ana görevi tamamlayamıyorsa, başka bir özellik eklemeden önce bu sorunu çözüyorum. Kafa karıştırıcı bir ana akışa sahip cilalı bir ürünün kullanımı hala zordur. ## Neyi saklayacağınıza, değiştireceğinize veya kaldıracağınıza karar verin Geri bildirim bunaltıcı olabilir. Bir kullanıcı karanlık mod talep edebilir. Bir diğeri ödeme entegrasyonu isteyebilir. Üçüncüsü beş yeni rapor isteyebilir. Geri bildirimleri her isteğin arkasındaki soruna göre gruplandırıyorum. Bir istek şu durumlarda daha fazla önem kazanır: - Birkaç kullanıcı aynı sorundan bahsettiğinde. - Sorun ana görevi engelliyor. - Sorun hedef müşteri grubuyla eşleşen kişileri etkiliyor. - Sorun yalnızca konuşma sırasında değil, fiili kullanım sırasında da ortaya çıkıyor. - Çözülmesi ana ürün vaadini destekler. İstenilen her özelliği eklemiyorum. Bir ürünün net bir amacı olmalı ve her özellik bu amacı desteklemelidir. ## Ürünü dikkatli bir şekilde fiyatlandırın Fiyatlandırma aynı zamanda bir ürün testidir. Ücretsiz deneme, kayıt sayısını artırabilir ancak müşterilerin ödemeye değer olup olmadığını göstermeyebilir. Küçük ücretli bir pilot, teklifin dürüst olması ve ödemeden önce fiyatın açıklanması koşuluyla daha net geri bildirim sağlayabilir. Farklı fiyatlandırma yapılarını test edebilirim: - Tek seferlik satın alma - Aylık plan - Kullanım başına ödeme - Hizmet ücreti - Daha düşük aylık ücretle ücretli kurulum Doğru seçim, müşterilerin nasıl değer elde edeceğine bağlıdır. Her gün kullanılan bir tasarım aracı aylık bir plana uygun olabilir. Bir kerelik iş raporu sabit bir ücrete uygun olabilir. Baskıya dayalı ifadeler kullanmaktan kaçınırım. Net bir fiyat, net bir hizmet kapsamı ve net bir geri ödeme politikası, daha iyi bir müşteri deneyimi yaratır. ## Testi bir ürün planına dönüştürün Testten sonra olanları gözden geçiririm. Şunlara bakarım: - Hangi müşteriler ürünü kullandı - Hangi görevi tamamladılar - Nerede durdular - Ne istediler - Geri dönüp dönmediler - Ödeme yapıp yapmadılar veya ödemeye açık bir isteklilik gösterip göstermediler Sonra bir yol seçerim: - Aynı müşteriyle devam edin ve ürünü geliştirin - Hedef müşteriyi değiştirin - Ana kullanım senaryosunu değiştirin - Fikri duraklatın ve farklı bir sorunu test edin Yön değiştirmek boşa giden bir çaba değildir. Zayıf bir varsayıma daha büyük bir yatırım yapılmasını önleyebilir. Yaygın bir hata, orijinal planı bir vaat olarak ele almaktır. Bunu bir başlangıç ​​noktası olarak görüyorum. Müşteri sorunu bir sonraki sürüme yön vermelidir. ## Pratik bir örnek Küçük pazarlama ekipleri için bir görev yönetimi aracı oluşturmak istediğimi hayal edin. İlk planım takvimleri, zaman takibini, dosya depolamayı, raporları ve ekip sohbetini içeriyor. Bu, erken bir test için çok geniş. Altı küçük ekiple konuşuyorum ve kaçırılan içerik onaylarının görev oluşturmaktan daha fazla soruna yol açtığını öğreniyorum. Üç aşamalı basit bir onay panosu oluşturuyorum: - Taslak - İnceleme - Onaylandı Her kartta bir sahip, bir son tarih ve bir yorum kutusu bulunur. Ekip, e-postada arama yapmadan neyin incelenmesi gerektiğini görebilir. İki hafta sonra ekiplerin bunu nasıl kullandığını kontrol ediyorum. Bazı ekipler kartları taşır ancak yine de çalışmayı e-posta yoluyla onaylar. Bu bana panonun görünürlük açısından yararlı olduğunu ancak onay eyleminin ürünün içinde gerçekleşmesi gerektiğini söylüyor. Bir sonraki sürüm, anlaşılır bir onay düğmesi ve bir bildirim içerebilir. Ürün, uzun bir özellik listesinden değil, gözlemlenen davranıştan gelişir. Büyük bir fikri gerçek bir müşteriye, gerçek bir soruna ve tek bir yararlı eyleme indirgediğimde yönetimi daha kolay hale gelir. Bana bir şeyler öğretebilecek en küçük versiyonu test ediyorum. Destekleyemeyeceğim sözler vermeden davranışları dinlerim, kanıtları gözden geçiririm ve planı düzenlerim. Amaç her şeyi bir anda inşa etmek değil. Amaç, birinin onu tekrar kullanmasına yardımcı olacak bir ürün yaratmaktır.

Aklınızda bir fikir var ancak bunu insanların görebileceği ve kullanabileceği bir şeye dönüştürmek zor gelebilir. Notlar bir belgede bulunur. Eskizler not defterinde kalır. Planlar doğru desteği bekler. Süreci takip etmeyi zorlaştırmadan bu ilk fikirlerin net, kullanılabilir sonuçlara dönüştürülmesine yardımcı oluyorum. Neyi başarmak istediğinizi dinleyerek başlıyorum. Hedef kitlenizi, mesajınızı, tercih ettiğiniz tarzı ve projenizin çözmesi gereken sorunları soruyorum. Bu bize tahminlere güvenmek yerine pratik bir başlangıç ​​noktası sağlar. Daha sonra fikri net bir plan haline getiriyorum. Şunları görebilirsiniz: - Ne oluşturulacak - Proje hangi adımları içerecek - Sizden hangi bilgi veya materyallere ihtiyacım olacak - Geri bildirim nasıl ele alınacak - Nihai sonuç size neleri yardımcı olacak Açık bir plan zamandan tasarruf sağlar ve tekrarlanan değişiklikleri azaltır. Ayrıca iş çok ileri gitmeden önce düşüncelerinizi paylaşmanız için size alan sağlar. Çalışma basit bir yol izleyebilir: 1. Fikrinizi paylaşın Notlarınızı, örneklerinizi, eskizlerinizi, marka ayrıntılarınızı veya ihtiyacınız olan şeyin kısa bir açıklamasını gönderirsiniz. Fikrinizin tam olarak oluşmasına gerek yok. Kaba bir başlangıç ​​noktasıyla çalışabilirim. 2. Yönü tanımlayın Düşüncelerinizi odaklanmış bir proje özetine dönüştürmenize yardımcı oluyorum. Bu, görsel stili, ses tonunu, sayfa yapısını, temel özellikleri veya içerik ihtiyaçlarını içerebilir. 3. İlk versiyonu oluşturun Fikrinize net bir şekil veren, çalışan bir versiyon oluşturuyorum. Yönü gözden geçirebilir ve neyin doğru olduğunu veya neyin değişmesi gerektiğini belirtebilirsiniz. 4. Ayrıntıları hassaslaştırın Geri bildiriminiz bir sonraki tura rehberlik eder. Sonuçların hedeflerinizle daha yakından eşleşmesi için düzeni, ifadeleri, görselleri veya işlevleri ayarlıyorum. 5. Nihai çalışmayı hazırlayın Biten proje kullanım, paylaşım, yayınlama veya devretme için düzenlenir. Sonraki adımlar hakkında net bilgi alırsınız. Örneğin, yerel bir fırın sahibi basit bir istekle başlayabilir: "Menümüzü göstermenin ve özel pasta soruları almanın daha iyi bir yoluna ihtiyacım var." Gerçek ihtiyaç yeni bir sayfadan daha fazlasını içerebilir. Müşterilerin yoğun saatlerde aramadan hızlı bir şekilde lezzet bulmaları, sipariş ayrıntılarını görüntülemeleri, teslim sürelerini anlamaları ve talep göndermeleri gerekebilir. Yararlı bir çözüm, bu ihtiyaçları basit bir akışta bir araya getirecektir. Sahibi, menüyü net fotoğraflarla sunabilir, sipariş sürecini açıklayabilir ve yanıt için gereken ayrıntıları toplayabilir. Sonuç, müşterinin işini kolaylaştırırken işi de destekler. Her projeye bu şekilde yaklaşıyorum. Fikrinizi sabit bir paket olarak ele almıyorum. İnsanların bitmiş işi gördükten sonra ne anlamasını, hissetmesini ve yapmasını istediğinize bakıyorum. Her küçük görevi yönetmeye gerek kalmadan işin içinde kalırsınız. Süreci net tutuyorum, geri bildirimlerinizi dinliyorum ve yönü kullanabileceğiniz çalışmalara dönüştürüyorum. Fikriniz notların ve eskizlerin ötesine geçmeye hazır olduğunda elinizde olanı paylaşın. Açık bir konuşma ona ihtiyaç duyduğu şekli verebilir.

Bir ürün fikri bir toplantıda kulağa güçlü gelebilir ama insanlar onu kullanmaya çalıştığında hala belirsiz gelebilir. Pek çok ekip aynı sorunla karşı karşıya: çok fazla özellik, değişen geri bildirimler, yavaş kararlar ve ilk taslaktan halka açık lansmana kadar net bir yol yok. Birkaç hafta içinde fikirden çalışan ürüne geçmek için odaklanmış bir süreç kullanıyorum. İş pratik kalır. Her adım ekibe inceleyecek, test edecek ve geliştirecek bir şeyler verir. 1. Hafta: Fikri şekillendirin Basit sorular sorarak başlıyorum: - Ürünü kim kullanacak? - Hangi sorunu çözmeye çalışıyorlar? - Bugün ne kullanıyorlar? - Ürün piyasaya sürüldükten sonra hangi eylem daha kolay hissettirmeli? - Daha sonraki bir sürüm için ne beklenmeli? Bu sorular, kullanışlı bir özelliği yalnızca kağıt üzerinde iyi görünen bir özellikten ayırmaya yardımcı olur. Örneğin küçük bir randevu hizmeti, müşteri profilleri, ödeme araçları, ekip hesapları, hatırlatıcılar ve raporlara yönelik taleplerle başlayabilir. Ekip, birkaç kullanıcıyla konuştuktan sonra asıl sorunun çok daha dar kapsamlı olduğunu öğrenebilir: Müşterilerin müsait bir zamanı ayırtmak için hızlı bir yola ihtiyacı vardır. Bu içgörü ilk ürünü değiştirir. İlk sürümde yalnızca bir hizmet listesi, müsaitlik takvimi, rezervasyon formu ve onay mesajı gerekebilir. Daha küçük bir kapsam, ekibe ekstra işlevlere zaman harcamadan önce ana fikri test etmesi için daha fazla alan sağlar. 2. Hafta: Bir çalışma taslağı oluşturun Ana kullanıcı akışı netleştikten sonra bunu basit bir ürün taslağına dönüştürüyorum. Bu şunları içerebilir: - Kaba bir sayfa yapısı - Kısa bir kullanıcı yolculuğu - Örnek içerik - Anahtar ekranlar - Temel etkileşim kuralları - Açık soruların listesi Bu aşamada her ekranı mükemmel hale getirmeye çalışmıyorum. Bir kullanıcının bundan sonra ne yapacağını anlayıp anlayamayacağına odaklanıyorum. Yararlı bir taslak aşağıdaki gibi sorulara cevap vermelidir: - Yeni bir kullanıcı ana eylemi bulabilir mi? - Sayfa hizmeti sade bir dille açıklıyor mu? - Form gönderildikten sonra ne olur? - Kullanıcı bir hatayı yeniden başlatmadan düzeltebilir mi? - Ürün telefonda iyi çalışıyor mu? Ürünü uzun bir sunum yerine gerçek bir görev üzerinden incelemeyi tercih ediyorum. Bir ekip üyesi randevu almayı, hesap oluşturmayı veya fiyat teklifi talep etmeyi deneyebilir. Eylemleri genellikle bir sayfalık yazılı geri bildirimden daha fazlasını açığa çıkarır. 3. Hafta: Geri bildirim yoluyla iyileştirmeler Geri bildirim, belirli bir görevle bağlantılı olduğunda yararlı olur. “Bu sayfayı beğendin mi?” diye sormak yerine Soruyorum: - Sizce bu düğme ne işe yarayacak? - Bundan sonra ne görmeyi beklersiniz? - Hangi kısım belirsiz geliyor? - Bu görevi tamamlamanıza ne engel olur? - Hangi bilgiler eksik? Bu yaklaşım, kullanıcıların kendi başlarına bahsetmeyebilecekleri sorunları bulmama yardımcı oluyor. Küçük bir yazılım şirketi bir keresinde beş kullanıcılı bir kayıt sayfasını test etmişti. Sayfanın kısa bir formu vardı ama ana düğmede "Devam et" yazıyordu. Bazı kullanıcılar başka bir bilgi sayfasına geçeceğini düşündü. Şirket, etiketi "Hesap oluştur" olarak değiştirdi ve görevin anlaşılması daha kolay hale geldi. Değişiklik küçüktü. Etki, kelimelerin kullanıcının beklentisiyle eşleştirilmesinden kaynaklandı. Ayrıca geri bildirimleri üç türe ayırıyorum: - Ana görevi engelleyen bir sorun - Karışıklığa neden olan bir sorun - Bekleyebilecek bir tercih Bu, ekibin her yorumu acil bir değişiklik olarak ele almasını engeller. Ana kullanıcı görevi merkezde kaldığında ürün kararları daha kolay hale gelir. 4. Hafta: Lansmana hazırlanın Lansman için bitmiş bir arayüzden daha fazlasına ihtiyaç vardır. Güveni ve günlük kullanımı etkileyen detayları kontrol ediyorum. İnceleme şunları kapsayabilir: - Mobil ve masaüstü düzenleri - Sayfa hızı - Form davranışı - Hata mesajları - İletişim ayrıntıları - Gizlilik bilgileri - Analitik kurulumu - Arama sayfası başlıkları ve açıklamaları - Resim boyutları ve alternatif metin - Bozuk bağlantılar - Temel erişilebilirlik Ayrıca lansman için aşağıdakiler gibi basit içerikler de hazırlarım: - Kısa bir ürün açıklaması - Ürünün kimin için olduğuna dair net bir açıklama - Sık sorulan soruların yanıtları - Destek talimatları - Mevcut müşteriler için bir mesaj - Lansmandan sonra geri bildirim toplamaya yönelik bir plan Arama görünürlüğü, tekrarlanan anahtar kelimelerle değil, faydalı içerikle başlar. Müşterilerin sorunlarını anlatırken zaten kullandıkları kelimeleri kullanıyorum. Her sayfa net bir amaca odaklanmalı ve ziyaretçilere devam etmeleri için bir neden vermelidir. Desteklenemeyecek iddialardan kaçınırım. Bir ürün yeni ise onu binlerce kullanıcının güvendiği bir ürün olarak sunmuyorum. Sonuçlar müşteriye göre değişiklik gösteriyorsa bu sonuçları neyin etkileyebileceğini açıklarım. Dürüst kopya, insanlara karar vermeleri için daha iyi bir temel sağlar. Öğrenim planıyla lansman Lansmanı projenin sonu olarak değil, ürün öğreniminin başlangıcı olarak görüyorum. Yayınlanmadan önce ne izleyeceğime karar veririm: - Hangi sayfa en çok ziyaret alıyor? - Kullanıcılar nereden ayrılıyor? - Ana görevi kaç kişi tamamlıyor? - Destek ekibine hangi sorular ulaşıyor? - Hangi cihazlar sorun yaratıyor? - Erken kullanıcılar en sık neyi talep ediyor? Lansmandan sonra bu bilgiyi gözden geçiriyorum ve orijinal hedefle karşılaştırıyorum. Ziyaret sayısının fazla olması kulağa olumlu gelebilir ancak kullanıcıların sorunu çözüp çözmediğini göstermez. Temel görevi tamamlayan daha küçük bir hedef kitle daha yararlı kanıtlar sağlayabilir. Benim görüşüm basit: Bir ürün, ekip aylarca önemli olmayan ayrıntıları cilalamadan önce kullanıcılara ulaşmalıdır. Odaklanmış bir kapsam, düzenli kullanıcı kontrolleri ve dürüst lansman içeriği, fikirden faydalı ürüne giden daha iyi bir yol oluşturur. İlk uygulanabilir sürümü oluşturun. Gerçek geri bildirimlerle geliştirin. Bundan sonra ne olacağını öğrenmek için net bir yöntemle başlayın.

Güçlü bir kitap bir satış vaadiyle başlamaz. Net bir fikir, gerçek bir okuyucu ve sayfaları değere dönüştüren bir planla başlar. Kaba bir konseptten bitmiş bir taslağa geçmenin ne kadar zor olduğunu biliyorum. Yararlı bilgileriniz, kişisel deneyimleriniz veya paylaşmaya değer bir hikayeniz olabilir, ancak erken taslaktan piyasaya hazır kitaba giden yol belirsiz görünebilir. Yapı zayıf olabilir. Mesaj çok geniş olabilir. Kapak, açıklama ve lansman planı doğru kitleye hitap etmeyebilir. Bu belirsizliğin pratik bir yayıncılık sürecine dönüştürülmesine yardımcı oluyorum. Okuyucuyu tanımlayarak başlıyoruz. Herkes için yazılmış bir kitap çoğu zaman herkesle bağlantı kurmakta zorlanır. Kitaptan en çok yararlanacak kişilere bakıyorum ve soruyorum: - Hangi sorunu çözmeye çalışıyorlar? - Satın almadan önce hangi soruları soruyorlar? - Hangi dili kullanıyorlar? - Tutamayacağı sözler vermeden kitap hangi sonucu destekleyebilir? Yeni restoran sahipleri için bir iş rehberinin, kariyer değişikliği sonrasında hayatı yeniden inşa etmeye ilişkin bir anı kitabından farklı bir üsluba ihtiyacı olacaktır. Konu faydalı olabilir ancak mesajın konuyla alakalı olup olmadığına okuyucu karar verir. Bir sonraki adım ana fikri şekillendirmektir. Açık bir kitabın genellikle bir ana vaadi vardır. Bu söz okuyucunun ne öğreneceğini, anlayacağını veya deneyimleyeceğini açıklamalıdır. Bölümlere rehberlik etmeli ve yazının ilgisiz düşüncelerin toplamı haline gelmesini önlemelidir. Örneğin, bir küçük işletme danışmanı "işletmenin büyümesi" hakkında geniş bir fikirle başlayabilir. Bu konunun konumlandırılması zordur. Danışmanın deneyimini gözden geçirdikten sonra odak noktası, daha iyi müşteri iletişimi yoluyla sürekli iş kurmak isteyen yerel hizmet sağlayıcılar için bir rehber haline gelebilir. Yeni yön, kitaba daha net bir okuyucu kitlesi, daha güçlü bölüm fikirleri ve daha kullanışlı bir açıklama sağlıyor. Daha sonra yapıyı oluşturuyoruz. Metnin akışını okuyucunun bakış açısından gözden geçiriyorum. Her bölümün net bir rolü olmalıdır. Aynı noktayı farklı kelimelerle tekrarlamak yerine okuyucuyu ileriye taşımalıdır. Pratik bir yapı şunları içerebilir: - Okuyucunun karşılaştığı sorun - Sorunun devam etmesinin nedenleri - Bir yöntem veya adımlar dizisi - Yöntemin nasıl çalıştığını gösteren örnekler - Yaygın hatalar - Okuyucunun her bölümden sonra yapabileceği eylemler Yapı, kitabın türüne göre değişebilir. Bir anı; zamanı, duyguyu ve kişisel değişimi takip edebilir. Bir iş kitabı problem çözme yolunu izleyebilir. Ebeveynler için bir rehberde kısa dersler, örnekler ve alıştırmalar kullanılabilir. Yazma aşaması tutarlı bir sese ihtiyaç duyar. Pek çok yazarın değerli bilgileri vardır ancak bunların sayfada doğal görünmesini sağlamakta zorlanırlar. Dilin açık, doğrudan ve dinleyicilere uygun olmasına yardımcı oluyorum. Teknik fikirler okuyucunun kendini kaybolmuş hissetmesine neden olmadan açıklanabilir. Kişisel hikayeler kitabın tamamını ele geçirmeden mesajı destekleyebilir. Ayrıca daha fazla desteğe ihtiyaç duyan alanları da arıyorum: - Kaynak gerektiren iddialar - Daha fazla ayrıntı gerektiren örnekler - Tekrarlanan noktalar - Bölünebilecek uzun bölümler - Her okuyucuya uymayabilecek tavsiyeler - Mevcut kanıtlardan daha güçlü görünen ifadeler Bu, okuyucunun güvenini korur. Bir kitap abartılı iddialar kullanılmadan da ikna edici olabilir. Sunum aynı zamanda insanların bir kitabı nasıl değerlendirdiğini de etkiler. Kapak konu ve hedef kitleye uygun olmalıdır. Profesyonel bir rehber, kişisel gelişim kitabı ve çocuk hikayesi, her biri farklı bir görsel yöne ihtiyaç duyar. Başlık ve alt başlık, okuyucuların yanlış beklentiler yaratmadan konuyu anlamalarına yardımcı olmalıdır. Kitap açıklaması pratik sorulara cevap vermelidir: - Bu kitap kimin için? - Neleri kapsıyor? - Okuyucu neden umursasın ki? - Okuyucu sayfalardan ne bekleyebilir? Arama görünürlüğü de önemlidir. Konuyla ilgili kitap ararken okuyucuların girebileceği doğal terimleri kullanıyorum. Bu terimler açıklamada, yazar sayfasında, web sitesi içeriğinde ve destekleyici makalelerde görünebilir. İfadeler öncelikle okuyucuya hizmet etmelidir. Aynı ifadeyi çok sık tekrarlamak kopyanın zorlama hissettirmesine ve güvenin azalmasına neden olabilir. Gerçek bir örnek, küçük değişikliklerin yönü nasıl iyileştirebileceğini gösteriyor. Bağımsız bir yazar liderlik hakkında 70.000 kelimelik bir metin yazmıştı. İçerik güçlü işyeri hikayeleri içeriyordu ancak izleyici kitlesi belirsizdi. Taslak ekip yönetimi, kişisel alışkanlıklar, işe alma ve şirket kültürü arasında gidip geliyordu. Materyali inceledikten sonra, asıl odak noktası yöneticilerin ilk yıllarında liderlik oldu. Birkaç geniş bölüm kaldırıldı veya daha kısa destekleyici bölümlere taşındı. Örnekler geri bildirim verme, çatışmayı ele alma ve beklentileri belirleme gibi ortak durumlar etrafında düzenlenmiştir. Kitabın anlaşılması daha kolay hale geldi çünkü yapı okuyucunun günlük kaygılarıyla eşleşiyordu. Yazarın hâlâ fikri gerçek okuyucularla test etmesi gerekiyordu. Küçük bir yönetici grubu taslağı ve örnek bölümleri inceledi. Soruları dilin nerede çok genel olduğunu gösteriyordu. Onların geri bildirimleri, kitabı diğer insanların görüşlerinden oluşan bir koleksiyona dönüştürmeden son versiyonun şekillendirilmesine yardımcı oldu. Bu süreci hatırlamaya değer: Okuyucu geri bildirimi bir kitaba rehberlik edebilir, ancak yazarın kendi deneyimi merkezde kalmalıdır. Yayınlamadan önce okuyucu yolculuğunun tamamını kontrol etmenizi öneririm: 1. Kitabın başlığı doğru beklentiyi yaratır. 2. Kapak konuyu destekliyor. 3. Açıklama belirli bir hedef kitleye hitap ediyor. 4. Açılış sayfaları okuyuculara devam etmeleri için bir neden verir. 5. Bölüm sırası doğal geliyor. 6. Örnekler ana mesajı desteklemektedir. 7. Yazar sayfası bağlam ve güven oluşturur. 8. Satış sayfası okuyucunun sık sorulan sorularına yanıt verir. 9. Kitap formatı seçilen okuma cihazlarında çalışır. 10. Pazarlama içeriğinde doğru ve desteklenebilir bir dil kullanılır. Bir kitap sırf iyi yazılmış diye ticari bir başarıya dönüşemez. Dağıtım, hedef kitleye uygunluk, fiyatlandırma, tasarım, okuyucu geri bildirimi ve tutarlı tanıtımın hepsinin bir rolü vardır. Bir satış sonucu vaat etmiyorum. Planlanabilecek, gözden geçirilebilecek ve iyileştirilebilecek kısımlara odaklanıyorum. Bir sonraki kitabınız kaba bir fikirle, bir notlar klasörüyle veya yönlendirilmesi gereken bir taslakla başlayabilir. Yararlı olan çalışma, bu materyali belirli bir izleyici kitlesi için net bir okuma deneyimine dönüştürmektir. Mesaj odaklandığında, yapı onu desteklediğinde ve tanıtım kitabı dürüstçe yansıttığında, okuyucuların dikkat etmeleri için daha iyi bir nedenleri olur. Güçlü bir yayıncılık yolculuğunun başladığı yer burasıdır.

Bir ürün fikri kafanıza faydalı gelebilir ama yine de gerçek müşterilerde başarısız olabilir. Ekiplerin, insanların bir çözüm için ödeme yapacak kadar sık ​​sorunla karşılaşıp karşılaşmadıklarını kontrol etmeden önce özellikler geliştirmek için aylar harcadıklarını gördüm. Pazara hazır bir ürün fikri heyecanla değil kanıtla başlar. ### İnsanların zaten hissettiği bir sorunla başlayın Sorunu net bir cümleyle yazın: "[Belirli bir durum ortaya çıktığında] [belirli bir müşterinin] [belirli bir sorunu] çözmesine yardımcı oluyorum." "Çevrimiçi alışverişi geliştirmek istiyorum" gibi genel ifadelerden kaçının. Daha açık bir versiyon şu olabilir: "Bağımsız giyim mağazalarının tekrarlanan teslimat sorularını yanıtlamak için harcadığı zamanı azaltmasına yardımcı oluyorum." Bu sürüm bana bir müşteri grubu, bir sıkıntı noktası ve bir iş ortamı sağlıyor. Ayrıca alakalı anahtar kelimeleri, rakipleri, forumları ve müşteri yorumlarını aramama da yardımcı oluyor. Kendime soruyorum: - Bu sorunu kim yaşıyor? - Ne sıklıkla oluyor? - Sorunun zaman, para veya satış kaybı açısından maliyeti nedir? - Bugün insanlar ne kullanıyor? - Mevcut çözüm neden zayıf geliyor? Yılda bir kez ortaya çıkan bir sorun, ücretli bir ürünü desteklemeyebilir. Günlük işleri etkileyen bir sorunun çözülmesi için daha güçlü bir nedeni vardır. ### Potansiyel kullanıcılarla konuşun Arkadaşlarıma ve aileme talebin kanıtı olarak bakmıyorum. Beni desteklemek istedikleri için bu fikri destekleyebilirler. Hedeflenen müşteri profiline uygun kişilerden geri bildirime ihtiyacım var. Kısa bir görüşme şu tür soruları içerebilir: - Bana bu sorunun en son ne zaman yaşandığını anlatın. - Bununla başa çıkmak için ne yaptın? - Ne kadar zaman aldı? - Bir alet veya hizmet için ödeme yaptınız mı? - Mevcut sürecin hangi kısmı en çok sıkıntıya neden oluyor? “Ürünümü alır mısın?” diye sormaktan kaçınırım. İnsanlar sıklıkla gelecekteki davranışları hakkında kibar cevaplar verirler. Geçmiş eylemlerle ilgili sorular genellikle daha iyi bilgi sağlar. Örneğin, küçük çevrimiçi mağazalara yönelik bir aracı test ederken mağaza sahiplerine son müşteri hizmetleri iş yüklerini sorardım. Gerçek süreçleri, teslimatla ilgili soruların ana sorun olmadığını gösterebilir. Ürün iadeleri, stok güncellemeleri veya ödeme anlaşmazlıkları daha fazla zaman alabilir. ### Oluşturmadan önce pazarı kontrol edin Pazar araştırmasının büyük bir rapora ihtiyacı yoktur. Şunları inceleyebilirim: - Rakip web siteleri ve fiyatlandırma sayfaları - Ürün incelemeleri - Reddit ve sektör forumları - Arama önerileri - Quora ile ilgili sorular - Sosyal medyadaki müşteri yorumları - Aradığım sorundan bahseden iş gönderileri Tekrarlanan dil. Birkaç müşteri aynı zorluğu benzer kelimelerle anlatırsa, bu ifadeler hem ürün kararlarına hem de SEO içeriğine yol gösterebilir. Ayrıca mevcut seçenekleri de karşılaştırıyorum. Bir rakip her zaman durmak için bir neden değildir. Bu, insanların soruna zaten para harcadığını gösterebilir. Ürünümün daha basit bir kurulum, dar bir müşteri grubu için daha iyi bir iş akışı veya belirli bir kullanım senaryosu desteği gibi net bir farklılığa ihtiyacı var. Bu ifadeyi destekleyemediğim sürece ürünümün “tek çözüm” olduğunu iddia etmekten kaçınırım. Açık konumlandırma, geniş vaatlerden daha fazla güven oluşturur. ### En küçük kullanışlı sürümü tanımlayın Pazara hazır bir ürün fikri, planlanan her özelliğe ihtiyaç duymaz. Net bir hedef kitle için tek bir yararlı sonuca ihtiyaç vardır. Şunları yazıyorum: - Ana müşteri - Ana sorun - Ürünün sunması gereken tek sonuç - Bu sonuç için gereken özellikler - Bekleyebilecek özellikler Diyelim ki yerel tamir atölyeleri için bir randevu aracı oluşturmak istiyorum. İlk sürümde rezervasyon bağlantıları, hizmet seçimi, müşteri iletişim bilgileri ve randevu hatırlatıcıları gerekebilir. Bir sadakat programı, mobil uygulama ve gelişmiş raporlama, kullanıcılar onlara ihtiyaç duyana kadar bekleyebilir. Küçük bir versiyon, fikri daha az maliyetle ve daha az kafa karışıklığıyla test etmeme yardımcı oluyor. Ayrıca müşteri geri bildirimlerinin anlaşılmasını kolaylaştırır. ### Fikri tam geliştirmeden önce test edin Bir ürün fikrini bir açılış sayfası, tıklanabilir bir prototip, manuel hizmet veya küçük ücretli bir pilot aracılığıyla test edebilirim. Test şunları açıklamalıdır: - Ürünün kime hizmet ettiği - Hangi sorunu çözdüğü - Sürecin nasıl çalıştığı - Müşterinin ne aldığı - Ürünün vaat etmediği şeyler Bir açılış sayfası, ilgilenen kullanıcılar için bir form içerebilir. Manuel bir hizmet, ben işi otomatikleştirmeden önce müşterilerin sonuca değer verip vermediğini gösterebilir. Dropbox, ürünün tamamı yaygın olarak kullanıma sunulmadan önce dosya senkronizasyonunun nasıl çalışabileceğini göstermek için erken bir tanıtım videosu kullandı. Test, ekibin insanların bu deneyimi önemseyip umursamadığını öğrenmesine yardımcı oldu. Buradan alınacak ders, her ürünün bir videoya ihtiyacı olduğu değildir. Buradan alınacak ders, ilginin büyük bir yapıdan önce test edilebileceğidir. ### Pratik bir fiyat belirleyin Fiyat, sorunun değeriyle bağlantılı olmalıdır. Mevcut sürecin maliyetini, tasarruf edilen zamanı ve müşterilerin beklediği sonuçları karşılaştırırım. Birkaç basit seçeneği test edebilirim: - Tek seferlik proje ücreti - Aylık abonelik - Ücretli pilot - İsteğe bağlı ücretli özelliklere sahip temel plan Baskıya dayalı mesajlar veya garantili sonuç vaatleri kullanmıyorum. Müşterilerin kendi hızlarına göre karar verebilmeleri için yeterli bilgiye ihtiyaçları vardır. Bir fiyatlandırma sayfası aynı zamanda müşteri beklentilerini de ortaya çıkarabilir. İnsanlar kurulum, limitler, geri ödemeler veya destek hakkında sorular sorarsa bu sorular teklifin daha net ayrıntılara ihtiyacı olduğunu gösterebilir. ### Davranışları izleyin, yalnızca fikirleri değil Olumlu yorumlar faydalıdır, ancak eylemler daha fazla ağırlık taşır. İnsanların şunları yapıp yapmadığını takip ediyorum: - Bir test için kaydolun - Kurulumu tamamlayın - Ana özelliği kullanın - Ürüne geri dönün - Ödeme hakkında bilgi isteyin - Bir meslektaşınıza önerin - Deneme veya pilot uygulamadan sonra devam edin Kullanıcılar fikri övüyor ancak kullanmıyorsa, ürün düşük öncelikli bir sorunu çözüyor olabilir. Temel sürümü kullanmaya devam ederlerse bu davranış bir sonraki geliştirme adımına rehberlik edebilir. Geri bildirimleri her hafta gözden geçiriyorum ve üç alanda gruplandırıyorum: tekrarlanan sorunlar, faydalı istekler ve kişisel tercihler. İstenilen her özelliği eklemek yerine tekrarlanan sorunlar etrafında gelişiyorum. Pazara hazır bir ürün fikri, daha fazla özellik eklenerek oluşturulmaz. Belirli bir müşteriyi seçerek, gerçek bir sorunu doğrulayarak, küçük bir çözümü test ederek ve gerçek davranışı dinleyerek bunu daha net hale getiriyorum. Kanıtlar bu fikri desteklediğinde, daha fazla odaklanarak ürünü geliştirebilir ve ürünü müşterilerin zaten anlayacağı dilde açıklayabilirim. Daha fazlasını mı öğrenmek istiyorsunuz? Shaoneng Lu ile iletişime geçmekten çekinmeyin: rxyx@ronnaso.com/WhatsApp +8613777688618.

Eric Ries (2011) The Yalın Startup Alexander Osterwalder ve Yves Pigneur (2010) İş Modeli Üretimi Steve Blank ve Bob Dorf (2012) The Startup Owner's Manual Marty Cagan (2017) İlham Veren: How to Create Tech Products Müşteriler Don Norman'ı Seviyor (2013) The Design of Everyday Things Philip Kotler ve Kevin Lane Keller (2016) Pazarlama Yönetimi