İnşa Etmek ve Diğerleri

Son iki yılda 31.832 kişi Whatnot'ta Ürün Müdürü olmak için başvurdu. Bir kişiyi işe aldık. Sadece başvurarak iş bulduğunuz bir işe girmektense, delikten bir vuruş yapma ihtimaliniz iki kat daha fazla.

Bu bir süreç hatası değil. On yılı aşkın süredir ürünler – ve ürün ekipleri – inşa ediyorum ve en büyük etkenlerden biri, yaklaşık 3 yıl önce Whatnot'a gelmeye karar vermemdeki en büyük etkenlerden biri, çok bilinçli bir şekilde oluşturulmuş ürün kültürüydü. Yapay zeka dünyasında PM olmanın ne anlama geldiğini kimse bilmiyor, ancak gördüğüm her şey, sektörün bize ve burada nasıl inşa ettiğimize doğru ilerlediğini gösteriyor – çünkü doğru işi yapmıyorsanız hiçbir araç sizi faydalı kılmaz.

Öncelikle şunu kabul etmeliyiz: ortalama PM'lerin çoğu vasatın da altındadır.

Ürün yönetimi işlevi ölçeğe bir yanıt olarak ortaya çıktı – mühendislik ekipleri CEO'ların veya Genel Müdürlerin doğrudan yönetemeyeceği kadar büyüdü, bu yüzden iş <> teknoloji arasında bir kanala ihtiyaç duyuldu. Zamanla bu rolü tembelliğe vurup "Her Mühendislik Müdürü işe aldığınızda bir PM işe alırsınız" şeklinde genelleştirdik. Ancak Bir Mühendislik Direktörü, Mühendislik Müdürleri aracılı 30-40 kişiyi yönetirken, bir PM Direktörü sadece beş kişiyi yönetiyordu. Teşvikler dünyayı yönetir, bu yüzden bu Direktörlerin işi "Mühendislik ortağımın kadrosunu büyütmeyi haklı çıkarmak" haline geldi, böylece onlar da kendi kadrolarını büyüterek VP olabilsinler. Yavaş yavaş kıdemli PM'lerin rolü "ürünün CEO'su"su olmaktan "butonların bakıcısı" olmaya kaydı ve ürün odaklı mühendisleri de bebekleştirilmiş sipariş alıcıları haline geldi.

Sonra COVID patlak verdi ve sektör sadece dört yılda akıl almaz bir şekilde 500.000 yeni yazılım mühendisi işe aldı ve buna uygun olarak yaklaşık 80.000 yeni PM yaratıldı. Bu 80.000 PM, FAANG'deki devasa ekiplerin içine gömülmüş, herhangi bir müşteriden uzak, işin olduğu zoom toplantısından 50 katman uzakta, bir ürün okulunda "sayılarla boyama" PM'liği öğretilmiş, her şeyin işe yarıyormuş gibi görünen, kazanılmamış etkileşim büyümesi çağında.

Bunun içinden harika ürün içgüdülerine, deneyime ve azme sahip birinin çıkma olasılığı, delikten bir vuruş yapmaktan daha düşük görünüyor.

İkincisi: En iyilerimizi daha da kötüleştirdik.

İşiniz beş kişiyi denetlemek olduğunda, gününüzü sadece başkalarının işine karışarak geçirebilirsiniz. Onlar bundan hoşlanmaz ve anonim bir anketlerde "mikro yönetim" olarak etiketler, siz de geri çekilirsiniz. Peki zamanınızı nasıl geçirirsiniz? Hikayeler anlatırsınız, ekiplerinizin "başarılı" görünmesi için işleri inceleme süreçlerinden geçirir, kaynakları haklı çıkarırsınız. Ama hangi hikayeyi anlatacağınızı bilmezsiniz, bu yüzden size yapılacak işleri söylemesi için bir kullanıcı araştırma ekibi kurar, sonra da bu hikayeyi müşayı müşterilere anlatması için bir PMM işlevini oluşturursunuz. Bağlamı topladığı ve netliği yaydığı için stratejik olarak önemli hale gelen işlev, giderek daha fazla fildişi kulelerine çekildi.

Ama gerçek, sistemlerinizin veri modellerinde, satış görüşmelerinde, CX biletlerinde, analitiklerde yatıyor – tüm bunları basitleştirmek için yapılmış şık 2x2 matrislerinde değil.

