Bir Araç Ne Zaman Feature, Ne Zaman Ayrı Bir Üründür?

Yeni bir araç çalışmaya başladığında çok cazip bir soru ortaya çıkar:

“Bunu ayrı ürün yapalım mı?”

Logo bulunur. Domain bakılır. Yeni landing page açılır.

Teknik olarak bir uygulamayı ayırmak kolay olabilir.

Ürün sınırı çizmek daha zordur.

Ayrı URL ayrı ürün demek değildir

Ben bir surface’i ayrı ürün kabul etmek için URL’ye bakmıyorum.

Şunlara bakıyorum:

• Kullanıcı buraya bağımsız bir iş için geliyor mu?
• Araç tek başına anlamlı değer üretiyor mu?
• Kendi input → output döngüsü var mı?
• Ana ürünü kullanmadan anlaşılabilir mi?
• Kendi state veya geçmişine ihtiyaç duyuyor mu?
• Ayrı discovery yüzeyi mantıklı mı?
• Ayrı release/ownership maliyetini hak ediyor mu?

Bu soruların çoğuna hayır cevabı veriyorsak, muhtemelen yeni bir ürün değil, mevcut sistemin capability’sidir.

Feature olarak kalması gereken şey

Bir fonksiyon ana ürünün işini tamamlıyorsa feature olarak kalması daha doğru olabilir.

Örneğin mevcut audit akışının içinde kullanılan küçük bir formatter’ın ayrı landing page’e, markaya ve analytics’e ihtiyacı olmayabilir.

Ayırdığınız anda şunlar doğar:

• ayrı navigation,
• ayrı copy,
• ayrı SEO,
• ayrı deploy,
• ayrı docs,
• ayrı bakım,
• ayrı link ownership,
• ayrı kullanıcı beklentisi.

Yeni subdomain yalnız teknik karar değildir. Operasyon yüzeyi açar.

Ayrı ürün olmayı hak eden şey

Tersine, bazı araçlar ana sitenin içine gömüldüğünde değerini kaybeder.

Kullanıcı belirli bir problemi çözmek için direkt gelebiliyorsa, girdi verip bağımsız çıktı alıyorsa, çıktıyı kaydedebiliyor veya paylaşabiliyorsa, araç tekrar kullanılan kendi döngüsüne sahipse, ayrı URL güçlü bir ürün kararı olabilir.

Burada subdomain navigasyon kolaylığı değil, product boundary’nin sonucu olur.

Ahmetcanal.com için kural

Benim için doğru yön şu:

Ahmetcanal.com otorite ve karar merkezi.

Projects çalışan sistemlerin kanıtı. Services müdahale rotaları. Toolkit teknik audit platformu. Capabilities problem çözme katmanları.

Bağımsız değer üreten araçlar ise gerektiğinde kendi subdomain’lerinde yaşayabilir.

Ama “yeni bir şey yaptım, o hâlde yeni subdomain” yaklaşımı yanlış.

Her yeni yüzey ekosistemin toplam context maliyetini artırıyor.

Boundary test

Bir aracı ayırmadan önce şu testi kullanıyorum:

Job test: Kullanıcı tek cümlede bu aracın yaptığı bağımsız işi söyleyebiliyor mu?

Entry test: Ana ürünü tanımadan direkt gelebilir mi?

Output test: Kendi başına değerli bir çıktı üretiyor mu?

Return test: Kullanıcının tekrar gelmesi için kendi nedeni var mı?

Ownership test: Ayrı state, data veya release ownership’i var mı?

Cost test: Ayrı yüzeyin bakım maliyeti ürettiği değerden küçük mü?

Altı testten yalnız “cool URL” geçiyorsa ayırmıyorum.

Ayrı ürün yapmamanın stratejik değeri

Solo ürün geliştirmede en kıt kaynak kod yazma kapasitesi değil, dikkat.

Her ayrı ürün:

• yeni roadmap,
• yeni bug listesi,
• yeni analytics,
• yeni copy,
• yeni support context’i

demek.

Bu yüzden product boundary aynı zamanda focus boundary’dir.

Doğru sınır çizmek yalnız kullanıcı deneyimini değil, operatörün kapasitesini de korur.

Sonuç

Bir şeyin feature mı ürün mü olduğunu komponent boyutu belirlemez.

Bağımsız kullanıcı işi, state, yaşam döngüsü ve değer döngüsü belirler.

Yeni ürün açmak yaratıcı olarak tatmin edicidir.

Doğru ürün sınırı çizmek ise daha değerlidir.