4 Ways to Succeed at the Lean Startup Machine

I heard about the Lean Startup Machine onLean Startup Machine my first day of work at HubSpot, the day before the event was to start.  So of course, being me, I figured that rather than have a relaxing weekend and exploring Boston, I would jump right in and make this the first weekend in my new city. I also figured that this would be a). a good way to meet people, and b). my one chance to participate in such a workshop.
Initially I started this article with a description of what the Lean Startup Machine is, even what is the Lean Startup methodology, but I realized that this was pointless. There are tons of good resources that can describe them better than I, so if you’re curious you can check out the links at the bottom. I’ll only say that the Lean Startup Machine is a series of workshops and talks that take you through the entire process of building a business over the course of one weekend. I’m also including a sample schedule so that later references make sense.

Schedule

LSM Boston schedule

The other thing that I started out to do was to simply describe my experience, but I realized that my blog is for other people not just me. I’ll write all about my experience in my journal. Rather, I’m going to discuss my key takeaways from the weekend so that hopefully someone will find some valuable insight for the future. I would also mention that these insights, while they came out of the one weekend, are really generalizable to any startup following the Lean Startup methodology.

  1. Find a great team

    Team

    My team

    As I’ll mention later, the idea matters much less than the team. Your idea will continue to change over the weekend, but your team won’t. These are the people who are going to cause the success or failure of your weekend both in terms of your learning and succeeding at building your idea. After the opening talks, these are the people you will be spending all of your time with for the next two days, so you’d better like them.

    One thing to think about is how you will use the available networking time at the beginning. In the schedule, there is 30 minutes allotted at the very beginning for dinner and networking. I highly recommend using this to scope out potential team members. If you really take the opportunity to meet people and talk, you can get a much better sense for who you might want to work with.

  2. Elect a team leader

    This may seem obvious, but in retrospect, we should have thought much more carefully about our team’s organization. Since one of your teammates will be the person who originally pitched the idea, they can implicitly become the group leader since they have the clearest vision. I would warn against accepting this at face value rather than discussing group leadership directly, even if you end up electing that teammate as group leader.

    By discussing out in the open who your group leader will be, you can clearly establish leadership in the group. As I have learned the hard way on multiple occasions, you simply cannot be as efficient without a clear group leader. It is so easy to become sidetracked, especially when you get together multiple people who are enthusiastic about an idea. By having a clearly defined group leader, you have someone who can take charge of keeping the group on track without any resentment from others, which will ultimately ensure your productivity.

  3. Know where to find your target customers

    This can be a little tricky, as your target customer may change, but just remember that you have one weekend to interview as many people in this demographic as possible. We made the huge mistake of targeting teachers and parents of young children. While these people may be out in force during the week, it can be hard to find them on the weekend. When they do go out, young parents have kids in tow and are distracted enough without you trying to interview them. Because a key part of the Lean Startup Machine is interviewing people, you need to be able to find those people, so whether its through internet forums or parts of town where they congregate, know how to find your customers.

  4. Don’t be attached to your original idea

    There isn’t too much to say about this because the Lean Startup methodology essentially requires it to be the case, but some people definitely struggled with this so its worth a mention. When you are going out and interviewing people, it becomes clear very quickly that not everyone likes your idea, which is somewhat disheartening. On the flipside, however, even a couple people saying it sounds interesting can be enough for you to convince yourself to persevere. This is where it becomes essential to create hypotheses and stick to them. It is so easy to rationalize undesirable responses in your interviews. You have to set your hypothesis (‘5/10 people will give us their email address’), and even if you’re slightly under (‘4/10 people gave us their email address’), you have to pivot. There’s no looking back. And one thing you should look for when picking a team is how willing people are to part with their ideas, because that can be really hard.

Overall, I would highly recommend the Lean Startup Machine to anyone who is interested in starting their own company.  The Lean methodology really allows you to go from 0 to 60 in a matter of days, which is invaluable in the fast paced startup world. I also can say without hesitation that there were things that I struggled with before the workshops and continue to struggle with now, but having mentors available to teach you how to interview people or how to pivot your idea shows you how you can improve.

If you liked this article, please subscribe and leave me a comment. I’d love to hear from you!

Resources:

Lean Startup Methodology

The Lean Startup by Eric Ries

This is the book that coined the Lean Startup methodology.  Definitely worth a read.

How to Build a Startup by Steve Blank

This course on Udacity is a great introduction to the Lean Startup methodology taught by one of the greats.

The Lean Startup Machine

Advertisements

The Inception of WhatWouldMyHarvardGrade.Be