Yönetim oynayarak geçirdiğiniz tüm zaman, sorunlara dair içgüdüsel anlayışınızın bayatlamasına, müşterinize dair içgüdülerinizin körelmesine ve haklı olma olasılığınızın düşmesine neden olur.

Bir işlev olarak vuruş ortalamamız düştü, çünkü hem payda büyüdü hem de bu büyüme, yedi yıl önce ürün konusunda iyi olan herkesin fiili işi fiilen yapmaktan terfi ettirilmesi (ya da kalıp siyaset oynmaya yetecek kadar zengin olması) anlamına geliyordu.

Whatnot Yolu

Whatnot ürün ekibi, en başından beri itibariyle oldukça basit bir öncül üzerine inşa edildi: Ürün yönetiminin var olmasından pişmanız. Satış ve mühendislik, biz işe alınmadan önce gayet iyi anlaşıyordu, bu yüzden mümkün olduğunca prosedürel bekçilik veya anlamsız evrak işleri olmadan doğrudan göndermeliler. Ürün bir nitelik değil, bir zanaattır. Bunu iyi yapan herkes, yaparak ve harika insanların yanında olarak öğrenmiştir.

Geçenlerde bir mülakattaydım ve birisi bana Whatnot'un Twitch ile eBay'in bir bebeği varmış gibi hissettirdiğini söyledi – kültürel olarak bundan daha yanlış olamazdı, ancak ürün kapsamı açısından makul bir karşılaştırma. İhtiyatlı bir tahmin, bu iki kuruluşun birleşik olarak 400'den fazla PM'si olduğunu söylüyor. Bizim 20 tane var. 1200'den fazla toplam çalışan için 20 PM.

PM'lerimiz Mühendislik Müdürlerine değil, sorunlara eşlenmiştir. Bu ikisi sık sık örtüşür, ancak aynı şey değildir. Moda satıcıları için yeni bir satış formatı oluşturuyorsanız, listeleme ve envanterin nasıl işlediğini yöneten Mühendislik Müdürleriyle olduğu kadar, lojistik ve ödeme Mühendislik Müdürleriyle de oldukça iç içe olacaksınız.

Birden çok yığın üzerinde çalışmak ve farklı müşteriler üzerindeki etkileri tartmak kolay değildir – iş geniş bir iş bağlamı, herhangi bir özellikteki değişikliklerin aşağı yönlü etkilerini öngörme yeteneği, bağlam değiştirme becerisi ve tek bir ortak yerine tüm bir kuruluş genelinde güven inşa etme ve harcama yeteneği gerektirir. Bu yüzden neredeyse sadece kıdemli PM'leri işe alıyoruz. Sonsuz uyum toplantılarından bıkmış ve yeniden inşa etmek için can atan PM'ler. Ya da umut verici satış veya operasyon kişilerini dönüştürüp yaparak öğrenmelerine izin veriyoruz. Her zaman kariyer ortasında L5/L6 seviyesinde bir delikten vuruş arıyoruz, ancak istatistikler onları ne sıklıkta bulduğumuz konusunda yalan söylemez.

Son olarak, herkes gönderir, ben de dahil. Her zaman bir mühendis ve tasarımcı ekibiyle doğrudan Bireysel Katkıcı olarak özellik özellikler göndermek için çalışıyorum ve her iki kurucu ortağımız da öyle. PM'lerin küçük özellikleri "vibecode" ile kodlamasının mümkün olup olmadığını test etme zamanı geldiğinde, kobay oldum. Avustralya'daki ilk satıcımızı işe alma zamanı geldiğinde, bunu kurucu ortağımız Logan yaptı. Zendesk müşteri biletlerini düşürmeye başladığında, CEO'muz Grant onların destek mühendisiyle konuşuyordu.

Bir şirket olarak her çalışanın satış yapmasını, satın almasını ve müşteri deneyimi biletlerini yapmasını zorunlu kendilerine beklentilerin altında bir not veririz. PM'ler, müşteri odaklılığa bu kadar bağlı bir şirkette liderlik edecekse, işlerin nasıl yürüdüğüne derinlemesine ve neden yürüdüğüne geniş bir şekilde hakim olmalıyız. Buna "T-şekilli olmak" diyoruz – aynı anda geniş bir bağlama ve alanınızın derinliğine sahip olmak. Derinlik ve deneyim, hızlı kararlar almanızı sağlar; bu kararların eyleme dönüşmesi için 5 katman yönetimin incelemesini beklemeklemesine gerek kalmaz.

Teknik Personel Üyeleri

