At ExtensionEngine we recently launched an online budget estimating tool for mobile apps and I thought I’d share a bit of the back story.

Almost every day I meet with our current clients or prospective clients and I get some version of this question, “Back of the envelope, how much will it cost me and how long will it take to [build/maintain some sort of web or mobile software solution]?” Usually this question comes from the business sponsor for the project, like a Chief Marketing Officer, General Manager or a Product Manager.

For the past few years, what happens next is a little bit like Groundhog Day, the movie (not that I mind doing it). I launch into a series of questions that ask about an important driver of work effort and complexity with a question that isn’t technobabble, i.e something answerable by a business person. Typically after about a dozen questions I can usually come up with a guess on cost and timeframe that historically (across hundreds upon hundreds of projects) is accurate to about +/- 25%, although by no means not always that close.

I think someone who sells professional services to other businesses gets this same question, relevant to their services, equally as often and I’ve always wanted some sort of solution that is halfway between a Magic 8 Ball and a full-on detailed proposal.

So we built one!

We decided to see if we could come up with a tool that would automate this process, specifically for mobile apps. We looked back at about 100 proposals and teased out 15 key questions and the few hundred potential responses to them. We then generated unique functions that map the 6.5X10^13 potential combinations and permutations to specific budget estimates. We then back tested it on old estimates and then threw all kinds of fringe scenarios at it.

Then, once we had the math worked out, we handed it over to the UX/design team to figure out the best way to ask the questions and deliver the estimate and the end result is an amazing tool.

Obviously to do a proper proposal and estimate, it requires a lot more detail, but I really like this quick estimation tool as a way to give a sense to folks based off our years of experience and without the overhead of having to take a meeting, go through all the back-and-forth and, worse yet, the obligatory follow-up.

So with that, I hope you check out the tool and I’d love to hear any feedback.

Every time an airplane crashes or even has an incident in the US, the NTSB does a thorough investigation of what lead to the crash. The investigations don’t just focus on the plane itself, but also the flight crew, ground crew, air traffic control and much more. The findings of these investigations are detailed and insightful. The conclusions of that investigation are then used to improve designs, polices, procedures, etc. As a result, air travel is one of the safest forms of travel, safer than driving, riding a bicycle, safer, in fact, than walking down the street.

I’ve been advocating for a while, that we create some sort of “NTSB for entrepreneurship”. Historically, we do a great deal of research on successful entrepreneurial ventures and almost none on all but the most egregious failures. Doing case studies on successes is, I think, not very instructive. It’d be like doing an after action report on a successful flight from BOS to SFO. But if something fails, wouldn’t it be interesting to do a deep dive into what when wrong and why? It’s in all of our common interest to learn from our failures. One startup failing takes with it so much learning potential. I think we can learn more from a bunch of failures than from all of the successes combined.

What do you think, is this possible?

—————–

Dead equity — equity held by employees and founders no longer working at the company — is a large and growing problem.

Every share of dead equity could have been redeployed as incentive for a current or future contributor to grow the value of the startup.  Instead, the dead equity languishes on the cap table, weighing down the startup and making it harder to attract and motivate the people who could impact its growth.

Facebook’s situation is far from unique, even among recent tech IPOs. Mark Pincus of social gaming company Zynga recently confronted a similar problem when he tried to reclaim equity that he felt he had over-allocated to some early hires.

Imagine how much tougher a dead-equity dilemma becomes when co-founders, who tend to hold large equity stakes, are involved. Facebook co-founder Eduardo Saverin was able to hold onto a significant chunk of equity after his forced exit from the company; that equity is now worth billions. Other prominent examples of drop-out co-founders who held significant amounts of dead equity include those at car-sharing company Zipcar and at tech startup govWorks.com (made famous in the movie “Startup.com”).

A Significant – and Growing – Problem

Dead equity has always been a significant issue for startups. Founders and hires have always quit, after all, and their companies don’t always have a way to reclaim their equity. However, our CompStudy data show that the problem has been growing in recent years.

We analyzed the dead-equity data from a total of 733 tech startups: 257 from our 2008 survey and 476 from the 2011 survey.  We took the percentage of equity held by former employees and founders and multiplied it by the startup’s valuation during its most-recent round of financing.  The graph below compares the value of dead equity in 2008 and 2011.

On average, the value of dead equity in these technology startups tripled between 2008 and 2011, from $480,000 to more than $1.5 million.  As shown above, the dead-equity problem increased across the full spectrum of company sizes, but is now a significant problem even for the youngest of startups, which saw the biggest increase in dead equity.

