Recently, my job has changed a bit. I’ll probably write about that in a post coming up, but for now it suffices to say that I’m definitely spending more time than usual thinking about entire projects and all aspects of the project. Naturally that has me thinking about process more. I have always tended to prefer Agile methodologies, and the Lean flavors in particular.
However, I didn’t feel that I really had a solid background in the lean parts. While I’ve understood the processes and motions and studied Lean manufacturing in college, some of the motivations and subtleties are tied to a deeper understanding. I feel like I needed to spend some time reading the best works on the subject. Practical experience on lean teams is great, but I wanted more.
With that in mind, I reached out to Rick Simmons (@simmons3k). I used to intern for Rick way back in my college days and we keep up and discuss software, Agile from time to time. Rick is an Agile Coach for Rally, and at one time helped implement and improve Agile processes at Constant Contact. Needless to say, he’s an expert in the area. Rick was kind of enough to give me a list of Lean books that he recommended, and I got the idea to publish the list as a post with his permission.
A couple of months ago, I finished reading Eric Ries’The Lean Startup. It got me to thinking about startups and small projects I’ve been a part of in the past.
In particular, I think of a social site for readers that I was apart of that failed. I think of the the end, where I was trying to make the case to launch something and let users drive the feature list. What I find really frustrating is that I did such a poor job of communicating that at the time. Reading the book, I hear a much better way of emphasizing the point of customer feedback loops. The minimum viable product with hypothesis and user testing driving the next steps; it has so much value. Additionally, that movement has a number of successful followers to their name, so they have credibility with their message. Timing and other market factors may have doomed us anyway, but I can’t help but thinking of what could have been different armed with some of that information at the time.
The other part of the book that really resonates with me is how hard successful startups are. People are so afraid of there idea being stolen. In the book, Eric Ries suggests that you try to have someone steal your idea (it’s hard to do). He’s right. If someone actually wants to steal your idea, at least it validates that other people think it’s a good idea.
I get approached by people with startup ideas a lot, looking for programmers who want to work for equity. For young developers with the time, I think they should get involved, it’s a great way to learn the realities of business and to get some extra experience. But beware of how much of a longshot it is to get the product successfully to market. It has to be a good idea, successfully built, successfully marketed, and fill a timely need. Miss any of those categories, and you probably won’t do much.
I’m not suggesting people avoid startups. They are a great learning experience and some of them work out. But go in with your eyes open to the amount of work you have in front of you. And be discriminatory about where you choose to invest your time. Are the others involved willing to put in the same effort you are? Will this new organization be capable of all of the things needed to be done to launch a product?
My advice for evaluating an idea: run a set of books for the project (meaning keep accounting). If you’re working for equity, keep track of time anyway and what you could have been paid at your regular rate to do that work. How long will it take for the project to pay that back? That question opens a lot of eyes. Say what you will about money as a measuring tool, but it’s the standard for all projects and companies. It’s relatively objective, and very compatible with math. The same can’t be said of a subjective goal like “let’s take over the XYZ market.” Presumably, you have your day job because you make someone more money than you cost them. If you can’t say the same of your startup project within the first year, then your project doesn’t even have the ROI of your “boring old day job” (you may love your job, my point here is that people thing of startups as high risk / high ROI and that may not be the case). Every time you sit down to put more into the project, you’re saying that you will get that back in cash on the other end. Is that true, or are you kidding yourself?
There can be other reasons to do a startup. I’ll use a personal recent example. I built VicinityBuzz, and iOS application around Social geo-search (also coming soon to Android and WP7). It’s been slow out of the gate so far, but I’m hopeful that some of the new features coming in the next update and some marketing ideas I have will help. Regardless, I’m certainly a long way from paying myself back for the time I put in. But I have been working in cutting edge technologies more and mobile is a real focus. I knew even if the project never paid for itself that it was valuable time learning and to put the project into my portfolio of work. I went in with those realistic expectations, but try really hard to exceed them.
If there is intended to be a single message of this post, it is to apply measurable goals to your projects, and evaluate and pivot your direction as often as reasonbale. If I had to boil down the message of the book to one sentence, that would be it.