Şu anda "inşa etmek" hakkında çok fazla gürültü var... Hayır, ürün gereksinim dokümanları ölmedi. Bir ÜGD, bir sorunu net bir şek düşünmek ve bunu başkalarına ifade etmek için sadece bir kaptır. İsterseniz etkileşimli hale getirin, kimsenin umrunda değil. Hayır, kötü bir ürün göndermenin maliyeti sıfıra düşmedi, hala müşterileriniz tarafından ödeniyor. Onlara 16 kat daha hızlı spagetti fırlatmak aslında bir devrim değil, sadece sinir bozucu. Ve hayır, herkes tek başına S-seviyesi Mühendis, Tasarımcı ve PM olmayacak. Birkaç kişi olacak, ancak uzmanlaşmanın aynı itici güçleri – insanların neyden hoşlandıkları ve ne iyi oldukları – çalışma şeklimizi yönlendirmeye devam edecek.

Değişen şey, Bireysel Katkıcı olmanın, bir belgeyi 5. kez mevcut bilgiçlerin tercih ettiği formata uydurmak için yeniden taslak haline getirmektense, birçok kişinin becerisi, deneyi, deneyimini ve bu dünyadaki sınırlı zamanını çok daha iyi kullanması olduğunun farkına varılmasıdır. Whatnot'taki birkaç PM yöneticidir, ancak her biri zamanının %90'ından fazlasını Bireysel Katkıcı olarak geçirir. Yöneten veya yönetmeyenler için unvanlarımızda veya ücretlerimizde bir ayrım yoktur, çünkü bunda içsel bir erdem görmüyoruz. Yapay zeka bize inanılmaz bir kaldıraç sağlıyor – geliştirme sürecindeki hemen hemen her görevde daha hızlı hareket edebiliyorum; ister bir veri bilimci gerektiren verileri anlamak, ister bir ÜGD'yi, normalde lansman haftasında ofiste uzun gecelerin konusu olacak olan her türlü Müşteri Deneyimi Standart İşletim Prosedürü dönüştürmek olsun. Satıştan haftada 100 soruyu triyaj yapacak veya son bir deneyde bıraktığımız yerelleştirme boşluklarını bulacak bir bot inşa edebilirim.

Yapay zekanın PM'ler için en yıkıcı yanı, insanları yetiştirme ve onlar aracılığıyla çalışma kaldıraç kullanmanın, bir zamanlar olduğu gibi tek kaldıracın tek kaynağı olmadığını göstermesidir. Özellikle de bu insanlar – kendi hataları olmaksızın – derinlemesine vasatsa. Ancak bu kaldıraç, yalnızca işi nasıl yapacağını hala bilen kişiler için geçerlidir.

Bu eğilimle ilgili özellikle cesaret verici olan şey, en iyi PM'leri gerçek PM işine geri çekecek olmasıdır. Müşterinin ve işin ihtiyaçlarını düşünmek ve bunu en iyi şekilde çözmek için iyi bir zevke sahip olmak. Diğer şirketlerin bir müşterisi olarak, sektörümüzün yıldızlarının yeniden inşa etmeye başlamasını görmek beni heyecanlandırıyor – bu, ürünlerini daha iyi hale getirecek. Tarihin en küçük, en yüksek kaldıraçlı PM ekibini kurmaya kafayı takmış biri olarak, yarı yıldır yol haritası incelemelerini kaytaran inanılmaz insanların serbest kalması beni heyecanlandırıyor.

Göster, Anlatma

Aşağıda, Whatnot'ta Ürün üzerinde nasıl çalıştığımıza dair sahip olduğumuz tek belgeyi (tam olarak) kopyalayacağım. Eğer bir kez olsun tanıştıysak, yazarın kim olduğunu söylemem gerekmez – biz böyle konuşur ve böyle çalışırız.

Ayrıca ekibimizde kimlerin çalıştığına da bakabilirsiniz – bugün ekipte, bir B-C serisi girişimde Ürün Direktörü olabilecek en az altı kişi var ve akşamlarını satıcılarla telefonda, bir Hex Thread'de 400 sorgu derinliğinde veya yarınki lansman için v1 iletişimlerini taslak halinde geçirecek. Bunlar, hiçbir şeyin kendi yetki alanları dışında olduğunu kabul etmemiş dört eski kurucu. Günlerini dokuz kime dokuz kutu ızgarasında nerede yaşaması gerektiğini tartışarak geçirmeyen dört eski FAANG direktörü. İnanılmaz zevke sahip, daha fazla şey denemeleri söylenen altı erken aşama PM'si, çünkü sadece yaparak öğren sadece yaparak öğreniyoruz.