About three-quarters of this change in the value of dead equity is due to an increase in the percentage of dead equity; the rest is due to changes in company valuations.

Anticipating and Avoiding the Dead-Equity Pitfalls

Startups that anticipate dead-equity problems can structure their early equity allocations to increase the chances of protecting themselves.  Within the founding team, the majority of startups split the equity without taking into consideration the unexpected bumps in the road ahead. They fail to include vesting terms (i.e., the progressive earning of equity stakes by remaining involved in the startup or by achieving predetermined milestones), buyback provisions, or other dynamic elements that would help them reclaim the equity stakes of drop-out founders.  (For more about this, see Eric Ries’ blog post and excerpt from The Founder’s Dilemmas.)

It is more common that startups include vesting terms for their non-founding hires.  However, those vesting periods often underestimate the time horizon over which key hires should be adding value to the startup.  Startups overwhelmingly use “4 years of vesting” as a rule of thumb; as shown in Figure 8.8 of The Founder’s Dilemmas, 77% of non-founding senior executives have 4 years of vesting.  This is true regardless of whether they were hired during downturns in the business cycle (when it will take longer to lead the startup to an exit), the startup’s industry segment, its stage of development, and many other factors.

Vesting can serve both as handcuffs that encourage important contributors to remain at the startup, and as a way to preserve equity when those contributors leave. However, blindly applying the four-year rule, when a longer horizon is needed, weakens both the handcuffs and the ability to recover and redeploy equity. When a fully-vested person leaves prematurely, the startup will have added dead equity to its cap table instead of being able to dedicate the equity to a value-creating employee.

Startups need to evaluate their specific situations and craft appropriate vesting periods by asking (among other things):

• How long will it be until we will realistically exit? How does our timeframe change as market conditions change?
• Over what horizon will each key contributor be needed?
• Given our business challenges, what are the best approaches for minimizing dead-equity problems?  For instance, are there specific business milestones we can tie to vesting?

Founders, board members, and senior executives should try to anticipate these dead-equity problems and avoid the often-costly pitfalls caused by them. Ignore this growing problem at your peril.

—————-

In this era of Big Data where more than 90% of the world’s stored information was created in the , there is a challenge that has emerged which we see very frequently.  The problem is “Dark Data” which is data and information that is segregated or hidden within an organization accessible by only a few people.

First, let’s address why Dark Data is a problem at all.  There are countless examples through history where one person or team makes a discovery but a completely different person or team creates a useful application…some that come to mind are ether (for medical anesthesia) and Teflon (for nonstick cooking ware).  With all the data accumulated in research and development today there are even more opportunities for applications resulting from solving the Dark Data puzzle.

At ExtensionEngine, a lot of our work involves solving the Dark Data problem.  For example, we recently completed a project for a large property and casualty insurance company where they had data spread across nearly 30 different regional offices and we were able to aggregate that information into a single data warehouse and then make it accessible throughout their organization, including from executive management to their field sales reps on iPads, and many others in between.  Another Dark Data solution we built and manage is for Harvard Business School professor Noam Wasserman’s research of entrepreneurial organizations and the founders who launch them.  Wasserman’s research was, for many years, “Dark Data” but then through a collaboration (CompStudy) with industry players including Ernst & Young, WilmerHale and Park Square, an executive search firm, we were able to create an application providing compensation benchmarking data for entrepreneurial executives.

Solving the Dark Data puzzle requires addressing the following issues:

• Creating a central data repository. Often times data is spread out across systems and formats.  Bringing it all together with a single ontology is key.
• Managing access.  One of the main legacy reasons for Dark Data is fear of it falling in to the wrong hands.  Designing a process and system to manage and secure access to the data is a top priority.
• Cleaning data.  Even the best systems will have data quality issues and making it easy and quick to ensure dirty data doesn’t get into the system and being able to clean or expunge dirty data that does get in is a must.
• Automatic publishing.  Ultimately, the key to solving the Dark Data problem is creating a way to automatically publish the right data in an informative fashion to the right people.  Often this means publishing using interactive charts and graphs.

The way it works is that each year nearly 1,000 companies complete a comprehensive survey of the executive compensation in their company as well as detailed demographic and firmographic information.  These data are then anonymized and presented in an interactive web tool (ahem….designed by my firm, ExtensionEngine) which allows you to look at six different compensation elements:

1. Base Salary
2. Target Bonus
3. Actual Bonus
4. Equity at Hire
5. Current Equity
6. Severance

——————————-

Mark Zuckerberg and his executive team have been extremely successful at retaining equity in their company. But how well do most other founders do?