For anyone who hasn’t already seen it, Harvard Crimson LogoThe Harvard Crimson recently published an article entitled Substantiating Fears of Grade Inflation, Dean Says Median Grade at Harvard College Is A-, Most Common Grade Is A.  As is pretty clear from the title, the article pointed out that the most commonly awarded grade at one of the world’s most elite institutions is an A.

For most of us at Princeton, the news of this rampant grade inflation was more than a little depressing.  Since I’ve been at Princeton, I’ve known that for the same amount of work at Harvard, I would have been getting an A- instead of my B+.  Even though it doesn’t sound like much of a difference it looks very different on your transcript (and that is what potential employers are looking at).

Consequently, I have been contemplating for a while (ever since I took statistics) making a site that would do an accurate conversion of your grade at Princeton into the equivalent of that at Harvard using a statistical analysis.  I still haven’t gotten around to that (and it turns out something like that already exists: http://gradedeflation.com/), but the Crimson article got me thinking.

The one other thing that I have wanted to do for a while is to create a viral site.  This would be for no other reason than to watch the traffic flow in and see how far and fast it can spread.  I envisioned something like isitchristmas.com or whatrhymeswithhug.me.  It would have to be something simple with no real purpose, but I didn’t really know what to do.  I wanted to capitalize on some sort of social trend, but I’m not necessarily the most on top of things so it seems that someone always beats me to it.  So finally this time I felt like I had a good idea.

This is what led me to create whatwouldmyharvardgrade.be.

Over the course of the day that the article was published, it appeared on my newsfeed countless times.  I started talking with my girlfriend about the possibility of throwing together a site and we realized that it would be easy (and pretty funny, in our opinions).  After I got home around 12, I registered the domain and set up the site in all of 30 minutes.  The longest part was just waiting for my custom domain to get linked together with my AppEngine app.  And that was all there was to it.

Finally, once all was done, I wrote a single Facebook post, which I published at 2am.

Facebook post

I wanted to see how this would grow organically, so it was important not only to hide the fact that I had myself created the site, but also not to do much to promote it.

From this single Facebook post, the site got 60,000 unique views on the first day.  Clearly creating something relevant is all you need to get viral traffic.  Promotion, while it may help, is completely superfluous.

Since then, the traffic has died down, but the site still gets several thousand views per day.  A few days ago, the site passed 100,000 views, which I think is phenomenal for the 30 minutes of work that I put in.  While this may be a little narcissistic, it amuses me to search for the site on Facebook and Twitter, just to see what sorts of gems I find.

traffic stats

Traffic stats

Facebook stats

Facebook stats

My very own Crimson article: The Harvard Grade Generator

Twitter:

Anyways, thats about it.  I hope this doesn’t seem too braggy I just wanted to talk about something that I think is pretty cool.  Also:

Disclaimer: I totally mean this as a joke, so I sincerely apologize if anyone from Harvard was offended by this site.

Using Git Properly

To anyone who has tried to figure out how to use git on the command line, it is clear how much there is to know.  Most people provide an exhaustive list of all of the possible commands, which is overwhelming and not very helpful, especially for a beginner.

I am not going to do that.  Instead, I will show you a standard workflow that will work for any of your projects and the 8 commands you need for that.  Trust me, once you know these 8 commands, they will be all you need 98% of the time.

Standard Workflow:

I am going to discuss this from the standpoint of someone working on a project that is on Github and has multiple contributors.  However, even if you are the sole contributor, you can follow the exact same workflow.  I am also going to assume that you already have your project set up, but if you don’t, there are good instructions on Github.

The general git workflow goes as follows:

  1. Make sure that the local version of your project is up to date.
  2. Create a test copy of your project (branch).
  3. Make all your changes and test in this branch.
  4. Check again to make sure your local version of the project is up to date.
  5. If you are happy with your changes, merge them into the main project.  Otherwise you can delete them.
  6. Update the version of your project on Github.
Git branches

Here you can see sort of what this might look like. The grey circles are the main project, and the yellow ones are your branch.

 

Now lets actually look at the commands for this process:

1. Pull

First, we have to update our local version of the project.  This is actually unnecessary if you are the only one working on the project, but its not bad to just do it anyway.  For this we use the pull command:

git pull origin master

This will pull the master branch from your online repository and update the master branch in your local repo.

2. Checkout

Next, we want to create a new branch for us to create our new feature.  First, we want to make sure that we’re on the master branch.  We can switch to that with the command:

git checkout master

The checkout command will switch our current branch to the master branch. Now we want to create a new branch:

git checkout -b update

By adding the -b flag, we are telling git to create a new branch with the name update before switching to it.

Now that you have created a new branch, you can go ahead and make any changes that you want to your code.  If you mess up and want to just get rid of the branch and start over, just do:

git commit -m "Commit message"

git checkout master

git branch -d [branchname]

3. Status

Now that you’ve made changes, it is time to save (commit) them in git.  Status is not actually an essential command, but it is very useful:

git status

This command will show you which files have been changed/added.  It also shows you which files will actually be committed.  If you accidentally changed files you didn’t mean to change or you forgot to stage a file to be committed, this can be helpful.

4. Add

Once you are satisfied with your changes, you have to ‘stage’ them so that git knows which files to commit.  If you want to add all of the new/changed files, it is easy:

git add .

You can also add individual files:

git add [filename]

This will tell git to commit all the files you have added.  You can also use status again to see which files are now staged.

5. Commit

Once you’ve staged all of your files, you have to actually commit them:

git commit -m "Commit message"

Git requires you to add a commit message, and by adding the -m flag, we are able to add the message in the same line, instead of being prompted to add a message after committing.

Now it is time for us to merge our branch back into the main branch.  You want to make sure that you triple check your branch before merging it back because if you merge in a bug, that defeats the purpose of making a branch in the first place.

6. Merge

Merging will require 2 steps.  First, you want to pull again as you did in the first step (and again, this is unnecessary if you are the sole contributor).  This will ensure that you are merging into the most up-to-date version of the project.  Then:

git merge [branchname]

This will merge [branchname] into the current branch, master. Unless multiple people have made changes to the same lines of code, git should be able to do this automatically.

7. Push

Now we need to update the version of the code on Github:

git push origin master

This will push the master branch from our local project to the main version on Github.

8. Branch

Finally, this step is simply a matter of preference, but I like to delete any of my branches when I’m done with them.  This allows me to reuse the same branch names.

git branch

This will allow us to see the names of all of our branches, as well as which branch we are currently on (denoted by a ‘*’). To delete a branch:

git branch -d [branchname]

Just make sure you don’t delete the master branch, and you can’t delete the branch you’re currently on.

 

So there you have it.  This general workflow is what I use 98% of the time when using Git.  Of course there are many other things you can do as you become more of a power user, but hopefully this will be a good start.  In the near future, I hope to post a cheat sheet that will just have descriptions of some of the most useful commands (mostly the ones used in this post) so that you can refer to them as needed.

I hope this post has been helpful.  Please let me know what you think of it!

Learning Best Programming Practices

Anyone can write code.

Well maybe thats not exactly true, but the point is that its not too hard to learn to code.  With sites like Codecademy and Udacity that teach many different programming languages as well as countless books, anyone who has a computer can learn to write programs.

If it so easy, why are programmers still in such high demand?  Because you can learn to program, but its really hard to become a great programmer.  Now bear with me for a second.  Of course you can learn everything about a language.  You can learn every keyword and every structure, but that means nothing if you can’t put it together into elegant code, which as it turns out, is really hard.

What it really comes down to is best programming practices.  You have to know them.  You have to use them.  And they’re hard to learn, especially by yourself.  An email I received from a professor at the beginning of this year is particularly indicative.  I had asked him to confirm the reading list for the semester so that I could get a head start and his response was:

I don’t want you to pick up too many bad habits before we begin!

So my question was always: How can you actually learn best programming practices?

I think I’ve figured out the answer.  There are 3 parts.

  1. Code review
    Letting great programmers critique your code is crucial. Sometimes it is as simple as you not knowing the most concise way to express a function, sometimes your logic is overly complicated.  In code, like in writing, the more you can simplify the better.  Having someone smarter than you review your code is a great way to see the flaws in how you write your own code.
  2. Pair programming
    Most of the times that I write inelegant code, I did not know of a better way to express it.  Working side by side with great programmers code is a great way to get inside their head and see how they approach problems, so you can compare this to your own approach.  A common scenario: “Whoa, I didn’t know you could do that like that!”  This is why I find pair programming to be so essential in improving my programming skill.
  3. Read elegant code
    I hate reading code.  Unlike in pair programming, you are looking at a finished product so you have to work very hard to deconstruct what the writer did.  However, reading elegant code is another great way, like pair programming, to learn things that you never knew were possible.  Once you figure out their logic, an elegant program can become a truly beautiful thing.  And then you know how to do it yourself next time around.

To make a long story short, becoming a great programmer is hard.  As Malcolm Gladwell says, it takes 10,000 hours to become a master at anything.  But if you follow the steps above, then you’ll be well on your way.

A Computer Science Education (in theory)

Last time I checked, Princeton offers one truly practical Computer Science course.  One.

Advanced Programming Techniques, taught by Brian Kernighan, which is really a software development class despite what the title may suggest. The course revolves around the six week group design project, where students create full-on applications or websites.  Many of these are Princeton-related and have become staples on campus, such as the Integrated Course Engine and other TigerApps.

This is, however, the extent of Princeton’s practical CS curriculum.  There are certainly other classes that contain practical elements or information that could be directly applied in the real world, but classes have a tendency to focus heavily on the theoretical end of the spectrum.  And there is no equivalent to courses such as Stanford’s CS193p (iOS Programming), despite it certainly being a topic of great interest.

Let us consider two of the introductory CS classes, Intro to CS and Data Structures & Algorithms.  Both of these classes use Java extensively, but I came out of these classes lacking fundamental elements of the Java language, the things that would be in any Intro to Java book.  I did not know Standard Input or Output, how to access the filesystem, draw to the screen, or even use Eclipse or a simple debugger.  Instead, I knew how to do these things using custom libraries that would be useless to me beyond the scope of the class.

Now clearly these classes were about Computer Science, not Java in particular and certainly did teach me much of the relevant theory, but what if I wanted to become more skilled at Java?  There’s no course for that.  There’s no course for Web Design, or Mobile Apps, or Game Design, or really any other job that I might be looking for.

So why aren’t there classes for that?  I would love to tell a prospective employer ‘yeah, I took a class on exactly that thing that you’re going to have me working on,’ but the fact of the matter is I can’t.  Princeton believes that once you know the theory, it is easy to learn the practical bits.  If you know how to design an algorithm, you can write it in any language.

I think this is a valid assumption, at least to an extent.  Any programmer knows that once you learn one language it is easy to pick up another.  But not as easy as having someone teach it to you.  I would prefer having someone teach me the specifics, but maybe some people feel differently.  In this way you can focus your limited class time on learning the more difficult topics, while parsing the ‘simpler’ ones on your own.

The real challenge comes in the sense that any prospective employee has to prove himself.  It is not enough to say that you took a class about that, because there are no classes about that.  Internships and personal projects become increasingly important.  You have to find time outside of your classes and work to improve your coding skills and build up a practical baseline to show employers.

As long as you are willing to put in the extra effort, a theoretical CS education has great potential, as it creates students who can learn new technologies on their own and adapt to new challenges, ultimately becoming stronger Computer Scientists if they can keep up.

The One Man Startup

Clearly its been a long time since I’ve written anything.  I have yet to finish my series of posts on setting up a cheap website (which I promise I will do, if anyone reading this actually cares), but at some level I just gave up on this blog for about a month.  Right after writing a post about getting over the slump and motivating myself, too.  But now I really want to commit to this.  If anyone has any ideas of things that I could/should write about or anything that they’d like to here, let me know.  I will certainly be writing at least one or two more posts about RightCall as the summer winds to a close, so keep an eye out for those!

Anyways down business (literally).

Empirically it seems to be hard to start a startup with just one founder. Most of the big successes have two or three.

Paul Graham

In Paul Graham’s list of 18 Startup Mistakes, the very first mistake he listed was “1. Single Founder.”  Well I guess I sorta screwed the pooch with that one.  I am sure that this is not always true, and Paul does cede that there are exceptions, but it does seem to be overwhelmingly the case that the best startups are formed in teams.  Even Dropbox, on whose Y Combinator application Drew Houston listed himself as sole founder, was founded by a team for all intents and purposes.

Completely ignoring all of this advice, I obviously went ahead and struck out on my own.  I’ve mentioned this in a past post, but here’s the problem: There’s way too much for one person to do.  Period.

What I didn’t fully consider going in was simply how many different things there were to get done.  There is development, business, marketing, bookkeeping, all of which can be broken down even further so when building RightCall, I had to make a decision.  I reached a fork in the road where I had to choose what sort of startup I wanted to be.  I could go the route of building a business, marketing and conducting extensive research, validating my product and iterating until I had a good sense of what to build, or I could just build it.

The Lean Startup methodology doesn’t work so well if you have to do everything yourself.  Steve Blank recommends getting out of the building and contacting at least 10 people per day per founder until you set up “enough meetings to fill your calendar.”  At the same time you need to build an MVP (it doesn’t need to be great but someone still has to build it).  But guess what happens when your calendar is full of meetings.  You don’t have time to build an MVP.  And the opposite problem is also true.

Now the clear choice is to split your time between the two, maybe alternating days of meetings and dev, but I would argue that this doesn’t work.  In a startup, where speed is everything, you are severely limiting yourself when you divide your time that drastically.

The other possibility, which I would argue is better if you are a developer building a startup as, say, a summer project where you have a limited timeframe.  Just build the damn thing, who gives a crap about the users.  If you are building a startup during your summer break, you are building a project for your resume.  If you are a developer, then what people really want to see is a portfolio.  So just give them a portfolio.  If you build something awesome, no one will care how many users you have.  And if it is truly something awesome, then you will get users organically.

And here is where I failed.  I admit it.  I tried to split the difference.  I attempted to take into account lean methodologies while developing my own software.  Recently (in the last two weeks) I have realized the importance of focusing on development, which I am pleased to say has been going well, as I think is apparent to visitors to the site.  Clearly time is a scarce resource, and I would say that you should put it where you will see the fastest results.

If you are working on a startup longterm (and I mean fully, not as a side project, like I plan on doing with RightCall during the upcoming year), I’m sure that the Lean Methodology will be beneficial.  If you can find a partner, it will be even better.  Just between research and development, you have two full-time (and thats startup full-time, 10am to 10pm) jobs.  And I haven’t even gotten into marketing and social media, which is at least as much work.

So is Paul Graham right?  Probably, much as it pains me to say.  Not that I regret going at it alone and it has been (and I hope will continue to be) a great experience either way, and you never know, maybe something will come of it.

The Two Week Slump

As far as I can tell, this is something that everyone experiences.  When you first have an idea, you are so excited.  You have the motivation and energy to work on it constantly and initially you make rapid progress, but eventually this ‘honeymoon period’ has to come to an end.  For me it took about 2 weeks.

In fairness, I have had some personal issues in the last week that kept me from working as much or writing blog posts, but I find that the motivation simply is not there in the way that it was a week ago.  Although it is still early and I don’t know what will happen into the future, I wanted to report my findings.

Reasons for the slump:

  1. Hard work.
    If you’ve ever heard someone say that starting a company is a lot of work, they’re right.  As a CS major at Princeton University, I came into this with the impression that I understood how to do hard work (20 hour theory problem sets), but a startup isn’t like that.  You are never done with your work because there is no right answer and therefore work follows you around constantly.  There is also a huge amount of trial and error because you can’t just look up the answer.
  2. Too much work.
    If you’ve never heard this before, investors tend to dismiss startups with only a single founder.  I ignored this warning sign and struck out on my own.  While I am not going to give up and start again, I promise you that next time I won’t be so naive.  There is simply too much at a startup for one person to do.  In the past few weeks I have been trying to balance all of these things: planning, market research, social media, product planning, product development, accounting, legal, etc.  Its a lot to manage and at this point I don’t have the money to hire people, so you need a co-founder who is invested enough in your vision that they will be happy to work for equity.
  3. No results.
    This shouldn’t be a surprise, but its hard to get any results when you don’t have a product.  While this may seem trivially obvious, it does lead to a severe lack of motivation.  When you see clearly the fruits of your labor, it is easier to see light on the road ahead.
  4. Gritty details.
    As part of the product development process, there are simply things that are a pain in the ass that suck but you have to do them.  While you can avoid these initially by getting other things done, you must face them eventually.  If you have any tendency towards procrastination, these are the little things that trip you up and keep you from getting things done.  Whether it is making that one phone call or writing content for that one page on your site, this can create a substantial mental block.

The obvious question now is: where do I go from here?

I am in the middle of this now, so there is no way I can give an informed answer, so instead I will look at what steps I am planning to take based on my research, and at some point I hope to do a follow up on this post to see how all of these different techniques worked.

  1. Surrounding myself by motivated people.
    Currently, I am working in a co-working space called Tigerlabs where there are many other startups.  This is invaluable because other peoples’ success is helpful at inspiring my own.
  2. Keeping a strict schedule.
    I find that this is extremely important for me to get work done.  If I don’t make myself get to the office by a certain time, I’ll never get nearly as much done because it is so easy to procrastinate.
  3. Setting goals.
    When I don’t know what to work on, I get lazy.  I’ll do lots of little tasks that aren’t necessarily relevant to my ultimate goal.  A couple tools that I find helpful for this are PivotalTracker/Trello (project management) and Producteev (to-do list).  This can also involve setting deadlines, which may be helpful.
  4. Motivational reading.
    It may just be me, but I find that other peoples’ success stories are quite motivational and inspire me to keep working.  I like startup blogs (I don’t have any favorites) and my two favorite motivational books are The 4 Hour Work Week and The Millionaire Fastlane, both of which are both inspirational and have some useful information.
  5. Staying healthy.
    I know that I feel better and more productive if I stay in shape, so I try to make a routine of going to the gym every day before work.

Hopefully with time and making use of these strategies, I will be able to overcome this slump and move forwards.