# Sunday, October 07, 2012

As people realize that the economics of startups have changed and more and more people are willing to jump to a startup, accelerators are popping up everywhere to support them. This includes China. Chinaccelerator based in Dalian, China, is the gold standard of accelerators in China. I am a mentor there and last week went up to Dalian for a visit. The cohort at Chinaccelerator is working out of an awesome office in Dalian with epic views of the bay.

2012-09-19 18.28.41

Chinaccelerator had me do a two hour talk to the group about my experiences in raising money over the years. I called it “Lessons Learned from Raising Venture Capital.” I went through several lessons I have learned over the years ranging from how much money to raise, how to approach investors, and how to determine valuation. We then had an awesome exchange and Q&A session.

After the talk I had one on one meetings with six of the teams and was very impressed with each of them. I suspected that all of them would be targeting the China market exclusively, however, only a handful were, the rest were global in their business plans. I left Dalian inspired by all the teams’ passion and energy.

It is great seeing accelerators pop up all over the world to support startups. This week I visit one in Sofia, Bulgaria.

posted on Sunday, October 07, 2012 9:43:27 AM (Eastern Daylight Time, UTC-04:00)  #    Comments [0] Trackback
# Tuesday, September 25, 2012

I often get the question, “why the focus on hybrid development for your accelerator?” This question has come up more and more as Mark Zuckerberg said that Facebook’s focus on HTML5/hybrid development was a mistake.

As I argued over a year ago on this blog, it is mistake to bet exclusively on native or hybrid since some Apps will call for a native approach and some will call for a hybrid approach. Projects that need maximum performance and hardware interaction will require a native approach (medical scanning/rendering apps and some games come to mind) and projects that require larger reach and very fast time to market require a hybrid approach. Each approach has its limitations and trade offs.

If I advocate both approaches in a developer’s toolkit, why would I be starting the world’s only Hybrid Accelerator? The reason is that a startup should never, ever, go native. The very nature of a startup is that you have no money and require a super fast time to market. Just last week at a startup networking event in Hong Kong two super cool startups showed me their native apps on their iPhones. They then asked me what I thought of the app. I said: “your app sucks since over 75% of the smartphone market can’t use it, myself included as an Android user.” They countered: “we have no money, so we choose one platform to build the prototype on.”

My advice for them and most startups: For your prototype and V1 release you should go hybrid. You will have a much broader reach and won’t have to maintain two or more codebases (and double the programmer staff.) You’ll save time and money. Once your company matures and you have lots of users and the money to spend on the development, then you should consider going native if you are bumping into the limitations of hybrid development (chances are only a small percentage of apps ever will).

What about a company with 1 billion users, over $1b in profits post-IPO, and a super slow API in the first place? Yes, Mark Zuckerberg proves my point, hybrid development helped Facebook get to market fast with its hybrid mobile app. It was not a mistake for Facebook to go to market fast and cheap with a hybrid app. The mistake Zuckerberg made was not deploy some of those profits to build a better hybrid or go native years ago.

posted on Tuesday, September 25, 2012 2:07:22 AM (Eastern Daylight Time, UTC-04:00)  #    Comments [4] Trackback
# Thursday, September 13, 2012

As Paul and I are starting to review the first batch of applications to AcceleratorHK, we have stressed that you can’t apply for the accelerator program with only one founder. The optimum team make-up is two people: one “business” co-founder and one “technical” co-founder.

The most frequent question that I get from potential applicants is: “Why do I need a technical co-founder?” The question alone tells you something since it is not: “Why do I need a business guy co-founder?” This tells me that there are TONS of excited non-technical people willing to take the plunge and start a business, but not enough techies. This is a problem.

image

I answer this question by saying that first you can’t do it all alone. Very few tech companies today were founded by one business guy. Second, at such an early stage (and by definition if you are applying to an accelerator you are an early stage), you will be doing a lot of Customer Development, MVPs, and “pivots.” It is critical in this early stage that your tech lead is part of the Customer Development process. If your tech lead is not a co-founder, at best, they will not understand Customer Development and want to do product development, and at worst, they will resist the process every step of the way. Only by constantly meeting with potential customers, doing Customer Development, and “having skin in the game” will a programmer be able to deliver on the vision of the company.

