Şok Gerçek: Neden En İyi Mühendisler Yeniliğimizi Seçiyor?

Deneyimli mühendisler kağıt üzerinde iyi görünen bir üründen daha fazlasını ararlar. Açık spesifikasyonlara, istikrarlı kaliteye, faydalı desteğe ve küçük detayların tüm projeyi ne kadar etkileyebileceğini anlayan bir ekibe ihtiyaçları var. Bu yüzden her adımın gözden geçirilmesini ve güvenilmesini kolaylaştırmaya odaklanıyorum. Teknik detaylarla başlıyorum. Bir çözümü tartışmadan önce çalışma koşullarını, gerekli malzemeleri, boyutları, performans hedeflerini ve proje sınırlarını anlamak istiyorum. Bir ürün bir uygulamaya uyabilirken diğerinde başarısız olabilir. Net bilgiler, mühendislerin eksik verileri aramak için fazladan zaman harcamadan seçenekleri karşılaştırmasına yardımcı olur. Ürün bilgilerimiz pratik sorular etrafında düzenlenmiştir: - Hangi sorunu çözüyor? - Çalışma limitleri nelerdir? - Hangi malzemeler ve konfigürasyonlar mevcut? - Nasıl kurulmalı veya kullanılmalıdır? - Onay için hangi bilgilere ihtiyaç var? Bir mühendis bu cevapları hızlı bir şekilde bulabildiğinde tasarım süreci daha yönetilebilir hale gelir. Ayrıca iletişimi doğrudan tutuyorum. Mühendisler genellikle sıkı programlarla ve aynı anda birden fazla ekiple çalışır. Belirsiz bir yanıt, tasarım, satın alma, test etme ve üretim arasında gecikmelere neden olabilir. Belirli ayrıntılarla, faydalı belgelerle ve net bir sonraki adımla yanıt vermeyi hedefliyorum. Eğer bir cevabım yoksa tahminde bulunmak yerine söylerim ve bilgileri kontrol ederim. Bu yaklaşım kulağa basit gelebilir ancak daha sonra önlenebilir değişikliklerin önlenmesine yardımcı olur. Ürün tutarlılığı da aynı derecede önemlidir. Bir bileşen ilk incelemeyi geçebilir ancak boyut, malzeme veya kaplama bir siparişten diğerine değişirse yine de sorun yaratabilir. Kararlaştırılan spesifikasyonlara dikkat ediyorum ve iletişim kayıtlarını temiz tutuyorum, böylece aynı gereklilikler daha sonraki aşamalarda kontrol edilebilir. Yaygın bir örnek, yeni bir montaj hazırlayan bir makine üreticisidir. Tasarım ekibinin test için bir numuneye, ardından doğrulama için küçük bir partiye ihtiyacı olabilir. Bu aşamada sadece parçanın çalışıp çalışmadığını kontrol etmiyorlar. Ayrıca uygunluğu, tekrarlanabilirliği, paketlemeyi, dokümantasyonu ve yanıt süresini de kontrol ediyorlar. Bu ayrıntılar birlikte ele alındığında ekip, kendi testlerine dayanarak daha iyi bir karar verebilir. Mühendislerin bir öneriyi sorgulamak için alan istediklerini anlıyorum. Benim görevim sabit bir cevabı zorlamak değil. Mevcut seçenekler arasındaki farkları açıklayabilir, olası sınırlara işaret edebilir ve ekibin pratik bir yol seçmesine yardımcı olabilirim. Nihai seçim, satış senaryosuyla değil, projeyle eşleşmelidir. Kullanımı kolay teknik belgelere de bu yüzden değer veriyorum. Net çizimler, ürün verileri, kurulum notları ve inceleme ayrıntıları, mühendislere meslektaşlarıyla paylaşabilecekleri ve şirket içi incelemelere dahil edebilecekleri bir şeyler sağlar. Sipariş verildikten sonra destek devam etmelidir. Sorular genellikle ilk sorgulama sırasında değil, kurulum veya test sırasında ortaya çıkar. Bir ekibin açıklığa kavuşturulması gerektiğinde asıl konuya odaklanırım. Yararlı bir yanıt; bir çizim, bir ölçüm, bir kullanım notu veya kurulumun kontrol edilmesine yönelik bir öneri içerebilir. Benim görüşüm basit: Mühendisler tedarikçiyi, tedarikçi belirsizliğin azaltılmasına yardımcı olduğunda seçerler. İnceleyebilecekleri bilgilere, üzerinde anlaşmaya varılan gereksinimlerle eşleşen ürünlere ve teknik çalışmalarına saygılı iletişime ihtiyaçları var. Hizmetimi bu ihtiyaçlar etrafında oluşturuyorum, böylece mühendisler tasarımlarını geliştirmeye daha fazla, tedarik sürecindeki boşlukları gidermeye daha az zaman ayırabilirler. Güçlü bir çalışma ilişkisi net bir konuşmayla başlar. Başvuruyu, teknik gereksinimleri ve projeniz için önemli olan koşulları paylaşın. Pratik bilgiler ve doğrudan bir yaklaşımla mevcut seçenekleri gözden geçirmenize yardımcı olacağım.