En fazla 20 PM'lik eski bildirimizin kalıcı olacağından şüpheliyim – önümüzdeki fırsat o kadar büyük ki kendimizi keyfi olarak sınırlamayacağız – ancak işe aldıklarımız için çıta, sektör ve yapay zeka araçları harika Bireysel Katkıcıları kaldıraçla ödüllendirmeye devam ettikçe sadece yükselecek. Eğer siz de bu kişilerdenseniz ve yukarıda tarif ettiğim şey sizi heyecanlandırıyorsa, benimle nasıl iletişime geçeceğinizi bulursunuz.

Whatnot'ta İnşa Etmek

Harika ürünler inşa etmek zordur. Sadece sorunla ilgili doğru içgörüye sahip olmak, detayları doğru yapmak, onu doğru şekilde pazara sunmak, performansını anlamak için doğru ölçmek veya üzerinde hızlıca yineleme yapmak zorunda değilsiniz. Tüm bunları yapmak zorundasınız, yoksa işe yaramaz. Daha da kötüsü, başarısız olmak pahalıdır. Az sayıda ekibimiz ve önümüzde muazzam miktarda fırsatımız var – .300 vuruş ortalaması MLB'de oynuyorsanız harikadır, ancak hedeflerimize ulaşmak için .500'e daha yakın bir ortalamaya ihtiyacımız var. Yüksek bir ortalama olmadan, ya kısa vadede büyümeyi sınırlarız ya da iş büyümesini kadro büyümesine bağlar ve uzun vadede kendimizi sınırız.

Bu belgenin 2 bölümü vardır:

1. Felsefemiz – bu değişmeyecek
2. Süreçlerimiz – bunlar gelişecek ve mevcut durum burada tutulacak

Nasıl inşa ettiğimiz bize kaldıraç sağlar

Bir binayı oda oda inşa edemezsiniz, tüm binayı aynı anda tasarlam ve hepsini aynı anda inşa etmelisiniz. Neyse ki inşaatta çalışmıyoruz, yazılımda çalışıyoruz. Yinelemeli inşa etmek bizim süper gücümüz. Her zaman gerçek kullanıcı değeri ve sağlam bir kullanıcı deneyimi sağlayan en küçük birimi başlatırız, ancak ölçeklendirebilmemizi sağlamak için şeyleri daha ileriye taşırız.

Burada başarılı bir ürünün mutlu yolu, 7 adımı tutarlı bir şekilde izler:

1) Kullanıcılarımız ve işimiz için önemli olan bir şeydir

Kullanıcılarımız ve iş ihtiyaçlarımız için çözen en etkili şeyleri acımasızca önceliklendirin.

• Bu değeri açıkça ifade edebilmelisiniz: "Ölü satıcıların birden çok konumda depolanan ürünleri tek bir gösteridek bir gösteride satmasını sağlayın – 'gönderim yeri'ni bir gösteri alanı değil, bir ürün alanı yaparak"
• Sistemi düşün.

1. Bu ürün başlatıldığında hemen değerli mi?
2. Diğer şeyler için bir 'yapı taşı mı?

Eğer (1) doğru değilse, devam etmeyin. (1) doğruysa, zamanla nasıl (2) haline gelebileceğini çalışın.

2) İnsanların istediği bir şeydir

Onlar için bir ürün oluşturmak üzere acı noktalarını, arzularını ve davranışlarını anlayın.

• Onlar için inşa ettiğiniz kullanıcıyıyı ayrıntılı olarak anlamadıkça. Nitel ve nicel verileri birleştirin.
• Mevcut ürün iş akışı bağlamında ürünüzü düşünün.
• Kötü şeylerin üzerine katman eklemeyin.
• Sorun B sorun B'yi çözen bir iş akışını, sorun A'ya odaklandığınız için havaya uçurmayın
• Sorun gerçekse – bugün bunun etrafında nasıl çalıştırm yapıyorlar?
• Parlak nesnelere dikkat edin. Özellikle geçmişte başka bir yerde inşa ettiğiniz parlak nesnelere.

3) Müşteri ihtiyaçları, organizasyon şemalarımızla uyumlu değildir / hiçbir zaman tek bir özellikle karşılanmaz.

Yerel olarak inşa ediyorsanız, safça inşa ediyorsunuzdur.