I’ve witnessed quite a few early stage companies enter an accelerator with a hired gun (consultant) as the “technical co-founder” in order to satisfy the two co-founder rule. The founder and the consultant have an agreement that the consultant would build the MVP and prototype and get the company to demo day in exchange for some equity. Never have I seen this work out; most have had disastrous results. In just about every case the consultant “co-founder” is in consulting mode and complains that “all those Accelerator meetings get in the way.” By forcing the startup into product development mode, the consultant negates all the benefits of the accelerator, since all accelerators are built around the Customer Development methodology. This also shows the level of disengagement, an accelerator cohort is for the entire team, not hired guns. I have seen one company recently lose their technical consultant “co-founder” halfway through the accelerator when he got a better gig. He used the first pivot as an excuse to bail. (At least he returned some of the equity.)

Usually, the non-technical founder is held hostage by the development team’s schedule and often times, the development progress is slower. Since the same level of passion is not there, the consultant just chugs along doing what he is told, leading to a misallocation of total work. You have founders working 16 hour days sleeping under their desks and the programmers pulling some overtime grumbling that they are losing money on this gig.

The only exception I have seen to this is a founder who had a team of guys in another country as full time developers lined up. He applied to an accelerator and was told he needed a technical co-founder, so he brought the lead developer to the accelerator for the duration of the program. While this worked out well, the company already had enough cash on hand to lock up the development team, so this is probably not the case for most other early stage startups.

image

If you are thinking of doing a startup, remember you can’t do it alone. If you are non-technical, you can’t outsource your core intellectual property. Besides if you can’t convince a techie with a well paying and stable job to quit and work at your high risk venture for free, then well, you probably don’t have enough sales skills to convince customers to buy your revolutionary new product. Smile

posted on Thursday, September 13, 2012 9:21:32 AM (Eastern Daylight Time, UTC-04:00)  #    Comments [0] Trackback
# Wednesday, September 05, 2012

Over the past year I have been a mentor at an accelerator called Haxlr8r. Haxlr8r, based just north of me in Shenzhen, China, is a unique accelerator since it is the only accelerator to focus exclusively on hardware startups. The targeted hyper-focus of the cohort paid dividends as everyone is in the same space and learned from each other and shared their experiences.

That got me thinking, why not do the same for software!?!? Over the past few months,  I’ve been helping organize the first ever early-stage startup accelerator in Hong Kong. This accelerator is not like any of its kind. It is the only accelerator to focus exclusively on startups doing hybrid mobile development. Why the focus on hybrid? Gartner predicts that by 2015, 80% of all mobile applications developed will be hybrid or mobile-Web-oriented. Just like at Haxlr8r, the laser beam focus of the cohort on hybrid mobile development will only enhance the experience. Why Hong Kong? There are two mobile phones for every man, woman, and child in Hong Kong. In a country of 7 million people, there are 7 independent 3G mobile phone providers with coverage everywhere, even in the subway and on top of the tallest mountain. Facebook penetration in Hong Kong is one of the top per-capita in the world. Hong Kong is not only all over Twitter, but Weibo as well. This is one mobile crazy town, the average taxi driver even has 2 phones. Hong Kong is a great place to validate your mobile app and one of the top places in the world to do business.

image