Pek çok mühendislik ekibi daha iyi fikirler ister, ancak aynı sorunlar tekrarlanmaya devam eder: toplantılar çok sayıda öneri üretir, prototipler çok uzun sürer ve önemli kararlar alındıktan sonra faydalı geri bildirimler gelir. Bu modeli ürün geliştirme ekiplerinde gördüm. İnsanların becerileri eksik değildi. Bir fikri kanıta dönüştürmenin net bir yolu yoktu. Güvendiğim yaklaşım basit: Küçük bahisler yapın, bunları erken test edin ve bir sonraki hamlenizi kanıtların şekillendirmesine izin verin. Bu, üretime geçmek için acele etmek anlamına gelmez. Bu, hatalı olmanın maliyetini azaltmak anlamına gelir. ## Kullanıcının sorunuyla başlayın Güçlü bir fikir genellikle bir özellik isteğiyle değil, belirli bir sorunla başlar. Bir ekip şöyle diyebilir: > "Daha hızlı bir kontrol paneline ihtiyacımız var." Bu cümle pek çok soruyu cevapsız bırakıyor. Kime göre daha hızlı? Hangi görev sırasında? Gecikmeye ne sebep olur? Kullanıcının daha hızlı bir ekrana, daha az adıma veya daha net bilgilere mi ihtiyacı var? Ben talebi bir kullanıcı sorunu olarak yeniden yazmayı tercih ediyorum: > “Destek personeli, müşteri aramaları sırasında sipariş ayrıntılarını bulmak için çok fazla zaman harcıyor.” Bu sürüm ekibe üzerinde çalışılacak bir konu verir. Görevi izleyebilir, harcanan zamanı ölçebilir ve kafa karışıklığının nerede başladığını sorabiliriz. Yararlı bir sorun bildirimi şunları içermelidir: - Etkilenen kişi - Tamamlamaya çalıştığı görev - Karşılaştığı zorluk - İhtiyaç duyduğu sonuç Bu adım, asıl sorunu çözmeyen bir özellik üzerinde haftalarca süren çalışmayı engelleyebilir. ## Varsayımları sorulara dönüştürün Her proje varsayımlar içerir. Kullanıcıların yeni menüyü anlayacağını varsayabiliriz. Bir sensörün zorlu koşullarda çalışacağını varsayabiliriz. Daha küçük bir pilin günlük kullanım ihtiyacını karşılayacağını varsayabiliriz. Tasarım çok detaylı hale gelmeden bu varsayımları yazıyorum. Daha sonra onları riske göre sıralıyorum. Basit bir soru yardımcı olur: > "Bu fikrin başarısız olmasına ne sebep olabilir?" Bir mobil saha uygulaması için cevap zayıf ağ erişimi olabilir. Bir depo aracı için eldiven, toz veya parlak aydınlatma olabilir. Tıbbi bir cihaz için ekibin temizlik rutinlerini ve kullanım hatalarını incelemesi gerekebilir. Amaç her sorunu tahmin etmek değildir. Amaç, erken testi hak eden varsayımları bulmaktır. ## En küçük kullanışlı testi oluşturun Bir prototipin eksiksiz görünmesine gerek yoktur. Açık bir soruya cevap vermesi gerekiyor. Bir kağıt ekran düğmelerin sırasını test edebilir. Bir e-tablo bir fiyatlandırma modelini test edebilir. 3D baskılı bir kabuk kavrama ve boyutu test edebilir. Kısa bir komut dosyası, bir veri işleminin mümkün olup olmadığını test edebilir. Bir zamanlar müşterilerin raporları nasıl kullandığını kontrol etmeden önce tam bir raporlama sistemi kurmayı planlayan bir ekiple çalışmıştım. Mühendisler bunun yerine basit, tıklanabilir bir model oluşturdu. Kısa oturumlarda beş müşteri bunu inceledi. Çoğu önerilen grafiği görmezden geldi ve eksik bir filtreyi aradı. Bu küçük test, ekip büyük bir yapıya geçmeden önce ürünün yönünü değiştirdi. Yararlı bir prototip şunları içermelidir: 1. Yanıtlanacak bir soru 2. Sınırlı bir test grubu 3. Geri bildirimi kaydetmenin açık bir yolu 4. Sonuçtan çıkan bir karar Ekip, prototipin onlara ne öğreteceğini açıklayamıyorsa, prototip çok geniş olabilir. ## Eleştiriyi erkenden davet edin Çoğu tasarım incelemesi, bir çözümün kişisel olduğunu hissettirdikten sonra gerçekleşir. Bu aşamada geri bildirim bir saldırı gibi gelebilir. Fikir henüz kabayken eleştiri istediğimde daha iyi sonuçlar alıyorum. Sormak yerine: > “Bu tasarımı beğendin mi?” Soruyorum: > “Günlük kullanım sırasında bu nerede başarısız olabilir?” Bu ifade tartışmayı değiştiriyor. Mühendisler davranış, yük, bakım, güvenlik ve maliyet konularına odaklanabilirler. Lezzet konusundaki konuşmalar azalıyor. İyi bir inceleme, ürünü farklı açılardan gören kişileri içermelidir: - Kullanıcı eylemlerini inceleyen bir tasarımcı - Sistem sınırlarını anlayan bir mühendis - Şikayetleri dinleyen bir destek çalışanı - Onarımlarla ilgilenen bir teknisyen - Ürünü baskı altında kullanan bir müşteri Her kişi farklı türde bir riskin farkına varır. ## Önemli olanı ölçün Daha fazla veri her zaman daha iyi kararlara yol açmaz. Bir ekibin küçük bir takım yararlı önlemlere ihtiyacı vardır. Bir yazılım özelliği için şunları izleyebilirim: - Görev tamamlama süresi - Hata oranı - Destek taleplerinin sayısı - Tekrar kullanım - Görevi bitirmek için gereken adımlar Fiziksel bir ürün için şunlara bakabilirim: - Montaj süresi - Arıza noktaları - Malzeme israfı - Onarım çabası - Tekrarlanan kullanım sırasındaki konfor Ölçü, orijinal soruna bağlanmalıdır. Kullanıcılar bir görevi tamamlamakta zorlanırsa, daha fazla sayıda tıklama asıl amaç değildir. Daha az hata içeren daha kısa bir görev süresi bize daha fazlasını anlatabilir. Testin kanıtlayamadığı şeyleri de kaydediyorum. Kısa bir deneme, bir tasarımın anlaşılmasının kolay olduğunu gösterebilir. Altı aylık kullanımdan sonra tasarımın nasıl performans gösterdiğini göstermeyebilir. ## Küçük deneylere yer açın Her fikrin tam bir iş senaryosuyla birlikte gelmesi gerektiğinde inovasyon ortadan kaybolabilir. Pratik bir ekip, küçük testler için sınırlı zaman ve malzeme ayırabilir. Kurallar açık olmalıdır: soruyu tanımlayın, maliyeti kontrol edin, sonucu kaydedin ve test soruyu yanıtladığında durun. Bir üretim ekibi tekrarlayan bir paketleme sorununu incelemek için bu yöntemi kullandı. İki mühendis, hattın tamamını değiştirmek yerine ekipmanın yedek bir bölümünde birkaç düşük maliyetli kılavuzu test etti. Bir kılavuz, deneme sırasında ürün sıkışmalarını azalttı. Ekip daha sonra üretim kurulumunu değiştirmeden önce daha uzun bir test gerçekleştirdi. Sonuç dramatik bir icattan gelmedi. Bu, küçük bir deneye yararlı kanıtları ortaya çıkaracak kadar yer verilmesinden geldi. ## Başarısızlığı bilgi olarak değerlendirin Başarısız bir test, ekibi daha büyük bir başarısızlıktan kurtarabilir. Bu yalnızca ekip sonucun nedenini kaydettiğinde işe yarar. "Prototip işe yaramadı" ifadesi çok belirsiz. Daha iyi bir not şöyle olabilir: - Malzeme belirli bir sıcaklığın üzerinde fazla esnek hale geldi - Etiketi net olmadığı için kullanıcılar kontrolü kaçırdı - Süreç, mevcut olmayan ağ erişimine bağlıydı - Montaj, teknisyenlerin taşımadığı bir alet gerektiriyordu Bu notlar bir sonraki tasarıma yardımcı olur. Ayrıca tekrarlanan hataları da azaltırlar. Takımların zayıf sonuçları gizlemediklerinde daha hızlı hareket ettiklerini öğrendim. Açıkça başarısız olan bir test, insanlara test edilmemiş bir fikirden daha iyi bir başlangıç ​​noktası sağlar. Deneyimli mühendislerin güvendiği uygulama gizli bir formül değildir. Bu bir çalışma alışkanlığıdır: sorunu anlayın, varsayımları ortaya çıkarın, küçük bir kısmı test edin, eleştiriyi davet edin ve bir sonraki adıma rehberlik etmek için kanıtları kullanın. İyi inovasyon çoğu zaman dışarıdan sıradan görünür. Kısa bir konuşma, kaba bir prototip, dikkatli bir ölçüm veya durma kararı, kendinden emin görüşlerle dolu uzun bir toplantıdan daha iyi bir ürünü şekillendirebilir.