• Kod sahipliğinden değil, eksiksiz bir müşteri deneyiminden geriye doğru çalışıyor olmalısınız. Sorunu çözün, nokta.
• Bunun tersi de doğrudur – diğer PM'ler "sizin alanınıza" girmek zorunda kalacak. Onlara yardım edin.
• Bu ilke, mümkün mümkün olan en küçük Ürün ve Tasarım ekibine sahip olmaya çalışmamızın nedenidir. Rolü dar bir şekilde tanımlanmış ne kadar çok kişi varsa, yol haritaları o kadar dar görüşlü hale gelir ve koordinasyon ve danışma için o kadar fazla zaman harcarız.

4) Sorunu çözen mümkün olan en basit çözümdür.

Kullanıcıların sevdiği hızlı ve güvenilir ürünler inşa etmenin anahtarı, gereksiz ve etkisiz işlerden kaçınmaktır

• Basit sadece hızlı inşa etmek değildir, aynı zamanda tipik olarak en başarılı olana benzer şekilde
• Sistemi düşünmek, sistemi önceden inşa etmek anlamına gelmez.
• Doğru olduğunuzu bilmeden önce ne kadar çok inşa ederseniz, yanlış olduğunuzda o kadar pahalıya mal olur.

5) Mümkün olan en küçük kitle ile doğrulandı.

Birisi kullanana kadar sadece tahmin ediyorsunuzdur.

• Kağıt veya tıklanabilir prototipleri mümkün olan en kısa sürede satıcıların ellerine verin. Personelin kendi ürününü kullanması, bir çözümü doğrulamaktan çok hataları yakalar çünkü biz müşterilerimiz değiliz.
• Pazara Giriş hareketinizi dü düşünün
• Satıcıya Yönelik Ürünler: <10 satıcıyla başlayın, Genel Kullanıma Sunuma geçmeden önce satıcı sayısına veya birkaç kategoriye göre ölçeklendirin.
• Alıcıya Yönelik Ürünler: Bir kategori veya küçük bir yüzdeyle başlayın ve sinyalle birlikte artırın.
• Ekosistem Ürünleri (her ikisine de görünür): Bir kategori veya küçük bir pazar başlayın
• Doğrulama modundaysanız, farkındalık (iç veya dış) yaratmak bir başarısızlık modudur.
• O kadar küçük ölçeklidir ki insanları gerçekten etkilemez
• Henüz işe yarayıp yaramayacağını bilmiyorsunuz – insanların zamanınızın zamanını boşa harcamayın

6) Doğrulandıktan sonra çılgınca yineleme yapıyoruz.

Müşterilere canlıya geçtikten sonra, haftalık olmasa da günlük iyileştirmeler gönderiyoruz.

• "X'i gönderdiğimizde Y'ye geçebiliriz" ifadesini duyarsanız, bu büyük bir kırmızı bayraktır.
• Bir şey olacağını bildiğimizde, geri dönüp Kategori ve Müşteri Deneyimi için çözmelisiniz
• Başlat, doğrula, ölç, yinele, yinele, yinele, yinele > sonra bir sonraki önceliğe geç.

7) Beta aşamasında duvarları delip geçiyoruz.

Bir kıvılcık almak zordur. Bir kez aldığınızda, üzerine yakıt dökmezseniz ölür.

• Hiper basit, hiper erken ürünleri başlatmanın en büyük riski, eksik olmaları ve bu nedenle gerçekten uzun vadeli faydalı olmamalarıdır. Başlattığınızda, yüksek potansiyelden yüksek etkiye geçmek için süre başlar.
• Yaratığınız değeri en üst düzeye çıkarmaya odaklanın ve her küçük şikayeti, riski veya yansımayı yönetmeyin.
• Hangi şikayetler, riskler ve yansımalar hakkında endişeleneceğinizi bulmak, her lansman için bir yargı sorunudur. Risk olmayan şeyler hakkında endişelenmek, onlar hakkında endişelenemek kadar tehlikelidir

8) Bu bir bekar – her şeyi ayırın

Bir sistemi tasarlarken, birden çok parçasını aynı anda gönderme eğilimi vardır. Bizimki gibi yeterince karmaşık karmaşık bir sistemde, birden çok ekibin bir sistemin bileşenleri üzerinde paralel olarak çalışması muhtemeldir ve bunları birlikte göndermek, tek büyük bir değişiklik yerine iki değişiklik olması nedeniyle mantıklı görünebilir. Aynı zamanda bir tuzaktır.

