30 sn özet
Ürün yaşam döngüsü, ürünün pazara girişinden büyümesine, olgunlaşmasına ve yenilenmesine ya da sonlandırılmasına uzanan gelişimini anlamaya yardımcı olur. Her dönemde aynı yatırım ve başarı ölçütü uygun olmayabilir. Sunset, ürünün veya belirli bir özelliğin kontrollü biçimde kullanımdan kaldırılmasıdır. Karar yalnızca düşük kullanım sayısına dayanmaz; müşteri bağımlılığı, bakım maliyeti, stratejik uyum ve alternatifler birlikte değerlendirilir. İyi sonlandırma, kapatma tarihini duyurmanın yanında müşterinin işini nasıl sürdüreceğini de açıklar. Geçiş, ürün yönetiminin sorumluluğunun parçasıdır.
Neden önemli?
Bir ürün portföyünde her şeyi süresiz yaşatmak mümkün değildir. Az kullanılan bir özellik ayrı altyapı, uzmanlık ve test yükü gerektirebilir. Eski sürümleri desteklemek, yeni geliştirmelerin hızını düşürebilir. Ancak kullanımın az olması, iş değerinin düşük olduğu anlamına gelmez. Bir rapor yalnızca ay sonunda çalıştırılıyor olabilir; yine de müşterinin önemli bir iş sürecini destekleyebilir.
Bu nedenle sonlandırma kararı hem ekonomik hem operasyonel bir değerlendirmedir. Eski çözümü sürdürmenin maliyeti ile müşteriyi yeni çözüme geçirmenin maliyeti karşılaştırılmalıdır. Geliştirme ekibinin kazanacağı kapasite, geçiş boyunca doğacak destek ihtiyacıyla birlikte hesaplanmalıdır. Kapatma sonrasında tasarruf sağlanması, geçişin ücretsiz olduğu anlamına gelmez.
BA, mevcut iş akışlarının ve bağımlılıkların görünür olmasını sağlar. PM, sürdürme, yenileme veya sonlandırma seçeneklerini ürün stratejisiyle ilişkilendirir. PO, geçiş için gereken geliştirmeleri ve kapsamı uygulanabilir işlere dönüştürür. Satış ve müşteri başarısı ekipleri, müşterinin operasyonuna ve taahhütlerine etkisini açıklar. Yönetim ise kısa vadeli tasarrufla uzun vadeli müşteri ilişkisi arasında karar verir.
Kötü yönetilen bir kapanış, müşterinin yalnızca o ürüne değil şirketin diğer tekliflerine de güvenini azaltabilir. Buna karşılık açık kapsam, yeterli hazırlık ve işleyen bir alternatif, zor bir kararı anlaşılabilir kılar. Sonlandırmanın kalitesi, kapatılan sistemin yanında kalan müşteri ilişkilerinde de görülür.
Terim nedir?
Ürün yaşam döngüsü genellikle giriş, büyüme, olgunluk ve gerileme aşamalarıyla anlatılır. Bu çerçeve bir takvim kuralı değildir. Aynı ürün farklı segmentlerde farklı aşamalarda olabilir. Bir pazarda olgunlaşmış çözüm, başka pazarda yeni benimseniyor olabilir. Yönetim, aşama adını ürünün yaşıyla değil gözlenen talep, kullanım ve ekonomik koşullarla ilişkilendirmelidir.
Girişte müşterinin problemini gerçekten çözüp çözmediğini öğrenmek ön plandadır. Büyümede edinme, aktivasyon ve hizmet kapasitesi birlikte ölçeklenir. Olgunlukta verimlilik, farklılaşma ve müşteri ilişkisini derinleştirme öne çıkabilir. Gerileme döneminde ise talep kaybının nedeni araştırılır: ihtiyaç değişmiş, alternatifler güçlenmiş veya ürün deneyimi zayıflamış olabilir. Her düşüş kapatma gerektirmez; bazen yeniden konumlandırma veya kapsamı daraltma daha uygun olur.
Sunset, ürünün, özelliğin, entegrasyonun veya API sürümünün planlı biçimde kaldırılmasıdır. Yeni satışın durması, geliştirmelerin sona ermesi, desteğin bitmesi ve erişimin kapanması ayrı olaylardır. Bunların tek tarihle ifade edilmesi müşterinin hangi hakkının ne zaman değişeceğini anlamasını zorlaştırabilir.
Sonlandırma kararı verilmeden önce alternatifler incelenmelidir. Ürünü bakım modunda tutmak, başka çözümle birleştirmek, kapsamını küçültmek veya tamamen kapatmak farklı maliyetler taşır. Geçiş çözümü de her müşterinin ihtiyacını aynı biçimde karşılamayabilir. Yeni sürümde aynı özellik adının bulunması, mevcut iş akışının kesintisiz çalışacağını göstermez.
Bir geçiş planı; etkilenen müşterileri, bağımlı sistemleri, veri taşımayı, eğitim ihtiyacını ve destek hazırlığını kapsar. Nihai kapatma için yalnızca tarih değil, hazır olma koşulları da tanımlanmalıdır. Örneğin kritik hesapların geçiş testlerini tamamlaması veya belirli hata seviyesinin aşılmaması bir karar koşulu olabilir. Sınırsız erteleme yerine istisnaların kapsamı, sahibi ve süresi açık tutulur.
Gerçek vaka
Microsoft, 19 Mayıs 2021 tarihli duyurusunda Internet Explorer 11 masaüstü uygulamasının belirli Windows 10 sürümlerinde 15 Haziran 2022’de emekliye ayrılacağını ve desteğinin sona ereceğini açıkladı. Böylece planlanan değişiklik için yaklaşık bir yıllık hazırlık aralığı sundu.
Şirket, geçiş adresi olarak Microsoft Edge’i gösterdi. Edge içindeki Internet Explorer modu, eski IE tabanlı siteler ve uygulamalar için uyumluluk yolu sağlıyordu. Duyuru, kapsamın bütün sistemleri aynı biçimde etkilemediğini de belirtti: o tarihte piyasada bulunan Windows 10 LTSC ve Server üzerindeki IE11 masaüstü uygulamaları ile MSHTML motoru bu emeklilik kapsamının dışındaydı.
Vakanın ürün yönetimi açısından değeri, bitiş tarihiyle birlikte alternatifin, uyumluluk yaklaşımının ve istisnaların açıklanmasıdır. Bu, eski masaüstü uygulamasının sonlandırılmasıyla bütün eski uygulamaların aynı gün ortadan kalkmasının farklı kararlar olduğunu gösterir. Kaynak, geçişin tüm müşteriler için sorunsuz tamamlandığını veya belirli bir maliyet tasarrufu yarattığını kanıtlamıyor. Buradan çıkarılabilecek ders, sonlandırma kapsamını teknik ve müşteri bağlamıyla birlikte tanımlamaktır.
Varsayımsal örnek: Eski raporlama API’sinden kontrollü geçiş
Bir B2B operasyon ürünü, eski raporlama API’sini yeni sürümle değiştirmek istiyor. Son 90 günde 60 müşteri hesabı eski API’ye istek göndermiş. Bunların 12’si ay sonunda toplu rapor aldığı için günlük kullanım grafiğinde neredeyse görünmüyor. Ekip, yalnızca son haftanın aktif hesaplarına bakarsa bu bağımlılığı atlayacak.
Yeni API daha hızlı çalışıyor; fakat bazı müşterilerin kullandığı alan adları ve tarih filtreleri değişmiş durumda. BA mevcut entegrasyonları sınıflandırıyor, mühendislik eşleştirme rehberi ve test ortamı hazırlıyor. Müşteri başarısı ekibi her hesap için teknik sorumlu ve geçiş takvimini belirliyor. İlk pilotta çıktıların aynı iş sonucunu üretip üretmediği karşılaştırılıyor.
Plan, yeni müşterilere eski API erişiminin kapanmasını, çift çalışma dönemini ve nihai kapatmayı ayrı adımlar olarak düzenliyor. Veri dışa aktarma ihtiyacı olan müşterilere uygun yol sunuluyor. Hesaplardan birinin ay sonu raporu yeni sürümde eksik sonuç verince sorun kapanıştan önce düzeltiliyor. Geçiş başarısı yalnızca yeni API’ye gelen çağrı sayısıyla ölçülmüyor; kritik raporların doğruluğu ve eski kullanımın neden sürdüğü de inceleniyor.
Nihai tarihe yaklaşırken eski API’ye devam eden üç hesap kalıyor. Ekip bunları sessizce kapatmak yerine engelleri değerlendiriyor. Bir hesapta sınırlı süreli istisna onaylanıyor; diğerlerinde geçiş tamamlanıyor. İstisnanın sahibi ve bitiş koşulu kaydediliyor. Kapatma sonrasında destek talepleri, başarısız istekler ve müşteri kaybı izlenerek kararın etkisi değerlendiriliyor.
Yaygın 3 hata
- Düşük kullanımı düşük değer saymak
Seyrek çalışan iş akışları kritik olabilir. Kullanım sıklığıyla birlikte işin amacı, aksamasının etkisi ve müşterinin alternatifi araştırılmalıdır. Özellikle dönemsel işlemler için yeterince uzun gözlem penceresi kullanılmalıdır.
- Alternatifi duyurup geçişin tamamlandığını varsaymak
Yeni ürünün mevcut olması, müşterinin entegrasyonunu ve iş süreçlerini taşıdığı anlamına gelmez. Veri, erişim, çıktı doğruluğu ve kullanıcı hazırlığı doğrulanmalıdır. Müşterinin duyuruya yanıt vermemesi hazır olduğu şeklinde yorumlanmamalıdır.
- İstisnaları süresiz bırakmak
Her erteleme yeni bakım ve destek yükü yaratabilir. İstisnalar gerekçe, sorumlu, süre ve çıkış koşuluyla yönetilmelidir. Aksi hâlde kapatılması planlanan sistem kalıcı bir ikinci ürüne dönüşebilir; beklenen kapasite kazanımı gerçekleşmez.
Mini uygulama/şablon
- Karar konusu
- Hangi ürün, özellik veya sürüm değerlendiriliyor?
- Karar gerekçesi
- Strateji, maliyet, talep veya sürdürülebilirlik açısından sorun.
- Etkilenen kullanım
- Hesaplar, iş akışları ve dönemsel bağımlılıklar.
- Alternatifler
- Sürdürme, daraltma, yenileme veya kapatma seçenekleri.
- Geçiş yolu
- Yeni çözüm, veri taşıma, test ve eğitim.
- Ayrı tarihler
- Satışın, yeni erişimin, desteğin ve kullanımın kapanışı.
- Hazır olma koşulları
- Kritik testler, geçiş durumu ve kabul sınırları.
- İstisna yönetimi
- Onay sahibi, süre ve çıkış koşulu.
- İletişim
- Teknik sorumlu, ticari sorumlu ve müşteriye verilecek bilgi.
- Sonuç ölçümü
- Eski kullanım, hatalar, destek yükü ve müşteri etkisi.
Önce bir bağımlılık envanteri çıkarın. Ardından kapatma kararını geçiş maliyetiyle birlikte değerlendirin. Planı müşterinin hangi adımı ne zaman atacağını anlayacağı biçimde yazın. Son karar toplantısında yalnızca takvimi değil, hazır olma kanıtını da inceleyin.
İlgili terimler
Product Strategy, Product Portfolio, Product Roadmap, Deprecation, End of Support, Migration, Technical Debt, Dependency Management, Customer Success, Change Management, Retention