Lean Startups and Sproutcore

I'm in the process of reading Running Lean by Ash Maurya. It's an excellent book that I would recommend to any entrepreneur, whether they are working on the web or not.

In a society where 9 out of 10 startups fail, some thinkers such as Steve Blank, Eric Ries, and Ash Maurya have been advocating a new approach to starting companies, based on the scientific method. They've named it Lean Startups.

Most entrepreneurs build startups assuming that their initial plan is flawless. They come up with an idea, develop it in their heads, then get a team together to execute on it. Often, when their product is ready to hit the market, that's when they realize that they've built something that no one wants or needs.

The problem is that an entrepreneur's initial vision is based largely on faith and untested hypotheses. That's why most Plan As do not work.

In his book, Maurya makes the case that "what separates successful startups is not necessarily starting with a better initial plan (Plan A), but finding a plan that works before running out of resources." He lays out a systematic process for building startups that involves iterating from that flawed plan A to a plan that works, by making and testing hypotheses along the way.

He advocates first creating a plan A. No need for a lengthy business plan here. A single page document describing that plan A is enough at this stage. This document lists things such as the customer segments targeted, the top 3 problems the company will be solving, the solution they've imagined, etc... He came up with a format for this document which he calls a Lean Canvas.

With the plan A in hand, the next step is to verify that the problem the company is set to solve is indeed a problem that the customers targeted have experienced. To figure that out, an entrepreneur should conduct interviews with people that belong to his target customer segments until he understands the problem.

Once he understands the problem the next step is to build a Minimum Viable Product (MVP), which solves the problem. This is not a final product, but just a demo that the entrepreneur will use in the subsequent round of interviews. Maurya says: "The main objective is using the demo to illustrate how you intend to solve the problem, convey your unique value proposition, and test pricing." Therefore, the demo needs to be realize-able, needs to look real, needs to allow you to iterate quickly, and needs to minimize waste.

Maurya says that he himself uses Ruby on Rails to build these demos: "For those familiar with the Model-View-Controller pattern, I build my demos by going in the complete reverse order. I’ll first setup some controllers, then sketch the views on paper which I’ll then translate to HTML/CSS. The model is something I tackle only after I’ve qualitatively tested a screen and got a strong signal to implement it."

At Intellum, we've invested time into learning the Sproutcore framework in the last year. We've developed pretty good expertise in building applications quickly using this framework. As I was reading Maurya's requirement for a mockup and the way he uses Ruby on Rails to create his demos, it occurred to me that Sproutcore is a perfect tool for a Lean Startup. Let me explain.

The way we develop Sproutcore applications at Intellum is to start by laying out the User Interface (UI) the way we envision it. We can build a complete UI very quickly without the need for a backend by using data from client-side fixtures. The result is a fully functional application that we can serve from a web-server and have customers test-drive.

This approach meets the four criterias for a good demo listed by Maurya:

Realize-able

What we show a customer during these interviews is exactly what they will see when we are done with the product. There are no un-met expectations, because we are building the demo with the same tool with which we will build the final application.

Looks Real

The demo will not only look real, but the customer will be able to 'drive it' by clicking around and seeing what exactly is happening.  Not only will the UI behave as a customer would expect, but this UI will actually be backed by a data model (Javascript objects) just like the real product will eventually be built.

Quick Iterations

Sproutcore views are very quick to build, and since we do not connect these client applications with the backend (we use client-side fixtures), it's really easy to iterate quickly and change things around in the mockup. Furthermore, we build applications that are backed by statecharts. This approach tends to make it really easy to quickly refactor the code and change things around. If you've never developped an application backed by an in-memory statechart, you should give it a try. It's a really nice and agile way to build applications.

Sproutcore also ships with a good set of UI widgets that we can use to create these demo applications. This means we spend less time designing. We do not need to involve a designer early in the process because these widgets are good enough for a demo.

Minimize Waste

There is literally no waste with this approach. All the code we wrote for the demo will be used for the final product. When we've found a demo that solves the problem at hand, we can quickly go from that demo to the final product. All that's needed is to create a backend for the application, modify the client-side code to use that backend instead of fixtures, and make other appropriate changes.

To make the process of demo to real-app even faster, we've been experimenting with using and syncing changesets between the client-side application and the server. This approach is very portable from application to application as a lot of the code can be reused.

As a matter of fact, whether you are using a lean startup approach or not, this is the best process we've identified to build Sproutcore applications so we do not have to take any detours in building our application. With Sproutcore, the development process closely matches the Lean Startup approach to building startups.