katalog promo

>> [music playing] >> abby fichtner: hello, i'm abby fichtner. most people know me as hackerchick, because i do the hacker chick blog on how to build better technology. and i'm also over atharvard innovation labs. do you know the innovation lab? ok, so that is wicked fun. i'm hacker in residencethere, where my role is to help students do everything fromhacking on cool side projects, all

the way up to starting tech startups. >> i am a programmer, sothat's my background. i kind of got into programming andstartups by an interesting route. when i was in school, i wantedto be a management consultant, because i thought thatwould be the shit. i don't know if that's still a thing. do students still want tobe management consultants? is that considered really cool? >> ok, so i thought that was really cool.

i landed a job with one ofthe top management consulting firms right out of school. i was very excited right upuntil i started working there, and then absolutely hated it. i didn't like the company. i didn't like the culture. >> i didn't like anything about itexcept that they very bizarrely put me in programming, which wasreally weird, because my title wasn't programmer.

there was nothing that i canremember in the interview about, you're going to be programming. i thought i was going be consultingmanagers, whatever that means. i'm still not actually sure, butit made sense to me at the time. >> so i go there, and theyactually gave me an office, which was cool, because i thinkit's the only job i've ever had where i had an office. and they gave me a computer and this bigequipment that the computer was hooked up to, so i was writing code to controlthis equipment, which was really neat.

and that part i actually liked. >> and i was doing code for thensa, which was really weird. it was my first job out of college. and so i'm writing this code. i'm just totally hacking,because i have no idea what i'm doing, and tryingto make it do things. >> and i get to this point where i'm usinglibraries to control this equipment. and i can only dowhat's in the libraries, and the thing that i need to do,there isn't any functions for.

and i'm like, ok. but there was a supportnumber, so i call up the company who created the software,and i said i need to do this. and they were like,yeah, you can't do that. and it was my first job out ofschool and my first project, and i just didn't feel like i couldjust go to the boss and be like-- and he did just kindof put me on my own. >> i didn't really feel likei could go to the boss to be like, oh, go tell the nsa sorry,we're not going to do this for them,

because the library isn't available. it just didn't seem acceptable. and so i kind of stayed up allnight hacking something together, and i made it work. >> and it was this turning momentfor me, where it just clicked. and i realized this iswhat i wanted to do. i thought it was the coolest thingever, that i was like i did something that the creators of the softwarethought weren't even possible. and i was possibly the firstperson ever to do this, right?

and it wasn't that big of a thing,but it was just such a cool idea. >> and so i left the bigmanagement consulting firm, and i went to work for startups,because startups are all about creating things thatno one's ever created before. and i thought that was themost awesome thing ever. so i did that for a numberof years, kind of built out the technology for startups. and then i kind of, as i wassaying before, got into this area where i'm just going around helpinghackers and tech entrepreneurs who

are building innovative,disruptive products-- helping them to do that and find waysto do that in which they can be successful in the market. >> so that's what i want totalk to you guys about today. so for me, i think it's a reallyexciting time to be in this space right now, because technology isexpanding at this incredible rate, and it's making all theseopportunities available that were never available before. so i feel like we're back to thatpoint, where you can create things

that no one ever created before. and especially, you lookat things like 3d printing. so people are 3d printing thingslike human organs or food. nasa has started 3dprinting food astronauts, so this is a 3d printerwith dough and pizza sauce and cheese as its cartridges,rather than polymers. >> and cars. urbee 3d printed the world'scheapest and most fuel efficient car, and they're about to driveit across the country

on under 10 gallons offuel, which is pretty crazy. and of course, everything going onwith mobile, and the fact with things like 3d printing are making creatingphysical devices so much cheaper has led to the internet of things,which is this notion that hey, why do we have to have the functionalityin our computers and our tablets? why don't we take it outof those and actually put it right into thedevices, where we care about. >> and so we're gettingthings like-- david rose over at the media lab created anumbrella that tells the weather.

and so you can imagine it inan umbrella stand by the door. and as it senses you walk past it,if it's going to rain, it'll blink, so you know to take it with you. or valour created a bike thatgives you directions and gives you all of your riding stats. >> or hapi created a fork thatmonitors your eating habits to help you eat more healthy. and everything from self-drivingcars to mind-controlled helicopters-- >> [laughs slightly]

>> even things that we thought of asvery low-tech, like reading the news. gannett just announced thatthey're working on virtual reality journalism, where you absorbthe news not by reading it, but by actually experiencingit and being a part of it. or other things that we might thinkof as low-tech, like gardening, because you need to de-stress. because i don't knowabout you guys, but i would find living thenews being very stressful. >> [laughs]

>> a team out of mit, grove, hascreated a produce appliance that actually, you can put in yourkitchen to grow fruits and vegetables. and so it's really coollooking at all of the startups. there's just this amazingnumber of startups that are out these daysthat are trying to take advantage of these technologies. and what's really interesting-- justlooking at all of these things that are coming up, but realizing only a verysmall percentage of those startups are actually going to makeit into the future,

and kind of understanding why some ofthem make it and some of them don't. >> so i gave a talk last monthat an engineering conference, and i wanted to talk tothem about this topic. and i thought they're engineers. they want rules. like, i'm an engineer. i like rules. it's very nice and neat, right? so i was trying to come upwith the rules of innovation.