Cesur bir fikir, konseptten uygulamaya giden yol belirsiz olduğunda şeklini kaybedebilir. Ekiplerin güçlü bir vizyonla başladıklarını, ardından dağınık geri bildirimlerle, kaçırılan ayrıntılarla, yavaş kararlarla ve artık orijinal hedefi yansıtmayan işlerle karşılaştıklarını gördüm. İyi çalışmanın, fikrin anlaşılmasını kolaylaştırmakla başladığına inanıyorum. Neyi başarmak istediğinizi, kime hizmet etmesi gerektiğini ve önünüzde nelerin durabileceğini dinliyorum. Oradan, erken konseptin pratik adımlar, tanımlanmış öncelikler ve düşünceli değişikliklere yer veren net bir plana dönüştürülmesine yardımcı oluyorum. Süreç odaklı kalır: - Ana fikri ve amacını netleştirin - Bunu kullanacak veya deneyimleyecek kişileri belirleyin - Gerçekçi bir kapsam belirleyin - Çalışma için net bir yön oluşturun - Her aşamayı yararlı geri bildirimlerle gözden geçirin - Orijinal ruhu kaybetmeden ayrıntıları hassaslaştırın Bu yaklaşım yaygın bir sorunun önlenmesine yardımcı olur: yanlış sorunu çözen cilalı bir şey yapmak. Yeni bir çevrimiçi hizmet hazırlayan küçük bir işletme, çok çeşitli özelliklerle başlayabilir. Ekip, müşteri yolculuğunu inceledikten sonra kullanıcıların esas olarak üç basit eyleme ihtiyaç duyduğunu görebilir: hizmeti anlamak, seçenekleri karşılaştırmak ve iletişim kurmak. Fazladan adımların kaldırılması, deneyimin kullanımını ve bakımını kolaylaştırabilir. Güçlü uygulamanın değerini burada görüyorum. Cesur bir fikrin karmaşık hale gelmesine gerek yok. Net bir amaca, uygun bir yapıya ve doğru aşamalarda dikkatli kararlara ihtiyaç vardır. Orijinal hedefi merkezde tutarak her projeye kendi bakış açımı getiriyorum. Doğrudan sorular soruyorum, seçenekleri sade bir dille anlatıyorum ve mevcut zamana, bütçeye ve kaynaklara uygun çözümler arıyorum. Sonuç zorlama değil amaca yönelik hissettirmelidir. İnsanlara dikkat etmeleri için bir neden, mesajı anlamanın basit bir yolunu ve ihtiyaç duyulduğunda bir sonraki adımın net bir şekilde verilmesini sağlamalıdır. Fikriniz takip edilmesi zorlaşmadan iddialı olabilir. Doğru süreçle güçlü yönlendirme, insanların anlayacağı, kullanabileceği ve hatırlayabileceği bir işe dönüşebilir.

