[Musik spiller] ABBY FICHTNER: Hej, jeg er Abby Fichtner. De fleste kender mig som Hacker Chick, fordi jeg gør det Hacker Chick Blog om hvordan man opbygger bedre teknologi. Og jeg er også over på Harvard Innovation Labs. Kender du det Innovation Lab? OK, så det er ond sjov. Jeg er hacker i bopæl der, hvor min rolle er at hjælpe eleverne med at gøre alt fra hacking på kølige sideprojekter, alle vejen op til start tech nystartede. Jeg er en programmør, så det er min baggrund. Jeg slags fik i programmeringen og nystartede ved en interessant rute. Da jeg var i skole, jeg ønskede at være en konsulent, fordi jeg troede, at ville være lort. Jeg ved ikke, om det er stadig en ting. Må eleverne stadig ønsker at være ledelseskonsulenter? Er det betragtede virkelig cool? OK, så jeg troede, det var virkelig cool. Jeg landede et job med en af topledelsen rådgivning virksomheder lige ud af skolen. Jeg var meget spændt lige op indtil jeg begyndte at arbejde der, og så absolut hadede det. Jeg kunne ikke lide det selskab. Jeg kunne ikke lide kulturen. Jeg kunne ikke lide noget om det bortset fra at de meget bizart sætte mig i programmering, som var virkelig underligt, fordi min titel var ikke programmør. Der var ikke noget, som jeg kan Husk i interviewet om, du kommer til at programmere. Jeg troede, jeg skulle være rådgivning ledere, hvad det så betyder. Jeg er stadig ikke faktisk sikker, men det gav mening for mig på det tidspunkt. Så jeg går der, og de faktisk gav mig et kontor, som var cool, fordi jeg tror, det er det eneste job, jeg nogensinde har havde hvor jeg havde et kontor. Og de gav mig en computer og denne store udstyr, som computeren var tilsluttet op til, at så jeg skrev kode styre dette udstyr, som var virkelig pæne. Og den del jeg faktisk godt lide. Og jeg gjorde kode for NSA, som var virkelig underligt. Det var mit første job ud af college. Og så jeg skriver denne kode. Jeg er bare helt hacking, fordi jeg har ingen idé om, hvad Jeg gør, og forsøger for at gøre det gøre ting. Og jeg kommer til dette punkt, hvor jeg bruger biblioteker til at kontrollere dette udstyr. Og jeg kan kun gøre hvad der er i bibliotekerne, og de ting, jeg skal gøre, Der er ikke nogen funktioner til. Og jeg er ligesom, OK. Men der var en støtte nummer, så jeg kalder op det selskab, der har oprettet softwaren, og jeg sagde, at jeg har brug for at gøre dette. Og de var ligesom, Ja, du kan ikke gøre det. Og det var mit første job ud af skole og mit første projekt, og jeg bare ikke føler, at jeg kunne bare gå til chefen og være like-- og han gjorde lige slags af sætte mig på min egen. Jeg havde ikke rigtig lyst til Jeg kunne gå til chefen at være som, åh, gå fortælle NSA sorry, Vi kommer ikke til at gøre det for dem, fordi biblioteket er ikke tilgængelig. Det bare ikke synes acceptabel. Og så jeg slags blev oppe hele nat hacking noget sammen, og jeg gjorde det arbejde. Og det var denne drejning øjeblik for mig, hvor det bare klikkede. Og jeg indså dette er hvad jeg ønskede at gøre. Jeg troede, det var de fedeste ting nogensinde, at jeg var ligesom jeg gjorde noget at skaberne af softwaren Tanken var ikke engang muligt. Og jeg var muligvis den første nogensinde, der gør det, ikke? Og det var ikke så stor en ting, men det var bare sådan en cool idé. Og så jeg forlod den store management konsulentfirma, og jeg begyndte at arbejde for nystartede, fordi opstarter er alle om at skabe ting, ingen har nogensinde skabt før. Og jeg troede, det var det mest awesome ting nogensinde. Så jeg gjorde det for en række år slags bygget teknologien til nystartede. Og så jeg slags, da jeg var siger før, kom ind i dette område hvor jeg bare at gå rundt at hjælpe hackere og tech iværksættere, der er ved at opbygge innovative, forstyrrende products-- hjælpe dem at gøre det og finde måder at gøre det, som de kan blive en succes på markedet. Så det er hvad jeg ønsker at tale med jer om i dag. Så for mig, jeg synes det er en rigtig spændende tidspunkt at være i dette rum lige nu, fordi teknologien er udvide på dette utrolig hastighed, og det gør alle disse muligheder der var aldrig tilgængelige før. Så jeg føler, at vi er tilbage til at punkt, hvor du kan oprette ting at ingen nogensinde er skabt før. Og især, du ser på ting som 3D-print. Så folk er 3D-print ting som menneskelige organer eller mad. NASA har startet 3D udskrivning fødevarer astronauter, så dette er en 3D-printer med dej og pizza sauce og ost som dets patroner, snarere end polymerer. Og biler. Urbee 3D trykt verdens billigste og mest brændstoføkonomiske bil, og de er ved at køre det over hele landet på under 10 gallons brændstof, som er temmelig vanvittigt. Og selvfølgelig alt foregår med mobil, og det faktum, med ting ligesom 3D-print gør skaber fysiske enheder så meget billigere har ført til tingenes internet, der er denne forestilling, at hey, hvorfor skal vi have funktionaliteten i vores computere og vores tabletter? Skal vi ikke tage det ud dem og faktisk sparker den helt ind i enheder, hvor vi holder af. Og så vi får ting like-- David Rose over på Media Lab skabt en paraply, der fortæller vejret. Og så du kan forestille dig det i en paraply står ved døren. Og da det registrerer du gå forbi det, hvis det kommer til at regne, vil det blinke, så du ved at tage den med dig. Eller Valour skabt en cykel, giver dig retninger og giver dig alle dine ridning statistik. Eller Hapi skabte en gaffel, der overvåger dine spisevaner at hjælpe dig med at spise mere sundt. Og alt fra selv-kørsel biler til sind-kontrollerede helicopters-- [Griner LIDT] Selv ting, som vi opfattes som meget lavteknologisk, som at læse nyheder. Gannett netop meddelt, at de arbejder på virtual reality journalistik, hvor man optager nyheden ikke ved at læse det, men ved faktisk oplever det og være en del af det. Eller andre ting, som vi måske tror af så lavteknologisk, ligesom havearbejde, fordi du har brug for at de-stress. Fordi jeg ved ikke om jer, men jeg ville finde lever nyheder bliver meget stressende. [Griner] Et team af MIT, Grove, har skabt en producere apparat der faktisk kan du sætte i din køkken til at vokse frugter og grøntsager. Og så det er virkelig cool ser på alle opstarter. Der er bare denne fantastiske antal opstarter der er ude i disse dage der forsøger at tage fordel af disse teknologier. Og hvad der virkelig interesting-- bare ser på alle disse ting, der er kommer op, men kun en meget realisere lille procentdel af disse nystartede er faktisk vil gøre det i fremtiden, og form for forståelse, hvorfor nogle af dem gøre det, og nogle af dem ikke. Så jeg gav en tale i sidste måned på en ingeniør konference, og jeg ønskede at tale med dem om dette emne. Og jeg troede, at de er ingeniører. De vil have regler. Ligesom, jeg er en ingeniør. Jeg kan lide regler. Det er meget rart og nydelige, ikke? Så jeg prøvede at komme op med reglerne for innovation. Og så snart jeg gjorde det, jeg indså, at er lidt fjollet. Den første regel for innovation er, at der er ingen regler for innovation. For hvis du gør det rigtigt, så er du bryde flere regler end din følgende. Og, selvfølgelig, Thomas Edison berømt sagde, at "jeg ikke har fejlet. Jeg har lige fundet 10.000 måder, der ikke vil arbejde. " Og så, naturligvis mere nyskabende, at du bliver, du har brug for at slags forventer, at du kommer at finde flere måder, der ikke virker. Men den gode nyhed er, at det er ikke en komplet sort hul. Når man ser på nystartede der har været en succes, innovatorer, der har bygget disse produkter, har haft succes med markeder, hvad du vil se er igen og igen, det samme mønstre spirende af de ting at de laver. Og en masse af disse, når man slags grave ned i dem, de er slags bygger på en masse principperne bag Lean og Agile-- og folk bare at tage dem og sagde: Hvordan kan disse give mening for en start? Så jeg ønsker at gå gennem disse. For at være ærlig, tror jeg jeg havde gerne bruge omkring halvdelen tiden på denne sidste en-- dette "Fokus! Og få lort gjort. " Fordi virkelig, det er hvad det kommer til stykket. Men jeg tror, ​​de første fire er virkelig vigtigt at forstå sammenhæng og tankegang, du har brug for at indgå, når du laver noget virkelig nyskabende, at er ikke blevet gjort før. Så det første princip er fjerne affald, som, hvis du ved noget om Lean-principper, det er en af ​​de vigtigste principper for Lean. Og i virkeligheden, Eric Ries, der er skaberen af ​​Lean opstart metodologi, siger nummer et vigtigste for en start er at lære at se forskel mellem værdi og waste-- som er temmelig underligt, ikke? Ligesom hvordan kunne du ikke kender hvad der er værdi, og hvad der er affald? Men jeg synes, det giver mere mening, hvis du synes om rødderne af Lean. Så Lean stammer fra Lean produktion Toyota Production System i Japan. Og "affald" er en oversættelse fra Udtrykket "Muda", som faktisk er bredere. Så virkelig, hvad du vil at gøre, er elimineret Muda. Og Muda betyder ikke bare noget, der er uproduktive, men noget, der ikke tilføje værdi i dag. Fordi især når du laver noget så usikre som gør en start, skabe noget innovativt, hvis du tror, ​​at du er går på denne måde, og du begynde at bygge noget for dette, og så skal du finde ud af, hvad der virkelig foregår på, og du går denne vej, derefter noget du gjorde i løbet af her er spild, ikke? Og så i Agile, vi har et udtryk kaldes YAGNI, som er "Du Er det ikke Gonna har brug for det. " [Griner] Så det er en rigtig god ting at huske som du bygger nye teknologier. Alt, hvad du tror at du får brug for, bare antage, at du er ikke før du gør. Så det er interessant at se på eksempler på nystartede, der har gjort det og se, hvor de kom fra. Så PayPal faktisk startede som en måde at stråle betalinger mellem PDA'er. Men det viste sig, at verden var ikke klar til mobile betalinger i '99, ikke? Vi er kun lige begyndt at få der nu. Flickr startede som et massivt multiplayer online rollespil spil. Men det viste sig, ligesom når folk spille det, at det sjoveste aspekt deling af fotos. Det er lidt sjovt. Og så Instagram startede som en gamified Foursquare. Og de faktisk bygget hele app og kiggede på det, og gik wow, Der er alt for meget foregår her. Det er alt for kompliceret. Og de bare skrottet det hele ting og sagde, ved du hvad? Vi er lige kommer til at fokusere igen på billederne. Og det var, hvad der var succes for dem. Og så det er dem, der gjorde det, men når du slags ser over hele linjen, den statistik er temmelig dystre. Fordi statistik er, at ni ud af ti nye produkter ikke, som er temmelig elendige. Og som udviklere, som folk der arbejder med teknologi, Jeg tror, ​​når vi ser ved en stat som dette, vi forstår, hvor svært det er at bygge tech når du bygger noget det er ikke blevet bygget før. Og vi antager, at disse ikke fordi vi kan ikke bygge teknologien. Men når du virkelig grave dybt, hvad happening-- disse produkter ikke ikke fordi teknologi fungerede. De er ikke, fordi de mennesker, der skabte dem ikke var i stand til at finde et marked for dem. Min favorit eksempel på dette er et firma kaldet Aktualitet Systems, som var faktisk her i Boston. De skabte en 3D holografisk display. Det er temmelig badass, ikke? De skaber det, og de fik det arbejder, og derefter de tilbragte de næste 10 years-- så de skabte dette. Dette ville være imponerende at skabe i dag, ikke? De skabte dette over 10 år siden. De tilbragte de næste 10 år på at forsøge uden held at finde et marked for det og skabe en rentabel forretning ud af det, og til sidst var nødt til at lukke ned, og alt, hvad de kunne gøre, var sælge off en licens til teknologien. Så blev de succes med at innovere? Jeg mener, de fik teknologien til at arbejde. Det er forbløffende. Men hvis du forsøger at faktisk opbygge en rentabel forretning ud af dette, ikke så meget. Og så hvad er interessant er der har været forskning i, hvad der er den største enkeltstående indikator for opstart fiasko. Er der nogen af ​​jer ønsker at gætte, hvad det er? PUBLIKUM: Ingen marked? ABBY FICHTNER: Ingen marked, ja. Så noget, der rent faktisk jeg skulle har said-- noget nystartede gør, at hvis de gør det her, det er den største prædiktor, at de er vil mislykkes, eller den største indikator. Så ikke noget marked er sortering af noget, der sker for dem. Så Don [uhørligt] gjorde en undersøgelse i dette, og hvad han fandt var single største indikator for opstart fiasko stikning til den oprindelige business plan-- som er temmelig forvirrende, ikke? For hvis du starter på en ny venture, du skal prøve at finde ud af hvis du er på rette spor eller ej. Selv den terminologi, på sporet, indebærer at du taler efter planen. Og så hvis stikning til at planlægge betyder, at du kommer til at mislykkes, det er meget forvirrende. Right? Og så bringer os til innovation mønster nummer to, som er, at man bør virkelig starte små. Og denne slags pauser vores mentale model, Jeg tror, ​​for hvordan folk tænker hvordan opstarter fungere. Fordi jeg mener, ligesom vi har fået billedet af nystartede som går stort eller gå hjem, skat. Right? Som jeg har fået en stor vision, og boom. Jeg har tænkt mig at gå store, og jeg er kommer til at være den næste Facebook. Men spørgsmålet er, hvordan gør du det, ikke? Hvordan kan du gå fra ingenting, men en idé at lide en milliard brugere, som Facebook har? Hvordan ville du selv bygge ud nok funktioner fra dag ét at man kunne appellere til en milliard brugere? Og selv hvis man ville opbygge den næste Facebook i morgen, hvordan kan du begynde få mennesker på det? Fordi ville nogen af ​​jer bruger "den næste Facebook "hvis ingen du vidste var på det? Sandsynligvis ikke, vel? Og så hvad jeg se nystartede as-- når du er virkelig tidligt stages-- slags at gøre søgningen efter skæringspunktet mellem vores store vision af, hvad vi ønsker at opnå med det, virkeligheden kan faktisk rumme dag. Og den måde, at du gør dette er normalt gennem en række små eksperimenter eller små opgaver. Så bare for at tage et par eksempler af virksomheder, der har gjort det store og hvordan de startede, Microsoft startede med at skrive en version af BASIC, som er et programmeringssprog, for Altair, som var ligesom det første hjemmecomputer. Så jeg ved ikke præcis hvor mange Altairs blev foretaget, men jeg gætte kun et par tusinde. Så det er ikke et stort marked, ikke? Og så, selvfølgelig, Facebook, som er quintessential-- gå store, blive den næste Facebook-- startede her på Harvard, hvor der er kun 20.000 studerende. Så igen, ikke et stort marked. Og så når du tænker den mentale model for, hvordan nystartede skal se, det skal se mere som denne. Du starter med din store vision, men så skal du gå lille. Og du finde ud af en måde at dominere en rigtig nichemarked, og så kan du bygge videre på at succes at gå store. Og der er et par grunde til. Den ene er, hvis vi accepterer, at stikning til den oprindelige forretningsplan s kommer til at mislykkes, vil vi finde 10.000 måder, der ikke virker, uanset hvad, vi vil lave en masse fejl. Vi kommer til at have en masse ulykker. Hvis vi forsøger at gå store, vi vil bruge al vores tid og ressourcer på de forkerte ting. Og så er det meget bedre at gå små, så vi kan eksperimentere hurtigt. Men endnu vigtigere, det er så meget nemmere at være en succes, når vi går lille, fordi alt hvad du skal gøre er at finde dette marked, som du vil gå after-- der virkelig nichemarked. Og så bare identificere den en ting, som de er virkelig døende at have, og bygge det for dem. Og så kan du være virkelig overbevisende. Så ligesom Altair brugere virkelig ønskede en måde at programmere deres computer. Og jeg tror ikke know-- jeg tror det var ligesom vippekontakter og blinkende lys, ikke? Så jeg ved ikke, hvordan de gjorde det. Så give BASIC, så de kunne programmere det er forbløffende. Eller Harvard studerende ville blot en enkelt, centraliseret student bibliotek, ret? Og så Facebook havde kun til bestemme, at en funktion. De behøvede ikke at bygge det ud som det er i dag for virkelig at få trækkraft. Så det tager os til nummer tre, der er i orden at finde, at en funktion, der dit marked er virkelig at dø for, du er nødt til virkelig dybt forstå dine kunder. Og jeg føler mig som folk undervurderer betydningen af ​​denne-- især i dag, når der er så mange nystartede, der er derude. Hvis du virkelig kigger på, hvad der er foregår i opstart rum, du vil finde 100 nystartede alle gør det samme. Right? Og det er fordi alle kan se at teknologien er her i dag, ikke? Men vi ønsker at være her. Så folk ser disse huller, og alle forsøger at gå efter disse huller. Og du har alle disse nystartede alle gør det samme, og du er ligesom, hvorfor ikke nogen af ​​dem lykkes? Der er et hul her. Jeg tror, ​​at dem, der kommer til at lykkes er dem, der tager sig tid til at rigtig forstå deres kunder. Et godt eksempel på dette, Jeg synes, er Dropbox. Da Drew Houston, grundlæggeren, gik at forsøge at skaffe penge til Dropbox, VCS virkelig afskrækket ham. De er ligesom, jeg ikke forstår hvorfor du selv indtaste denne plads. Der er allerede ligesom en million milliard Cloud opbevaring nystartede derude. Og Drew var ligesom, yeah, men bruger du nogen af ​​dem? Og de var ikke. Og så føler jeg mig som Drew lykkedes, fordi A, han startede med et lille marked. Han forsøgte ikke at gå efter alle. Han gik efter hardcore teknikere, der har en masse udstyr, en masse af computere, og de har dette problem i at overføre filer. Og han bare målrettet dem. Og alt, hvad han skulle gøre, var at give en løsning, der arbejdede for dem. Så igen, jeg føler som om der er en masse myter omkring nystartede, fordi vi ser så mange nystartede sker i dag. Og du bare høre 20.000 fod visning af åh, de gjorde det natten over. De var en succes. Men myten om, hvis du bygger det, de vil come-- når du virkelig grave dybt ind i, hvad der sker i disse succeshistorier, tid og igen, tror jeg, hvad du finder er grundlæggerne der gik til disse ekstraordinære længder til at forstå deres kunder. Så bare for at give et par examples-- I ved ikke, om dette er stadig tilfældet, men i første omgang en af de medstiftere af Airbnb ikke ejer eller leje en bolig. Han gik lige rundt og boede i Airbnbs. Ligesom jeg ved ikke engang, hvad der så like-- som at leve i en kuffert? Eller Ben Silverman fra Pinterest er forbløffende på dette. Han gik og personligt nået ud til de første 5.000 kunder. Han gav dem sin mobiltelefon. Han mødte dem til morgenmad. Jeg har lige talt med deres CTO et par uger siden. Og de kommer ind i nye lande nu, og han gå ud og gøre det igen. Så han er utroligt for at gå ud og individuelt at tale med folk. Så selvfølgelig, da du går ud og at have disse samtaler, hvad du ønsker at gøre, er altid lære af din kunde om, hvad der kommer til at give mening og hvad der kommer til at være en succes. Jeg føler mig som den bedste nystartede, de bedste innovatører, behandle innovation som om det var en videnskab experiment-- eller i et meget videnskabelig måde, jeg tror jeg skal sige. Så jeg er ikke en videnskabsmand, men som Jeg forstår, forskerne kommer op med hypoteser, og så udvikler eksperimenter til validering eller afkræfter deres hypoteser. Og så er spørgsmålet, hvordan kan vi gør det med innovation? Vi har en idé, men det er bare en idé. Hvis vi virkelig gør noget der er aldrig blevet gjort før, alt, hvad vi har, er gæt. Right? Og så hvad er nogle eksperimenter, vi kan gøre for at validere eller afkræfter disse idéer uden at opbygge ud hele ting? Så taler er stor, og jeg kan faktisk ikke understrege, hvor strongly-- hvor vigtigt det er at gå ud og tale med din kunder, i hvert fald i første omgang, at forstå, hvem de er, hvilke problemer, de har i dag, hvordan de er løse dem i dag. Men at tale kan kun tage dig så langt. Right? Du kan ikke bruge tale at sige, hey, jeg har fået denne store idé! Har du lyst til at købe det? Fordi de kommer til at være ligesom, åh, ja selvfølgelig. Det lyder godt. Fordi folk vil gerne opfordre dig. De ser, at du er begejstret noget, så de kommer til at sige ja. Og people-- mennesker er bare frygtelige til at forudsige deres adfærd. Og så hvis du spørger them-- hvis du siger, Jeg har tænkt mig at, på et tidspunkt i en fremtid, frigive denne abstrakte, hypotetiske produkt, vil du have det? De kan sige nej, men hvis du faktisk sætte det foran dem, de måske ønsker det. Og så virkelig, at gøre det test af forståelse hvis folk vil vil det eller ej, du virkelig brug for at sætte noget foran dem. Så jeg kan godt lide dette citat fra Linus Torvalds, som er "Talk er billigt. Vis mig koden. " Eller hvis du er en start, du kan sige, "Talk er billigt. Vis mig MVP. " Så har du fyre hørt MVP, Minimum levedygtigt produkt? Det er lidt det buzzword, der Jeg elsker og hader på samme tid. Fordi jeg elsker begrebet det, men det bliver lidt misbrugt. Men ideen er gyldig, der er ikke går bygge ud dette produkt, der kommer at tage dig et år at bygge. I stedet finde ud af hvad er, at man ting, at folk dør efter? Hvad er den mindste ting Jeg kan bygge for dem? Og sætte det foran dem, og se, hvordan de reagerer. Så kvintessensen MVP er en destinationsside. Jeg er sikker på jer har set dette. Hvis du har forsøgt at tilmelde dig Ello eller Gmails nye indbakke, og de er som oh, vi er ikke klar endnu! Jeg gætter de er lidt anderledes, fordi de er klar. Men de giver dig en landing page, og det er ligesom, det er kun invitere lige nu. Men giv os din e-mailadresse. Højre Mange steder vil gøre det før de har selv bygget det produkt, bare for at se, om der er interesse eller ej. Så med Dropbox, trak Houston, der var kompleks teknologi bag det. Så gik han, og han var ud teknologiforbedringer slags bevist, at ud at der skulle på arbejde. Men før han byggede ud slutproduktet, han gjorde det mock-up på sin computer, Dette tre-minutters screencast video-- meget brokket. Sæt det på Hacker News, fordi han vidste var slags sit publikum, var de virkelig tekniske folk. Udbudt en destinationsside, sagde bare, her er videoen. Vi har ikke lanceret endnu, men hvis du er interesseret, giv os din e-mailadresse. Overnight, fik 75.000 underskrive-ups, som er utroligt. Selv i dag, ville det være imponerende, men i dag, de har ligesom 300 millioner brugere, ikke? Da han indsendt dette, ingen vidste hvem Dropbox var fordi de ikke eksisterede endnu. Og så det var en virkelig stærk signal at han havde fået noget rigtigt. For at give dig en lille smule mere omfattende af et eksempel på, at tror du fyre kender buffer? Det er en social media deling websted, og tanken is-- Jeg har tendens til at læse nyheder på ligesom 2:00, fordi jeg ønsker ikke at gå på vågeblus. Og så kunne jeg læse ligesom 10 artikler, der er alle virkelig cool og jeg ønsker at dele dem med folk. Men A, hvis jeg deler dem ud på Twitter lige nu, ingen er vågen 02:00 undtagen for mig. Og B, hvis de er vågne, de er ligesom hvorfor er du spamming mig med 10 Artikler på én gang, ikke? Og så hvad det gør, er det form af en kø eller en buffer at du tilføjer ting til, og det vil skubbe dem ud et par gange om dagen på en mere realistisk tidsplan. Så dette er, hvordan det ser ud i dag. Det er ikke sådan, det begyndte. Grundlæggeren havde denne idé, og Han troede, det var en god idé, men han ønskede ikke at bygge det. Han ønskede ikke at holde op hans dag job endnu, indtil han fik nogle validering, at andre mennesker troede, det var en god idé, også. Så han havde ikke engang brug for en video. Det var sådan et simpelt koncept. Bare starte med Twitter, lægger op en destinationsside. Det er det, vi gør. Han tweets det ud. Når folk klikker Planer og Priser, det bare giver dem et "du fanget os, før vi er klar. ", men hvis du er interesseret, give os din e-mailadresse. Tweets det ud. Folk gik til webstedet. De fik deres e-mail-adresse. Han var ligesom, OK, det er en temmelig god indikator for, at der er en vis interesse, så jeg er klar til at gå videre til næste trin. Men jeg ønsker ikke at bygge det endnu. Jeg ønsker at see-- folk er interesserede, men kan jeg tjene penge ud af det? Kan jeg gøre det til en forretning? Så alt han blev tilsat en midterste side når folk klikkede Planer og Priser med tre prisfastsættelse plans-- ene var gratis. To blev betalt. Holdes twitte det ud. Folk holdt klikke. De fleste mennesker gjorde den frie plan, men nogle mennesker gjorde betalt plan. Han er ligesom, ved du hvad? Det er nok validation-- ikke for mig måske at afslutte min dag job og tilbringe et år på dette, men for mig bare gå heads-ned og gøre en meget simpel version af denne. Han troede, det ville at tage ham en dag. Teknologi hårde, så det tog ham som syv dage. Men det var nok for ham at tilbringe syv dage på det. Og meget hurtigt, begyndte han få brugere på den første version, selvom det var meget minimal. Og hvad var awesome om det var, han var i stand til at se, hvordan folk virkelig bruge det, og derefter slags udvikle det baseret på dem ved hjælp af det. Så Buffer vidunderlige, fordi det er en virkelig simpelt eksempel. Ikke alle teknologi er simpelt, men dette er sortering af indbegrebet Lean opstart tilgang, ikke? Dette er store-- du er teste det hvert skridt, og du kun vil langt nok, at du har valideret, at det er sådan af værd at bruge tid til at gøre. En anden god måde at få validering, selvfølgelig, gør et crowdfunding kampagne som Kickstarter, hvor du kan få forudbestillinger. Det gør en masse mening, hvis du er gøre noget, der er hardware. Igen var Pebble den største Kickstarter indtil denne titel fik taget af en cooler-- gjorde jer se det? Ligesom en faktisk køler, som du bringe til picnic slå ud, så de fik mere end $ 10 millioner. [Griner LIDT] Men igen, ligesom Dropbox, med Pebble, det var kompliceret teknologi. De havde at gøre en proof of concept, sørg de kunne bevise ud at teknologien kunne fungere. Men så er det dyrt at fremstille, så før de rent faktisk er fremstillet, de udbudt en Kickstarter. Og de brugte den til at få forudbestillinger, ikke? De sagde, at hvis vi kan få $ 100.000 i forudbestillinger, det er det værd at gå fremad. De fik $ 10 millioner, så gør temmelig god-- temmelig god validering. Så disse ideer er alle virkelig store, men som vi siger i nystartede, idéer er en dime et dusin. Det handler om henrettelse. Så dette er min favorit del er "Focus! Og få lort gjort. " Så de bedste iværksættere er i stand til at bare have denne vanvittige, intens hyper-fokus og få tingene gjort med en forbløffende fart. Så jeg slags går gennem nogle af udviklingsomkostningerne praksis. Og stille spørgsmål, hvis du har dem. Jeg var ikke helt sikker på, hvor meget du fyre vidste om udviklingspraksis, så slags have en diskussion om, hvad der ser ud, når du er udvikle noget som dette. Så det første er at finde ud af OK, hvad er det, at jeg skal fokusere on-- som kan virkelig udfordrende, når du laver noget nyt. Fordi alle har alle disse ideer, og der er så mange forskellige retninger, du kan gå, og så mange forskellige spørgsmål som du har. Så skridt nummer et, figur ud, hvad de skal fokusere på. En masse gange, som udviklere, som folk der tænker teknologi, vi virkelig tænker om produkterne. Vi tænker over tingene slags i denne order-- først, kan jeg bygge det? Antages det, at jeg kan bygge det, så kan jeg få folk til at vide om det? Antages det, at jeg kan, kan Jeg tjene penge på det? Men hvis vi prøver at gøre en rentabel virksomhed, vi måske ønsker at tænke af dem i den modsatte rækkefølge. Årsagen er, at jeg føler like-- og Jeg gør det selv, så jeg får det. Jeg føler, at vi får meget hang op på dette "Kan jeg bygge det?" spørgsmål, for hvis du er en teknologi person-- hvis du er en developer-- du virkelig tænker over det. Men sandheden er som regel, når vi komme med en idé til en start, vi kommer op med det baseret på Jeg har set denne teknologi her og denne teknologi her og denne teknologi her, og hvis jeg bare kombinere dem på en eller anden ny måde, Jeg tror, ​​det ville være virkelig interessant. Tja, hvis jeg har allerede set den teknologi i disse steder, du slags kender den eksisterer, ikke? Så sikker, gøre nogle bevis for begreber. Hvis der er nogle tekniske risiko derinde. Men for det meste, de ting at vi kommer op med-- medmindre vi er virkelig fantastisk og gør noget helt nyt, i hvilket tilfælde regne ud, hvis du kan bygge det. Men sædvanligvis det meste af nystartede Jeg ser, du kan bygge det. Det er ikke engang et spørgsmål. Så begynde at tænke over er noget, som folk vil være i stand til at betale mig for Og så hvordan skal jeg nå dem? Det er virkelig hårdt, især hvis du er en teknisk person, har du en måde at nå ud til disse mennesker og få dem til at købe dit produkt? Så når du regne ud, OK, hvad er det question-- slags altid have i tankerne, dette er det vigtigste spørgsmål at jeg har brug for at være kørsel i retning, eller det vigtigste at jeg skal validere. Og så du ønsker at komme tilbage til denne forestilling om at eliminere spild. Bare regne ud ligesom magreste, mest effektive måde at du kan gå om besvarelsen af ​​dette spørgsmål. Så jeg talte om minimum levedygtigt produkt. Jeg vil sige komme ind i denne tankegang for mindste levedygtige everything-- hvormed jeg mener ikke, at du skal gøre en crappy job på tingene. Jeg mener bare, hvordan kan du skære affaldet? Hvordan får du lige højre til hjertet af sagen og finde ud af at validere ting uden overregulering, uden at gøre mere, end du har brug for. Så bare for at give nogle eksempler, Jeg har lyst til at begynde med, er du forsøger at finde ud I har denne store idé. Er der nogen selv vil have det? Så en rigtig nem måde at gøre det er en landing side, ligesom vi talte om. Du behøver ikke at skrive en kode for det. Der er værktøjer, der gør det for dig. Hvis du siger, OK, jeg regnede med, at ud. Nu vil jeg Jeg antager at-- OK, folk synes at have det. Ville de faktisk betaler mig penge for det? Du kan gøre ting som det, Buffer gjorde med prisfastsættelsen siden eller endnu bedre, en Kickstarter og få forudbestillinger. Ordrer Den næste ting, jeg tror, ​​du er vil være der ønsker at se på is-- OK, det ser ud som folk ville have det. Det ser ud til folk vil betale for det, men især med apps, vil folk faktisk bruger det? Så jeg kender ikke statistik, men de er temmelig elendige. Et stort antal apps får downloades og derefter aldrig brugt. Og det er ikke nogen hjælp. Det er dejligt, at du fik en mange mennesker henter det. Men hvis det ikke er brugt, er du ikke vil holde sig omkring længe. Når du tænker om det første version at du ønsker at sætte ud there-- Deres mindste levedygtige product-- tænke på, hvad er det præcist at jeg forsøger at teste? Og hvad kan jeg gøre det bare tal, at ud? Jeg bare lidt tog et gæt på dette. Jeg ved faktisk ikke, hvad Buffer s første version lignede nøjagtigt. Men hvis du tænker over Buffer-- bare på grund af denne enkle example-- du måske tror, ​​at dette er, hvad de har lyst til som deres første minimum levedygtigt produkt. Jeg har brug for at være i stand til oprette en brugerkonto, selvfølgelig, linke det til min sociale medier konti. Jeg har brug for at tilføje stillinger som tweets i mine buffer. Redigere dem. Slet dem. Indstil det tidspunkt, hvor jeg ønsker dem, der skal bogføres. Klart, at software behov til automatisk at skrive på Twitter eller hvad bygger på samme skema. Og så skal jeg være i stand til se en historie af mit indlæg. Det føles temmelig minimal, temmelig grundlæggende, ikke? Jeg opfordrer altid startups-- kan især godt lide, det er let for os, fordi det ikke er vores baby. Right? Være ligesom, Oh, yeah uanset Kig på det igen, og holde siger er der en måde at jeg kan få det skrabet endnu mere? Så hvad er det vi er forsøger at finde ud? Hvis vi forsøger at finde ud af, om de vil bruge det, vi prøver at se, om er de selv kommer til at skrive noget til kofangeren? Så det føles lidt Hacky, men hvis de har ikke sendt den til Buffer endnu, ikke har du virkelig nødt til at give dem mulighed for at redigere eller slette eller se indlæg i historien. Hvis du kan plante, at noget derude virkelig hurtigt og se om folk selv kan tilføje posteringer til det, når du ser det, kan du meget hurtigt begynde tilføje på denne funktion. Men bare få noget derude. Har du brug for at gøre det muligt for brugeren at indstille en udstationering tidsplan? Sandsynligvis ikke, hvis de er ligesom mig og de er ligesom, Jeg vil ikke have min alle mine godbidder går ud på 02:00 søndag aften. Man kan sige, disse er de mest populære gange. Uanset hvad, vi bare at skrive det i henhold til det. Du kan sikkert gøre det. Og så jeg slags gjorde det op, fordi Jeg ved, at de kun i gang med Twitter. Men selvfølgelig kan du bare vælge de sociale medier netværk, der gør mest fornemme og bare starte med det. Og så nu er du nede til fire ud af 10. Og hvis du kan få noget derude, en pet peeve af mine er, at folk tænker og MVP betyder crappy produkt. Og jeg tror ikke, det har brug for. Jeg tror, ​​du kan få noget derude, det er stadig nyttigt, men er ikke guld plated-- er blot det absolutte bear minimum. Og jeg gætte, du skal slags figur ud baseret på dit publikum, hvad der sker at give mening, eller hvad der ikke er. Men en masse gange, du får noget derude mere minimal end du ville tror-- bare en test, hvordan folk bruger det. Så som du bygger disse funktioner, du ønsker at tænke over, hvad der er minimum levedygtig proces. Og så en masse gange, når vi tænker om virkelig letvægts processer, vi tænker agile processer. Vi tænker lean-- det er lidt bit random-- blot nogle agile og lean bøger, som jeg kan lide. Så der er store praksis gerne fra Extreme Programming og kontinuerlig integration, og refactoring, som jeg vil tale til en lille smule. Men de ting er, når du begynder at få i Agile og: praksis, det kan meget hurtigt komme overvældende. Og det kan afvikle begynde real overkill for en start. Så de ting er, at en masse af disse bøger taler om hvordan at gøre Agile, når du er gør et produkt for en etableret virksomhed. Right? Og du ved, hvem markedet er, og du ved, hvad dit produkt køreplan. Og de vind up-- selv selvom vi er formodes at være lys weight-- de ender faktisk bliver alt for sværvægter for vores opstart, fordi opstart er bare opererer ved denne helt andet niveau. Så min fornemmelse er, at når du går en start, du skal være brokket som helvede. Right? Så i første omgang, er der ingen proces. Du ønsker at holde det så enkelt som muligt. Og kun tilføje proces, der er sortering af en just-in-time proces. OK, ser vi, at der er et problem? Lad os tilføje lige nok proces at løse det problem. Ved du, hvad jeg mener? Det er fordi du ikke vil have nogen af os holder dig ned, ikke? Scrum er en rigtig populær proces til Agile udvikling. Jeg ved ikke, om du fyre er bekendt med dette. OK, well-- [Griner] Det ville være alt for overkill for en start. Så jeg vil ikke bekymre dig om det. Så OK, hvis du tænker over, hvad der er den absolut enkleste ting, som jeg har brug for. Tja, jeg har brug for at nok holde styr på, hvad Jeg gør, især hvis der er mere end én person, men selv om der er én person. Hvad arbejder jeg på? Så en simpel opgave board-- meget let. Dette er, hvad jeg ønsker at gøre. Det er det, jeg arbejder på. Det er, hvad jeg har gjort. Det eneste problem, jeg ser, når jeg ser nystartede gør noget som dette, er, at meget hurtigt, deres igangværende kolonne har tendens til at ligne det, som ikke er meget helpful-- især hvis der er kun én person eller kun én udvikler. Right? Fordi du ikke er få noget gjort. Alt du gør er gå frem og tilbage forsøger at få alle disse ting gjort. Og så dette er en rigtig godt eksempel hvor lige nok proces kan komme. Så Kanban er en virkelig fantastisk værktøj. Det kommer også fra Lean produktion. Og ideen er, at det, vi ønsker at gøre er at sætte begrænsninger omkring, hvor meget arbejde, vi kan håndtere på ethvert givet tidspunkt. Og så hvis vi er én person, så vi kan kun arbejde på ét element ad gangen. Undskyld. Så alt det andre ting skal gå derovre. Så det, vi gør, er vi sætter arbejdet i fremskridt grænser for søjlerne. Hvis der er to mennesker, kan det være to. Du kan regne ud, hvad giver mest mening for dig. Men ideen er at holde tingene sane, så du bare gør en ting ad gangen. Du er i stand til at gøre det. Du er i stand til rent faktisk at få det gjort. En ting at huske på is-- hvis du har en ét element at du laver, men det element tager tre måneder at ville være en vanskelig for en start, naturligvis. Du skal være i stand til at være fleksibel og være stand til at håndtere tingene da de kommer på dig. Du kan ikke sige, jeg ikke gør noget i tre måneder indtil jeg får login-skærmen gjort. Jeg ved det ikke. Så jeg råde nystartede til holde denne virkelig kort, at holde disse opgaver, så at de passer ind i en dag. Naturligvis, hvis det er mere kompliceret, at måske nødt til at være en lille smule længere. Men finde ud af, hvad der virker bedst for dig. Du kan prøve forskellige længder. Men generelt, ligesom en Hvis du f.eks holder alle de opgaver så de passer inden for én dag, at betyder, at hver eneste dag, du får noget gjort. Og du giver værdi. Og det momentum kan virkelig bevæge dig fremad i stedet for situationen før, hvor du har 500 ting i gang, og ingen af ​​dem er færdig. Den anden ting, Men er stadig på udkig på dette gøremål column-- jeg overvældet kigger på det. Og så hvis jeg var en udvikler, og jeg var arbejder på en, og jeg var som åh, lort. Jeg har B og C og De og E og F og G og H. Blah! Kommer ned ad vejen. Jeg er ligesom freaking ud, og jeg "m forsøger at finde ud af, hvordan design vil til at rumme alle disse ting. Og sandheden er, at hvis vi accepterer faktum, at vi faktisk ikke helt ved, hvad produktet kommer til at nødt til at se ud til vi har lagt foran af en kunde, så skal vi virkelig vide at vi har brug for alle disse opgaver endnu? Eller er vi slags narre os selv? Så hvis du virkelig har alle de ideer, stor. Læg dem i en bærbar eller en regneark eller noget lignende. Men jeg råde nystartede til holde en work-in-progress grænse på to-do-søjle, også. Det er et absolut maksimum, Jeg vil sige, hvor meget du kan få gjort i en eller to uger. Så det behøver ikke engang at være, at mange. På den måde er du bare hyper-fokuseret på dette er, hvad jeg gør, at få gjort denne uge. Eller måske disse to uger ikke? Og intet andet er at få i vejen, og du er bare at sikre, at du er få den derude. Og især da du begynder at tilføje nye teammedlemmer, det virkelig hjælper. En masse mennesker kan lide at gøre dette i software, som du kan. Men det er endnu bedre, hvis du alle kan være i det samme rum og bare sætte det op på en væg. Det er bare rigtig synlige, og alle kan bare se det, og se, hvad der er vigtigst. Så OK, det er hvordan du er regne ud, hvad de skal gøre. Som du gør det, du ønsker at tænke om, hvad der er den mindste levedygtige design? Eller i Agile, vi faktisk har noget, der hedder emergent design, som er den samme idé. Så har du fyre hørt om emergent design før? OK. S-- faktisk, jeg prøver at huske where-- OK. Så tanken om en købmand design snarere end at komme op med denne store, upfront design og siger jeg er kommer til at tilbringe en måned at regne ud den rette arkitektur hvilke komponenter gå, hvor og alt, lad mig bare designe nok for de funktioner at jeg ved, jeg sætter i denne første udgivelse. Og intet else-- eller funktionerne at jeg gør i denne uge, selv. Og så kun som jeg har brug for nye funktioner skal jeg finde ud af designet til dem. Du er ikke at finde ud af design forhånd. Jeg tror i virkeligheden, det er ikke det on-off switch eller denne toggle. Jeg synes det er mere en spektrum af hvor du har falder på visheden med usikkerhed. Og så hvis i en start up, eller hvis du bygger noget, der er aldrig blevet bygget før, du er smuk langt over på usikkerheden kurven her, ikke? Og hvis du tænker over det i Vilkår for virksomheden plan-- lignende, vi talte om det indre største indikator for fiasko er at holde sig til den oprindelige forretningsplan. Hvis du gør dette store upfront forretningsplan, og du siger jeg bare blindt følge det og ikke gøre noget. Men du bare kommer til at mislykkes, ikke? Fordi der var for meget usikkerhed. Og jeg har lyst til det samme gælder for design. Beklager, så i stedet for at gøre en stor upfront forretningsplan, du ville gøre en meget lys vægt forretningsmodel lærred, som du måske har hørt om. Det er ligesom en én-personsøger, bare at få mine ideer ud. Det er ikke, at du ikke tænker over det overhovedet. Det er godt at tænke på det i første omgang. Men bare få det noget rigtig fleksibel ud there-- blot én side. Og så, som du går, slags vise sig, at planen med tiden som du lærer fra kunder, og du kan tilpasse sig til dem. Og så så det samme er sandt for design. Du kan gøre en stor, forhånd design, men at giver ikke mening, hvis der er en masse usikkerhed. En masse mennesker vil hævde at der er aldrig så meget sikkerhed i software, selvom du ikke laver i opstart. Så du aldrig ønsker at gøre det store af en upfront design. Men jeg har lyst til det niveau af design vil at variere baseret på, hvor meget vished eller usikkerhed der er. Og så hvis du ikke har nogen freaking clue og du bare smide noget ud der kan lide en landing side, naturligvis, er du ikke kommer til at gå tage tid til arkitekt et helt system. Det er latterligt, ikke? Så du behøver ikke nogen upfront design. En masse gange, den første version du sat ud af software til en start bare bliver smidt væk. Og så en masse gange, selv selvom jeg kan sige dette, du kan bare lidt hack noget sammen. Det er sandsynligvis kommer til at blive smidt væk. Men igen, bruge det just-in-time idé til design samt. At OK, ved du hvad? Dette er faktisk nogle trækkraft. Nogle mennesker er interesseret i dette. Jeg har tænkt mig at tilføje nogle funktioner på. Nu, jeg føler, at jeg bør være en lidt smartere om design. Så ideen er så dit design, bare holde denne YAGNI i tankerne. Du er ikke Gonna har brug for det. Må ikke design for ting der ikke er der endnu. Og holde det enkelt, dum principle-- gøre den enkleste ting der kunne gøre arbejdet. En masse gange, det er interessant, fordi som udviklere, vi får lært at gøre disse virkelig komplekse designs. Og vi lærte, at det er godt. Men det forhindrer os i at være fleksibelt, og det kan være virkelig spild Hvis vi ender går i på forskellige retninger. Så Agile slags siger, skal du ikke gøre det. Bare regne ud, hvad den enkleste måde, den enkleste kode at du kan sætte ind her der kommer til at gøre det arbejde. Og så hvis jeg har brug for at tilføje på det, jeg kan slags løse denne kode op og readdress designet. Så der er noget, der hedder refactoring det er virkelig vigtigt, når du gør emergent design. Og ideen med refactoring is-- undskyld, jeg har tænkt mig at bakke lidt op. Så hvis du laver emergent design, du kun at designe for fremtiden at du har i dag. Men det betyder ikke, at du hacking. Det betyder ikke, når du tilføjer en anden funktion, du bare gå til slags gaffatape det på. Right? Fordi det kommer til at give du denne store kugle af mudder kode der kommer til at være umuligt at opretholde. Ideen med refactoring er OK, jeg kender jeg behøver blot, siger, Twitter i dag, så jeg har ikke tænkt mig at gøre dette store abstraktion, der siger, Åh, lad mig få denne abstraktionslag der vil arbejde med alle de sociale medier netværk, som jeg nogensinde kunne muligvis tænke på det i fremtiden, fordi det tager tid. Lad mig bare-- den enkleste ting, der eventuelt kunne arbejde er lad mig bare gøre det kendt med Twitter, fordi det er alt jeg har brug for at gøre i dag. Så i morgen, vi er klar OK, vi gør nødt til at gøre dette arbejde med Facebook. Så refactoring vil sige, lad mig vende design, før jeg endda tilføje Facebook, og sige givet, at jeg vide, at nu har jeg brug til at håndtere de fleste af flere sociale netværk, hvad ville det optimale design ser ud? Lad mig refactor koden til at håndtere, at design, og så kan jeg sætte Facebook-funktionalitet på. Giver det mening? Så en masse mennesker tror, ​​når de høre noget som emergent design, at du laver mindre design eller at du bare hacking. Men sandheden er, at du er faktisk gør mere design. Det er en slags det samme ting med planlægning, ikke? Du faktisk gør mere planning-- det er bare at i stedet for gør det hele op foran, du gør det hele tiden som du går sammen. Så jeg synes, det er virkelig stor at du fyre tager CS50, fordi jeg hører dette så mange gange en dag, kan jeg ikke engang fortælle dig. Folk kommer op til mig og de siger, Abby, jeg har denne store idé! Alt, hvad jeg behøver, er en udvikler. Og jeg slags ønsker at skyde mig selv i hovedet, når jeg hører det. Da denne form for assumes-- de vil komme op, og de vil være ligesom jeg har ideen hele regnet ud. Jeg har forretningsplanen. Jeg har designet. Jeg skal bare have en udvikler til gå kode det for mig, ikke? Og det er bare at antage, at de har fik alle svarene op foran, og denne person kan bare gå kode det for dem, og de kommer til at gøre en million dollars-- som bare ikke tager faktisk alle de usikkerhedsmomenter. Så hvis vi slags ser på de skridt af development-- og jeg undskylder. Dette er en lille vandfald-y. Men hvad der typisk sker, er du figur ud OK, dette er, hvad jeg ønsker at kode. Du tager noget tid at udvikle det, teste det. Kvalitetssikring tester det. Og så når du har fået en hel frigivelse sammen, som kan tage en måned. Det gør to tre måneder. Så du slipper det ud, ikke? Men hvis vi siger, OK, lad os tænke over, hvordan gør vi maksimere læring, der sker her? For hvis vi bare gå heads-down for til tre måneder eller et år eller noget og sætte noget kode ud der, og det virker ikke, så vi slags skruet, ikke? Så hvor gør læring sker i her? Sker noget at lære når vi gør krav, fordi vi taler med kunderne, og vi prøver at forstå om dem. Men virkeligheden er, at mest læring ikke ske indtil vi faktisk sætte noget i deres hænder og se, hvordan de bruger det. Og så hvad det betyder er at den tid, de steder at vi bruger den mest time-- der udvikling og QA eller testing-- der er meget lidt læring, der sker. Og så hvis vi ser på det, og sige, hvordan kan vi optimere udbyttet af udvekslingen? Eller hvordan kan vi reducere den tid der sker mellem læring? En stor ting er kontinuerlig implementering. Jeg ved ikke, om du fyre har hørt om kontinuerlig implementering. Så ideen med at-- stedet at sige, OK, vi kommer til at gå. Vi har denne frigiver til tre måneder. Vi kommer til at bygge alle de funktioner til det. Og så kun på ende af frigivelsen vi faktisk skubbe det i produktion og sætte det foran brugere. Ideen med kontinuerlig implementering tager det til den anden yderlighed. Så er du fyre kender med den version kontrol? Så ideelt set, når du arbejder på din kode, hver gang du tilføje nogle nye funktioner, er du skal nok tjekke det i versionsstyring. Så hvis du skrue noget op, kan du altid gå tilbage. Eller du kan se hvad der er ændret, hvis noget er brudt. Så ideen med kontinuerlig implementering er så snart du tjekke noget i versionsstyring, skubber koden til en mellemstation server. Det kommer til at køre automatiserede test på det, så sørg for du ikke bryde noget. Hvis du ikke bryde noget, det kommer til at skubbe det lige ud fra produktionen. Så boom. Det er i hænderne på kunden. Meget anderledes. Men hvis vi gør det, hvis vi skubber ting ud til kunden så hurtigt som muligt, så vi får koden i deres hænder. Vi kan se, hvordan de er arbejder med dem, og vi kan virkelig maksimere læring. Så jeg har tænkt mig at tale gennem dette en lille smule mere, fordi jeg ved ikke, om det was-- kontinuerlig implementering kan være temmelig ekstreme, ikke? Og det kan være temmelig svært at gøre. Så folk, sædvanligvis selskaber slags begynde med kontinuerlig integration, og de arbejder deres vej frem. Så løbende integration er dette koncept, der er lidt af den første del at jeg talte om. Så ideen med løbende integration er du stadig har din udgivelsesplan. Du kommer til at frigive hver anden uge eller hver tredje måned eller hvad er. Men hver eneste gang nogen kontrollerer noget kode i, det gør skubbe kode på en mellemstation server. Iscenesættelsen server ser ligesom produktion og det kører en serie af automatiserede test på dem for at sikre intet brød. Hvis noget brød, så er det vil lade alle vide hey, build blev brudt. Og alle har stoppe og sørg for at det er fast. Så på den måde, er du altid garantere at alt, hvad du tjekke er at holde koden på en OK tilstand. Så når du er klar til at frigive den i fraktionen, indser du alt. Kontinuerlig tilførsel er sortering af næste skridt i denne proces, som er, at hver gang du check-- det siger samme thing-- hver gang vi kontrollerer noget i versionsstyring, det skubber den til mellemstationen serveren. Det kører testene på det. Men kulturen er indstillet som sådan, at du altid holde koden, så at det kan være skubbet til produktion til enhver tid. Så med kontinuerlig integration, du måske har en køreplan, og sige, vi kun kommer til at skubbe den til produktion i tre måneder. Right? Det behøver ikke virkelig nødt til at være klar til at blive set af en kunde. Men med dette, er du siger på et givet tidspunkt, du kan være som jep, jeg er tilfreds med denne feature sæt, selvom vi er kun to uger i. Jeg har tænkt mig at gå videre og skubbe det ud til kunden, og jeg ved, det vil være OK. Og så du kan have noget ligesom afbrydere i din kode der siger for funktioner der er kun halvt fuldendt. De er faktisk ikke synlige. Hvorfor er det synligt for kunden endnu? Eller noget i den retning. Men du altid sørge at du ikke har noget det er i denne underlige tilstand, fordi det kan skubbe ud til produktion til enhver tid. Og lige når du er i, har du slags af fået alle bruges til denne idé at du altid kodning, således at det er klar til at gå ud i produktion. Så er det ikke så svært at flytte løbende implementering, som er, at hver eneste gang du tjekke noget på, så længe testen bestået, det går ud til produktionen. Er den slags mening? Så det kan stadig være virkelig skræmmende begreb, men det er interessant at se på, hvordan nogle virksomheder gør det. Så Etsy gør en rigtig godt stykke arbejde med dette. Hvis du er interesseret, de har fået en blog, taler om, hvordan de gør kontinuerlig implementering, som er virkelig awesome. De installere på produktion op til 50 gange day-- ret? Hvilket er crazy-- kan du forestille dig, hvis Du går til Etsy hjemmeside, 50 gange i dag, er, at stedet er opdateret bag kulisserne. Og i 2011, de indsat 10.000 gange i løbet af året med 100 ingeniører. Og det, de sagde, er i strid med hvad du måske tror-- ligesom Åh min Gud, det er forfærdeligt! Koden, stedet er vil være en katastrofe. De sagde faktisk, når du er implementering, der ofte er systemet så meget mere stabilt, de faktisk kalder det tillid som en service. For når vi implementere, vi har allerede gjort 9.999 gange. Vi fik denne. Det gør det også så meget lettere for dem at eksperimentere med tingene. Så hvad de sagde før er de bruges til at frigive til produktionen hver anden uge eller hver måned. Og du fyre måske Tænk, hvis du nogensinde har fik en frist for en stor projekt, du arbejder på, og du har denne liste over ting at du ønsker at få gjort, og derefter som det får tættere på deadline, Listen begynder faldende en lille smule. Ligesom godt, måske gør jeg ikke virkelig brug for at gøre dette. Måske jeg ikke rigtig brug for at gøre det. Så det er, hvad de sagde ville ske. Da de ville komme tættere på release-- og det var sådan en big deal. De skulle få udgivelsen ud til tiden. Men de ville begynde at skrælle væk funktioner. Og så de faktisk gjorde mindre funktioner, fordi de var kun frigive hver anden uge eller en måned. Nu, hvor de er frigive så mange gange, det giver dem denne fleksibilitet at sige, ved du hvad? Vi ønsker at opbygge en ny funktion, men vi gør ikke vide, om vi skal sætte en masse tid i det. Lad os sætte denne virkelig minimum version af funktionen og se, om nogen selv klikker på det, hvis nogen er endda interesserede. Hvis de er, så vi kan enten trække det tilbage og bygge det ud, eller vi kan meget hurtigt tilføje nye funktioner til det. Og så sagde de det bare gav dem så meget mere fleksibilitet til at eksperimentere. Og så det er virkelig interessant at se større virksomheder gør. Og på en start, især, hvor det er så vigtigt at lære, hvad der foregår, det kan være virkelig effektiv. Og derefter kommer tilbage til vores Kanban bord. Det er interessant. En masse gange, når folk gøre en bestyrelse som dette, Der er en masse debat hvad Udført kolonne betyder. Så OK, jeg arbejder på en opgave. Er det gjort, når dens kode fuldføre? Er det gjort når nogen revideret det, og det føles som om det er testet? Er det gjort, når det går ud i produktion? Og så en masse opstarter vil sige, ved du hvad? Vi kommer til at tilføje en ny kolonne i her, hvilket er en læreproces kolonne. Det er faktisk ikke gjort indtil vi har ikke kun sat i produktion, Vi har sat det i kundernes hands-- men vi har faktisk lært af, hvordan de har brugt det. Og hvad er virkelig cool om det er så vi får til at optage, at learning tilbage i cyklussen, og sige baseret på, hvad vi har lært, er baseret om, hvad vi se-- hvordan vi ser dem bruge det-- vi kan finde ud af det næste sæt at gøre. Så det er de mønstre, som jeg har set for vellykket innovation på tværs af opstarter at har været en succes. Jeg skulle også tale en lidt om ressourcer der er tilgængelige, hvis du er interesseret i at gøre en start iLab. Men jeg kan også stoppe det her, hvis du fyre har spørgsmål om, hvad jeg talte. Fortsæt? OK. [Griner] OK, så gør du ved om iLab? OK, awesome. Så iLab har awesome ressourcer. Hvis du søger for at gøre en start, har vi noget from-- vi gør hacknights der. Nogle gange, vi gør hackathons, hvis du bare vil at gå hack på kølige projekter med mennesker. Vi har workshops. Vi har klasser, re for kredit, er lidt cool på iværksætteri der er åbne at-- fleste de er åbne for alle. Men vi har også gratis workshops et par gange om ugen, at vi bare sætter i eksperter fra branchen at tale om anything-- fra tekniske begreber, til at hæve penge, til, hvordan du gør salget. Alt, hvad du ønsker omkring nystartede, vi har eksperter og beboere, der til at foretage en-til-dem. Du kan bare tilmelde dig kontortid med dem. Du behøver ikke engang at have en start. Bare hvis du har ideer og du ønsker at balance-- få oplysninger eller indsigt fra en ekspert på samme thing-- salg, finansiering. Vi får juridisk hjælp. Du kunne tilmelde dig dem der. Vi har altid fået ting foregår. Så hvis du er interesseret, det er en virkelig stor ressource. Du kan gå til vores hjemmeside. Nyhedsbrevet er virkelig awesome. Jeg slags normalt hader få email, men det er cool. Vi har så meget foregår, jeg ved ikke engang, hvad alt det er. Så hvis du tilmelder dig nyhedsbrevet, vil vi lade dig vide hver uge, hvad der foregår. Du kan også se på vores kalender for at se, hvilke begivenheder der kommer op. Og jeg er der til at hjælpe, hvis du ønsker at gøre en tech opstart. [Griner] Så det er hvad jeg har. [Applaus] [Griner] Tak.