>> [MUSIC PLAYING]
>> ABBY FICHTNER: Hello, I'm Abby Fichtner.
Most people know me as Hacker Chick, because I do the Hacker Chick
Blog on how to build better technology.
And I'm also over at Harvard Innovation Labs.
Do you know the Innovation Lab?
OK, so that is wicked fun.
I'm hacker in residence there, where my role
is to help students do everything from hacking on cool side projects, all
the way up to starting tech startups.
>> I am a programmer, so that's my background.
I kind of got into programming and startups by an interesting route.
When I was in school, I wanted to be a management consultant,
because I thought that would be the shit.
I don't know if that's still a thing.
Do students still want to be management consultants?
Is that considered really cool?
>> OK, so I thought that was really cool.
I landed a job with one of the top management consulting
firms right out of school.
I was very excited right up until 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 it except that they very bizarrely
put me in programming, which was really weird, because my title wasn't
programmer.
There was nothing that I can remember in the interview about,
you're going to be programming.
I thought I was going be consulting managers, whatever that means.
I'm still not actually sure, but it made sense to me at the time.
>> So I go there, and they actually gave me an office,
which was cool, because I think it's the only job I've ever
had where I had an office.
And they gave me a computer and this big equipment that the computer was hooked
up to, so I was writing code to control this equipment, which was really neat.
And that part I actually liked.
>> And I was doing code for the NSA, 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 trying to make it do things.
>> And I get to this point where I'm using libraries to control this equipment.
And I can only do what'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 support number, 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 of school and my first project,
and I just didn't feel like I could just go to the boss and be like--
and he did just kind of put me on my own.
>> I didn't really feel like I 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 all night hacking something together,
and I made it work.
>> And it was this turning moment for me, where it just clicked.
And I realized this is what I wanted to do.
I thought it was the coolest thing ever, that I was like I did something
that the creators of the software thought weren't even possible.
And I was possibly the first person 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 big management consulting firm,
and I went to work for startups, because startups are all
about creating things that no one's ever created before.
And I thought that was the most awesome thing ever.
So I did that for a number of years, kind of built out
the technology for startups.
And then I kind of, as I was saying before, got into this area
where I'm just going around helping hackers and tech entrepreneurs who
are building innovative, disruptive products-- helping them
to do that and find ways to do that in which they
can be successful in the market.
>> So that's what I want to talk to you guys about today.
So for me, I think it's a really exciting time to be in this space
right now, because technology is expanding at this incredible rate,
and it's making all these opportunities available
that were never available before.
So I feel like we're back to that point, where you can create things
that no one ever created before.
And especially, you look at things like 3D printing.
So people are 3D printing things like human organs or food.
NASA has started 3D printing food astronauts,
so this is a 3D printer with dough and pizza sauce
and cheese as its cartridges, rather than polymers.
>> And cars.
Urbee 3D printed the world's cheapest and most fuel efficient car,
and they're about to drive it across the country
on under 10 gallons of fuel, which is pretty crazy.
And of course, everything going on with mobile, and the fact with things
like 3D printing are making creating physical devices so much cheaper
has led to the internet of things, which is this notion that hey, why do we
have to have the functionality in our computers and our tablets?
Why don't we take it out of those and actually
put it right into the devices, where we care about.
>> And so we're getting things like-- David Rose
over at the Media Lab created an umbrella that tells the weather.
And so you can imagine it in an 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 that gives you directions and gives you
all of your riding stats.
>> Or Hapi created a fork that monitors your eating habits
to help you eat more healthy.
And everything from self-driving cars to mind-controlled helicopters--
>> [LAUGHS SLIGHTLY]
>> Even things that we thought of as very low-tech, like reading the news.
Gannett just announced that they're working on virtual reality
journalism, where you absorb the news not by reading it,
but by actually experiencing it and being a part of it.
Or other things that we might think of as low-tech, like gardening,
because you need to de-stress.
Because I don't know about you guys, but I
would find living the news being very stressful.
>> [LAUGHS]
>> A team out of MIT, Grove, has created a produce appliance
that actually, you can put in your kitchen to grow fruits and vegetables.
And so it's really cool looking at all of the startups.
There's just this amazing number of startups
that are out these days that are trying to take
advantage of these technologies.
And what's really interesting-- just looking at all of these things that are
coming up, but realizing only a very small percentage of those startups are
actually going to make it into the future,
and kind of understanding why some of them make it and some of them don't.
>> So I gave a talk last month at an engineering conference,
and I wanted to talk to them 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 up with the rules of innovation.
>> And as soon as I did that, I realized that's kind of silly.
The first rule of innovation is that there are no rules of innovation.
Because if you're doing it right, then you're
breaking more rules than your following.
And, of course, Thomas Edison famously said that "I have not failed.
I've just found 10,000 ways that won't work."
And so, of course, the more innovative that you're being,
you need to kind of expect that you're going
to find more ways that don't work.
But the good news is that it's not a complete black hole.
When you look at the startups that have been successful,
the innovators that have built these products that
have been successful in markets, what you'll see
is time and again, the same patterns emerging of the things
that they're doing.
And a lot of these, when you kind of dig down into them,
they're kind of predicated on a lot of the 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'd like to spend about half
the time on this last one-- this "Focus!
And get shit done."
Because really, that's what it comes down to.
But I think the first four are really important to understand
the context and the mindset that you need
to enter into when you're doing something really innovative that
hasn't been done before.
>> So the first principle is eliminate waste,
which, if you know anything about Lean principles,
that's one of the key principles of Lean.
And, in fact, Eric Ries, who's the creator of the Lean startup
methodology, says the number one most important thing for a startup
is learning to tell the difference between value and waste--
which is pretty weird, right?
Like how could you not know what's value and what's waste?
>> But I think it makes more sense if you think about the roots of Lean.
So Lean comes from Lean manufacturing Toyota Production System in Japan.
And "waste" is a translation from the term "muda," which is actually broader.
So really, what you want to do is eliminated muda.
And muda means not just anything that's unproductive,
but anything that isn't adding value today.
Because especially when you're doing something
so uncertain as doing a startup, creating something innovative,
if you think that you're going this way and you
start building something for this, and then you
find out what's really going on and you go this way,
then anything you did over here is wasteful, right?
And so in Agile, we have an expression called
YAGNI, which is "You Ain't Gonna Need It."
>> [CHUCKLES]
>> So it's a really good thing to remember as you're building new technologies.
Anything that you think that you're going to need,
just assume that you're not until you do.
>> So it's interesting to look at examples of startups that have made it
and see where they came from.
So PayPal actually started as a way to beam payments between PDAs.
But it turned out that the world wasn't ready for mobile payments
in '99, right?
We're only just starting to get there now.
>> Flickr started as a massively multiplayer online role playing game.
But it turned out, like when people were playing it,
that the most fun aspect was sharing photos.
It's kind of funny.
>> And then Instagram started as a gamified Foursquare.
And they actually built out the entire app 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 whole thing and said, you know what?
We're just going to focus again on the photos.
And that was what was successful for them.
And so these are the ones that made it, but when you kind of look
across the board, the stats are pretty bleak.
Because the stats are that nine out of ten new products fail,
which is pretty abysmal.
And as developers, as people who work with technology,
I think when we look at a stat like this,
we understand how hard it is to build the tech when
you're building something that's not been built before.
And we assume that these are failing because we can't build the technology.
But when you really dig deep, what's happening-- these products
aren't failing because the technology didn't work.
They're failing because the people who created
them weren't able to find a market for them.
>> My favorite example of this is a company called
Actuality Systems, which was actually here in Boston.
They created a 3D holographic display.
That's pretty badass, right?
They create it, and they got it working, and then
they spent the next 10 years-- so they created this.
This would be impressive to create today, right?
They created this over 10 years ago.
They spent the next 10 years trying unsuccessfully to find a market for it
and create a viable business out of it, and in the end had to shut down,
and all they could do was sell off 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 actually build a viable business out of this,
not so much.
>> And so what's interesting is there's been research
into what's the single biggest predictor of startup failure.
Do any of you want to guess what this is?
>> AUDIENCE: No market?
>> ABBY FICHTNER: No market, yes.
So something that actually I should have said-- something that startups do,
that if they do this thing, it's the biggest predictor that they're
going to fail, or the biggest indicator.
So no market is sort of something that happens to them.
>> So Don [INAUDIBLE] did a survey into this,
and what he found was the single biggest predictor of startup failure
was sticking to the initial business plan-- which
is pretty confusing, right?
Because if you're starting on any new venture,
you should try to figure out if you're on track or not.
Even that terminology, on track, implies that you're talking according to plan.
And so if sticking to plan means that you're going to fail,
it's very confusing.
Right?
>> And so that brings us to innovation pattern number
two, which is that you should really start small.
And this sort of breaks our mental model,
I think, for how people think about how startups operate.
Because I feel like we've got this image of startups as go big or go home, baby.
Right?
Like I've got a big vision, and boom.
I'm going to go big, and I'm going to be the next Facebook.
>> But the question is how do you do that, right?
How do you go from nothing but an idea to like a billion users,
like Facebook has?
How would you even build out enough features from day one
that you could appeal to a billion users?
And even if you wanted to build the next Facebook
tomorrow, how do you start getting people on it?
Because would any of you use "the next Facebook" if no one you knew was on it?
Probably not, right?
>> And so what I view startups as-- when you're really early
stages-- sort of doing the search for the intersection of our big vision
of what we want to accomplish with what reality can actually accommodate today.
And the way that you do this is usually through a series
of small experiments or small tasks.
So just to take a couple examples of companies that have made it big
and how they started, Microsoft started with writing
a version of BASIC, which is a programming language,
for the Altair, which was like the first home computer.
So I don't know exactly how 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, which is 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 about the mental model for how startups
should look, it should look more like this.
You start with your big vision, but then you go small.
And you figure out a way to dominate a really niche market,
and then you can build on that success to go big.
And there's a couple reasons for this.
One is if we accept the fact that sticking to the initial business plan's
going to fail, we're going to find 10,000 ways that don't work,
whatever, we're going to make a lot of mistakes.
We're going to have a lot of misses.
If we try to go big, we're going to use up all of our time and resources
on the wrong thing.
And so it's much better to go small so we can experiment quickly.
>> But even more importantly, it's so much easier
to be successful when we go small, because all you have to do
is find that market that you want to go after-- that really niche market.
And then just identify the one 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 wanted a way to program their computer.
And I don't know-- I think it was just like toggle switches
and blinking lights, right?
So I don't know how they did that.
So providing BASIC so they could program it is amazing.
Or Harvard students just wanted a single, centralized student directory,
right?
And so Facebook only had to provide that one feature.
They didn't have to build it out like it is today to really get traction.
>> So that takes us to number three, which is in order
to find that one feature that your market is really dying for,
you have to really deeply understand your customers.
And I feel like people underestimate the importance of this--
especially today, when there's so many startups that are out there.
If you are really looking at what's going on in the startup space,
you're going to find 100 startups all doing the same thing.
Right?
>> And that's because everybody can see that technology is here today, right?
But we want to be here.
So people see those gaps, and everybody tries to go after those gaps.
And you have all these startups all doing the same thing,
and you're like, why isn't any of them succeeding?
There's a gap here.
I believe that the ones that are going to succeed
are the ones that take the time to really understand their customers.
A great example of this, I think, is Dropbox.
When Drew Houston, the founder, went to try to raise money for Dropbox,
the VCs really discouraged him.
They're like, I don't understand why you're even entering this space.
There's already like a million billion cloud 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 Drew succeeded because A,
he started with a small market.
He didn't try to go after everybody.
He went after the hardcore techies who have
a lot of devices, a lot of computers, and they
have this problem in transferring files.
And he just targeted them.
And all he had to do was provide a solution that worked for them.
>> So again, I feel like there's a lot of myths around startups,
because we see so many startups happening today.
And you just hear the 20,000 foot view 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 happening in those success stories, time
and again, I think what you'll find are founders
who went to these extraordinary lengths to understand their customers.
So just to give a couple examples-- I don't know if this is still the case,
but at least initially, one of the co-founders of Airbnb
did not own or rent a home.
He just went around and lived in Airbnbs.
Like I don't even know what that looked like-- like living out of a suitcase?
>> Or Ben Silverman from Pinterest is amazing at this.
He went and personally reached out to the first 5,000 customers.
He gave them his cellphone.
He met them for breakfast.
I just spoke to their CTO a couple weeks ago.
And they're entering into new countries now,
and he's going out and doing it again.
So he's incredible for going out and individually talking to people.
So, of course, as you're going out and having these conversations, what
you want to be doing is always learning from your customer
about what's going to make sense and what's going to be successful.
I feel like the best startups, the best innovators,
treat innovation as if it was a science experiment-- or in a very
scientific way, I guess I should say.
>> So I'm not a scientist, but as I understand, scientists come up
with hypotheses, and then they develop experiments to validate or invalidate
their hypotheses.
And so the question is how can we do that with innovation?
We have an idea, but it's just an idea.
If we're truly doing something that's never been done before,
all we have are guesses.
Right?
And so what are some experiments that we can do to validate or invalidate
those ideas without building out 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 your customers, at least initially,
to understand who they are, what problems they
have today, how they're solving them today.
But talking can only take you so far.
Right?
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 be like, oh, yeah of course.
That sounds great.
>> Because people want to encourage you.
They see that you're excited about something, so they're going to say yes.
And people-- human beings are just terrible 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, hypothetical product, are you going to want it?
They might say no, but if you actually put it in front of them,
they might want it.
>> And so really, to do the test of understanding
if people are going to want it or not, you really
need to put something in front of them.
So I like this quote from Linus Torvalds, which is "Talk is cheap.
Show me the code."
Or if you're a startup, you might say, "Talk is cheap.
Show me the MVP."
>> So have you guys heard MVP, Minimum Viable Product?
It's kind of this buzzword that I 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 going to take you a year to build.
Instead, figure out what's that one thing that people are dying for?
What's the minimum thing I can build for them?
And put that in front of them, 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 or Gmail's new inbox, and they're like oh,
we're not ready yet!
I guess those are a little different, because those are ready.
But they give you a landing page, and it's like, it's invite only right now.
But give us your email address.
Right
A lot of places will do this before they've even built out the product,
just to see if there's interest or not.
So with Dropbox, drew Houston, there was complex technology behind it.
So he went, and he figured out the technology-- kind of proved that out,
that that was going to work.
But before he built out the final product,
he did this mock-up on his computer, this three-minute screencast
video-- very scrappy.
Put it out on Hacker News, because he knew was sort of his audience,
were the really technical people.
Put up a landing page that just said, here's the video.
We haven't launched yet, but if you're interested, give us your email address.
>> Overnight, got 75,000 sign-ups, which is incredible.
Even today, that would be impressive, 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 signal that he had gotten something right.
>> To give you a little bit more extensive of an example of that,
do you guys know Buffer?
It's a social media sharing site, and the idea
is-- I tend to read news at like 2:00 AM, because I
don't want to go to sleep.
And so I might read like 10 articles that are all really cool
and I want to share them with people.
But A, if I share them out on Twitter right now,
nobody is awake at 2:00 AM except for me.
And B, if they are awake, they're like why are you
spamming me with 10 articles at once, right?
And so what it does is it's kind of a queue or a buffer
that you add things to, and it'll push 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, and he thought this was a good idea,
but he didn't want to build it.
He didn't want to quit his day job yet until he
got some validation that other people thought 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 and Pricing, it just gives them
a "you caught us before we're ready." 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 good indicator 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 page when 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-- not for me maybe to quit my day job
and spend a year on this, but for me to just go heads-down and do
a really simple version of this.
He thought it was going to take him a day.
Technology's hard, so it took him like seven days.
But it was enough for him to spend seven days on it.
>> And very quickly, he started getting users on that first version,
even though it was very minimal.
And what was awesome about that was he was
able to see how people were really using it,
and then kind of evolve it based on them using it.
So Buffer's wonderful, because it's a really simple example.
Not all technology is that simple, but this
is sort of the quintessential Lean startup approach, right?
This is great-- you're testing it every step,
and you're only going far enough that you've
validated that it's kind of worth your time to do.
>> Another great way to get validation, of course,
is doing a crowdfunding campaign like Kickstarter,
where you can get pre-orders.
This makes a lot of sense if you're doing anything that's hardware.
Again, Pebble was the biggest Kickstarter
until that title got taken by a cooler-- did you guys see this?
Like an actual cooler that you bring to the picnic beat out,
so they got more than $10 million.
[LAUGHS SLIGHTLY]
>> But again, like Dropbox, with Pebble, 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 to get 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 doing pretty good-- pretty good validation.
>> So these ideas are all really great, but as we say in startups,
ideas are a dime a dozen.
It's all about execution.
So this is my favorite part is the "Focus!
And get shit done."
So the best entrepreneurs are able to just have
this crazy, intense hyper-focus and get things done at an amazing pace.
>> So I kind of walk through some of the development practices.
And ask questions if you have them.
I wasn't quite sure how much you guys knew about development practices,
so kind of have a discussion about what that
looks like when you're developing something like this.
So the first thing is to 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 all these ideas, and there's
so many different directions you can go, and so many different questions
that you have.
>> So step number one, figure out what to focus on.
A lot of times, as developers, as people who are thinking about technology,
we're really thinking about the products.
We think about things kind of in this order-- first, can I build it?
Assuming that I can build it, then can I get people to know about it?
Assuming that I can, can I make money from it?
>> But if we're trying to do a viable business,
we might want to be thinking of those in the opposite order.
The reason is I feel like-- and I do this myself, so I get it.
I feel like we get very hung up on this "Can I build it?"
question, because if you're a technology person-- if you're a developer--
you're really thinking about that.
>> But the truth is usually, when we come up with an idea for a startup,
we're coming up with it based on I've seen this technology here
and this technology here and this technology here,
and if I just combine them in some new way,
I think it would be really interesting.
Well, if I've already seen the technology 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 things that we're coming up with--
unless we're really awesome and doing something totally new, in which case,
figure out if you can build it.
But usually, most of the startups I see, you can build it.
That isn't even a question.
>> So start thinking about is something that people
are going to be able to pay me for And then how am I going to reach them?
That's really hard, especially if you are a technical person,
do you have a way to reach out to these people
and get them to buy your product?
>> So once you figure out, OK, what's that question-- kind of always have in mind,
this is the most important question that I need to be driving towards,
or the most important thing that I need to be validating.
And then you want to get back to this notion of eliminating waste.
Just figure out like the leanest, most efficient way
that you can go about answering that question.
>> So I talked about minimum viable product.
I would say get into this mindset of minimum viable everything--
by which I don't mean that you should be doing a crappy job at things.
I just mean how can you cut out the waste?
How do you get just right to the heart of the matter
and figure out how to validate things 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 I have this great idea.
Is anyone even going to want it?
So a really easy way to do that is a landing page, like we talked about.
You don't have to write any 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 what Buffer did with the pricing page,
or even better, a Kickstarter and get pre-orders.
Orders
>> The next thing that I think you're going to be wanting to look at is-- OK,
it seems like people wanted it.
It seems like people will pay for 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 get downloaded and then never used.
And that isn't helpful.
That's nice that you got a lot of people downloading it.
But if it's not used, you're not going to stick around for long.
When you're thinking about that first version
that you want to put out there-- your minimum viable product--
think about what is it exactly that I'm trying to test?
And what can I do that just figures that out?
I just kind of took a guess at this.
I don't actually know what Buffer's first version looked like exactly.
But if you think about Buffer-- just because of this simple example--
you might think this is what they feel like
as their first minimum viable product.
I need to be able to create a user account,
obviously, link it to my social media accounts.
I need to add posts like tweets into my buffer.
Edit them.
Delete them.
>> Set the time when I want those to be posted.
Obviously, the software needs to automatically post to Twitter
or whatever based on that schedule.
And then I should be able to view 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.
Right?
Be like, oh, Yeah whatever Look at it again, and keep saying is there a way
that I can get it stripped down even more?
>> So what is it we're trying to figure out?
If we're trying to figure out if they'll use it,
we're trying to see if are they even going to post anything to the bumper?
So this feels a little hacky, but if they haven't posted it to the Buffer
yet, you don't really need to allow them to edit
or delete or view posts in history.
If you can plant that something out there really quickly
and see if people can even add postings to it, once you see that,
you can very quickly start adding on this functionality.
But just get something out there.
Do you need to allow the user to set a posting schedule?
Probably not, if they're like me and they're just like,
I don't want my all my treats going out at 2:00 AM on Sunday night.
>> You can say these are the most popular times.
Whatever, we're just going to post it according to that.
You can probably do that.
And then I kind of made this up, because I know they only started with Twitter.
But obviously, you can just pick the social media
network that makes the most sense and just start with that.
And so now you're down to four out of 10.
>> And if you can get something out there, a pet peeve of mine
is that people think and MVP means crappy product.
And I don't think it needs.
I think you can get something out there that it's still useful,
but isn't gold plated-- is just the absolute bear minimum.
And I guess you have to kind of figure out based on your audience what's going
to make sense or what isn't.
>> But a lot of times you get something out there more minimal
than you'd think-- just a test, how people use it.
So as you're building out these features,
you want to think about what's the minimum viable process.
And so a lot of times when we think about really lightweight processes,
we think about agile processes.
We think about lean-- this is a little bit random-- just some agile and lean
books that I like.
So there's great practices like from Extreme Programming
and continuous integration, and refactoring,
which I'll speak to a little bit.
But the thing is, once you start getting into the Agile and mean practices,
it can very quickly get overwhelming.
And it can wind up begin real overkill for a startup.
>> So the thing is that a lot of these books
are talking about how to do Agile when you're
doing a product for an established company.
Right?
And you know who the market is, and you know what your product road map.
And they wind up-- even though we're supposed
to be light weight-- they wind up actually being way too heavyweight
for our startup, because the startup is just
operating at this completely different level.
So my feel is that when you're going a startup,
you need to be scrappy as hell.
Right?
So initially, there's no process.
You want to keep it as simple as possible.
And only add process that's sort of a just-in-time process.
OK, we see that there's a problem?
Let's add just enough process to address that problem.
Do you know what I mean?
It's because you don't want any of us holding you down, right?
>> Scrum is a really popular process for Agile development.
I don't know if you guys are familiar with this.
OK, well--
>> [CHUCKLES]
>> It would be just too overkill for a startup.
So I won't worry about that.
So OK, if you think about what's the absolute simplest thing that I need.
Well, I need to probably keep track of what
I'm doing, especially if there'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 see startups doing something like this,
is that very quickly, their in-progress column
tends to look like that, which is not very helpful-- especially if there's
only one person or only one developer.
Right?
>> Because you're not getting anything done.
All you're doing is going back and forth trying to get all these things done.
And so this is a really good example of 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 we want to do is put constraints
around how much work we can handle at any given time.
And so if we're one person, then we can only work on one item at a time.
Sorry.
So all that other stuff needs to go over there.
So what we do is we put work in progress limits on the columns.
If there's two people, it can be two.
You can figure out what makes the most sense for you.
>> But the idea is keep things sane, 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 mind is-- if you have a one item
that you're doing but the item takes three months, that
would be a difficult for a startup, obviously.
You need to be able to be flexible and be
able to handle things as they come at you.
You can't say I'm not doing anything for three months
until I get the login screen done.
I don't know.
>> So I advise startups to keep this really short,
to keep these tasks so that they fit into a day.
Obviously, if it's more complex, that might need to be a little bit longer.
But figure out what works best for you.
You can try different lengths.
But generally, just as an example, if you keep all the tasks
so they fit within one day, that means that every single day,
you're getting something done.
And you're providing value.
And that momentum can really 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'm overwhelmed looking at that.
And so if I was a developer and I was working on A, and I was like oh, shit.
I've got B and C and De and E and F and G and H. Blah!
Coming down the road.
I'm like freaking out, and I"m trying to figure out how the design is going
to accommodate all these things.
And the truth is that if we accept the fact that we don't actually quite know
what the product's going to need to look like until we've put in front
of a customer, then do we really know that we need all those tasks yet?
Or are we kind of fooling ourselves?
>> So if you really have all those ideas, great.
Put them in a notebook or a spreadsheet or something like that.
But I advise startups to keep 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 just hyper-focused on this
is what I'm doing, getting done this week.
Or maybe these two weeks, right?
And nothing else is getting in your way, and you're just
making sure that you're getting that out there.
And especially as you start adding new team members, this really helps.
A lot of people like to do this in software, which you can.
But it's even better if you all 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're figuring 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 actually have something called
emergent design, which is the same idea.
So have you guys heard of emergent design before?
OK.
>> S-- actually, I'm trying to remember where-- OK.
So the idea of a merchant design is rather than coming up
with this big, upfront design and saying I'm
going to spend a month figuring out the right architecture what components
go where and everything, let me just design enough for the features
that I know I'm putting in this first release.
And nothing else-- or the features that I'm doing this week, even.
>> And then only as I need new features do I figure out the design for those.
You're not figuring out design upfront.
I think in reality, it's not this on-off switch or this toggle.
I think it's more of a spectrum of where you've fall
on the certainty to uncertainty.
And so if in a startup up, or if you're building something that's never
been built before, you're pretty far over on the uncertainty curve
here, right?
>> And if you think about it in terms of the business plan-- like,
we talked about the single biggest predictor of failure
is sticking to the initial business plan.
If you do this big upfront business plan,
and you say I'm just going to blindly follow that and not do anything.
But you're just going to fail, right?
Because there was too much uncertainty.
And I feel like the same is true for design.
>> Sorry, so instead of doing a big upfront business plan,
you would do a very light weight 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't think about it at all.
It's good to think about it at first.
But just get it something really flexible out there-- just one page.
And then, as you go, kind of emerge that plan over time
as you learn from customers, and you can adapt to them.
>> And so then the same thing is true for design.
You can do a big, upfront design, but that
doesn't make sense if there's a lot of uncertainty.
A lot of people would argue there's never that much certainty in software,
even if you're not doing in startup.
So you never want to do that big of an upfront design.
But I feel like the level of design is going
to vary based on how much certainty or uncertainty there is.
And so if you have no freaking clue and you're just throwing something out
there like a landing page, obviously, you're
not going to go take the time to architect a whole system.
That's ridiculous, right?
So you don't need any upfront design.
A lot of times, the first version you put out of software for a startup
just gets thrown away.
And so a lot of times, even though I might say this,
you can just kind of hack something together.
It's probably going to be thrown away.
But again, use that just-in-time idea 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 a little 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 things that aren't there yet.
And the keep it simple, stupid principle--
do the simplest thing that could possibly work.
>> A lot of times, it's interesting, because as developers,
we get taught to do these really complex designs.
And we're taught that that's good.
But it prevents us from being flexible, and it can be really wasteful
if we wind up going in at different directions.
So Agile kind of says, don't do that.
Just figure out what the simplest way, the simplest code
that you can put in here that's going to make it work.
And then if I need to add onto it, I can kind of fix that code up
and readdress the design.
>> So there's something called refactoring that'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 mean that you're hacking.
That doesn't mean when you add another feature,
you're just going to kind of duct tape it on.
Right?
Because that's going to give you this big ball of mud code
that's going to be impossible to maintain.
The idea with the refactoring is OK, I know I only need, say, Twitter today,
so I'm not going to do this big abstraction that says,
oh, let me have this abstraction layer that will work with any social media
network that I could ever possibly think of it in the future,
because that takes time.
Let me just-- the simplest thing that could possibly work
is let me just make it known with Twitter,
because that's all I need to do today.
Then tomorrow, we realize OK, we do need to make this work with Facebook.
So refactoring would say, let me revisit the design before I even add Facebook,
and say given that I know that now I need
to handle most multiple social networks, what would the optimal design look
like?
Let me refactor the code to handle that design,
and then I can plug Facebook functionality in.
Does that make sense?
>> So a lot of people think, when they hear something like emergent design,
that you're doing less design or that you're just hacking.
But the truth is you're actually doing more design.
It's sort of the same thing with planning, right?
You're actually doing more planning-- it's
just that instead of doing it all up front,
you're doing it continuously as you go along.
>> So I think it's really great that you guys are taking CS50,
because I hear this so many times a 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 myself in the head when I hear that.
>> Because that kind of assumes-- they'll come up,
and they'll be like I have the idea all figured out.
I've got the business plan.
I've got the design.
I just need a developer to go code it for me, right?
And it's just assuming that they've got all the answers up front,
and this person can just go code it for them,
and they're going to make a million dollars-- which
just doesn't take into fact all the uncertainties.
>> So if we kind of look at the steps of development-- and I apologize.
This is a little waterfall-y.
But what typically happens is you figure out OK, this is what I want to code.
You take some time to develop it, test it.
Quality assurance is testing it.
And then once you've got an 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's think about how do we
maximize the learning that happens here?
Because if we just go heads-down for three months or a year or something
and put some code out there and it doesn't work,
then we're kind of screwed, right?
So where does the learning happen in here?
Some learning happens when we do requirements,
because we're talking to customers, and we're trying to understand about them.
But the reality is that most learning doesn't
happen until we actually put something in their hands
and see how they use that.
And so what this means is that the time, the places
that we spend the most time-- which is development and QA or testing-- there's
very little learning that happens.
>> And so if we look at this and say how can we maximize learning?
Or how can we reduce the time that happens between learning?
A great thing is continuous deployment.
I don't know if you guys have heard about continuous deployment.
So the idea with that-- instead of saying, OK, we're going to go.
We have this releases at three months.
We're going to build all the features for it.
And then only at the end of the release are
we are going actually push that into production
and put it in front of users.
>> The idea with continuous deployment is taking that to the other extreme.
So are you guys familiar with the version control?
So ideally, when you're working on your code, every time you
add some new functionality, you're gonna check it into version control.
So if you screw something up, you can always go back.
Or you can see what changed, if something's broken.
>> So the idea with continuous deployment is
as soon as you check something into version control,
it pushes the code to a staging server.
It's going to run automated tests on it, 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 pushing things out to the customer as fast
as possible, then we're getting the code into their hands.
We can see how they're working with them,
and we can really maximize learning.
>> So I'm going to talk through this a little bit more,
because I don't know if that was-- continuous deployment
can be pretty extreme, right?
And that can be pretty tough to do.
So people, companies usually kind of start with continuous integration,
and they work their way forward.
>> So continuous integration is this concept that's kind of the first part
that I talked about.
So the idea with continuous integration is
you still have your release schedule.
You're going to release every two weeks or every three months or whatever is.
>> But every single time someone checks some code in,
it does push the code onto a staging server.
The staging server looks like production and it
runs a series of automated tests on them to make sure nothing broke.
If something broke, then it's going to let everybody know hey,
the build was broken.
And everybody has stop and make sure it's fixed.
>> So that way, you're always guaranteeing that everything that you check in
is keeping the code at an OK state.
Then when you're ready to release it in the fraction, you realize everything.
Continuous delivery is sort of the next step in this process, which
is that every time you check-- it says the same thing-- every time we check
something into version control, it pushes it to the staging server.
It runs the tests on it.
>> But the culture is set as such that you always
keep the code so that it can be pushed to production at any time.
So with continuous integration, you might have a road map and say,
we're only going to push it to production in three months.
Right?
It doesn't really have to be ready to be seen by a customer.
But with this, you're saying at any given point in time,
you can be like yep, I'm happy with this feature set,
even though we're only two weeks in.
I'm going to go ahead and push it out to the customer,
and I know it's going to be OK.
>> And so you might have something like switches in your code
that say for features that 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 sure that you don't have anything
that's in this weird state, because it can push out to production at any time.
>> And just once you're in, you've kind of gotten everybody used to that idea
that you're always coding such that it's ready to go out into production.
Then it's not so hard to move to continuous deployment, which
is that every single time you 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 really scary concept, but it's
interesting to look at how some companies are doing it.
So Etsy does a really good job with this.
If you're interested, they've got a blog that
talks about how they do continuous deployment, which is really awesome.
They deploy to production up to 50 times a day-- right?
Which is crazy-- can you imagine if you go to the Etsy website, 50 times
in day, that site is being updated behind the scenes.
>> And in 2011, they deployed 10,000 times over the year with 100 engineers.
And what they said is contrary to what you might think-- like oh my god,
that's terrible!
The code, the site's going to be a disaster.
They said actually, once you're deploying that often, the system is
so much more stable, they actually call it confidence as a service.
Because when we deploy, we've already done this 9,999 times.
We got this.
>> It also makes it so much easier for them to experiment with things.
So what they said before is they used to release to production
every two weeks or every month.
And you guys might imagine if you've ever
got a deadline for a big project you're working on,
and you have this list of things that you want to get done,
and then as it gets closer to the deadline,
the list starts shrinking a little bit.
Like well, maybe I don't really 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 the release-- 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 less features, because they were only
releasing every two weeks or a month.
Now that they're releasing so many times,
it gives them this flexibility to say, you know what?
We want to build a new feature, but we don't
know if we should put a lot of time into it.
Let's put out this really minimum version of the feature
and see if anyone even clicks on it, if anyone's even interested.
If they are, then we can either pull it back and build it out,
or we can very quickly add new features to it.
>> And so they said it just gave them so much more flexibility to experiment.
And so it's really interesting to see bigger companies doing that.
And at a startup, especially, where it's so important to learn what's going on,
it can be really effective.
And then coming back to our Kanban board.
>> It's interesting.
A lot of times, when people do a board like this,
there's a lot of debate over what 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 reviewed it and it feels like it's tested?
Is it done when it goes out into production?
>> And so a lot of startups will say, you know what?
We're going to add a new column in here, which is a learning column.
It's not actually done until we've not 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 cool about that is then,
we get to incorporate that learning back into the cycle,
and say based on what we'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 I have seen for successful innovation
across the startups that have been successful.
I was going to also talk a little bit about resources
that are available if you're interested in doing a startup iLab.
But I can also stop it here, if you guys have questions about what I talked.
Keep going?
OK.
>> [CHUCKLES]
>> OK, so do you know about the iLab?
OK, awesome.
So the iLab has awesome resources.
If you're looking to do a startup, we have anything
from-- we do hacknights there.
Sometimes, we do hackathons, if you just want
to go hack on cool projects with people.
>> We have workshops.
We have classes that re for credit that are kind of cool on entrepreneurship
that are open to-- most of those are open to everybody.
But we also have free workshops a couple times a week,
that we just bring in experts from the industry
to talk about anything-- from technical concepts, to raising money,
to how to do sales.
>> Anything that you want around startups, we
have experts and residents who are available to do one-on-ones.
You can just sign up for office hours with them.
You don't even have to have a startup.
Just if you've got ideas and you want to balance--
get information or insight 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 hate getting email, but it's cool.
We have so much going on, I don't even know what all it is.
So if you sign up for the newsletter, we'll
let you know every week what's going on.
You can also look at our calendar to see what events are coming up.
>> And I am there to help if you want to do a tech startup.
>> [CHUCKLES]
>> So that's what I've got.
>> [APPLAUSE]
>> [LAUGHS]
>> Thank you.