Büyük mühendislik çalışmaları büyük bir bütçeyle ya da çarpıcı bir fikirle başlamaz. Çoğu zaman insanların kabul etmeyi öğrendiği bir sorunla başlar. Mühendislik ekiplerinin kullanıcıyı anlamadan önce araçlara odaklandıkları için zaman kaybettiklerini gördüm. Basit bir soru sormadan özellikler ekliyor, karmaşık sistemler oluşturuyor ve çıktıyı ölçüyorlar: Bu gerçek bir ihtiyacı çözüyor mu? Mühendislik inovasyonunun güçlü bir yeri, insanlara daha iyi sorular sorma, küçük fikirleri test etme ve sonuçlardan öğrenme olanağı sağlar. ### Sorunla başlayın Bir mühendislik ekibiyle çalıştığımda, insanlardan bir ürün veya teknoloji adı vermeden sorunu açıklamalarını isterim. “Kullanıcıların daha hızlı bir kontrol paneline ihtiyacı var” bir çözüm talebidir. "Kullanıcılar bir hesap ayrıntısını bulmak için 20 dakika harcıyor" sorunu açıklıyor. İkinci açıklama takıma daha fazla seçenek sunuyor. Cevap bir kontrol paneli, bir arama özelliği, daha net bir rapor veya iş akışında bir değişiklik olabilir. Mühendisler tanıdık bir cevaba doğru acele etmek yerine sebebi keşfedebilirler. Bu yaklaşım aynı zamanda ekiplerin kullanışlı görünen ancak çok az değer katan özellikler geliştirmekten kaçınmasına da yardımcı olur. ### Mühendislere kullanıcılarla doğrudan iletişim kurun Tasarım belgeleri ve raporlar küçük ayrıntıları gizleyebilir. Bir kullanıcıyla kısa bir konuşma bunları ortaya çıkarabilir. Bir destek ekibi, müşterilerin yavaş bir sistemden hoşlanmadığını bildirebilir. Süreci izleyen bir mühendis, gecikmenin sunucu hızından değil tekrarlanan veri girişinden kaynaklandığını keşfedebilir. Küçük bir imalat projesinde de benzer bir model gördüm. Ekip, operatörlerin kafa karıştırıcı olduğunu düşündüğü için kontrol panelini değiştirmeyi planladı. Operatörleri gözlemledikten sonra mühendisler asıl sorunun etiketin kötü yerleştirilmesi olduğunu buldu. Basit bir düzen değişikliği, tüm sistemi değiştirmeden hataları azalttı. Mühendisler, yaptıkları işin günlük görevlere nasıl uyduğunu görebildikleri zaman daha iyi kararlar verirler. ### Küçük testler için alan yaratın Büyük projeler genellikle çok fazla baskı taşır. Bir ekip, başarısızlığın maliyetinin çok yüksek olduğunu düşünerek yararlı bir fikirden kaçınabilir. Küçük testler bu durumu değiştirir. Açık bir soru içeren kısa bir testi tercih ederim: - Kullanıcılar görevi daha az adımla tamamlayabilir mi? - Sistem daha büyük bir veri setini işleyebilir mi? - Yeni bir malzeme bakım çalışmalarını azaltır mı? - Basit bir komut dosyası, tekrarlanan bir manuel görevi kaldırabilir mi? Bir prototipin cilalanmasına gerek yoktur. Yararlı kanıtlar sunması gerekiyor. Ekip bir kağıt arayüzünü, küçük bir yazılım modülünü, geçici bir donanımı veya sınırlı bir üretim çalışmasını test edebilir. Her testin ölçülebilir bir sonucu ve net bir sonraki kararı olmalıdır. ### Başarısızlığı bilgi olarak değerlendirin Başarısız bir test, ekibi daha sonra daha büyük bir başarısızlıktan koruyabilir. 3M Post-it Note hikayesi tanıdık bir örnek sunuyor. Spencer Silver, şirketin beklediğinden daha zayıf bir yapıştırıcı geliştirdi. Orijinal hedefe uymuyordu ancak Art Fry adlı başka bir çalışan, çıkarılabilir notların olası bir kullanımını gördü. Ürün, ekibin malzemeye farklı bir açıdan bakmasıyla ortaya çıktı. Bu, başarısız olan her projenin ürün olacağı anlamına gelmez. Bu, mühendislerin bir testin onlara öğrettiklerini kaydetmenin bir yoluna ihtiyaç duyduğu anlamına gelir. Ekipleri şunları belgelendirmeye teşvik ediyorum: - Ne bekledik - Ne oldu - Farka ne sebep oldu - Neyi değiştireceğiz - Ne yapmayı bırakacağız Bu kayıt, insanların konuşmayı kişisel eleştiriye dönüştürmeden işi tartışmasına yardımcı olur. ### Farklı becerileri bağlayın Yararlı mühendislik fikirleri sıklıkla disiplinler arasında ortaya çıkar. Bir yazılım mühendisi, ürün ekibinin gözden kaçırdığı bir süreç sorununu fark edebilir. Bir teknisyen, tasarımı iyileştiren bir bakım değişikliği önerebilir. Bir müşteri destek uzmanı, kullanıcıların bir özellikten neden kaçındığını açıklayabilir. Paylaşılan incelemeler bu görünümler için alan yaratır. Toplantının çok kişiye ihtiyacı yok. Doğru insanlara, net bir soruya ve dinlemek için yeterli zamana ihtiyacı var. Karma ekiplerin, herkesin bir fikre, onu öneren kişiye saldırmadan meydan okuyabildiği durumlarda en iyi şekilde çalıştığını düşünüyorum. Saygılı bir anlaşmazlık, zayıf varsayımları görünür tutar. ### İnsanların hissettikleri sonucu ölçün Mühendislik ekipleri genellikle teslimat tarihlerini, sistem hızını ve kusur sayılarını takip eder. Bu önlemler önemlidir ancak değişimin tam etkisini göstermezler. Ayrıca şunlara da bakarım: - Ortak bir görev sırasında kazanılan zaman - Tekrarlanan hataların sayısı - Bakım talepleri - Yeni kullanıcılar için eğitim süresi - Enerji veya malzeme kullanımı - Düzenli kullanımdan sonra kullanıcı geri bildirimi Daha hızlı bir sistem, daha fazla kafa karışıklığı yaratıyorsa yardımcı olmayabilir. Daha ucuz bir bileşen, daha sık arızalanırsa işe yaramayabilir. İyi mühendislik, teknik performansı kullanıcı deneyimi ve işletme maliyetiyle birleştirir. ### Soruları destekleyen bir iş yeri oluşturun İnovasyon, ofis dekorasyonları veya sloganlarla değil, günlük alışkanlıklarla büyür. Mühendislerin net hedeflere, yararlı verilere erişime, test için zamana ve beklemedikleri bir yanıtı kabul edebilecek liderlere ihtiyaçları vardır. Ayrıca ürünü kullanan, tamir eden, satan ve destekleyen kişilerden de geri bildirim almaları gerekiyor. Bir mühendislik ortamını değerlendirirken sağlıklı çalışmanın işaretlerini ararım: - İnsanlar problemi sade bir dille anlatabilirler. - Ekipler büyük taahhütlerde bulunmadan önce fikirleri test eder. - Kullanıcılar ürün incelemelerine katılır. - Başarısızlık raporları öğrenmeye odaklanır. - Kararlarda rütbe yerine kanıt kullanılır. - Mühendisler işlerinin insanları nasıl etkilediğini anlarlar. Böyle bir işyeri her fikrin başarılı olacağını vaat etmez. İyi fikirlere faydalı olma şansı verir. En güçlü mühendislik ekipleri ürettikleri fikirlerin sayısına göre tanımlanmaz. Sorunları ne kadar dikkatli seçtikleri, varsayımları ne kadar açık bir şekilde test ettikleri ve kanıtları ne kadar istikrarlı bir şekilde daha iyi kararlara dönüştürdükleri ile tanımlanırlar. Sorularınızı memnuniyetle karşılıyoruz: mr.huang@foyotrobotclaw.com/WhatsApp +8613600570999.

1. Eric Ries 13 Eylül 2011 Yalın Başlangıç 2. Don Norman 2 Kasım 2013 Gündelik Şeylerin Tasarımı 3. Tim Brown 29 Eylül 2009 Tasarıma Göre Değişim 4. Clayton M Christensen 1 Ekim 1997 Yenilikçinin İkilemi 5. Peter F Drucker 19 Kasım 1985 İnovasyon ve Girişimcilik 6. Steve Blank 1 Mayıs 2013 Epifani'ye Giden Dört Adım