Even as Facebook prepares to go public, Mark Zuckerberg, the founder and CEO, still owns 28% of his company.  As a whole, Zuckerberg, his co-founders, and his former and present employees, own about 55% of Facebook. How did they do this?

Fear vs. Greed

Each time founders seek capital they face what my colleague Bill Sahlman refers to as the fear versus greed tradeoff. On the one hand, founders fear that they will be forced to shut down their startup if they run out of money, which leads them to rush to raise new capital.  On the other hand, they are also understandably greedy about maintaining a high equity stake, by minimizing their dilution.  (Dilution is the progressive shrinking of each executive’s equity percentage as the startup raises each round of financing.)  When founders delay raising each round, they are typically hoping to achieve certain milestones that will raise the startup’s valuation. That will reduce the percentage of stock they will have to cede to their financiers, and thus reduce their dilution.

In every round of financing, Zuckerberg and his Facebook team have impressively minimized their dilution.  Our CompStudy data, which allows us to compare Facebook’s equity dilution against that of some 2,500 technology startups, shows how successful the team has been. To estimate how much the founders and other insiders owned after each of the startup’s first three rounds of financing, we used the two major factors that affect dilution: the capital raised by the startup and the pre-money valuation it received.

As shown in Figure 9.5 of my book, The Founder’s Dilemmas: Anticipating and Avoiding the Pitfalls That Can Sink a Startup, the averages for technology startups are as follows:

• First round: Raise $3 million, with a pre-money valuation of $5 million.
• Second round: Raise $5.5 million, with a valuation of $10 million.
• Third round: Raise $7 million, with a valuation of $15 million.

We then compared those numbers to Facebook’s numbers for its first three rounds:

• First round: Raise $500,000, with a pre-money valuation of about $5 million.
• Second round: Raise $12.7 million, with a valuation of about $100 million.
• Third round: Raise $27.5 million raised, valuation of about $525 million.

The resulting difference between the dilution experienced by the Facebook team versus that of the average technology startup is striking across all three rounds, as shown below.

After his first round of financing, Zuckerberg and the other Facebook insiders still owned about 91% of the equity.  Insiders in the typical startup own only 63% after round one.  As each round progressed, Zuckerberg widened the dilution gap, to the point where after the third round of financing, 77% of Facebook’s equity was owned by insiders, compared to only 27% in the typical startup.

One of a Kind

We then analyzed nearly 2,000 technology companies that submitted data to our CompStudy survey from 2008 through 2011, focusing on the software startups that had raised three or more rounds of financing. When they had finished raising their third rounds, in not a single startup did the founders still own 77%:

Minimizing dilution can come with a stiff price.  Zuckerberg and his team faced tremendous fear-vs.-greed pressures.  At the time of Facebook’s founding, the pressures to quickly raise a lot of money were heightened by the prominence of its major social-networking competitor, MySpace, which had a head start and was better funded.  In the first of Zuckerberg’s decisions to resist the call to grow his company quickly (which would have necessitated raising a lot of capital), he consciously limited the site first to Harvard, then to a hand-picked group of schools, and then to a steadily widening net of potential users.  Yet at the point where the typical startup with a pre-money valuation of $5 million is raising $3 million (and thus relinquishing 38.5% of the company to outsiders), Zuckerberg raised only $500,000, retaining a far higher percentage of his startup for himself and his team.  In the quest to minimize dilution and maximize control, Facebook skated to the edge of the “fear” cliff multiple times in their early days.

An Underappreciated Dilutor: Founders’ Equity Splits

In truth, Zuckerberg was minimizing his dilution even before the first round of outside financing.  A founder’s first real dilution – and often the most powerful – occurs when equity is split with cofounders.  Compared to raising a typical round of outside financing, a founder is  more diluted by adopting a 50/50 co-founding split instead of founding solo, or even taking 70% and giving a co-founder 30% (as Zuckerberg did, regretted, and sought to change).

By co-founding, a founder is betting that the value added by a co-founder will justify the relinquished equity. Throughout one’s entrepreneurial journey, there is a tension between amassing resources and wealth versus retaining control of the startup.  I call this tension the “Rich vs. King” tradeoff– a topic to be explored in a future column.

—————————————–

I’ve been collecting data about startups and compensation since 2001. Here’s what entrepreneurs think they know about startup pay–and what actually happens.

Entrepreneurial decision-making is often guided by anecdotes, rules of thumb, and intuition. Sometimes that’s because entrepreneurs don’t have time to look at reams of data, sometimes it’s because they’ve learned to trust their gut, and often it’s because the data just isn’t there.

