“Bubble Watch”


A few weeks ago CNBC hosted a segment titled “Bubble Watch”.  Inspired by the new all-time NASDAQ high, the question of the day was around a potential tech bubble and similarities to 1999.  With valuations and VC financing on the rise and more $B+ startups every week, this seemed like a natural question.

Counterpoint: in March 2000, the NASDAQ’s trailing P/E reached a peak of 175, yet at the time of the interview was below 25.  In other words, a metric normally associated with the expensiveness of a stock was six times lower than during the last bubble.  Meanwhile, the DJIA peak was only around 12,000 in March of 2000, increased to 14,000 pre-recession, and is now climbing above 18,000: over 50% higher than the Y2K peak.

Calling bubbles is a fool’s errand…but if there is a bubble, it seems that tech is the wrong place to search for it.  More thoughts at the linked image below.

Squawk Alley

Burn Rate


Recently I wrote a post for TechCrunch articulating my views on burn rate.  The thrust of the article was that it’s impossible to say whether cash burn is good or bad without knowing how the money is being spent.  This is finance 101: when deploying capital, what matters isn’t just the quantity of cash being reallocated, but the risk-return profile of those applications, or simply put the ROI.  A better way of thinking about burn is through two underappreciated metrics: speed of execution and efficiency of execution.

Here’s a link to the piece: http://techcrunch.com/2015/04/05/burn-rate-doesnt-matter

Since that article, some have asked how these two metrics can be used to generate insights about one’s own business, beyond simply determining which quadrant of the qualitative speed-efficiency 2×2 a company resides in.  As you might expect, using these metrics to evaluate a business quantitatively can be very illuminating as well.

Here’s an example: one VC-backed company I know well, cofounded by a few friends, recently looked at its burn rate and realized it was tracking lower than projected, seemingly a stroke of good fortune.  Most of the plans goals had been achieved on schedule, albeit with a handful slipping by a few months.  Overall, this seemed like a great outcome without much room for improvement – right?

Well, the good news was that the company had achieved each planned milestone for fewer dollars than anticipated (high efficiency), enabled by the incredible quality of the engineering team they had assembled by keeping the hiring bar very high.  The bad news was that they had accomplished milestones more slowly than planned, with the size of their team and overall bandwidth as the primary bottleneck.  By considering both sides of the speed-efficiency framework, the company realized that they had kept the hiring bar too high or had devoted too few resources to recruiting efforts.  This in turn had prevented them from hitting all the goals of the strategic plan on time – in some sense the ultimate litmus test of execution.

After realizing this, the company worked toward a solution: bringing on a few more junior engineers and technicians to better leverage their most experienced team members and scale technology development efforts.   While the end result was increased burn, the company also achieved faster execution at equal or better efficiency – a huge win on both fronts. Equipped with this new perspective on burn, the company continues to climb toward the upper right hand quadrant of the 2×2 proposed in the TechCrunch piece.

As is often the case, finding ways to apply a framework quantitatively can yield even deeper, more actionable insights than resting on its qualitative surface.  I’m hopeful and excited to see other great applications of the framework in the months ahead, unearthed by people digging deeper.


A friend of mine is weeks away from his company’s first product launch, and we were recently rehashing lessons learned from past startups, mine included.

During the conversation we found our way back to some points I made in an interview last year.  After rereading the piece, I thought it worth sharing.

You can’t simply iterate your way into orbit.
To do something transformational, you need to have a plan.

The Economist: Testing, Testing