>> and as soon as i did that, irealized that's kind of silly. the first rule of innovation is thatthere are no rules of innovation. because if you're doingit right, then you're breaking more rules than your following. and, of course, thomas edisonfamously said that "i have not failed. i've just found 10,000ways that won't work." and so, of course, the moreinnovative that you're being, you need to kind ofexpect that you're going to find more ways that don't work.

but the good news is that it'snot a complete black hole. when you look at the startupsthat have been successful, the innovators that havebuilt these products that have been successful inmarkets, what you'll see is time and again, the samepatterns emerging of the things that they're doing. and a lot of these, when youkind of dig down into them, they're kind of predicated on a lot ofthe principles behind lean and agile-- and people just taking those and saying,how can these make sense for a startup?

>> so i want to go through these. to be honest, i think i'dlike to spend about half the time on this last one-- this "focus! and get shit done." because really, that'swhat it comes down to. but i think the first four arereally important to understand the context and themindset that you need to enter into when you're doingsomething really innovative that hasn't been done before.

>> so the first principleis eliminate waste, which, if you know anythingabout lean principles, that's one of the keyprinciples of lean. and, in fact, eric ries, who'sthe creator of the lean startup methodology, says the number onemost important thing for a startup is learning to tell the differencebetween value and waste-- which is pretty weird, right? like how could you not knowwhat's value and what's waste? >> but i think it makes more sense ifyou think about the roots of lean.

so lean comes from lean manufacturingtoyota production system in japan. and "waste" is a translation from theterm "muda," which is actually broader. so really, what you wantto do is eliminated muda. and muda means not justanything that's unproductive, but anything that isn'tadding value today. because especially whenyou're doing something so uncertain as doing a startup,creating something innovative, if you think that you'regoing this way and you start building somethingfor this, and then you

find out what's really goingon and you go this way, then anything you did overhere is wasteful, right? and so in agile, we havean expression called yagni, which is "youain't gonna need it." >> [chuckles] >> so it's a really good thing to rememberas you're building new technologies. anything that you thinkthat you're going to need, just assume that you'renot until you do. >> so it's interesting to look atexamples of startups that have made it

and see where they came from. so paypal actually started as away to beam payments between pdas. but it turned out that the worldwasn't ready for mobile payments in '99, right? we're only just startingto get there now. >> flickr started as a massivelymultiplayer online role playing game. but it turned out, likewhen people were playing it, that the most fun aspectwas sharing photos. it's kind of funny.

>> and then instagram startedas a gamified foursquare. and they actually built out the entireapp and looked at it, and went wow, there is way too much going on here. this is way too complex. and they just scrapped the wholething and said, you know what? we're just going to focusagain on the photos. and that was what wassuccessful for them. and so these are the ones thatmade it, but when you kind of look across the board, thestats are pretty bleak.

because the stats are that nineout of ten new products fail, which is pretty abysmal. and as developers, as peoplewho work with technology, i think when we lookat a stat like this, we understand how hard itis to build the tech when you're building somethingthat's not been built before. and we assume that these are failingbecause we can't build the technology. but when you really dig deep,what's happening-- these products aren't failing because thetechnology didn't work.

they're failing becausethe people who created them weren't able tofind a market for them. >> my favorite example ofthis is a company called actuality systems, whichwas actually here in boston. they created a 3d holographic display. that's pretty badass, right? they create it, and theygot it working, and then they spent the next 10years-- so they created this. this would be impressiveto create today, right?

they created this over 10 years ago. they spent the next 10 years tryingunsuccessfully to find a market for it and create a viable business out ofit, and in the end had to shut down, and all they could do was selloff a license for the technology. so were they successful in innovating? i mean, they got the technology to work. that's amazing. but if you're trying to actuallybuild a viable business out of this, not so much.

>> and so what's interestingis there's been research into what's the single biggestpredictor of startup failure. do any of you want toguess what this is? >> audience: no market? >> abby fichtner: no market, yes. so something that actually i shouldhave said-- something that startups do, that if they do this thing, it'sthe biggest predictor that they're going to fail, or the biggest indicator. so no market is sort ofsomething that happens to them.

>> so don [inaudible] dida survey into this, and what he found was the singlebiggest predictor of startup failure was sticking to the initialbusiness plan-- which is pretty confusing, right? because if you're startingon any new venture, you should try to figure outif you're on track or not. even that terminology, on track, impliesthat you're talking according to plan. and so if sticking to planmeans that you're going to fail, it's very confusing.

right? >> and so that brings us toinnovation pattern number two, which is that youshould really start small. and this sort of breaksour mental model, i think, for how people thinkabout how startups operate. because i feel like we've got this imageof startups as go big or go home, baby. like i've got a big vision, and boom. i'm going to go big, and i'mgoing to be the next facebook. >> but the question is howdo you do that, right?

how do you go from nothing butan idea to like a billion users, like facebook has? how would you even build outenough features from day one that you could appealto a billion users? and even if you wanted tobuild the next facebook tomorrow, how do you startgetting people on it? because would any of you use "the nextfacebook" if no one you knew was on it? probably not, right? >> and so what i view startupsas-- when you're really early

