Bir SaaS ürününün ilk sürümünde ne olmalı?

Dar kapsam, tamamlanmış yolculuk

İlk sürümün amacı bütün olası özellikleri sergilemek değildir. Bir kullanıcının gerçek işini baştan sona tamamlayabildiği dar bir yolculuk seçin. Girişten kaydın oluşturulmasına, düzenlenmesine ve tekrar bulunmasına kadar akış tamamlanmalıdır.

Veri sınırı tasarım kararıdır

Hangi kullanıcı hangi şirketin hangi kayıtlarını görebilir? Bir hesabın kapanması kayıtlara ne yapar? Bu sorular, yalnız bir giriş ekranı ekleyerek çözülemez. Rol ve veri sahipliği kurallarını arayüzden önce tanımlayın.

Başarısız senaryo da ürünün parçası

Ödeme bildirimi iki defa geldiğinde, bağlantı kesildiğinde veya e-posta gönderilemediğinde ne olacak? İyi bir ilk sürüm, bunları sessizce görmezden gelmez. Kayıt durumlarını ve yeniden deneme davranışını görünür kılar.

Gösterge panelinden önce operasyon

Kullanıcının kaydı düzeltebildiği, destek ekibinin sorunu inceleyebildiği ve geri yükleme yolunun bilindiği bir sistem kurun. Gösterişli grafikler, verinin nasıl üretildiği doğrulanmadan karar aracı olarak sunulmamalıdır.

Çıkış ölçütünüzü yazın

İlk sürüm için birkaç açık ölçüt belirleyin: ana görev tamamlanıyor mu, yetkisiz erişim engelleniyor mu, hata sonrası kullanıcı devam edebiliyor mu? Özellik sayısı yerine bu sonuçları değerlendirin. Bu yazı Atlas’ın önerdiği geliştirme yaklaşımıdır; her ürün için kapsam ayrıca netleştirilir.

Örnek: küçük bir operasyon ürünü

Bir ekip için müşteri takip ürünü geliştirdiğimizi varsayalım. İlk sürümde kullanıcı hesabını açar, bir müşteri ekler, görev atar ve görevin sonucunu görür. Bu akışın yanına gelişmiş tahmin grafikleri, kampanya editörü ve onlarca entegrasyon eklemek yerine kayıt sahipliğini, yanlış veri girişini ve iptal edilen işlemi tamamlamayı tercih ederiz.

Basitlik, yetki kontrolünü atlamak demek değildir. Kullanıcı başka bir şirketin kaydını açamamalı; görev kaydedilmediğinde kaydedilmiş gibi görünmemeli; destek ekibi hatanın nerede oluştuğunu anlayabilmelidir. İlk sürümün değeri ekran sayısı değil, seçilen işin güvenilir biçimde bitmesidir. Bu yaklaşım bir kapsam önerisidir; her ürünün başlangıç ihtiyacı aynı olmayacaktır.

Özellik listesini kabul senaryosuna dönüştürün

“Müşteri eklenebilir” maddesini tek başına bırakmayın. Hangi alanlar zorunlu, aynı müşteri yeniden eklenirse ne olur, bağlantı kesilirse kullanıcı ne görür ve kim düzenleme yapabilir sorularını yanına yazın. Kabul örneği, ekiplerin aynı şeyi teslim edip etmediğini konuşabileceği somut bir sözleşme oluşturur.

Her yeni fikir için ana yolculuğu tamamlamak üzere gerçekten gerekli olup olmadığını sorun. Gerekli değilse sonraki sürüm listesine alın; reddedilmiş gibi davranmayın. İlk kullanıcılardan geri bildirim isterken “Beğendiniz mi?” yerine hangi işi tamamladıklarını ve nerede durduklarını inceleyin. Bir sonraki sürümün önceliği, en yüksek sesle söylenen özelliğe değil gözlenen soruna dayanmalıdır. Ödeme, üyelik ve müşteri verisi kapsamdaysa bunların sınırları prototipten üretime geçmeden ayrıca doğrulanmalıdır.