• Her parça bağımsız olarak uygulanabilir ve müşteriler için faydalı olduğu sürece, onları mümkün olan en kısa sürede başlatın
• Her birini daha etkili bir şekilde ölçmemize ve göreceli katkılarını anlamamızı sağlar
• Faydalı ürünleri bir başkası için beklemede bırakmak müşteriler için kötüdür

İncelemelerin ve Geri Bildirimin Rolü

Doğru şeyler üzerinde ve doğru şekilde çalışmamızı sağlamayı amaçlayan bir ürün sürecini belgeledik. Bu, görünürlük, onay ve hesap verebilirlik işlevlerini içerir. Ancak bu sürece körü körünce bağlı kalmaktan daha önemli olan şey, altta yatan felsefeyi düşünmekten daha iyi olan bir şeydir. Bu twitter dizisinde iyi ifade edilmiştir… (ciddi, devam etmeden önce okuyun)

1. Karmaşık bir sistemde, doğru cevaba ulaşmak için düşündüğünüzden çok daha fazla uyuma ihtiyacınız vardır. Çünkü bu kelime yanlış yorumlanabilir:
2. Uyum asla fikir birliği anlamına gelmez. Fikir birliği iyi karar almanın düşmanıdır.
3. Uyum, iş akışlarını birbirine bağlamak anlamına gelmez. Koordinasyon hızın düşmanıdır.
4. Uyumun turnusol testi – yazılı bir plan. Grant bir tane istiyorsa, uyumlu değiliz demektir.
5. Whatnot'ta özerklik, uygulama özerkliğidir. Hiç kimse strateji özerkliğine sahip değildir veya sahip olmayı beklememelidir. Uyum olmadan özerklik boşa harcanır.

Whatnot'ta beklentileri karşılamak için bir PM veya Tasarımcı

1. Hemen uyum gerektiren şeyleri belirler ve aktif olarak arar
2. Tartışmayı anlama ve uyum konusundaki derin anlayışları sayesinde uyumdan uygulamaya hızlıca geçer. Tartışmalarda 'evet' duymak için dinlemezler.
3. Uygulama detaylarını ekibiyle doldurabilir / uyumun ardından gelen kararları hızla kaldırabilir.

Hız Neden Önemlidir

Tüm sistemimiz, doğru şeyi gönderme hızını en üst düzeye çıkarmaya dayanır. Mutlu mutlu yolun 1-3 arası doğru şeyin ne olduğunu bulmakla, 4-7 arası ise bu şeyi doğrulama, yineleme ve ölçeklendirmeyle ilgilidir. Bunu yapıyoruz çünkü:

1) Sistemimizdeki her şey birleşir – iyi ve kötü

2025'te yaklaşık 250 iş gününde 750 deney yaptık, bu da kabaca günde kabaca 3 gönder/gönderme kararına denk geliyor. Bu kararların her birini sadece 3 takvim günü daha hızlı almanın 2 yıllık bir ufuktaki uzun vadeli etkisini simüle ederseniz, Whatnot Satıcıları için >1.1 milyar dolarlık ek kazanç anlamına gelir. Bu ürünlerin etkisi değil, sadece bu kararları kısmen daha hızlı almanın etkisi. Doğru şeyi göndermedeki her gecikme müşterilerimize zarar verir ve büyüdükçe hızın fırsat/maliyeti de artar.

2) Hız bir kez kaybedildiğinde bir daha geri gelir

İnsanlar doğal olarak sürece uyum sağlar ve güvenmeye başlar, bu nedenle dar kullanım durumları için icat edilenler bile amaçlanandan daha serbestçe uygulanır. Teşvikler, sistemin tasarlandığı etkiyi sağlamak yerine sistemi takip etmeye kayar ve organizasyonun "bilmek, ama gitmek" kas hafı kas hafızası körelir ve kaybolur. Uzun vadede inşa etme hızını yavaşlığı yavaşlatmak için önleyebileceğimiz neredeyse hiçbir tek hata iyi bir ticaret olmaz.

3) Hız, hataların/yanlışların nedeni değildir

Komiteler hataları ancak ilerlemeyi engellemenin bir yan ürünü olarak önler. Hataları gerçekten önleyen şey muhakemedir. Daha sık göndermek muhakememizi geliştirir – bir sporcu gibi tekrarlarla güçleniriz. Tekrarlar yaparken, ekipler daha fazla tekrarı ve bağlamı olanların muhakemesinden yararlanabilir – ürün liderliğinden sürekli anlık rehberlik, planlamanın en erken aşamalarında yasal ve iletişim gibi temel risk