stages-- sort of doing the search forthe intersection of our big vision of what we want to accomplish with whatreality can actually accommodate today. and the way that you do thisis usually through a series of small experiments or small tasks. so just to take a couple examplesof companies that have made it big and how they started,microsoft started with writing a version of basic, whichis a programming language, for the altair, which waslike the first home computer. so i don't know exactlyhow many altairs were made,

but i'm guessing only a few thousand. so this is not a big market, right? >> and then, of course, facebook, whichis the quintessential-- go big, become the next facebook--started here at harvard, where there's only 20,000 students. so again, not a big market. and so when you're thinking aboutthe mental model for how startups should look, it shouldlook more like this. you start with your bigvision, but then you go small.

and you figure out a way todominate a really niche market, and then you can build onthat success to go big. and there's a couple reasons for this. one is if we accept the fact thatsticking to the initial business plan's going to fail, we're going tofind 10,000 ways that don't work, whatever, we're going tomake a lot of mistakes. we're going to have a lot of misses. if we try to go big, we're going touse up all of our time and resources on the wrong thing.

and so it's much better to gosmall so we can experiment quickly. >> but even more importantly,it's so much easier to be successful when we gosmall, because all you have to do is find that market that you want togo after-- that really niche market. and then just identify theone thing that they're really dying to have, and build that for them. and then you can be really compelling. >> so like the altair users really wanteda way to program their computer. and i don't know-- i think itwas just like toggle switches

and blinking lights, right? so i don't know how they did that. so providing basic so theycould program it is amazing. or harvard students just wanted asingle, centralized student directory, right? and so facebook only had toprovide that one feature. they didn't have to build it out likeit is today to really get traction. >> so that takes us to numberthree, which is in order to find that one feature thatyour market is really dying for,

you have to really deeplyunderstand your customers. and i feel like people underestimatethe importance of this-- especially today, when there's somany startups that are out there. if you are really looking at what'sgoing on in the startup space, you're going to find 100 startupsall doing the same thing. >> and that's because everybody can seethat technology is here today, right? but we want to be here. so people see those gaps, andeverybody tries to go after those gaps. and you have all these startupsall doing the same thing,

and you're like, why isn'tany of them succeeding? there's a gap here. i believe that the onesthat are going to succeed are the ones that take the time toreally understand their customers. a great example of this,i think, is dropbox. when drew houston, the founder, wentto try to raise money for dropbox, the vcs really discouraged him. they're like, i don't understandwhy you're even entering this space. there's already like a million billioncloud storage startups out there.

>> and drew was like, yeah,but do you use any of them? and they weren't. and so i feel like drewsucceeded because a, he started with a small market. he didn't try to go after everybody. he went after thehardcore techies who have a lot of devices, a lotof computers, and they have this problem in transferring files. and he just targeted them.

and all he had to do was providea solution that worked for them. >> so again, i feel like there'sa lot of myths around startups, because we see so manystartups happening today. and you just hear the 20,000 footview of oh, they made it overnight. they were a success. but the myth of if you build it,they will come-- when you really dig deep into what's happeningin those success stories, time and again, i think whatyou'll find are founders who went to these extraordinarylengths to understand their customers.

so just to give a couple examples-- idon't know if this is still the case, but at least initially, oneof the co-founders of airbnb did not own or rent a home. he just went aroundand lived in airbnbs. like i don't even know what that lookedlike-- like living out of a suitcase? >> or ben silverman frompinterest is amazing at this. he went and personally reachedout to the first 5,000 customers. he gave them his cellphone. he met them for breakfast.

i just spoke to theircto a couple weeks ago. and they're enteringinto new countries now, and he's going out and doing it again. so he's incredible for going outand individually talking to people. so, of course, as you're going outand having these conversations, what you want to be doing is alwayslearning from your customer about what's going to make senseand what's going to be successful. i feel like the beststartups, the best innovators, treat innovation as if it was ascience experiment-- or in a very

scientific way, i guess i should say. >> so i'm not a scientist, but asi understand, scientists come up with hypotheses, and then they developexperiments to validate or invalidate their hypotheses. and so the question is how canwe do that with innovation? we have an idea, but it's just an idea. if we're truly doing somethingthat's never been done before, all we have are guesses. and so what are some experiments thatwe can do to validate or invalidate

those ideas without buildingout the entire thing? >> so talking is great,and i can't actually emphasize how strongly--how important it is to go out and talk to yourcustomers, at least initially, to understand who theyare, what problems they have today, how they'resolving them today. but talking can only take you so far. you can't use talking to say,hey, i've got this great idea! do you want to buy it?

because they're going to belike, oh, yeah of course. that sounds great. >> because people want to encourage you. they see that you're excited aboutsomething, so they're going to say yes. and people-- human beings are justterrible at predicting their behavior. and so if you ask them-- if you say,i'm going to, at some point in a future, release this abstract, hypotheticalproduct, are you going to want it? they might say no, but if youactually put it in front of them, they might want it.

>> and so really, to do thetest of understanding if people are going towant it or not, you really need to put something in front of them. so i like this quote from linustorvalds, which is "talk is cheap. show me the code." or if you're a startup, youmight say, "talk is cheap. show me the mvp." >> so have you guys heard mvp,minimum viable product? it's kind of this buzzword thati love and hate at the same time.

