[MUSIK SPELA] ABBY FICHTNER: Hej, jag är Abby Fichtner. De flesta människor känner mig som Hacker Chick, eftersom jag gör Hacker Chick Blogg om hur man bygger bättre teknik. Och jag är också över på Harvard Innovation Labs. Vet du Innovations Lab? OK, så det är onda roligt. Jag är hacker i bostad det, där min roll är att hjälpa eleverna att göra allt från hacka på svala sidoprojekt, alla vägen upp till start tech startups. Jag är en programmerare, så det är min bakgrund. Jag fick typ av i programmering och startups med en intressant väg. När jag var i skolan, ville jag vara managementkonsult, eftersom jag trodde att skulle vara skit. Jag vet inte om det är fortfarande en sak. Tycker eleverna fortfarande vill vara managementkonsulter? Är det anses riktigt coolt? OK, så jag tyckte det var riktigt coolt. Jag landade ett jobb med en av topp konsultverksamhet företagen direkt ur skolan. Jag var mycket upphetsad rätt upp tills jag började arbeta där, och sedan absolut hatade det. Jag tyckte inte om företaget. Jag tyckte inte om kulturen. Jag tyckte inte något om det förutom att de mycket bizarrely sätta mig i programmering, vilket var väldigt konstigt, eftersom min titel var inte programmerare. Det var inget som jag kan minns i intervjun om, du kommer att vara programmering. Jag trodde jag skulle bli konsult chefer, vad det nu betyder. Jag är fortfarande faktiskt inte säker, men det var meningsfullt för mig på den tiden. Så jag går där, och de faktiskt gav mig ett kontor, vilket var coolt, eftersom jag tror det är det enda jobb jag någonsin hade där jag hade ett kontor. Och de gav mig en dator och det stora utrustning som datorn var ansluten upp till, att så var jag skriva kod styra denna utrustning, som var riktigt snyggt. Och att en del jag faktiskt gillade. Och jag gjorde kod för NSA, som var riktigt konstigt. Det var mitt första jobb av college. Och så jag skriver denna kod. Jag är bara helt hacking, eftersom jag har ingen aning om vad Jag gör, och försöker att göra det göra saker. Och jag kommer till denna punkt där jag använder bibliotek för att kontrollera utrustningen. Och jag kan bara göra vad som finns i biblioteken, och det som jag måste göra, det finns inte någon funktion. Och jag är som, OK. Men det fanns ett stöd nummer, så jag ringer upp företaget som skapade programmet, och jag sa att jag behöver göra detta. Och de var som, Ja, du kan inte göra det. Och det var mitt första jobb ur skola och mitt första projekt, och jag bara inte känns som jag kunde bara att gå till chefen och vara like-- och han gjorde bara typ av sätta mig på min egen. Jag visste inte riktigt känns som Jag kunde gå till chefen att vara som, oh, gå berätta NSA sorry, Vi kommer inte att göra detta för dem, eftersom biblioteket inte är tillgänglig. Det verkar inte bara acceptabelt. Och så jag slags stannade upp hela natten hacka något tillsammans, och jag gjorde det att fungera. Och det var detta vridmoment för mig, där det bara klickade. Och jag insåg att detta är vad jag ville göra. Jag trodde det var det häftigaste någonsin, att jag var som jag gjorde något att skaparna av programvaran Tanken var inte ens möjligt. Och jag var kanske den första personen någonsin att göra det, eller hur? Och det var inte det stora en sak, men det var just en sådan cool idé. Och så jag lämnade den stora managementkonsultföretag, och jag gick till jobbet för startups, eftersom startups är alla om att skapa saker som ingen har någonsin skapats tidigare. Och jag tänkte att det var mest awesome sak någonsin. Så jag gjorde det för ett antal år, typ av utbyggd tekniken för startup. Och då jag liksom, som jag var säger innan, kom in i detta område där jag bara att gå runt att hjälpa hackare och tech entreprenörer som bygger nyskapande, störande produkter-- hjälpa dem att göra det och hitta sätt att göra det som de kan vara framgångsrika på marknaden. Så det är vad jag vill prata med er om idag. Så för mig, jag tycker det är en riktigt spännande tid att vara i detta utrymme just nu, beror teknik expanderar på denna otrolig takt, och det är att göra alla dessa möjligheter som finns som var aldrig tillgängliga innan. Så jag känner mig som om vi är tillbaka till det punkt, där man kan skapa saker att ingen någonsin skapat tidigare. Och speciellt, du ser på saker som 3D-utskrifter. Så folk är 3D utskrift saker som mänskliga organ eller mat. NASA har börjat 3D utskrift mat astronauter, så detta är en 3D-skrivare med deg och pizzasås och ost som dess patroner, snarare än polymerer. Och bilar. Urbee 3D tryckt världens billigaste och mest bränsleeffektiva bil, och de är på väg att köra det över hela landet på under 10 liter bränsle, vilket är ganska galet. Och naturligtvis, allt som händer med mobil, och det faktum med saker som 3D-utskrift gör skapar fysiska enheter så mycket billigare har lett till sakernas internet, vilket är den här föreställningen att hey, varför vi måste ha funktionaliteten i våra datorer och våra tabletter? Varför tar vi inte ut det av dem och faktiskt uttrycka det rakt in i enheter, där vi bryr oss om. Och så vi får saker like-- David Rose över på Media Lab skapade en paraply som berättar vädret. Och så ni kan tänka det i ett paraplyställ vid dörren. Och som den känner du gå förbi det, om det kommer att regna, det ska blinka, så du vet att ta den med dig. Eller Valor skapat en cykel som ger dig riktningar och ger dig alla dina ridning statistik. Eller Hapi skapade en gaffel som övervakar dina matvanor att hjälpa dig att äta mer hälsosamt. Och allt från själv körning bilar till tankestyrda helicopters-- [SKRATTAR NÅGOT] Även saker som vi tänkt på som mycket lågteknologiska, som att läsa nyheterna. Gannett just meddelat att de arbetar på virtuell verklighet journalistik, där du absorberar nyheterna inte genom att läsa den, men genom att faktiskt uppleva det och att vara en del av den. Eller andra saker som vi kanske tror av så låg-tech, som trädgårdsarbete, eftersom du måste varva. För jag vet inte om er, men jag skulle hitta leva nyheter är mycket stressande. [Skrattar] Ett team av MIT, Grove, har skapat en producerar apparat som faktiskt kan du sätta in ditt kök för att odla frukt och grönsaker. Och så det är riktigt cool titta på alla startups. Det är bara denna fantastiska antal startups som är ute dessa dagar som försöker ta Fördelen med dessa tekniker. Och vad som verkligen interesting-- bara tittar på alla dessa saker som är kommer upp, men insåg endast en mycket liten andel av dessa startups är faktiskt går att göra det in i framtiden, och typ av förstå varför vissa av dem gör det och vissa av dem inte. Så jag höll ett föredrag förra månaden vid en mekanisk konferens, och jag ville prata med dem om detta ämne. Och jag tänkte att de är ingenjörer. De vill regler. Precis, jag är ingenjör. Jag gillar regler. Det är mycket trevligt och snyggt, eller hur? Så jag försökte komma upp med reglerna för innovation. Och så fort jag gjorde det, jag insåg att är ganska dumt. Den första regeln för innovation är att Det finns inga regler för innovation. För om du gör det rätt, då är du bryta fler regler än din följande. Och naturligtvis, Thomas Edison ökänt sade att "jag har inte misslyckats. Jag har precis hittat 10.000 sätt som inte fungerar. " Och så, naturligtvis, desto mer innovativt att du är, du behöver sorts förvänta sig att du ska att hitta fler sätt som inte fungerar. Men den goda nyheten är att det är inte en fullständig svart hål. När man tittar på startups som har varit framgångsrika, innovatör som har byggt dessa produkter som har varit framgångsrika i marknader, vad du ser är gång på gång, samma mönster framväxande av de saker att de gör. Och en hel del av dessa, när du slags gräva ner i dem, de är typ av bygger på en hel del principerna bakom Lean och Agile-- och folk bara ta dem och sade: Hur kan dessa vara meningsfullt för en start? Så jag vill gå igenom dessa. För att vara ärlig, jag tror att jag skulle vilja spendera ungefär hälften tiden på denna sista en-- detta "Fokus! Och få skit gjort. " Eftersom riktigt, det är vad det handlar om. Men jag tror att den första fyra är verkligen viktigt att förstå sammanhanget och tänkesätt som du behöver att ingå när du gör något riktigt innovativt att har inte gjorts tidigare. Så den första principen är att eliminera slöseri, som, om du vet något om Lean principer, det är en av de viktigaste principer för Lean. Och, faktiskt, Eric Ries, som är skaparen av Lean startup metodik, säger nummer ett Det viktigaste för en start är att lära sig se skillnad mellan värde och waste-- vilket är ganska konstigt, eller hur? Liksom hur kunde du inte veta vad är värde och vad är avfall? Men jag tror att det är mer förnuftigt om du tycker om rötter Lean. Så Lean kommer från Lean manufacturing Toyota Production System i Japan. Och "avfall" är en översättning från Uttrycket "muda", som är faktiskt bredare. Så egentligen, vad du vill att göra elimineras muda. Och muda innebär inte bara något som är improduktiva, men allt som inte är addera värde idag. Eftersom speciellt när du gör något så osäker som gör en start, skapa något innovativt, om du tror att du är kommer detta sätt och du börja bygga något för detta, och då du ta reda på vad som verkligen pågår på och du går på detta sätt, då allt du gjorde över här är slöseri, eller hur? Och så i Agile, vi har ett uttryck som heter YAGNI, vilket är "Du Är inte går att behöva det. " [Småskrattar] Så det är en riktigt bra sak att komma ihåg som du bygger ny teknik. Allt som du tror att du kommer att behöva, bara anta att du är inte förrän du gör. Så det är intressant att titta på exempel på startups som har gjort det och se var de kom ifrån. Så PayPal började faktiskt som en väg till balk betalningar mellan handdatorer. Men det visade sig att världen var inte redo för mobila betalningar i '99, eller hur? Vi bara just börjat att komma dit nu. Flickr började som ett massivt multiplayer online role playing game. Men det visade sig, liksom när folk spelade det, att det roligaste aspekten var dela foton. Det är lite roligt. Och sedan Instagram började som en gamified Four. Och de faktiskt byggt ut hela app och tittade på det, och gick wow, Det är alldeles för mycket som händer här. Detta är alldeles för komplicerat. Och de bara skrotas hela sak och sa, vet du vad? Vi ska bara fokusera igen på bilderna. Och det var det som var framgångsrikt för dem. Och så dessa är de som gjorde det, men när man sorts ser över hela linjen, den statistik är ganska dyster. Eftersom statistiken är att nio av tio nya produkter misslyckas, som är ganska urusla. Och som utvecklare, som människor som arbetar med teknik, Jag tror att när vi ser vid en stat som denna, Vi förstår hur svårt det är att bygga tech när du bygger något det är inte byggts tidigare. Och vi antar att dessa inte eftersom vi kan inte bygga tekniken. Men när du verkligen gräva djupt, vad happening-- dessa produkter inte misslyckas eftersom teknik fungerade inte. De misslyckas eftersom de människor som skapade dem kunde inte hitta en marknad för dem. Min favorit exempel på Detta är ett företag som heter Aktualitet Systems, som var faktiskt här i Boston. De skapade en 3D holografisk display. Det är ganska badass, eller hur? De skapar det, och de fick det att fungera, och sedan de tillbringade nästa 10 years-- så de skapade denna. Detta skulle vara imponerande att skapa idag, eller hur? De skapade detta över 10 år sedan. De tillbringade de kommande 10 åren att försöka utan framgång att hitta en marknad för det och skapa en livskraftig verksamhet ur det, och till slut var tvungen att stänga, och allt de kunde göra var att sälja utanför en licens för tekniken. Så var de framgångsrika i nyskapande? Jag menar, de fick tekniken att fungera. Det är fantastiskt. Men om du försöker att faktiskt bygga en livskraftig verksamhet ur detta, inte så mycket. Och så vad är intressant är det har varit forskning i vad är den enskilt största prediktor för start misslyckande. Gör någon av er vill gissa vad det här är? PUBLIK: Ingen marknad? ABBY FICHTNER: Nej marknaden, ja. Så något som faktiskt borde jag ha said-- något som startups göra, att om de gör den här saken, det är den största prediktorn att de är kommer att misslyckas, eller den största indikatorn. Så ingen marknad är typ av något som händer dem. Så Don [OHÖRBAR] gjorde en undersökning i detta, och vad han hittade var enda största prediktor för start misslyckande stack till den ursprungliga affärs plan-- som är ganska förvirrande, eller hur? För om du börjar på någon ny satsning, du bör försöka lista ut om du är på rätt spår eller inte. Även det terminologi, på rätt spår, innebär att du pratar enligt plan. Och så om stickning planera innebär att du kommer att misslyckas, det är mycket förvirrande. Rätt? Och så det leder oss till innovationsmönsternummer två, vilket är att du borde verkligen börja i liten skala. Och denna typ av brott vår mentala modell, Jag tror, ​​för hur människor tänker om hur startup fungera. Eftersom jag tycker vi har fått den här bilden av startups som går stor eller gå hem, baby. Rätt? Som jag har en stor vision, och bom. Jag ska gå stora, och jag är kommer att bli nästa Facebook. Men frågan är hur gör du det, eller hur? Hur du går från ingenting men en idé att gilla en miljard användare, som Facebook har? Hur skulle du även bygga ut tillräckligt med funktioner från dag ett att man kunde överklaga till en miljard användare? Och även om du ville bygga nästa Facebook morgon, hur ska man börja få människor på det? Eftersom skulle någon av er använder "nästa Facebook "om ingen du visste var på det? Förmodligen inte, eller hur? Och så vad jag läser startups as-- när du är riktigt tidigt stages-- sorts göra sökandet efter korsningen av vår stora visioner av vad vi vill åstadkomma med vad Verkligheten kan faktiskt rymma idag. Och det sätt som du gör detta är vanligen genom en serie små experiment eller små uppgifter. Så bara för att ta ett par exempel företag som har gjort det stora och hur de började, Microsoft började med att skriva en version av BASIC, vilket är ett programmeringsspråk, för Altair, som var som den första hemdator. Så jag vet inte exakt hur många Altairs gjordes, men jag gissar bara några tusen. Så det här är inte en stor marknad, eller hur? Och sedan, naturligtvis, Facebook, vilket är quintessential-- gå stor, bli nästa Facebook-- började här på Harvard, där det finns bara 20.000 elever. Så återigen, inte en stor marknad. Och så när du funderar den mentala modell för hur startups ska se ut, bör det ser mer ut så här. Du börjar med din stora vision, men sedan går små. Och du räkna ut ett sätt att dominerar en riktigt nischmarknad, och sedan kan du bygga vidare på att framgång för att gå stort. Och det finns ett par anledningar till detta. En är om vi accepterar det faktum att fastnar den ursprungliga affärsplanen är kommer att misslyckas, kommer vi att hitta 10.000 sätt som inte fungerar, vad som helst, vi kommer att göra en massa misstag. Vi kommer att ha en hel del missar. Om vi ​​försöker gå stort, ska vi använda upp all vår tid och resurser på fel sak. Och så är det mycket bättre att gå liten så vi kan experimentera snabbt. Men ännu viktigare, det är så mycket lättare att vara framgångsrik när vi går liten, eftersom allt du behöver göra är att hitta den marknaden som du vill gå after-- som verkligen nischmarknad. Och sedan bara identifiera en sak som de är verkligen döende att ha, och bygga det för dem. Och då kan du vara riktigt övertygande. Så som de Altair användare verkligen ville ett sätt att programmera sin dator. Och jag tror inte veta-- jag tror det var precis som vippströmbrytare och blinkande lampor, eller hur? Så jag vet inte hur de gjorde det. Så ger BASIC så de kunde programmera det är fantastiskt. Eller Harvard studenter ville bara en enda centraliserad studentkatalog, rätt? Och så Facebook behövde bara föreskriva att en funktion. De behövde inte bygga det ut som det är idag att verkligen få dragkraft. Så det tar oss till nummer tre, vilket är i ordning att finna att en funktion som din marknad är verkligen dö för, du måste verkligen djupt förstå dina kunder. Och jag känner mig som folk underskattar vikten av this-- speciellt idag, när det finns så många startups som finns där ute. Om du verkligen tittar på vad som är pågår i startutrymmet, du kommer att hitta 100 startups alla gör samma sak. Rätt? Och det beror på att alla kan se att tekniken är här i dag, eller hur? Men vi vill vara här. Så folk ser dessa luckor, och alla försöker att gå efter dessa luckor. Och du har alla dessa startups alla gör samma sak, och du är som, varför inte någon av dem lyckas? Det finns en lucka här. Jag tror att de som som kommer att lyckas är de som tar sig tid att verkligen förstå sina kunder. Ett bra exempel på detta, Jag tror, ​​är Dropbox. När Drew Houston, grundare, gick att försöka samla in pengar till Dropbox, VC verkligen avskräckt honom. De är liknande, jag förstår inte varför du ens in detta utrymme. Det finns redan som en miljon miljarder moln lagring startups ute. Och Drew var som, ja, men använder du någon av dem? Och de var inte. Och så känner jag mig som Drew lyckades eftersom A, Han började med en liten marknad. Han försökte inte att gå efter alla. Han gick efter hardcore datanörd som har en hel del enheter, en hel av datorer, och de har detta problem med att överföra filer. Och han bara riktade dem. Och allt han behövde göra var att ge en lösning som fungerade för dem. Så återigen, jag tycker det finns en hel del myter kring startups, eftersom vi ser så många startups händer idag. Och du bara höra 20.000 fot syn på oh, gjorde de det över en natt. De var en framgång. Men myten om om du bygger det, de kommer come-- när du verkligen gräva djupt i vad som händer i dessa framgångshistorier, tid och igen, tror jag vad du hittar är grundare som gick till dessa extraordinära längder för att förstå sina kunder. Så bara för att ge ett par examples-- I vet inte om detta fortfarande är fallet, men åtminstone i början, en av grundarna av Airbnb inte äger eller hyr en bostad. Han gick bara runt och bodde i Airbnbs. Som jag vet inte ens vad som såg like-- som att leva i en resväska? Eller Ben Silverman från Pinterest är fantastiskt på detta. Han gick och personligen nått ut till de första 5.000 kunder. Han gav dem sin mobiltelefon. Han träffade dem till frukost. Jag pratade precis med deras CTO ett par veckor sedan. Och de kommer in in i nya länder nu, och han kommer ut och gör det igen. Så han är otroligt för att gå ut och individuellt tala med människor. Så, naturligtvis, som du ska ut och med dessa samtal, vad du vill göra är alltid lära av din kund om vad som kommer att vettigt och vad som kommer att bli framgångsrik. Jag känner mig som den bästa startups, de bästa innovatör, behandla innovation som om det var en vetenskap experiment-- eller i en mycket vetenskapligt sätt, jag antar att jag borde säga. Så jag är inte en vetenskapsman, utan som Jag förstår, forskare kommit fram med hypoteser, och sedan de utvecklar experiment ska godkännas eller ej sina hypoteser. Och så frågan är hur kan Vi gör det med innovation? Vi har en idé, men det är bara en idé. Om vi ​​verkligen gör något det har aldrig gjorts förut, allt vi har är gissningar. Rätt? Och så vad är några experiment som vi kan göra för att godkännas eller ej dessa idéer utan att bygga ut hela saken? Så talar är stor, och jag kan faktiskt inte betona hur strongly-- hur viktigt det är att gå ut och tala med din kunder, åtminstone inledningsvis, att förstå vem de är, vilka problem de har idag, hur de är lösa dem i dag. Men prata kan bara ta dig så långt. Rätt? Du kan inte använda prata säga, hej, jag har denna stora idé! Vill du köpa den? Eftersom de kommer att bli gillar, oh, ja naturligtvis. Det låter bra. Eftersom människor vill uppmuntra dig. De ser att du är upphetsad om något, så de kommer att säga ja. Och people-- människor är bara fruktansvärt på att förutsäga deras beteende. Och så om du frågar them-- om du säger, Jag ska till, någon gång i en framtid, släppa detta abstrakta, hypotetiska produkt, ska du ha det? De kan säga nej, men om du faktiskt sätta den framför dem, de kanske vill ha det. Och så egentligen, att göra test av förståelse Om människor kommer att vill det eller inte, du verkligen måste sätta något framför dem. Så jag gillar detta citat från Linus Torvalds, som är "Talk är billigt. Visa mig koden. " Eller om du är en start, du kanske säger, "Talk är billigt. Visa mig MVP. " Så har ni hört MVP, Minsta gångbar produkt? Det är typ av denna floskel som Jag älskar och hatar på samma gång. Eftersom jag älskar begreppet det, men det blir lite överansträngda. Men tanken är giltigt, vilket inte går att bygga ut denna produkt som händer att ta dig ett år att bygga. Istället lista ut vad är det man sak som människor dör för? Vad är den minsta sak Jag kan bygga för dem? Och lägga det framför dem, och se hur de reagerar. Så kvintessensen MVP är en landningssida. Jag är säker på att ni har sett detta. Om du försökte registrera dig för Ello eller Gmails nya inbox, och de är som oh, vi är inte redo ännu! Jag antar de är lite olika, eftersom de är redo. Men de ger dig en landningssida, och det är som, det är bara bjuda in just nu. Men ge oss din e-postadress. Höger En mängd platser kommer att göra detta innan de har även byggt ut produkten, bara för att se om det finns intresse eller inte. Så med Dropbox, drog Houston, där var komplicerad teknik bakom. Så han gick, och han tänkte ut technology-- sorts visat att ut, att det skulle fungera. Men innan han byggde ut den slutliga produkten, Han gjorde detta mock-up på sin dator, Detta tre minuter screencast video-- mycket scrappy. Sätt den på Hacker News, eftersom han visste var typ av sin publik, var de riktigt tekniska människor. Sätt upp en landningssida som just sagt, här är videon. Vi har inte lanserats ännu, men om du är intresserad, ge oss din e-postadress. Över en natt fick 75.000 registreringar, vilket är otroligt. Än idag, det skulle vara imponerande, men idag, de har liksom 300 miljoner användare, eller hur? När han postade det här, ingen visste vem Dropbox var för att de inte finns ännu. Och så det var en riktigt stark signal att han hade fått något rätt. För att ge dig lite mer omfattande av ett exempel på det, Vet ni Buffert? Det är en social media dela plats, och idén är-- Jag brukar läsa nyheter på som 2:00, eftersom jag vill inte somna. Och så jag kan läsa som 10 artiklar som är alla verkligen coolt och jag vill dela dem med människor. Men A, om jag delar dem ut på Twitter just nu, ingen är vaken på 02:00 utom för mig. Och B, om de är vaken, de är som varför är du spamming mig med 10 artiklar på en gång, eller hur? Och så vad det gör är att det är typ av en kö eller en buffert att du lägger saker på och det kommer driva dem ut ett par gånger om dagen på en mer realistisk tidsplan. Så här ser det ut idag. Det är inte så det började. Grundaren hade denna idé, och Han tyckte det var en bra idé, men han ville inte bygga det. Han ville inte sluta sitt jobb ännu tills han fick lite bekräftelse på att andra människor tyckte det var en bra idé också. Så han behövde inte ens en video. Det var en sådan enkelt koncept. Bara börja med Twitter, sätter upp en landningssida. Detta är vad vi gör. Han tweets ut. När folk klickar planer och Prissättning, bara det ger dem en "du fångat oss innan vi är redo. ", men om du är intresserad, ge oss din e-postadress. Tweets ut det. Folk åkte till platsen. De fick sin e-postadress. Han var som, OK, det är en ganska bra indikator på att det finns ett visst intresse, så jag är redo att gå vidare till nästa steg. Men jag vill inte bygga det ännu. Jag vill see-- folk är intresserade, men kan jag tjäna pengar på den? Kan jag göra det till ett företag? Så allt han gjorde sattes en mellansida när människor klickade planer och priser med tre prissättning plans-- var gratis. Två betalades. Hålls tweeting ut. Folk höll klick. De flesta människor gjorde den fria planen, men vissa människor gjorde betald planen. Han är som, vet du vad? Det räcker validation-- inte för mig kanske att sluta mitt vanliga jobb och tillbringa ett år på detta, men för mig att bara gå heads-ner och göra en riktigt enkel version av detta. Han trodde att det skulle att ta honom en dag. Teknik är svårt, så det tog honom som sju dagar. Men det var nog för honom att spendera sju dagar på den. Och mycket snabbt, började han få användare på den första versionen, trots att det var mycket minimal. Och vad som var fantastisk om det var var han kunna se hur människor verkligen använder den, och sedan sorts utvecklas Det bygger på dem med hjälp av den. Så Buffer underbara, eftersom det är en riktigt enkelt exempel. Inte alla teknik är så enkelt, men det här är typ av kvintessensen Lean startup tillvägagångssätt, eller hur? Detta är great-- du är testa det varje steg, och du bara gå tillräckligt långt att du har valideras att det är typ av värt din tid att göra. Ett annat bra sätt att få validering, naturligtvis, gör en crowdfunding kampanj som kicken, där du kan få förbeställningar. Detta gör ett mycket vettigt om du är gör något som är hårdvara. Återigen var Pebble den största Kick tills den titeln fick tas av en cooler-- gjorde ni ser detta? Som en faktisk kylare som du ta med till picknick slå ut, så de fick mer än $ 10 miljoner. [SKRATTAR NÅGOT] Men återigen, liksom Dropbox, med Kisel, var det komplex teknik. De var tvungna att göra ett proof of concept, Se till att de kunde bevisa ut att tekniken skulle kunna fungera. Men då är det dyrt att tillverka, så innan de faktiskt tillverkas, de sätter upp en Kickstarter. Och de använde den för att få förhandsbeställningar, eller hur? De sa att om vi kan få $ 100.000 i förbeställningar, det är värt det att gå framåt. De fick 10 miljoner dollar, så gör pretty good-- ganska bra validering. Så dessa idéer är alla verkligen stor, men som vi säger i startups, idéer är en dime ett dussin. Det handlar om avrättning. Så det här är min favorit delen är "Fokus! Och få skit gjort. " Så de bästa entreprenörerna kan bara ha denna galna, intensiva hyper fokus och få saker gjorda på ett fantastiskt tempo. Så jag slags gå igenom några av praxis utvecklings. Och ställa frågor om du har dem. Jag var inte helt säker på hur mycket ni visste om utvecklingsmetoder, så typ av en diskussion om vad som ser ut när du är utveckla något sådant. Så det första är att räkna ut OK, vad är det så att jag borde fokusera on-- vilket kan verkligen utmanande när du gör något nytt. Eftersom alla har allt dessa idéer och det finns så många olika riktningar du kan gå, och så många olika frågor att du har. Så steg nummer ett, figur ut vad man ska fokusera på. Många gånger, som utvecklare, som människor som funderar på teknik, vi verkligen tänker om produkterna. Vi tycker om saker typ av i detta order-- först, kan jag bygga det? Förutsatt att jag kan bygga det, då kan jag få folk att veta om det? Förutsatt att jag kan, kan Jag tjäna pengar på det? Men om vi försöker göra en lönsam verksamhet, Vi kanske vill vara tänkande av dem i motsatt ordning. Anledningen är att jag känner mig like-- och Jag gör detta själv, så jag får det. Det känns som att vi får mycket hängde upp detta "Kan jag bygga det?" fråga, för om du är en teknik person-- om du är en developer-- du verkligen tänker på det. Men sanningen är oftast, när vi komma med en idé för en start, vi kommer upp med det baserat på Jag har sett denna teknik här och denna teknik här och denna teknik här, och om jag bara kombinera dem på något nytt sätt, Jag tror det skulle vara riktigt intressant. Tja, om jag har redan sett den teknik på dessa platser, du slags känner den existerar, eller hur? Så säker, göra en del bevis på begrepp. Om det finns någon teknisk risk i det. Men för det mesta, de saker att vi kommer upp with-- om vi inte är riktigt häftigt och gör något helt nytt, i vilket fall, räkna ut om du kan bygga det. Men vanligtvis, de flesta av de startups Jag ser, du kan bygga det. Det är inte ens en fråga. Så börja tänka på är något som människor kommer att kunna betala mig för Och sedan hur ska jag nå dem? Det är verkligen svårt, speciellt om du är en teknisk person, har du ett sätt att nå ut till dessa människor och få dem att köpa din produkt? Så när du räkna ut, OK, vad är det question-- sorts alltid har i åtanke, Detta är den viktigaste frågan att jag måste köra mot, eller det viktigaste att jag måste validera. Och då du vill komma tillbaka till denna föreställning om att eliminera slöseri. Precis räkna ut som leanest, mest effektiva sättet att du kan gå om besvara den frågan. Så jag pratade om minimum gångbar produkt. Jag skulle säga komma in i denna tankesättet för minsta livskraftiga everything-- med vilket jag menar inte att du ska vara att göra ett skit jobb på saker. Jag menar hur kan du skär ut avfallet? Hur får man bara rätt till pudelns kärna och räkna ut hur att validera saker utan förgyllning, utan att göra mer än du behöver. Så bara för att ge några exempel, Jag känner mig som en början, du är försöker lista ut I har denna stora idé. Är någon ens kommer att vilja det? Så en riktigt enkelt sätt att göra det är en landning sida, som vi pratade om. Du behöver inte skriva någon kod för det. Det finns verktyg som gör det åt dig. Om du säger, OK, tänkte jag att ut. Nu vill jag jag antar that-- OK, folk verkar vilja det. Skulle de faktiskt betalar mig pengar för det? Du kan göra saker som vad Buffert gjorde med prissättningen sidan, eller ännu bättre, en kicken och få förbeställningar. Beställningar Nästa sak som jag tror att du är kommer att vilja titta på är-- OK, det verkar som folk ville ha den. Det verkar som att folk kommer att betala för det, men framför allt med appar, kommer folk faktiskt använder det? Så jag vet inte statistiken, men de är ganska urusla. Ett stort antal appar får ner och sedan aldrig använt. Och det är inte bra. Det är trevligt att du fick en många människor laddar ner det. Men om det inte används, du är inte kommer att stanna kvar för länge. När du tänker om det första versionen som du vill lägga ut there-- din minsta livskraftig product-- tänka på vad är det exakt att jag försöker testa? Och vad kan jag göra det bara siffror ut det? Jag bara typ av tog en gissning på detta. Jag vet faktiskt inte vad Buffer s första versionen såg ut exakt. Men om du tänker på Buffer-- bara på grund av denna enkla example-- du kanske tror att detta är vad de känner som sitt första minimi gångbar produkt. Jag behöver kunna skapa ett användarkonto, uppenbar, länka den till min sociala medier konton. Jag behöver lägga inlägg som tweets i min buffert. Redigera dem. Radera dem. Ställ in tiden när jag vill de att läggas upp. Självklart, de programvarubehov att automatiskt skicka till Twitter eller vad grundar sig på detta schema. Och då skulle jag kunna visa historik över mina inlägg. Det känns ganska minimal, ganska grundläggande, eller hur? Jag uppmuntrar alltid startups-- speciellt gillar, det är lätt för oss, eftersom det inte är vårt barn. Rätt? Var som, åh, Yeah oavsett Titta på det igen, och hålla säger är det ett sätt att jag kan få det avskalad ännu mer? Så vad är det vi är försöker lista ut? Om vi ​​försöker siffra reda på om de kommer att använda den, vi försöker att se om de är ens kommer att lägga något till stötfångaren? Så detta känns lite hacky, men om De har inte postat det till buffert ännu, gör du inte riktigt måste tillåta dem att redigera eller ta bort eller visa inlägg i historien. Om du kan plantera att något därute verkligen snabbt och se om folk även kan lägga inlägg till det, när du ser det, du kan mycket snabbt börja lägga på denna funktion. Men bara få något där ute. Behöver du att låta användaren att ställa en utstationering schema? Antagligen inte, om de är som mig och de är precis som, Jag vill inte att mina alla mina godsaker som går vid 02:00 på söndag kväll. Du kan säga det är de mest populära tider. Oavsett, vi ska bara att lägga upp den enligt denna. Du kan förmodligen göra det. Och då jag liksom gjort upp detta, eftersom Jag vet att de bara började med Twitter. Men självklart kan du bara plocka sociala medier nätverk som gör det mesta känna och bara börja med det. Och så nu du ned till fyra av tio. Och om du kan få något ute, en pet peeve av mina är att människor tänker och MVP betyder skit produkt. Och jag tror inte att det behöver. Jag tror att du kan få något ute som det fortfarande är användbart, men är inte guld plated-- är bara den absoluta björn minimum. Och jag antar att du måste typ av figur ut utifrån din publik vad som händer vettigt eller vad som inte är. Men många gånger du får något där ute mer minimal än du skulle think-- bara en test, hur människor använder den. Så när du bygger ut dessa funktioner, du vill tänka på vad som är den minsta rimliga processen. Och så en massa gånger när vi tänker om riktigt lätta processer, Vi tänker på agila processer. Vi tänker på lean-- det är lite bit random-- bara några vig och mager böcker som jag gillar. Så det finns stora praxis liknande från Extreme Programming och kontinuerlig integration, och refacto, som jag ska tala med en liten bit. Men saken är, när du börjar få i agila och medel praxis, Det kan mycket snabbt få överväldigande. Och det kan hamna börja verklig overkill för en start. Så saken är den att en hel del av dessa böcker talar om hur att göra Agile när du är gör en produkt för en etablerat företag. Rätt? Och du vet vem marknaden är, och du vet vad din produkt färdplan. Och de vind up-- även även om vi ska vara lätta weight-- de hamnar faktiskt vara alldeles tungvikt för vår start, eftersom start är bara arbetar vid detta helt annan nivå. Så min känsla är att när du kommer en start, du måste vara scrappy som fan. Rätt? Så till en början, det finns ingen process. Du vill hålla det så enkelt som möjligt. Och bara lägga process som är sorts just-in-time process. OK, ser vi att det finns ett problem? Låt oss lägga precis tillräckligt process att ta itu med det problemet. Vet du vad jag menar? Det är för att du inte vill att någon av oss att hålla ner dig, eller hur? Scrum är en riktigt populär process för Agile. Jag vet inte om ni är förtrogen med detta. OK, well-- [Småskrattar] Det skulle vara alldeles för overkill för en start. Så jag kommer inte att oroa sig. Så OK, om man tänker på vad som är den absolut enklaste sak som jag behöver. Tja, jag behöver nog hålla reda på vad Jag gör, särskilt om det finns mer än en person, men även om det finns en person. Vad är det jag arbetar med? Så en enkel uppgift board-- mycket lätt. Detta är vad jag vill göra. Detta är vad jag jobbar på. Detta är vad jag har gjort. Det enda problemet som jag ser när jag ser startups gör något sånt här, är att mycket snabbt, deras in-progress kolumnen tenderar att se ut som det, vilket inte är mycket helpful-- speciellt om det finns endast en person eller endast en utvecklare. Rätt? Eftersom du inte är få något gjort. Allt du gör är att gå fram och tillbaka försöker få alla dessa saker gjorda. Och så det här är ett riktigt bra exempel var bara tillräckligt process kan komma. Så Kanban är ett riktigt bra verktyg. Det kommer också från Lean manufacturing. Och tanken är att det vi vill göra är att sätta begränsningar runt hur mycket arbete vi kan handtag vid varje given tidpunkt. Och så om vi är en person, då vi kan bara arbeta med ett objekt i taget. Ursäkta. Så allt det andra grejer måste gå dit. Så vad vi gör är att vi sätter arbetet i framsteg gränser för kolumnerna. Om det finns två personer, kan det vara två. Du kan räkna ut vad känns bäst för dig. Men tanken är att hålla saker sane, så att du bara göra en sak i taget. Du kan göra det. Du kan faktiskt få det gjort. En sak att tänka på är-- om du har en ett objekt att du gör, men det post tar tre månader att skulle vara ett svårt för en start, uppenbarligen. Du måste kunna att vara flexibla och vara kunna hantera saker när de kommer på dig. Man kan inte säga att jag inte gör något för tre månader tills jag får inloggningsskärmen gjort. JAG VET INTE. Så jag råder startups till hålla detta riktigt kort, att hålla dessa uppgifter så att de passar in i en dag. Självklart, om det är mer komplext, att kan behöva vara lite längre. Men räkna ut vad som fungerar bäst för dig. Du kan prova olika längder. Men generellt, precis som en Om du exempelvis hålla alla de uppgifter så de passar inom en dag, att betyder att varje dag, du får något gjort. Och du ger värde. Och det momentum kan verkligen flytta dig framåt stället för situationen innan, där du har 500 saker som går, och ingen av dem är klar. Den andra saken, Men fortfarande ser Detta för att göra column-- jag är överväldigad att titta på det. Och så om jag var en utvecklare och jag var arbetar på A, och jag var som oh, shit. Jag har B och C och De och E och F och G och H. Blah! Kommer ner på vägen. Jag är som freaking och jag "m försöker att räkna ut hur mönstret går att rymma alla dessa saker. Och sanningen är att om vi accepterar Att vi inte faktiskt ganska vet vad produkten kommer att behöva se ut förrän vi har lagt fram av en kund, så vet vi egentligen att vi behöver alla dessa uppgifter ännu? Eller är vi typ av lurar oss själva? Så om du verkligen har alla dessa idéer, stor. Lägg dem i en anteckningsbok eller en kalkylblad eller något liknande. Men jag råder startups till hålla en work-in-progress gräns på att-göra-kolonnen. Det är ett absolut maximum, Jag skulle säga, hur mycket du kan få gjort i en eller två veckor. Så det behöver inte ens vara så många. Så att du är bara hyper-fokuserat på detta är vad jag gör, blir gjort den här veckan. Eller kanske dessa två veckor, eller hur? Och inget annat är att få i vägen, och du är bara att se till att du är få det där ute. Och särskilt som du börja lägga nya medarbetare, detta verkligen hjälper. Många människor gillar att göra detta i programvara, som du kan. Men det är ännu bättre om du alla kan vara i samma utrymme och bara sätta upp det på en vägg. Det är bara riktigt synliga, och alla kan bara se det, och se vad som är viktigast. Så OK, det är hur du är räkna ut vad du ska göra. Som du gör det, du vill tänka om vad som är den minsta livskraftiga design? Eller i Agile, vi faktiskt har något som kallas emergent design, som är samma idé. Så har ni hört talas om emergent designen innan? OK. S-- faktiskt, jag försöker att minnas where-- OK. Så tanken på en köpman designen är snarare än att komma upp med denna stora, upfront design och säger att jag är kommer att tillbringa en månad räkna ut rätt arkitektur vilka komponenter gå där och allt, låt mig bara design tillräckligt för de funktioner att jag vet att jag sätter i denna första utgåva. Och ingenting else-- eller funktioner att jag gör den här veckan, och med. Och då bara som jag behöver nya funktioner jag räkna ut design för de. Du är inte räkna ut designen förskott. Jag tror i verkligheten, det är inte det här on-off knapp eller här toggle. Jag tycker det är mer av en spektrum av var du har hösten på säkerhet för osäkerhet. Och så om en start upp, eller om du bygger något som är aldrig byggts innan, du är ganska långt över på osäkerheten kurvan här, eller hur? Och om man tänker på det i termer av verksamheten plan-- liknande, Vi pratade om det enda största prediktor för misslyckande är att hålla sig till initial affärsplan. Om du gör detta stora upfront affärsplan, och du säger att jag ska bara blint följa det och inte göra någonting. Men du bara kommer att misslyckas, eller hur? Eftersom det var för mycket osäkerhet. Och jag känner mig som den Detsamma gäller för design. Tyvärr, så istället för att göra en stor initial affärsplan, du skulle göra en mycket lätt vikt affärsmodell duk, som du kanske har hört talas om. Det är som en en-personsökare, bara få mina idéer ut. Det är inte så att du inte tänka på det alls. Det är bra att tänka på det först. Men bara få det något riktigt flexibelt ut there-- bara en sida. Och sedan, när du går, typ av visa sig att planen över tiden som du lär dig från kunder, och du kan anpassa sig till dem. Och så då samma sak gäller för design. Du kan göra en stor, öppen design, utan att inte vettigt om det finns en hel del osäkerhet. Många människor skulle hävda att det finns aldrig så mycket säkerhet i mjukvara, även om du inte gör i starten. Så du aldrig vill göra det stor av en upfront design. Men jag känner mig som den designnivå går att variera beroende på hur mycket säkerhet eller osäkerhet finns. Och så om du inte har någon freaking aning och du bara kasta ut något Det gillar en landning sida, naturligtvis, du är inte gå ta tid till arkitekten ett helt system. Det är löjligt, eller hur? Så du inte behöver någon upfront design. Många gånger, den första versionen du lägger ut av programvara för en start bara får kastas bort. Och så en massa gånger, även även om jag skulle säga detta, du kan bara typ av hacka något tillsammans. Det kommer förmodligen att kastas bort. Men återigen, använda det just-in-time idé för design också. Att OK, vet du vad? Detta är faktiskt en del dragkraft. Vissa människor är intresserade av detta. Jag kommer att lägga till några funktioner på. Nu, jag känner att jag borde vara en lite smartare om design. Så tanken är som din design, bara hålla denna YAGNI i åtanke. Du är inte går att behöva det. Inte designar för saker som inte finns ännu. Och hålla det enkelt, dum principle-- gör den enklaste sak som skulle kunna fungera. Många gånger är det intressant, eftersom som utvecklare, Vi får lära att göra dessa riktigt komplexa konstruktioner. Och vi lärt att det är bra. Men det hindrar oss från att vara flexibel, och det kan vara riktigt slösaktig om vi hamnar går i vid olika riktningar. Så Agile slags säger, gör inte det. Bara räkna ut vad det enklaste sättet, det enklaste koden som du kan sätta in här som kommer att få det att fungera. Och sedan om jag behöver lägga på Det kan jag liksom fixa den koden upp och readdress designen. Så det finns något som kallas refacto det är verkligen viktigt när du gör emergent design. Och idén med refactoring är-- sorry, jag ska backa upp lite. Så om du gör emergent design, du bara designa för framtiden att du har idag. Men det betyder inte att att du hacka. Det betyder inte att när du lägga till ytterligare en funktion, du ska bara sorts silvertejp på den. Rätt? Eftersom det kommer att ge du här stor boll av lera kod det kommer att bli omöjligt att upprätthålla. Tanken med refacto är OK, jag vet att jag behöver bara, säg, Twitter idag, så jag tänker inte göra det här stora abstraktion som säger, åh, låt mig ha denna abstraktionslager som kommer att arbeta med alla sociala medier nätverk som jag någonsin kunde möjligen tänka på det i framtiden, eftersom det tar tid. Låt mig bara-- den enklaste sak som möjligen skulle kunna arbeta är låt mig bara göra det känt med Twitter, eftersom det är allt jag behöver göra idag. Sen morgon, vi inser OK, vi gör måste göra detta arbete med Facebook. Så refacto skulle säga, låt mig återkomma designen innan jag lägger ens Facebook, och säger med tanke på att jag vet att nu behöver jag att hantera de flesta flera sociala nätverk, vad skulle den optimala designen ser ut? Låt mig Refactor koden att hantera att design, och då kan jag plugga Facebook funktionalitet i. Betyder det vettigt? Så många människor tror, ​​när de höra något liknande emergent design, att du gör mindre konstruktion eller att du bara hacka. Men sanningen är att du är faktiskt gör mer design. Det är typ av samma sak med planering, eller hur? Du faktiskt gör mer planning-- det är bara att i stället för gör det hela framsidan, du gör det kontinuerligt när du går längs. Så jag tycker det är riktigt bra att ni tar CS50, eftersom jag hör detta så många gånger en dag, kan jag inte ens berätta. Folk kommer fram till mig och de säger, Abby, jag har denna stora idé! Allt jag behöver är en utvecklare. Och jag liksom vill skjuta mig själv i huvudet när jag hör det. Eftersom denna typ av assumes-- de ska komma upp, och de ska vara som jag har idén räknat ut allt. Jag har affärsplanen. Jag har designen. Jag behöver bara en utvecklare till gå kod det för mig, eller hur? Och det är bara om man antar att de har fick alla svar på framsidan, och denna person kan bara gå kod det för dem, och de kommer att göra en miljon dollars-- som bara tar inte hänsyn till faktum alla osäkerheter. Så om vi slags tittar på stegen av development-- och jag ber om ursäkt. Detta är ett litet vattenfall-y. Men vad typiskt händer är att du figurerar ut OK, detta är vad jag vill koda. Du tar lite tid att utveckla den, testa den. Kvalitetssäkring testar den. Och sedan när du har fått en hel frisättning tillsammans, vilket kan ta en månad. Det gör två tre månader. Då du släpper ut det, eller hur? Men om vi säger, OK, låt oss tänka på hur gör vi maximera lärande som händer här? För om vi går bara heads-ner för tre månader eller ett år eller något och sätta lite kod ut där och det fungerar inte, då vi slags skruvad, eller hur? Så där gör lärande hända här? Några lärande sker när vi gör kraven, eftersom vi pratar med kunder, och vi försöker förstå om dem. Men verkligheten är att mest lärandet inte hända förrän vi faktiskt sätta något i sina händer och se hur de använder det. Och så vad detta innebär är att tiden, de platser att vi spenderar mest time-- som utveckling och QA eller testing-- det finns mycket lite lärande som sker. Och så om vi tittar på det här och säga hur kan vi maximera lärandet? Eller hur kan vi minska tiden det händer mellan lärande? En stor sak är kontinuerlig utbyggnad. Jag vet inte om ni har hört talas om kontinuerlig distribution. Så idén med that-- istället att säga, OK, vi ska gå. Vi har denna släpper tre månader. Vi kommer att bygga alla funktioner för det. Och då endast vid änden av frigör är vi kommer faktiskt skjut den i produktion och satte den framför användare. Tanken med kontinuerlig utbyggnad tar att till den andra ytterligheten. Så är ni bekanta med versionskontroll? Så helst, när du arbetar på din kod, varje gång du lägga till några nya funktioner, är du ska kolla det i versionskontroll. Så om du skruva något upp, kan du alltid gå tillbaka. Eller så kan du se vad som förändrats, om något är trasigt. Så idén med kontinuerlig utbyggnad är så snart du kontrollera något i versionskontroll, den pressar koden till en mellanstation server. Det kommer att köra automatiserade tester på det, se till att du inte skadar något. Om du inte bröt något, det kommer att driva det rätt ut från produktionen. Så boom. Det är i händerna på kunden. Mycket olika. Men om vi gör det här, om vi driver saker ut till kunden så snabbt som möjligt, då vi får koden i deras händer. Vi kan se hur de är arbeta med dem, och vi kan verkligen maximera lärandet. Så jag ska prata igenom detta lite mer, eftersom jag inte vet om det was-- kontinuerlig utplacering kan vara ganska extrem, eller hur? Och det kan vara ganska svårt att göra. Så folk, företag brukar slags börja med kontinuerlig integration, och de arbetar sig framåt. Så kontinuerlig integration är detta koncept som är typ av den första delen som jag pratade om. Så idén med kontinuerlig integration är har du fortfarande din release schema. Du kommer att släppa varannan vecka eller var tredje månad eller vad det är. Men varenda gång någon kontrollerar en del kod i, den gör pressa koden på en iscensättning server. Iscensättningen server ser som produktion och det driver en serie av automatiska tester på dem för att se till att ingenting gick sönder. Om något bröt, då är det kommer att låta alla veta hey, build bröts. Och alla har stopp och se till att den är fast. Så på det sättet, du alltid garanterar att allt som du checkar in är att hålla koden på en OK tillstånd. Sen när du är redo att släppa den i fraktionen, inser du allt. Kontinuerlig leverans är typ av Nästa steg i denna process, vilket är att varje gång du check-- det står samma thing-- varje gång vi kolla något i versionskontroll, det skjuter den till mellanlagringsservern. Det kör testerna på det. Men kulturen är inställd som sådan att du alltid hålla koden så att det kan vara skjuts till produktionen som helst. Så med kontinuerlig integration, du kanske har en färdplan och säga, vi bara kommer att driva det till produktion i tre månader. Rätt? Det har egentligen inte vara redo att ses av en kund. Men med det här, du säger vid varje given tidpunkt, du kan vara som yep, jag är nöjda med denna uppsättning funktioner, även om vi är bara två veckor i. Jag ska gå vidare och pressa ut den till kunden, och jag vet att det kommer att vara OK. Och så du kanske har något som växlar i din kod som säger för funktioner som bara halvfärdigt. De är faktiskt inte syns. Varför är det synligt för kunden än? Eller nåt sånt. Men du alltid se till att du inte har något det är i den här konstiga tillstånd, eftersom det kan pressa ut till produktionen som helst. Och precis när du är i, du har typ av fått alla brukade den idén att du alltid kodning så att det är redo att gå ut i produktion. Då är det inte så svårt att flytta kontinuerlig utbyggnad, vilket är att varenda gång du kontrollera något i, så länge testet gått, Det går ut till produktionen. Innebär den typen av vettigt? Så det kan fortfarande vara riktigt skrämmande koncept, är men det intressant att titta på hur Vissa företag gör det. Så Etsy gör ett riktigt bra jobb med detta. Om du är intresserad, de har fått en blogg som berättar om hur de gör kontinuerliga driftsättning, vilket är riktigt häftigt. De distribuerar till produktion upp till 50 gånger per day-- rätt? Vilket är crazy-- kan du föreställa dig om du går till Etsy webbplats, 50 gånger i dag, är att platsen är uppdaterad bakom kulisserna. Och år 2011, utplacerade de 10.000 gånger under året med 100 ingenjörer. Och vad de sa strider mot vad du kan think-- som oh my god, det är fruktansvärt! Koden, är platsen kommer att bli en katastrof. De sa faktiskt, när du är distribution som ofta är systemet så mycket mer stabil, de faktiskt kalla det förtroende som en tjänst. För när vi distribuerar, vi har redan gjort detta 9999 gånger. Vi fick detta. Det gör det också så mycket lättare för dem att experimentera med saker. Så vad de sagt tidigare är att de används för att till produktionen varannan vecka eller varje månad. Och ni kanske tänk om du har någonsin fick en tidsfrist för en stor projekt du arbetar på, och du har denna lista över saker att du vill få gjort, och sedan som det blir närmare deadline, listan börjar krympa lite. Liksom väl, kanske jag inte verkligen behöver göra det här. Kanske jag behöver egentligen inte göra det. Så det är vad de sagt skulle hända. När de skulle komma närmare release-- och det var en så stor sak. De var tvungna att få frisläppandet ut i tid. Men de skulle börja paring bort funktioner. Och så de faktiskt gjorde mindre funktioner, eftersom de var bara släppa varannan vecka eller en månad. Nu när de är släppa så många gånger, det ger dem denna flexibilitet att säga, vet du vad? Vi vill bygga ett nytt funktion, men vi gör inte veta om vi ska lägga mycket tid i den. Låt oss spela detta verkligen lägsta version av funktionen och se om någon ens klickar på det, om någon är ens intresserad. Om de är, då kan vi antingen dra tillbaka och bygga ut det, eller vi kan mycket snabbt lägga till nya funktioner till den. Och så de sa att det bara gav dem så mycket mer flexibilitet att experimentera. Och så det är verkligen intressant att se större företag gör det. Och vid en start, speciellt när det är så viktigt att lära sig vad som händer, Det kan vara riktigt effektiva. Och sedan kommer tillbaka till vår Kanban ombord. Det är intressant. Många gånger, när folk gör en styrelse som denna, det finns en hel del debatt om vad Klar kolumnen betyder. Så OK, jag arbetar på en uppgift. Är det gjort när dess kod slutföra? Är det gjort när någon granskas det och det känns som det är testat? Är det gjort när det går ut i produktion? Och så en massa startup kommer att säga, vet du vad? Vi kommer att lägga till en ny kolumn i här, vilket är en lärande kolonn. Det är faktiskt inte gjort förrän vi har inte bara tas i produktion, Vi har lagt den i kundernas hands-- men vi har faktiskt lärt från hur de har använt det. Och vad är riktigt cool om det är då, vi får införliva det learning tillbaka in i cykeln, och säga utifrån vad vi har lärt oss, baserat på vad vi se-- hur vi ser dem använder det-- Vi kan räkna ut nästa uppsättning att göra. Så de är de mönster som jag har sett för framgångsrik innovation över startups som har varit framgångsrika. Jag tänkte också prata lite om resurser som är tillgängliga om du är intresserad av att göra en start iLab. Men jag kan också stoppa det här, om du killar har frågor om vad jag pratade. Keep going? OK. [Småskrattar] OK, så vet du om iLab? OK, awesome. Så iLab har enorma resurser. Om du är ute efter att göra en start, vi har något from-- vi gör hacknights där. Ibland gör vi hackathons, om du bara vill gå hacka på coola projekt med människor. Vi har verkstäder. Vi har klasser som åter om kredit som är typ av cool på entreprenörskap som är öppna att-- flesta av de är öppna för alla. Men vi har också gratis workshops ett par gånger i veckan, att vi bara ta in experter från industrin att prata om anything-- från tekniska begrepp, till att samla in pengar, till hur man gör försäljningen. Allt som du vill runt startups, vi har experter och invånare som finns tillgängliga för att göra en-mot-dem. Du kan bara registrera dig för kontorstid med dem. Du behöver inte ens ha en start. Bara om du har idéer och du vill balance-- få information eller insikt från en expert på samma thing-- försäljning, finansiering. Vi får juridisk hjälp. Du kan registrera dig för dem där. Vi har alltid fått grejer på gång. Så om du är intresserad, det är en riktigt stor resurs. Du kan gå till vår webbplats. Nyhetsbrevet är verkligen häftigt. Jag sorts brukar hata få e-post, men det är coolt. Vi har så mycket på gång, jag vet inte ens vad allt det är. Så om du registrerar dig för nyhetsbrevet, vi ska låta dig veta varje vecka vad som händer. Du kan även titta på vår kalender för att se vilka evenemang kommer upp. Och jag är där för att hjälpa om du vill göra en teknisk start. [Småskrattar] Så det är vad jag har. [Applåder] [Skrattar] Tack.