But when it comes to pay, you need data. Since 2000, I’ve been collecting information about startups, including how much founders, their lieutenants, and their employees get paid. That research forms the basis for my annual CompStudy survey, as well as the quantitative backbone for my new book, The Founder’s Dilemmas: Anticipating and Avoiding the Pitfalls That Can Sink a Startup.

The research also highlighted four myths about startups and pay. Here’s how they contrast with reality.

Myth number 1. Startup CEOs make a lot more than the rest of the executive team. It’s easy to see where this myth comes from: The average Fortune 500 CEO makes several times as much as execs just one or two levels down.

The Truth: Compared to the lowest-paid member of the executive team, non-founding startup CEOs only make 1.7 times more in cash compensation. The big difference is in equity: Startup CEOs who are not founders get 6.2 times as much equity as the lowest-paid member of their team.

Myth number 2. Founders make more than everyone else. Founders often believe that their own compensation is a ceiling beyond which they will not have to pay new hires. They try to anchor compensation packages at or below their own pay.

The Truth: Across all senior-executive positions, founders make significantly less than other similarly-qualified execs. I call this the “founder discount.” This holds true even when we adjust for differences in the amount of experience these executives have and, importantly, their equity stakes. Founders refer to their startups as their “baby” and are willing to give up some personal comfort to fund their baby’s development. They soon learn that the rest of the management team doesn’t feel the same way, and often lose their best hires when they refuse to pay market rates.

Founder-CEOs are often the most striking victims of the founder discount. In startups that are led by a founder-CEO, there is almost always at least one other non-founding executive who makes more. In our 2011 dataset, we had 283 tech companies in which the founder was still the CEO. Only 17% of those founder-CEOs were the highest-paid member of the executive team. In another 24% of the companies, someone else on the executive team made as much. In a full 59% of startups, the founder-CEO was out-earned by at least one of his or her subordinates.

Myth number 3. Vesting is a tailored way to keep execs on board. Vesting, which requires executives to earn their equity through continuing involvement in their companies, is effective at “handcuffing” the executives to the company until their contribution is less crucial.

The Truth: Of the more than 15,000 non-founding executives in our database, a stunning 77% of them had four years of vesting. Four years may be a good amount of time for some startups and executives, but blindly applying that rule of thumb so broadly doesn’t make sense. Vesting terms should be tailored to the unique needs of the startup, the time during which the executive is expected to play a key role, and the startup’s stage of development. Yet four years remains the standard.

Myth number 4. You get paid more if you live in a high-cost area. Startup compensation is proportionally higher where the cost of living is higher. Silicon Valley and New York City startups pay significantly more than startups in Austin and Washington, D.C.

The Truth: Location has relatively little impact on executive pay in startups. (One exception is the Midwest, where startups tend to strike a different balance between cash and equity compensation.) There are valid reasons to want to work in Silicon Valley or another expensive place, but fiscally, a startup exec might want to work in a low-cost metro where pay is similar to that in a Silicon Valley or New York.

That is the big question facing hundreds of thousands of websites after Adobe, maker of the most popular technology for web video and other interactive multimedia features, said earlier this month it would no longer support Flash on mobile browsers, ceding to the newer, feature-rich HTML5 technology that works – and performs better – on most mobile devices.

For years, Flash has enjoyed a monopoly that is comparable to Microsoft in the past and Google now. Just consider the following, advanced by Adobe itself but citing independent companies such as Forrester, Alexa and ComScore:

• 85% of the top 100 websites used Flash;
• 75% of web video is played on Flash players;
• 98% of PCs connected to the Internet have Flash players;
• 98% of enterprises use Flash to deliver videos;
• 70% of games are delivered using Flash
• Developer community of 3 million

Even though Flash remains near ubiquitous on PCs, web developers such as Robert Accettura give the technology a life of no more than 24-36 months. Some others such as Robert Reinhardt, founder of VideoRx.com, believe the transition to HTML5 technologies will be “slow” but “inevitable,” with the latter the operative word.

If history is any guide, technology change typically occurs more rapidly than we ever realize. In about 18 months since Apple’s Steve Jobs mounted the first serious opposition to Flash’s monopoly – refusing to include the technology in Apple’s iPad or iPhone – HTML5 has soared in popularity and emerged as a consensus technology by biggies such as Microsoft and Google. Just look at the figures below:

• 34% of the 100 most popular websites used HTML5 in the quarter ended September, according to the blog binvisions.com.
• By 2016, 2.1 billion devices will have HTML5 support, according to ABI Research Data.
• Dice.com, the tech job site, has found that resume searches for HTML5 expertise more than doubled between the first and the third quarters.