because i love the concept of it,but it gets a little bit overused. but the idea is valid,which is don't go build out this product that's goingto take you a year to build. instead, figure out what's that onething that people are dying for? what's the minimum thingi can build for them? and put that in front ofthem, and see how they react. >> so quintessential mvp is a landing page. i'm sure you guys have seen this. if you tried to sign up for ello orgmail's new inbox, and they're like oh,

we're not ready yet! i guess those are a littledifferent, because those are ready. but they give you a landing page, andit's like, it's invite only right now. but give us your email address. right a lot of places will do this beforethey've even built out the product, just to see if there's interest or not. so with dropbox, drew houston, therewas complex technology behind it. so he went, and he figured out thetechnology-- kind of proved that out,

that that was going to work. but before he builtout the final product, he did this mock-up on his computer,this three-minute screencast video-- very scrappy. put it out on hacker news, becausehe knew was sort of his audience, were the really technical people. put up a landing page thatjust said, here's the video. we haven't launched yet, but if you'reinterested, give us your email address. >> overnight, got 75,000sign-ups, which is incredible.

even today, that would beimpressive, but today, they have like 300 million users, right? when he posted this,nobody knew who dropbox was because they didn't exist yet. and so that was a really strong signalthat he had gotten something right. >> to give you a little bit moreextensive of an example of that, do you guys know buffer? it's a social mediasharing site, and the idea is-- i tend to read newsat like 2:00 am, because i

don't want to go to sleep. and so i might read like 10articles that are all really cool and i want to share them with people. but a, if i share themout on twitter right now, nobody is awake at2:00 am except for me. and b, if they are awake,they're like why are you spamming me with 10articles at once, right? and so what it does is it'skind of a queue or a buffer that you add things to, and it'llpush them out a couple times a day

at a more realistic schedule. >> so this is how it looks today. that's not how it started. the founder had this idea, andhe thought this was a good idea, but he didn't want to build it. he didn't want to quithis day job yet until he got some validation that other peoplethought it was a good idea, too. so he didn't even need a video. it was such a simple concept.

>> just start with twitter,puts up a landing page. this is what we do. he tweets it out. when people click plans andpricing, it just gives them a "you caught us before we'reready." but if you're interested, give us your email address. tweets it out. people went to the site. they were given their email address.

>> he was like, ok, that's a pretty goodindicator that there's some interest, so i'm ready to go to the next step. but i don't want to build it yet. i want to see-- people are interested,but can i make money off of it? can i make it into a business? so all he did was added a middle pagewhen people clicked plans and pricing with three pricing plans-- one was free. two were paid. >> kept tweeting it out.

people kept clicking. most people did the free plan,but some people did the paid plan. he's like, you know what? that's enough validation-- notfor me maybe to quit my day job and spend a year on this, but forme to just go heads-down and do a really simple version of this. he thought it was goingto take him a day. technology's hard, so ittook him like seven days. but it was enough for himto spend seven days on it.

>> and very quickly, he startedgetting users on that first version, even though it was very minimal. and what was awesomeabout that was he was able to see how peoplewere really using it, and then kind of evolveit based on them using it. so buffer's wonderful, becauseit's a really simple example. not all technology isthat simple, but this is sort of the quintessentiallean startup approach, right? this is great-- you'retesting it every step,

and you're only goingfar enough that you've validated that it's kindof worth your time to do. >> another great way to getvalidation, of course, is doing a crowdfundingcampaign like kickstarter, where you can get pre-orders. this makes a lot of sense if you'redoing anything that's hardware. again, pebble was thebiggest kickstarter until that title got taken by acooler-- did you guys see this? like an actual cooler that youbring to the picnic beat out,

so they got more than $10 million. [laughs slightly] >> but again, like dropbox, withpebble, it was complex technology. they had to do a proof of concept,make sure they could prove out that the technology could work. but then it's expensive to manufacture,so before they actually manufactured, they put up a kickstarter. and they used it toget pre-orders, right? they said if we can get$100,000 in pre-orders,

it's worth it to go forward. they got $10 million, so doingpretty good-- pretty good validation. >> so these ideas are all reallygreat, but as we say in startups, ideas are a dime a dozen. it's all about execution. so this is my favoritepart is the "focus! so the best entrepreneursare able to just have this crazy, intense hyper-focus andget things done at an amazing pace. >> so i kind of walk through someof the development practices.

and ask questions if you have them. i wasn't quite sure how much you guysknew about development practices, so kind of have adiscussion about what that looks like when you'redeveloping something like this. so the first thing isto figure out ok, what is it that i should be focusing on--which can be really challenging when you're doing something new. because everybody has allthese ideas, and there's so many different directions you cango, and so many different questions

that you have. >> so step number one, figureout what to focus on. a lot of times, as developers, as peoplewho are thinking about technology, we're really thinkingabout the products. we think about things kind of inthis order-- first, can i build it? assuming that i can build it, thencan i get people to know about it? assuming that i can, cani make money from it? >> but if we're trying todo a viable business, we might want to be thinkingof those in the opposite order.