The accelerator runs from Nov 5th to Feb 8th and we are going to to provide mentors, investment ($15k USD), lean startup education, co-work space, demo day with investors, just like the gazillion other accelerators out there. In addition, we will also add a little on software development best practices, provide access to free developer tools (Telerik’s Icenium and KendoUI), do agile development training (I think accelerators forget about item #2 in the Customer Development Manifesto), and include free Pluralsight subscriptions.

I think that this represents the next stage of accelerators; laser focused with a little extra love for the tech team.

Want in? Apply today, we close out the cohort applications in a few weeks.

posted on Wednesday, September 05, 2012 7:21:32 AM (Eastern Daylight Time, UTC-04:00)  #    Comments [0] Trackback
# Thursday, August 30, 2012

Last week I traveled up to Shanghai, China to speak at the 10x10 event: bringing in 10 tech “pioneers” to speak for 10 minutes each to a crowd of entrepreneurs. I put pioneers in quotes, since there were 9 pioneers plus me speaking.

It was a great way to connect with the startup scene in China. The event was sponsored by Chinaccelerator, an early stage startup accelerator that has 10 companies in a cohort right now. I met with most of the 10 companies and was very impressed; most, but not all, were doing mobile or social media startups. People in the West understand that Facebook and Twitter are banned in China, but forget that there are local (but censored) alternatives.

The home grown Chinese versions of Facebook and Twitter are booming. The most popular being Weibo, which is the “Chinese Twitter.” There are just as many Weibos as there are Tweets and most of the companies in the accelerator are trying to leverage that. (Just a side note, my Weibo account is: SteveForte.)

Some of startups consisted of only Westerners, some were only local Chinese, and some were a mix. I am mentoring one company that has a local Chinese co-founder and an American co-founder.

2012-08-24 14.33.46

The sessions were great. One of the speakers said that Silicon Valley is about making money and that China is about acquiring users. While there may be 500 million internet users in China, most don’t have a credit card and only access the internet on their mobile phone or at an internet café. I find the similarity in the rush for users in China to the thinking of the startup and investment community in the USA in 1999 striking. That said, it is great to see so much action going on.

I did my talk on the “New New Startup Economics” which was about how it costs much less to start your business today than it did a few years ago and an order of magnitude less than 10 years ago.

Here are my slides:

 
posted on Thursday, August 30, 2012 4:35:33 AM (Eastern Daylight Time, UTC-04:00)  #    Comments [0] Trackback
# Friday, August 17, 2012

While I was in London last week, Telerk’s UK Country Manager and I took some time to visit the Google Campus, a massive co-working and startup incubation space. There are six floors of co-working space where you can apply to be a resident if you are a startup based in London and an awesome cafeteria/coffee shop where anyone can come in for the day. On the top floor is Google’s offices. Even though Telerik has a London office, we registered online and spent a day working at the co-work space, mostly to get a feel for the co-work space and check out the scene. (Also, Telerik’s KendoIU was featured at Google I/O 12, so we figured we should give Google some love.)

IMG_20120730_102408

The co-work space was very cool. From the moment we walked in there was a buzz of energy. Lots of meetings going on, people nose down doing work, and of course playing fuzz-ball.

IMG_20120730_103159

Besides the co-working space, Google is also deeply engaged and helping build a startup community in London by providing mentoring programs, speaker series, networking events, and all other types of startup support, open to the public. It is great seeing a large tech company helping build a startup community, I hope to see more companies do the same. (Hint Hint Google, Microsoft, Apple in Hong Kong. Smile )

If you a startup person and are passing through London, make sure you drop by. My favorite thing: the Android “Player.”

IMG_20120730_122106

posted on Friday, August 17, 2012 3:36:59 AM (Eastern Daylight Time, UTC-04:00)  #    Comments [1] Trackback
# Tuesday, July 24, 2012

Yesterday I blogged about using a spreadsheet in your Agile Estimation efforts. We left off after the first sprint and had an estimated time to completion of 15.14 weeks. Now let’s take a look at how this works after another sprint.

image

The spreadsheet is the same, however, now we have data for sprint 2. Cell C2 represents the backlog size in story points after sprint 1. In this case if you remember from the blog post yesterday, our backlog is 106 story points. The team is going to commit to 8 story points worth of work (cell C3) and completes 8 (cell C4, told you the team gets better. Smile) This makes our Team Velocity 7.5 (cell C5), which is just the average of the total story points completed in sprints 1 and 2 (cells B4 and C4) or B4+C4/2.

The users added 4 story points worth of work to the backlog (OBTW, cell C6) and the bugs were 2 story points worth of work (C7). No items were removed (C8). Now time for the math. If you remember from yesterday, it looks like this:

Total Backlog/Team Velocity

or

((C2+C6+C7)-(C4+C8))/C5

or

((Total story points at sprint start  + OBTW in points + Bugs in points)- (Total points removed from backlog + Total Story Points Completed in This Sprint )) / Team Velocity

or

((106 + 4 + 2)-8) / 7.5 or

104/7.5= 13.87

This means that it will take approximately 14 sprints to complete this project, fairly consistent with the 15 in the last estimation. But what about allocating time for OBTW and bug assessments as well as rework. Meaning, we have to allocate time to asses the bugs and OBTWs and estimate the ones that we decide to add in the backlog. This takes time, usually in the first sprints you work overtime and your Team Velocity goes down, however, we don’t want that to happen for the rest of the project. The way to work some of that time back into your estimate is to discount the Team Velocity and redo the math. Let’s take a look at our spreadsheet again, this time discounting the Team Velocity.

image

What we are doing here is providing a second estimate (C11) that will take into account the time added to the project for assessment of bugs, OBTWs, research spikes, etc, and the time it takes to estimate them. If you remember that we got an estimate of sprints to completion as 13.87 by 104/7.5= 13.87 where 7.5 was our cumulative Team Velocity.

Now we will discount that 7.5 by 5% and recalculate. Why 5%? Gut feel, you will eventually replace that 5% with a more precise number, but in absence of any real data, I just discount by 5% up front. You could either discount the Team Velocity by an additional 5% every 1-2 sprints, or you can try to calculate your bug rate/OBTW rate and replace the approximation by a different number. To be honest, it is easier to just use the sliding scale of –5% every 2nd or 3rd sprint to get started.

So the new math looks like this:

104/(7.5 * .95) or 104/7.125= 14.60. Almost 15 sprints, slightly more than our original estimate at the end of this sprint of 13.87 or 14 sprints. Our new, more accurate estimate takes into account the time that will be added to the project for new items, bugs, and R&D spikes.

The second discounted or “Weighted Sprints to Completion” (C11) is optional, however, it is more accurate. I like using that number since it attempts to account of the unknown. While it is impossible to predict the unknown, it is a scientific way to at least acknowledge that there will be bugs, OBTWs, and lots of other unaccounted for stuff.

Lastly, let’s take a look at how this progresses over more sprints.

image

As the screen shot above shows, as you progress to the next sprint, you are going to do the exact same thing, except that over time you will discount your Team Velocity by a larger percent, for example, in sprint 4, we reduce Team Velocity by 10% and 15% in Sprint 5. You increase the discount rate to account for more uncertainty in your project, the longer the project goes on, the larger the bugs and OBTWs get. Again, it is up to you how to adjust the percent used.

Hope that this helps everyone out there looking for some guidance on the spreadsheet.

posted on Tuesday, July 24, 2012 4:34:15 AM (Eastern Daylight Time, UTC-04:00)  #    Comments [0] Trackback
# Monday, July 23, 2012

During the recent conference season, I did a lot of presentations about Agile Estimation based on my Pluralsight course of the same name. At the end of the sessions I showed an Excel spreadsheet that shows how to take the concept of Agile Estimation one step further by measuring what actually happened and using that as part of your estimation.  I am assuming that you know something about Agile Estimation, however, at BarCamp Hong Kong, I got a request to further explain this spreadsheet in a blog post. As promised, here it is. Smile 

Let’s take a look at the spreadsheet after your first iteration (Sprint 1). Let’s assume that our iterations (sprints) are two weeks long. To keep things simple, let’s say that our product backlog had only 100 story points worth of work in it. (Remember this can represent 10 or 25 user stories, doesn’t matter.) This is shown in cell B2.

image

I like to track everything. Cell B3 shows how many story points the team took out of the product backlog and put into the sprint backlog. This is what they committed to do during the sprint. Remember for Sprint 1 the team will always over commit and under deliver. Who cares? We care more about what they can do averaged out over time (the Team Velocity.) After two or three sprints, the team will start to commit to the correct number and Team Velocity (the average of the total story points completed) will even out. But let’s not get ahead of ourselves.

Cell B4 shows us how many story points the team actually completed in the sprint (in this case 7 story points) and cell B5 shows us the cumulative Team Velocity, which in this case is also 7 since it is the first sprint. After the next sprint we will start to average this number.

Now it gets fun. Cell B6 shows how many story points of work were added to the backlog during or after the sprint. This is what the users forgot or got inspired to add by looking at your work in sprint 1. I call these affectionately OBTWs, for “oh, by the way..”

Cell B7 shows us how many story points worth of bugs were added to the product backlog. (More on bugs in Part II.) Cell B8 show us how many story points worth of work were removed from the backlog during the sprint. (This *does* happen but not usually on the first sprint.) Cells B6-8 assume that the team had time to do an assessment and estimation in points (planning poker, etc) of the new items/bugs during or immediately following the sprint.

Now for the estimate. At the end of each sprint you have to re-estimate the duration of the project. You do this by dividing the total backlog size by the cumulative team velocity. This is done by:

Total Backlog/Team Velocity

or

((B2+B6+B7)-(B4+B8))/B5

or

((Total story points at sprint start  + OBTW in points + Bugs in points)- (Total points removed from backlog + Total Story Points Completed in This Sprint )) / Team Velocity

or

(100 +10 + 3) – (0 + 7) / 7 = 15.14

Noticed that we had 100 points in the backlog and completed 7, bringing our backlog down to 93. However we added 13 points worth of work (OBTWs and Bugs), bringing our backlog up to 106 (93 + 13). So the math is factored down to:

106/7 = 15.14

What this means is that after the first sprint, our estimate is that the project will take 15.14 sprints to complete. Since our sprints are 2 weeks long, the project should be completed in 30 weeks. We also know that due to the cone of uncertainty and future bugs/feature requests, that this number is not super accurate (more on that in Part II tomorrow). That is ok, as you know from the theory of Agile Estimation, our estimate for the project completion will only get better over time and after about 5 sprints, it will be pretty dead on.

In Part II tomorrow, we’ll look at how this works over a few more sprints.

posted on Monday, July 23, 2012 6:41:46 AM (Eastern Daylight Time, UTC-04:00)  #    Comments [3] Trackback