If anything, HTML5 adoption will likely accelerate, ironically because of Adobe’s abandoning Flash for mobiles.

Given the situation, what are companies and IT heads to do?

As many have pointed out, the current period is one of transition in which web developers will have to work with multiple formats. Some believe HTML5 still lacks some features such as full-screen rendering that is so exciting on a desktop or laptop, or streaming out-of-the-box. Still, many will want to progressively convert from Flash to HTML5 in order to deliver their content. Also, companies can, and should, decide when and how to manage this transition, and when to dive headlong into HTML5. These are tricky decisions critical to the enterprise but those that nevertheless need to be taken at the right time.

If you’re involved in enterprise mobile whether it’s C-level strategy or implementation for a business unit, this book is worth a read. In truth, this book is really two books in one. The first seven or eight chapters are written for the CIO. The author, Nathan Clevenger, writes about the evolution of iOS and how enterprise IT has influenced it, the “consumerization” of IT, developing an enterprise mobile strategy, build vs. buy, etc. You can tell Clevenger interviewed a lot of people for the book and covers a lot of ground in these first chapters without diving too deep.

One of my favorite bits in the first chapters is Clevenger recounting an interview with Geoffrey Moore (of Crossing the Chasm fame) about how the technology adoption curve he theorized is affected by the consumerization of IT generally and the the iPad specifically. The response (which I think could be expounded into an entire book itself) was that it blows up the curve. The whole idea of early adopter and mainstream and laggards goes away with things like the iPad because it is so intuitive and easy to use. Grandmothers (traditional laggards) and nerds (early adopters) are adopting the iPad at the same time.

Not surprisingly, the biggest take-away of the strategy chapters of iPad in the Enterprise is defining and understanding the business metric(s) you want to improve and then working to build a team and plan to achieve that. Technology for the sake of technology is to be avoided.

On the topic of build versus buy, Clevenger offers a strategy of see-if-you-can-buy-before-you-build. There are probably 50 pages of the book dedicated to a review of dozens of applications that address various enterprise problems (from content management, to communication, to sales automation). With hundreds of thousands of apps in the app store, it’s hard to find fault with the advice of buy before you build. On the flip side, Clevenger points out that the apps themselves can be a small fraction of the overall cost (if you integrate with internal enterprise systems). This is not a warning, but rather a reminder to consider the total costs…a topic that I want to address in more detail in a future post.

In the second half of the book, Clevenger and his co-authors dive into the details of iPad application design and deployment. He touches on the entire development process from initial UI design through build, test and deploy. Probably the most important bit is the focus on what Apple has already defined in their Human Interface Guidelines. To understand design for iOS you really need to start with Apple’s HIG. Clevenger spills much ink on this topic, all of it warranted.

Then this is where the book gets into the weeds…to the point where there are pages with sample code. While it might be worth a CIO skimming these latter chapters, they’re really written for the IT professional and product managers implementing or considering implementing iPad applications in their company. There are many real design nuggets…one of my favorite is on the topic of data security and how to avoid users “capturing” data using the native screen capture functionality (hint: you can’t turn it off, but you can thwart it).

So all-in-all, iPad in the Enterprise is a well written, timely and informational book which we recommend.

Every year since 2005 has been declared (in advance) the “year of enterprise mobile” however not until 2010 was that prediction correct.  And the catalyst for that was the introduction of the Apple iPad (and subsequently similarly featured tablets on other OS’s) which is now being tested or deployed by 65% of the Fortune 500.  And this isn’t just theoretical for us.  extensionEngine has been developing mobile applications since the firm was founded in 2000 and in the past year we have seen explosive growth, particularly in iOS and for the iPad (but also to a lesser degree for Android devices and RIM). So we thought we’d share our top 10 tips on developing mobile applications for the enterprise:

10. Make sure you really need it.  First of all, make sure the app doesn’t already exist!  After that, check to see if an app is the right way to do it.  For the vast majority of use cases, it’s easier, cheaper and faster to develop an HTML 5 version of the current online website specifically for mobile.  You only need a native app if you require access to device specific controls or inputs; for example GPS location data, accelerometer data, multi-touch screen, camera, working offline, etc.  If you’re just pushing reports to your sales force in the field, you can do that with a HTML 5 site.  But if you want to show a map of your sales rep’s customer accounts within a few miles of her current location filtered for those that are large but haven’t had a recent touch and make the experience interactive…you’re going to want to do that in a native app.

Read the rest of the post here.