the reason is i feel like-- andi do this myself, so i get it. i feel like we get very hungup on this "can i build it?" question, because if you're a technologyperson-- if you're a developer-- you're really thinking about that. >> but the truth is usually, when wecome up with an idea for a startup, we're coming up with it based oni've seen this technology here and this technology hereand this technology here, and if i just combinethem in some new way, i think it would be really interesting.

well, if i've already seen thetechnology in those places, you kind of know it exists, right? >> so sure, do some proof of concepts. if there's some technical risk in there. but for the most part, the thingsthat we're coming up with-- unless we're really awesome and doingsomething totally new, in which case, figure out if you can build it. but usually, most of thestartups i see, you can build it. that isn't even a question.

>> so start thinking aboutis something that people are going to be able to pay me forand then how am i going to reach them? that's really hard, especiallyif you are a technical person, do you have a way toreach out to these people and get them to buy your product? >> so once you figure out, ok, what's thatquestion-- kind of always have in mind, this is the most important questionthat i need to be driving towards, or the most important thingthat i need to be validating. and then you want to get back tothis notion of eliminating waste.

just figure out like theleanest, most efficient way that you can go aboutanswering that question. >> so i talked aboutminimum viable product. i would say get into this mindsetof minimum viable everything-- by which i don't mean that you shouldbe doing a crappy job at things. i just mean how canyou cut out the waste? how do you get just rightto the heart of the matter and figure out how to validatethings without gold-plating, without doing more than you need to.

>> so just to give some examples,i feel like initially, you're trying to figure out ihave this great idea. is anyone even going to want it? so a really easy way to do that is alanding page, like we talked about. you don't have to writeany code for that. there's tools that do it for you. >> if you say, ok, i figured that out. now i want i'm assuming that--ok, people seem to want it. would they actually pay me money for it?

you can do things like whatbuffer did with the pricing page, or even better, a kickstarterand get pre-orders. orders >> the next thing that i think you'regoing to be wanting to look at is-- ok, it seems like people wanted it. it seems like people will payfor it, but especially with apps, will people actually use it? so i don't know the stats,but they're pretty abysmal. a huge number of apps getdownloaded and then never used.

and that isn't helpful. that's nice that you got alot of people downloading it. but if it's not used, you're notgoing to stick around for long. when you're thinkingabout that first version that you want to put out there--your minimum viable product-- think about what is it exactlythat i'm trying to test? and what can i do thatjust figures that out? i just kind of took a guess at this. i don't actually know what buffer'sfirst version looked like exactly.

but if you think about buffer-- justbecause of this simple example-- you might think thisis what they feel like as their first minimum viable product. i need to be able tocreate a user account, obviously, link it to mysocial media accounts. i need to add posts liketweets into my buffer. edit them. delete them. >> set the time when iwant those to be posted.

obviously, the software needsto automatically post to twitter or whatever based on that schedule. and then i should be able toview a history of my post. that feels pretty minimal,pretty basic, right? >> i always encourage startups--especially like, this is easy for us, because it's not our baby. be like, oh, yeah whatever look at itagain, and keep saying is there a way that i can get itstripped down even more? >> so what is it we'retrying to figure out?

if we're trying to figureout if they'll use it, we're trying to see if are they evengoing to post anything to the bumper? so this feels a little hacky, but ifthey haven't posted it to the buffer yet, you don't reallyneed to allow them to edit or delete or view posts in history. if you can plant that somethingout there really quickly and see if people can even addpostings to it, once you see that, you can very quickly startadding on this functionality. but just get something out there.

do you need to allow the userto set a posting schedule? probably not, if they're likeme and they're just like, i don't want my all my treats goingout at 2:00 am on sunday night. >> you can say these arethe most popular times. whatever, we're just goingto post it according to that. you can probably do that. and then i kind of made this up, becausei know they only started with twitter. but obviously, you canjust pick the social media network that makes the mostsense and just start with that.

and so now you're downto four out of 10. >> and if you can get somethingout there, a pet peeve of mine is that people think andmvp means crappy product. and i don't think it needs. i think you can get somethingout there that it's still useful, but isn't gold plated-- isjust the absolute bear minimum. and i guess you have to kind of figureout based on your audience what's going to make sense or what isn't. >> but a lot of times you getsomething out there more minimal

than you'd think-- just atest, how people use it. so as you're buildingout these features, you want to think about what'sthe minimum viable process. and so a lot of times when we thinkabout really lightweight processes, we think about agile processes. we think about lean-- this is a littlebit random-- just some agile and lean books that i like. so there's great practiceslike from extreme programming and continuous integration,and refactoring,

which i'll speak to a little bit. but the thing is, once you start gettinginto the agile and mean practices, it can very quickly get overwhelming. and it can wind up beginreal overkill for a startup. >> so the thing is thata lot of these books are talking about howto do agile when you're doing a product for anestablished company. and you know who the market is, andyou know what your product road map. and they wind up-- eventhough we're supposed

to be light weight-- they wind upactually being way too heavyweight for our startup, becausethe startup is just operating at thiscompletely different level. so my feel is that whenyou're going a startup, you need to be scrappy as hell. so initially, there's no process. you want to keep itas simple as possible. and only add process that'ssort of a just-in-time process. ok, we see that there's a problem?

