I would like to thank Jeff Cordova for his extensive feedback on a draft of this post.
For consumer web products, my rule of thumb is that it should take 90 days to get from IDEA and TEAM to your first external [closed] Alpha. In Part I of The Product, I suggested leading with design. I do want to be clear that: (1) during the period of time when your designer is working on mockups, the rest of the team should be busy working on key technology choices, and; (2) that the entire 90 day period [and beyond] is about constant iteration.
Hopefully the entire team is sitting near each other, because as soon as you divide up to work on your own task problems that you hadn’t considered will quickly surface. By having everyone there together, you can knock those problems down quickly and move on. As every entrepreneur quickly learns, where you end up is a very different place from where you started. As Jeff Cordova reminded me in his feedback on this post, “nobody has ever built a *world changing* product using top-down thinking. Instead, it requires dozens or even hundreds of product iterations to get there.”
Make a priority ordered list from 1 to 10 with the key features that you want to build. Push yourself to draw hard lines between each feature? Is Feature #1 by itself an interesting product? For a web product, that should be your goal — adding features is easy, but taking them away is hard. Your mocks should focus only on what you will ship in 90 days; focus is key in the early days of a new product.
The architecture.
All new web applications should follow the model view controller (MVC) pattern and employ a standard framework. Examples of standard frameworks include: Rails (for Ruby) and Spring (for Java). More than the language choice, these frameworks provide enormous leverage. They will allow you to move unbelievably quickly — an unfair advantage startups [can] have over larger companies which always devolve into a congealed mass of heterogenous technology crap.
The innovator’s paradox.
There is a paradox here: innovative people question everything, but success usually requires that you focus your innovation on the one thing that will make a big difference. Something that will either provide dramatically better value for consumers than the existing alternatives or something that will lower the cost of doing business dramatically (in a segment where lower costs are a key success factor). When these innovative people invent stuff that doesn’t need inventing (or at least that isn’t a major contributor to your core area of focus), they create unnecessary risk and lower the probability of success.
In investing there is a saying, “stay in the game.” The magic of compounding growth means that the number one priority of an investor should be to avoid taking a risk of going to zero. Entrepreneurs should heed this advice — make smart technology choices that will keep you in the game. On every technology choice you face, ask yourself if this architectural innovation is key to your success? If not, go with standard technologies and focus your engineering cycles on building a great product rather than innovating on architecture.
If your engineering team is strong, they will figure this out. If they are young, they will take more risks. This risk taking will increase innovation on your core product (good), but it will add unnecessary risk elsewhere (bad). Make sure that everyone understands what the potential rewards of taking those risks are before you decide to innovate everywhere.
It’s time to start writing code.
Set some goal about when you are going to pull your first internal alpha together — six weeks is half way to your external alpha, so that’s a good target. There will be some setup and startup time, but you should move to weekly sprints as soon as you can (Friday late afternoons are good as consumer web usage is low then — in the early days you will take the site down for pushes, but you will eventually move to hot rolls). Of course some projects will take longer than one week, but setting a release cadence will help the team stay focused. And nothing energizes a team like seeing a product come together. Once you are public, each release will also make your users feel like they are part of the innovation process.
8 responses so far ↓
Bob Ngu // June 22, 2008 at 9:00 pm |
Excellent post. Additionally, I would add that the team should be local and not offshore, especially for the early stages of development.
It is very tempting for young techies to focus too much on technology and lose track of whether it is crucial to the startup’s success, so your point of innovator’s paradox is well taken.
Also, your timebox commitment of 90 days to alpha is a good approach. Having a hard deadline is a good motivation for the team to hit the target and doing sprints is absolutely crucial to the process. This might be scary to developers trained on waterfall SDLC but then those developers aren’t likely to do startups anyway.
Having an ordered list of 10 features is a good way to start but expect that list to change (even during alpha) as the UI materializes.
Eran // June 22, 2008 at 11:37 pm |
I will raise your claims and even say 90 days to private beta(!). Of course it depends on the scope of the start-up but it can be done (from personal experience).
All you need is one or two rockstar developers and a solid supporting cast
MaxS // June 23, 2008 at 12:22 am |
Since you mentioned Kelly criterion, here is a tought. 3m is defenitely a minimal atomic unit of team production. say +3m more to prove result in the market. 6m becomes a “bet” in startup “game”. The winning is doubling company valution and the chance is say 10% (10 tries for 1 hit). What is Kelly-recomended burn rate per month in this case?
One quick excel later:
Funding $3,000,000.00
Chance of succesful product 10.00%
Valuation multiplier from succesful product 2
Current Valuation $9,000,000.00
Timeframe to develop/prove 6 months
Kelly burn (Kelly bet=Timeframe*Burn)
$71,428.57
Interesting! And higher burn would mean betting over Kelly limit.
Mike Speiser // June 23, 2008 at 12:41 am |
@Bob and Eran — You guys have clearly been there before. Agree with all of your points.
@Max — Brilliant! Leave it to a physicist to apply a theory of return maximization from gambling / investment into the recommended burn for a startup. Just awesome.
MaxS // June 23, 2008 at 1:30 am |
Another interesting tidbit. valuation mupltiplier matters very little! for example going from x2 to x20 valuation event gives only +20K/mon burn increase “allowed” by Kelly. Doing “next google” is not an excuse to spend lots more money?
After looking at math it becomes more obvious. “Big Payout” event worth it (in long run) only if chances to get there are high enough. Kelly is signaling that improving chances of success (get better team?) even for modest goal is way better strategy then going after huge valuation.
http://spreadsheets.google.com/pub?key=pVRwswyk9twHy-ZiA5nKIJw
Mukul Kumar // June 25, 2008 at 2:01 pm |
Hi Mike. Regarding ‘the innovator’s paradox’ – I believe an innovator needs to work in “two modes” – the innovation-mode and the implementer-mode. The “innovator-mode” is where the team members are thinking-aloud, brainstorming potentially open-ended ideas, somewhat technology agnostic discussion. You get a bunch of ideas in this mode. The “implementer-mode” is where the same team puts its head down and focuses purely at the implementation assuming certain design-constraints and certain technology constraints. In the implementation-mode there is little or no “loud thinking”, the discussion is very converging. These two modes should never overlap, in my opinion. Any loud-thinking during the implementation-mode can totally break the discussion. Also, the size of the team is very important. Smaller teams are better. Luckily, I have worked with some of the best engineers, and things have worked great so far.
Chris Caffee // June 28, 2008 at 9:47 pm |
This is all good but I have a much simpler theorem.
The BusDev of Common Sense.
$2.4M = burn rate of $100K/month = exit strategy of all 1st stage investors = success/fail of morphed tech/bus model = success or fail at next investment round.
It also plays well to investors if the revenue cycle starts either immediately or at the end of year 1 with a 10% loss or less by the end of year 2.
+ 最优化创业公司烧钱率和凯利定律计算器 | Startup|创业成长 // June 30, 2008 at 2:25 am |
[...] my last post, The Product, Part II: Technical architecture and the innovator’s paradox I talked about the importance of staying in the game and linked to a Wikipedia article on the Kelly [...]