let's add just enough processto address that problem. do you know what i mean? it's because you don't want anyof us holding you down, right? >> scrum is a really popularprocess for agile development. i don't know if you guysare familiar with this. ok, well-- >> it would be just toooverkill for a startup. so i won't worry about that. so ok, if you think about what's theabsolute simplest thing that i need.

well, i need to probablykeep track of what i'm doing, especially ifthere's more than one person, but even if there's one person. what am i working on? >> so a simple task board-- very easy. this is what i want to do. this is what i'm working on. this is what i've done. the only problem that i see when i seestartups doing something like this,

is that very quickly,their in-progress column tends to look like that, which is notvery helpful-- especially if there's only one person or only one developer. >> because you're notgetting anything done. all you're doing is going back and forthtrying to get all these things done. and so this is a really good exampleof where just enough process can come. so kanban is a really great tool. it comes also from lean manufacturing. >> and the idea is that what wewant to do is put constraints

around how much work we canhandle at any given time. and so if we're one person, then wecan only work on one item at a time. sorry. so all that other stuffneeds to go over there. so what we do is we put work inprogress limits on the columns. if there's two people, it can be two. you can figure out whatmakes the most sense for you. >> but the idea is keep thingssane, so that you're just doing one thing at a time.

you're able to do it. you're able to actually get it done. one thing to keep in mindis-- if you have a one item that you're doing but theitem takes three months, that would be a difficult fora startup, obviously. you need to be ableto be flexible and be able to handle thingsas they come at you. you can't say i'm not doinganything for three months until i get the login screen done.

i don't know. >> so i advise startups tokeep this really short, to keep these tasks sothat they fit into a day. obviously, if it's more complex, thatmight need to be a little bit longer. but figure out what works best for you. you can try different lengths. but generally, just as anexample, if you keep all the tasks so they fit within one day, thatmeans that every single day, you're getting something done.

and you're providing value. and that momentum canreally move you forward instead of the situation before,where you have 500 things going, and none of them are done. the other thing,though, is still looking at this to-do column-- i'moverwhelmed looking at that. and so if i was a developer and i wasworking on a, and i was like oh, shit. i've got b and c and de ande and f and g and h. blah! coming down the road.

i'm like freaking out, and i"m tryingto figure out how the design is going to accommodate all these things. and the truth is that if we accept thefact that we don't actually quite know what the product's going to need tolook like until we've put in front of a customer, then do we really knowthat we need all those tasks yet? or are we kind of fooling ourselves? >> so if you really haveall those ideas, great. put them in a notebook or aspreadsheet or something like that. but i advise startups tokeep a work-in-progress limit

on the to-do column, too. that's an absolute maximum,i would say, how much you can get done in one or two weeks. so it doesn't even have to be that many. >> that way you are justhyper-focused on this is what i'm doing,getting done this week. or maybe these two weeks, right? and nothing else is gettingin your way, and you're just making sure that you'regetting that out there.

and especially as you start addingnew team members, this really helps. a lot of people like to do thisin software, which you can. but it's even better if youall can be in the same space and just put it up on a wall. it's just really visible,and everyone can just see it, and see what's most important. >> so ok, that's how you'refiguring out what to do. as you're doing it,you want to be thinking about what's the minimum viable design?

or in agile, we actuallyhave something called emergent design, which is the same idea. so have you guys heard ofemergent design before? ok. >> s-- actually, i'm tryingto remember where-- ok. so the idea of a merchantdesign is rather than coming up with this big, upfrontdesign and saying i'm going to spend a month figuring outthe right architecture what components go where and everything, let mejust design enough for the features

that i know i'm puttingin this first release. and nothing else-- or the featuresthat i'm doing this week, even. >> and then only as i need new featuresdo i figure out the design for those. you're not figuring out design upfront. i think in reality, it's not thison-off switch or this toggle. i think it's more of aspectrum of where you've fall on the certainty to uncertainty. and so if in a startup up, or ifyou're building something that's never been built before, you're prettyfar over on the uncertainty curve

here, right? >> and if you think about it interms of the business plan-- like, we talked about the singlebiggest predictor of failure is sticking to theinitial business plan. if you do this bigupfront business plan, and you say i'm just going to blindlyfollow that and not do anything. but you're just going to fail, right? because there was too much uncertainty. and i feel like thesame is true for design.

>> sorry, so instead of doinga big upfront business plan, you would do a very lightweight business model canvas, which you might have heard of. it's like a one-pager,just getting my ideas out. it's not that you don'tthink about it at all. it's good to think about it at first. but just get it something reallyflexible out there-- just one page. and then, as you go, kind ofemerge that plan over time as you learn from customers,and you can adapt to them.

>> and so then the samething is true for design. you can do a big,upfront design, but that doesn't make sense ifthere's a lot of uncertainty. a lot of people would argue there'snever that much certainty in software, even if you're not doing in startup. so you never want to do thatbig of an upfront design. but i feel like thelevel of design is going to vary based on how muchcertainty or uncertainty there is. and so if you have no freaking clueand you're just throwing something out

there like a landingpage, obviously, you're not going to go take the timeto architect a whole system. that's ridiculous, right? so you don't need any upfront design. a lot of times, the first versionyou put out of software for a startup just gets thrown away. and so a lot of times, eventhough i might say this, you can just kind ofhack something together. it's probably going to be thrown away.

but again, use that just-in-timeidea for design as well. that ok, you know what? this is actually some traction. some people are interested in this. i'm going to add some features on. now, i feel like i should be alittle bit smarter about the design. >> so the idea is as your designing,just keep this yagni in mind. you ain't gonna need it. don't design for thingsthat aren't there yet.

and the keep it simple,stupid principle-- do the simplest thingthat could possibly work. >> a lot of times, it's interesting,because as developers, we get taught to do thesereally complex designs. and we're taught that that's good. but it prevents us from beingflexible, and it can be really wasteful if we wind up going inat different directions. so agile kind of says, don't do that. just figure out what thesimplest way, the simplest code

that you can put in herethat's going to make it work. and then if i need to add ontoit, i can kind of fix that code up and readdress the design. >> so there's something called refactoringthat's really important when you do emergent design. and the idea with refactoring is--sorry, i'm going to back up a little. so if you're doing emergent design,you're only designing for the future that you have today. but that doesn't meanthat you're hacking.

that doesn't mean whenyou add another feature, you're just going tokind of duct tape it on. because that's going to giveyou this big ball of mud code that's going to beimpossible to maintain. the idea with the refactoring is ok, iknow i only need, say, twitter today, so i'm not going to do thisbig abstraction that says, oh, let me have this abstraction layerthat will work with any social media network that i could ever possiblythink of it in the future, because that takes time.

let me just-- the simplestthing that could possibly work is let me just makeit known with twitter, because that's all i need to do today. then tomorrow, we realize ok, we doneed to make this work with facebook. so refactoring would say, let me revisitthe design before i even add facebook, and say given that iknow that now i need to handle most multiple social networks,what would the optimal design look like? let me refactor the codeto handle that design,

and then i can plugfacebook functionality in. does that make sense? >> so a lot of people think, when theyhear something like emergent design, that you're doing less designor that you're just hacking. but the truth is you'reactually doing more design. it's sort of the samething with planning, right? you're actually doingmore planning-- it's just that instead ofdoing it all up front, you're doing it continuouslyas you go along.

>> so i think it's really greatthat you guys are taking cs50, because i hear this so many timesa day, i can't even tell you. people come up to me and they say,abby, i've got this great idea! all i need is a developer. and i kind of want to shoot myselfin the head when i hear that. >> because that kind ofassumes-- they'll come up, and they'll be like i havethe idea all figured out. i've got the business plan. i've got the design.

i just need a developer togo code it for me, right? and it's just assuming that they'vegot all the answers up front, and this person can justgo code it for them, and they're going to makea million dollars-- which just doesn't take intofact all the uncertainties. >> so if we kind of look at the stepsof development-- and i apologize. this is a little waterfall-y. but what typically happens is you figureout ok, this is what i want to code. you take some time todevelop it, test it.

quality assurance is testing it. and then once you've gotan entire release together, which might take a month. it makes two three months. then you release that out, right? >> but if we say, ok, let'sthink about how do we maximize the learning that happens here? because if we just go heads-down forthree months or a year or something and put some code outthere and it doesn't work,

then we're kind of screwed, right? so where does thelearning happen in here? some learning happenswhen we do requirements, because we're talking to customers, andwe're trying to understand about them. but the reality is thatmost learning doesn't happen until we actuallyput something in their hands and see how they use that. and so what this means isthat the time, the places that we spend the most time-- which isdevelopment and qa or testing-- there's

very little learning that happens. >> and so if we look at this andsay how can we maximize learning? or how can we reduce the timethat happens between learning? a great thing is continuous deployment. i don't know if you guys haveheard about continuous deployment. so the idea with that-- insteadof saying, ok, we're going to go. we have this releases at three months. we're going to buildall the features for it. and then only at theend of the release are

we are going actuallypush that into production and put it in front of users. >> the idea with continuous deploymentis taking that to the other extreme. so are you guys familiarwith the version control? so ideally, when you're workingon your code, every time you add some new functionality, you'regonna check it into version control. so if you screw somethingup, you can always go back. or you can see what changed,if something's broken. >> so the idea withcontinuous deployment is

as soon as you check somethinginto version control, it pushes the code to a staging server. it's going to run automated tests onit, make sure you didn't break anything. if you didn't break anything,it's going to push it right out from the production. >> so boom. it's in the hands of the customer. very different. but if we do this, if we're pushingthings out to the customer as fast

as possible, then we're gettingthe code into their hands. we can see how they'reworking with them, and we can really maximize learning. >> so i'm going to talk throughthis a little bit more, because i don't know if thatwas-- continuous deployment can be pretty extreme, right? and that can be pretty tough to do. so people, companies usually kind ofstart with continuous integration, and they work their way forward.

>> so continuous integration is thisconcept that's kind of the first part that i talked about. so the idea withcontinuous integration is you still have your release schedule. you're going to release every two weeksor every three months or whatever is. >> but every single timesomeone checks some code in, it does push the codeonto a staging server. the staging server lookslike production and it runs a series of automated testson them to make sure nothing broke.

if something broke, then it'sgoing to let everybody know hey, the build was broken. and everybody has stopand make sure it's fixed. >> so that way, you're always guaranteeingthat everything that you check in is keeping the code at an ok state. then when you're ready to release it inthe fraction, you realize everything. continuous delivery is sort of thenext step in this process, which is that every time you check-- it saysthe same thing-- every time we check something into version control, itpushes it to the staging server.

it runs the tests on it. >> but the culture is setas such that you always keep the code so that it can bepushed to production at any time. so with continuous integration,you might have a road map and say, we're only going to push itto production in three months. it doesn't really have to beready to be seen by a customer. but with this, you're sayingat any given point in time, you can be like yep, i'mhappy with this feature set, even though we're only two weeks in.

i'm going to go ahead andpush it out to the customer, and i know it's going to be ok. >> and so you might have somethinglike switches in your code that say for featuresthat are only half done. they're not actually visible. why is it visible to the customer yet? or something like that. but you always make surethat you don't have anything that's in this weird state, because itcan push out to production at any time.

>> and just once you're in, you've kindof gotten everybody used to that idea that you're always coding such thatit's ready to go out into production. then it's not so hard to moveto continuous deployment, which is that every single timeyou check something in, as long as the test passed,it goes out to production. does that kind of make sense? >> so it can still be reallyscary concept, but it's interesting to look at howsome companies are doing it. so etsy does a reallygood job with this.

if you're interested,they've got a blog that talks about how they do continuousdeployment, which is really awesome. they deploy to production upto 50 times a day-- right? which is crazy-- can you imagine ifyou go to the etsy website, 50 times in day, that site is beingupdated behind the scenes. >> and in 2011, they deployed 10,000times over the year with 100 engineers. and what they said is contrary towhat you might think-- like oh my god, that's terrible! the code, the site'sgoing to be a disaster.

they said actually, once you'redeploying that often, the system is so much more stable, they actuallycall it confidence as a service. because when we deploy, we'vealready done this 9,999 times. we got this. >> it also makes it so much easierfor them to experiment with things. so what they said before is theyused to release to production every two weeks or every month. and you guys mightimagine if you've ever got a deadline for a bigproject you're working on,

and you have this list of thingsthat you want to get done, and then as it getscloser to the deadline, the list starts shrinking a little bit. like well, maybe i don'treally need to do this. maybe i don't really need to do that. >> so that's what they said would happen. as they'd get closer to therelease-- and it was such a big deal. they had to get the release out on time. but they'd start paring away features.

and so they actually did lessfeatures, because they were only releasing every two weeks or a month. now that they'rereleasing so many times, it gives them this flexibilityto say, you know what? we want to build a newfeature, but we don't know if we should puta lot of time into it. let's put out this reallyminimum version of the feature and see if anyone even clicks onit, if anyone's even interested. if they are, then we can eitherpull it back and build it out,

or we can very quicklyadd new features to it. >> and so they said it just gave them somuch more flexibility to experiment. and so it's really interesting tosee bigger companies doing that. and at a startup, especially, where it'sso important to learn what's going on, it can be really effective. and then coming backto our kanban board. >> it's interesting. a lot of times, when peopledo a board like this, there's a lot of debate overwhat the done column means.

so ok, i'm working on a task. is it done when its code complete? is it done when someone's reviewedit and it feels like it's tested? is it done when it goesout into production? >> and so a lot of startupswill say, you know what? we're going to add a new column inhere, which is a learning column. it's not actually done until we'venot only put into production, we've put it in customers'hands-- but we've actually learned from how they've used it.

and what's really coolabout that is then, we get to incorporate thatlearning back into the cycle, and say based on whatwe've learned, based on what we se-- how we see them use it--we can figure out the next set to do. >> so those are the patterns that ihave seen for successful innovation across the startups thathave been successful. i was going to also talk alittle bit about resources that are available if you'reinterested in doing a startup ilab. but i can also stop it here, if youguys have questions about what i talked.

keep going? >> ok, so do you know about the ilab? ok, awesome. so the ilab has awesome resources. if you're looking to do astartup, we have anything from-- we do hacknights there. sometimes, we dohackathons, if you just want to go hack on cool projects with people. >> we have workshops.

we have classes that re for credit thatare kind of cool on entrepreneurship that are open to-- most ofthose are open to everybody. but we also have free workshopsa couple times a week, that we just bring inexperts from the industry to talk about anything-- fromtechnical concepts, to raising money, to how to do sales. >> anything that you wantaround startups, we have experts and residents whoare available to do one-on-ones. you can just sign up foroffice hours with them.

you don't even have to have a startup. just if you've got ideasand you want to balance-- get information orinsight from an expert on the same thing-- sales, financing. we get legal help. you could sign up for those there. we've always got stuff going on. >> so if you're interested,it's a really great resource. you can go to our site.

the newsletter is really awesome. i kind of usually hategetting email, but it's cool. we have so much going on, idon't even know what all it is. so if you sign up forthe newsletter, we'll let you know every week what's going on. you can also look at our calendarto see what events are coming up. >> and i am there to help if youwant to do a tech startup. >> so that's what i've got. >> [applause]

>> thank you.