Want Help With Your Startup? Let It All Hang Out on Craigslist

It's awfully easy to go looking for folks doing stuff the wrong way ... and to find it. So it's nice to be surprised by someone doing something amazingly, shockingly, frighteningly ... right!

I was greeted by a craigslist ad in my RSS reader today, one of many startups looking for folks to, essentially, work for free. I've written about why this is a bad idea before, and it's still a bad idea.

But there's a little more to this ... the poster (the company's founder presumably) posts a link to a wiki. Maybe it's genius, maybe a trainwreck -- either way I had to look.

On the other side of this link is a company wiki. An explanation of what the company is building; where they are in the process; their calendar; UI mockups with notes and the comment stream by the creators; and other items.

This is absolute genius, and it's so rare. Plus it shows the guts that most entrepreneurs fancy themselves to have, but lack when tested. I'm not commenting on their specific business/tech idea, I haven't thought much about that to be honest.

But it is so refreshing to see someone out there on the beach letting it all hang out as it were.

I work with a lot of entrepreneurs and most of them think that they're the first ones to think up some genius idea, and the best way to be successful is to either keep it stealthy and secret, or to sign reams of NDAs and non-competes with you before disclosing (cue music) their subtle and delicate brilliance.

Just writing that last paragraph, it's a struggle to keep a professional tone. These folks are usually (97%, there are a couple of specific exceptions) complete fools. And truly, they are fooling themselves, unconsciously trying to avoid exposing their idea to someone who might not think it's so good, or who might point them to the dozen other people doing the same thing. Generally speaking, the secrecy ends up being a contributing factor to their failure. Which, since startups are highly failure-prone anyway, they will deny anyway.

That's why I was so thrilled to see this post. The founder is saying, "If you want to try and 'steal' my idea, you go ahead. But if you really believe there's a bunch of money in it, wouldn't you want to work with other people who believe the same thing and who have the will to execute? And if you go off with it and succeed anyway ... you're still helping me because you're establishing the category, while I plan to work nights and sweat blood to execute better and faster than you."

The ad is reproduced below. I was going to link it, but interestingly it has been 'flagged' for removal from craigslist. It's hard to imagine why -- the whole scenario seems rather more legitimate than the typical ad in the category. Perhaps the allusion to potential full-time work disqualifies it from the free "gig" listing ... but I think a startup seeking essentially non-paid volunteers in whatever capacity they can afford qualifies as a part-time or temporary arrangement.

Technical Wizard / Web Developer Wanted | Internet Startup (sunnyvale) An internet startup is seeking a highly talented web developer If you have experience with either: PHP/MySQL, Python, or Ruby we would love to talk with you. This a very exciting startup opportunity with massive potential. At this stage, we are looking to bring aboard those who are seeking equity share in the company. We simply do not have the capital to fund salaries. For more information, please have a look at: http://wiki.kunsoom.com All of the pertinent information will be included in the wiki page. Thanks for your interest in the project! We look forward to hearing from you.

Think About It: Do You Really Want Your Engineering Done "For Free"?

I enjoy reading the posts on craigslist, wherein naive entrepreneurs go looking for free software engineering talent. I know this sort of ad (no pay / equity only) bothers some people -- as though it somehow has real impact on the real jobs and pay in the industry -- but I think it's just fine. I mean, if you want a service for free, there's nothing wrong with asking. And if you are in the mood to work for free, it's nice to know where to find opportunities ...

Of course I am not referring to recruiters for genuine charity / volunteer work, where the goal is to provide services to a population that isn't served by the normal market mechanisms. Rather I'm talking about real for-profit, we're-gonna-be-the-1-in-100-successful-startup-and-make-a-boatload-of-cash kinda company.

The funny thing is that it's hard to imagine these wantrepreneurs looking for any other kind of professional services for free. Not because they feel coerced by social norms to offer money, but simply because they know better than to want what the "free professionals" have to offer.

I don't see these guys saying:

• I need heart surgery and I'm looking for a doctor who wants to keep their resume fresh. No compensation, but I'll thank you if I wake up.
• Going through a brutal divorce. Looking for a sharp lawyer to keep me from losing my shirt -- no pay, but I'll buy you a drink if we come out ok.
• Need a corporate lawyer and patent attorney. Equity only.
• Startup needs business travel on the cheap. Seeking a pilot and aircraft, not so concerned with FAA licenses or airworthiness.
• Building a new facility -- need architect, structural engineers, environmental compliance, project managers, and laborers. If we make a bunch of money, we'll pay you at some point in the future.
• Love my new car, but it needs engine work -- looking for a mechanic who'll work for free. Someone with little or no experience seeking to build up a resume is ideal.

Now, it is true that in the late 90s, during the dot-com bubble, landlords, attorneys and other did take equity. But they did so in addition to -- not instead of -- cash payment. And the odds of making bank on equity back then, while still long, were stunningly better than they are today.

I know what these guys are thinking. They're thinking "I just don't have a budget to pay for real development, and anything I can get for free is better than the nothing I can afford otherwise."

Well, in some cases, perhaps. But that's setting an awfully low bar. Likely too low to allow for a real chance of success. That is, the entrepreneur is theoretically pouring all his time, money, heart and soul into starting this business. But he's willing to gamble the whole thing on the questionable code he'll get out of someone who has nothing better to do to pad a resume while unemployed? Doesn't quite add up.

Or maybe he really wants a "partner" ... only it's unlikely this developer is going to see 50% equity. And anything less likely means the developer is along for the ride while the entrepreneur follows the same hare-brained decision process that led him to advertise the non-paid gig in the first place. In any case, the developer has no real clout when push comes to shove. He's a silent partner, just along for the ride.

True, there are a few brilliant technologists out there who simply don't need any (more) money. They have cashed out of a startup, or they run another business on the side that covers their expenses. And if you can hire one of these guys, then bully for you. But I think they are more likely to spend their time where they can make an impact on a real business, product, open-source project, or non-profit.

As for the entrepreneurs who get someone to bite ... they don't know what they're in for: a few months or more down the line, they have (perhaps) some kind of a half-baked system. They need the loyalty of that unpaid assistant to modify and improve the code, while the assistant has now seen through all the "about to receive funding" promises presented at the outset. And as the limitations of the half-baked system slowly become clear, the founder may wish to replace the developer, or throw the whole thing out and start over with a new iteration.

But unless the original developer was a real sucker, all that equity means unrecoverable dilution in the cap structure. The more equity involved and the earlier the start (meaning smaller valuation), the worse this situation turns out to be. It could even come to pass that a potential investor one day passes on the deal because of these problems in the cap structure.

We May Look Back Fondly on Our 68% Project Failure Rate

The report [PDF] referenced here -- focusing on failure originating in the business requirements realm and offering a "68% project 'failure'" headline -- inspired two thoughts.

First, it remains a head-scratcher why nearly every project, despite talk of risk analysis and mitigation, expects to be in the 32% success area. Even if a company has the best resources (and generally it will not), many causes of project failure originate in organizational factors -- friction, process, politics -- and externalities (e.g., no budget this quarter for the tools in the original plan).

Since these issues are rarely known -- and, I would argue, actively denied in the sense that whistle-blowers and problem-spotter are systematically excluded from planning (at best) or forced down or out -- the average "expected value" of the d100 role is way less than a 68.

In startups, I've heard the excuse that the whole company is a "long shot" -- as though that justifies taking on disproportionate risk in each project implementation.

In enterprises, it seems as though management is so used to failure (in a timeline or budgetary sense), that they have simply redefined success to mean anything that they can pull off in their tenure -- and if that means a system that kinda works, but no one likes, shipped in 200% time and 400% budget, well, that's just the "reality" (which, to be sure, it is once all other possible paths have been discarded).

This redefinition of success also has the side effect of removing accountability and pretty much assuring a nice bonus and making strict accountability impossible.

Another thought inspired by the report is how the gap between enterprise development and small / startup development is widening. On the one hand, large businesses could benefit from the high-productivity tools and agile approaches popular with startups; for a variety of reasons ranging from policies to personnel, they are not exploiting the latest wave of technology, and it's costing them.

On the other hand, what they need regardless of tech is solid analysis and estimation capabilities. Analysis and estimation are possible, but hard, and the agile camp has moved mountains to try and reframe the problem so that they can advocate punting on all of the hard parts of these disciplines. That works great for the hourly agile consultants, but inside large businesses and large projects, it just doesn't cut it. A business needs to be able to attempt to estimate and plan months or even years of a project (hence the prevalence of "fake" agile in companies that purport to use it).

The fact that the business does a horrible job with the estimation today does not mean that the organization (which, generally, is run by business people not developers) won't keep planning and targeting in the large.

The result of these two pieces (different tech, different process) is that enterprise and small development are moving farther and farther apart, which is a damaging long-term trend. Ideally, these two groups should be learning from each other. They should spend more time moving in the same world.

The enterprise learns that it probably doesn't need JavaEE and Oracle and a big planning process for myriad internal utility apps that could be done with Rails at a fraction of the cost and effort. The small company learns that relational integrity, transactions, estimation, and operations management are sometimes both necessary and profitable.

Even more importantly, individual employees in the industry can cross-pollinate ideas as they move between these environments over their careers, sorting fact from fiction and getting better at determining what will work.

The farther apart these groups are, the less appealing it will be for "startup guys" to work in an enterprise or a startup to hire on an "enterprise guy."

This trend -- since it keeps useful knowledge hidden -- can only help a 68% failure rate go up.

Yes, VC May Be Irrelevant if it Continues Focusing on Weekend Projects

Where are Web 2.0's Amazon.com, PayPal, Google, or Travelocity? They were never funded.

Paul Graham and now Eric Schonfeld are extending the several-year-old "VCs don't know what to do with Web 2.0's super-low-cost startups" meme. The extension has to do with the recession, arguing that it will accelerate the decline of VC relevance, as VCs become more reluctant to fund these shoestring startups, and more entrepreneurs pull a DIY anyway and ignore VC.

Well... maybe. The VC problem with micro-cap micro-startups is real, in the sense that it's a real math problem where the VC fund size divided by the proposed investment size equals too many portfolio companies to interact with, and a kind of interaction that is a big break away from the old model.

But the easiest fix is for VCs to simply invest in more expensive businesses. The current predicament is a classic chicken/egg: after the dot-com crash, VC money was hard or impossible to get, so the businesses people started were these undergraduate-level 1 man-year (or couple-of-weekends!) efforts.

Small product, small team, small money. We got things like 'Remember the Milk.' Cute, sure. Useful, sure. But nothing too hard or too ambitious. Nothing a tiny shop -- or a bored college student -- couldn't hack out in their spare time. Indeed many were spare time or side projects.

Some of these apps got a lot of users, especially where network effects were involved, and eventually VC wanted nothing that wasn't viral, network-effect, social. Never mind that there was never big challenge or big value in those. Facebook is the biggest thing in Web 2.0 at the moment, and it's nothing but network effect and questionable monetization. "Not that there's anything wrong with that..." It's a fine, useful application. But in the absence of any real substance the model became more Hollywoodesque, more personality- and connection-dominated than it should have.

So where is the Amazon? PayPal? Google? Travelocity? Ariba? Netflix? Danger (maker of the Sidekick devices)? Those big projects that take tens of man-years, maybe hundreds? The projects that can't "launch in beta" after a few months and acquire tens of thousands of fanatical users because they're more than a glossy AJAX UI on a local database?

Where are the startups that drag whole industries whining and screaming into the 21st century and liberate billions in value, trapped in transactions that real people make every day?

Those big projects haven't been A-round darlings for a long, long time. VCs, terrified of risk, moving in a tight pack, loved the new ethos: let the entrepreneur build a product, get it launched ("beta"), get customers, get mirror-hall PR (blogosphere), then later drop in a few bucks. Less risk. But not easy money. Count the exits.  And the ad-only valuation has no more magic today than it did in 1998.

And no one even notices when hundreds or thousands of these little pownces and iwantsandys hit the deadpool.

It's no coincidence that many of the step-by-step tutorials for new frameworks and tools teach you to clone a blogger, a flickr, or a wiki farm in a sitting. After all, those are trivial undertakings, lacking only for a network-effect mob signing on. And we'd all have a good laugh about widgets one day... if we weren't laughing so hard already.

Can you imagine a tool vendor of the dot-com era giving an hour tutorial that produces a working Travelocity clone? a working PayPal clone? It's sketch comedy, or something sadder and more disturbing. Frankly, the most ambitious projects in all of web 2.0 are the tooling and infrastructure plays that are largely open source.

Investors, entrepreneurs, engineers and end users might all do well by hunting some bigger game.

BizSpark Shows Wider Microsoft View Around SaaS Innovation

Depsite a lot of reporting about Microsoft's new BizSpark program, one interesting bit wasn't featured in the coverage:

Microsoft's existing nearly-free-licenses-to-help-developers-get-going-on-the-platform program has been around for a while and has always required that a company plan to distribute a "packaged and resalable" application targeting a Microsoft platform. 

It could be an app on Vista or Server, an Office add-in, a Windows Mobile app, or one of a few other options. But it had to be packaged, at least in the sense that it was digitally bundled into an installable set of files even if it never got put in a physical cardboard box.

This requirement made some sense as far as promoting the client OS ecosystem but it disqualified any online offering. An online service had to work around the restriction: for example, by offering a small Windows Mobile app that has some interaction with the service.

But the language makes a statement -- Empower was largely about helping ISVs new or old develop apps on the platform, thus making the client platform stronger. Nevermind that an online service that targets browsers and the iPhone might lead to Server license sales later.

BizSpark, on the other hand, takes another approach. There is much talk of online solutions -- the program is meant to dovetail with hosting providers (or Microsoft's Azure platform) to offer the server-side muscle a solution will need after its incubation period. The program is aimed exclusively at new companies -- if a firm has been in business 3 years or more, it does not qualify.

Both programs exist today and will presumably continue. So I'm not suggesting there is a big move from one view of the world to another. But there does seem to be a conscious broadening of horizons in terms of seeing where innovation is taking place and how Microsoft can be part of it.

On the Knocking at the Gate, VCs, and a Math Problem

Bang!

This economy may be the wakeup to VCs (and CEOs alike) that their future isn't what they want. But the murder happened years ago, and the "I don't want yes men, but strangely I don't listen to much else'" hivemind has just woken up.

The IPO window isn't shutting or recently shut -- it never re-opened after the dot-com meltdown. A handful of IPOs (including a Google) doesn't make a "window." Whether you blame SarbOx, or a trend of investing in companies with a wink-wink style of sustainable competitive advantage, that could not produce high enough valuations to warrant a public offering, there were to be few IPOs.

The startup and VC world started getting this idea a couple of years ago, when they realized that at the smaller exit values (for the exits that were to be had), in order to get a high multiple return, the initial investments would have to be so small that the venture fund couldn't afford to service the quantity of investments. That is, the investment would have to be too small to be worth the firm's time. Uh-oh. A few innovative programs came out of that realization. But for the most part everyone acted like this was just a bad dream.

Moreover, the vaunted "get acquired" exit that appeared to be the next-best exit option, has been rather overrated. The real acquisition numbers for the most part are not what investors (or founders) would like. Not to mention the acquisition could well mean the end of the road for the business (Google is the most famous for this) which is the opposite of what founders should want, and so produces some strange incentives. Yes, YouTube and Skype ... but the curve falls off quickly.

The bad news is that this pile of trouble has been sitting in the corner stinking up the room for years.

The good news is that it's not a sudden crisis, and may well be correctable by VCs who are willing to, um, take some risk (this means getting out of their comfort zone in terms of rituals and assumptions, or expanding said zone) which is, ironically, what they are supposed to be doing for their investors.

But what about all of that advertising? Isn't there money in all of those targeted ads? Or, at least, wasn't there supposed to be until the advertising market started downhill?

In the short term, maybe ... but in the long term, the model doesn't work at the macro level and here is some math that suggests why.

Showing ads is kind of like printing money. You can show as many as you like up to a function of your pageviews. In order for the ad-economy to grow, the attention economy has to grow. That is, the aggregate amount of attention-hours spent against ad-supported pages needs to grow. Ok, there's definitely evidence for that (GMail, etc.)

But what about the ratio of the ad growth rates to attention growth? Attention growth has real-world limits (number of people, amount of time, ad-blockers, desensitization to ads) while theoretical ad supply does not. The limit on attention growth does not limit real-world ad growth. For example, if I view 50 GMail pages where I used to view 15, it's entirely possible that the same amount of attention is now divided across more ads -- or that the total spent attention is even smaller.

In the long run, the ad-value growth is smaller than the application-value growth. So the deficit of uncaptured value for businesses relying on ad revenue grows larger over time.

We can check this analysis by looking at the numbers from another point of view. Start with the raw resource itself -- a piece of a data center that includes a unit of compute power, storage, bandwidth, and hosting.

Hosting and displaying ads is relatively less expensive (in units of the resource) than hosting application functionality. So the very resource which makes the ad-supported model plausible will supports growth on the ad side that is at least as strong as growth in hosted functionality, which is the attention-harnessing product. That is, the resource availability supports growing the supply of units for spending attention as fast or faster than the supply of units for capturing attention. Again, over time, in the aggregate, more ads are powering less features. The value of each ad goes down.

This has nothing to do with the overall economy, consumer spending, etc. It's simply a side-effect of the coupling between the monetization mechanism and the product.

If, at the same time, the "real-world" spending that is driven by even successful ads is flat or in decline, you have an even bigger problem.

My Brain on Web 3.0: a Killer App for the Semantic Web?

Here's a semantic app I'd really like and which could make the Internet -- and data stores in general -- more valuable. If anyone sees this and thinks it's a great startup idea, you're welcome to develop it.

Right now, a number of semantic analysis engines are being developed, and many are running well in production. Examples include ClearForest, which is related to Reuters Calais.

There are also a bunch of up-and-coming semantic-web apps, like Twine, that add semantic analysis to the extant web 2.0 experience. But while the RDF-enabled-del.icio.us-on-steroids-with-autotagging may be nice -- heck, I'm sure I'll be using one of those systems -- I want something that can carry out the kind of mental associations that I normally would have to do myself.

In order to make that a reality, I'll need several things:

1. The Model: it works by association, and associations have direction, degree, and kind, among other things. So we need more than just a network. We need a model that implements a metric space or vector space, allowing distances to be computed between any two points with sensible behavior, and where measures (length, volume) can easily and intuitively work.
2. Concepts (e.g., "politics"), and the places concepts are referenced (say, a political blog page), both live inside this space as subspaces, just like in my brain. Some of these spaces may consist of just one element.
   
3. The formulae that support metric need to be fine tuned so that abstract tags ("politics", "justice" as opposed to "Davis, CA" or "bananas") don't suck a million other things to within epsilon of themselves. We can't have everything that linguistically has to do with politics cluster tightly in the space to a politics node, or else the system isn't terribly helpful.
4. I want the system to start out thinking like me ... and then I can experiment later with "social thinking." What does this mean? My semantic tagging is different from everyone else's. Each group or culture I'm in sees the content differently from other groups and cultures; there is no universal invariant conceptual structure. One persons sees a news story and thinks "economics" while someone else thinks "environment" and another thinks "social justice." If we mush all these tags together we get nothing terribly useful. So: let's start out with my view of the world, we'll compare and integrate others' later.
5. How to do #4? Start with every web page I visit (not just those I actively tag) -- read my history file or my network traffic (obviously, keep raw data local for now). Read my email and my calendar and my notes and phone (PIM) and my to-do list. And weight accordingly: associations in a web page I write (like this blog post) count more than stuff I browse through; notes I make in my phone or Outlook count for even more; the metadata in my calendar and the titles of my contacts mean a heck of a lot for the model. Walk my social graph and look at what my friends know and are interested in! These are all straightforward algorithmic steps. Leaving aside any self-tuning in the metrics engine, there is no AI or black box here.
   
6. The data from #5 is part of the metric function ... that's how the system shapes itself to my view of the world, or at least my "attention waveform" as I transmit that through keystrokes and mouse clicks. Concretely, nodes "move" in the space based on whether I actually key them, whether they appear in meetings in my calendar, whether they are tightly clustered to my personal contacts etc. Even my contacts are arranged based on how long I've known them, what I talk to them about, how often, etc.
7. The system will make mistakes. So all the more reason for (1) privacy around my core data and (2) a dashboard where I can "juice" certain things or move them around. (This is where interesting goal-oriented self-retuning can come inThere is plenty of other data that can be shared and deduced for network-effect-dependent revenue streams.
   
8. A UI into the model. What I'd really like is something brilliant and minimalist (that I can't myself invent!) I know there are lots of desktop-based visualization methods that would be fascinating and could dazzle a crowd at a presentation, but I want something day-to-day useful ... and ideally something that fits on a mobile phone (or at least iPhone) screen. So that in a perfect world, if I'm out and about, I can poke this system with one piece of data and have it return the associations my brain makes -- and the ones it would make if I were jacked up on caffeine and had the whole internet in my frontal lobe somewhere. I'd like maps, charts, and pictures in there too.

I hope this outline makes some sort of sense. Like I said, it's really not as tricky or complex as it sounds. Fine tuning the metrics will take real work, as will optimizing the data structures so that the relevant queries are fast, and so that the system can work in "tinfoil-hat-private-mode" as well as "publish-whatever-you-deduce-from-my-friendfeed-and-private-chats-mode."

Incidentally, this app could also help solve the augmented reality dilemma of "how do you narrow down all the possible info about the input objects and coordinates, so that the user sees something interesting and/or actionable," so that's another angle.

Have some capital or time you want to throw in this direction? Feel free to email me -- adbreind@gmail.com ... or if you want to loot this idea and think you can build a killer app for the semantic web era? That's fine too -- send me a link when I can sign up for the beta.

How Bay Area Subprime Mortgages Relate to High-Tech Startups

Earlier this week, Tom Campbell, Dean of Berkeley's Haas School of Business, gave a long interview about "the mortgage crisis" on KCBS' in-depth segment [MP3]. At one point, the conversation turns to the general paucity of housing in the Bay Area (relative to demand, anyway), and the notion that landlords may be beneficiaries as folks suddenly discover that (1) they can't afford $975,000 for that 3-bedroom house and (2) it isn't worth $975,000 anymore either.

But aren't these b-school types the ones who are always telling us to "think outside the box"? The best Tom can come up with is a kind of housing trust or co-op, that lets you own, say, 25% of an expensive house, while you still get to live in it (an investor group owns the rest).

That's a really cute way of pumping up housing prices and speculation even further, by letting investors who would never do the real-estate transaction themselves pool their investments and then spread them across a bunch of properties (doesn't this sound a little like the mortgage problem we just saw?), while leaning on loan guarantees to cover their downside.

The cost of housing and difficult commutes are a big brake on the tech industry; they consistently rank at or near the top of Silicon Valley business leaders' concerns about the growth of their companies and the success of the region.

In the positions I've held over the last 4 years or so, I've been responsible for hiring engineers. Not just punch-the-clock engineers, but wicked smart, willing-to-build-it-from-scratch-but-wise-enough-not-to startup-minded engineers. But it is brutally hard. Even with robust salaries, it is difficult to get applicants in the door, let alone hired. And, no, it's not due to a shortage of U.S. geeks. Housing costs and impractical commutes seem to be the primary limit on the realistic pool of applicants.

Over time, if we don't do something about it, we'll only have the old-guard geeks (who bought homes a long time ago or live in rent-controlled places in SF or Berkeley) and immediate college grads (who are up for an adventure and happy to have roommates).

The problem is, when your only tool is sprawl, and you run out of farmland to sprawl on, you either throw in the towel (Silicon Valley) or you sprawl farther away (American Canyon, Fairfield, Tracy, even Monterey). When your only tool for traffic congestion is building more lanes, that's what you try to do, even though latent demand means that more freeway creates more traffic in the long run, not less.

If I'm so clever, what am I suggesting? We need to use a different tool, namely smart growth.

Among other things, we need significantly higher density, infill development, and more mixed-use development (residential, commercial, and light-industrial uses in the same or nearby buildings). This isn't a speculative proposal: where it has happened locally, it has been popular. Look at Santana Row, San Mateo, downtown San Rafael, even South of Market/Mission Bay SF (although arguably the planning there didn't go nearly far enough, leaving too few housing units to make any dent in affordability).

Luckily, the Bay Area does not share America's poorly grounded prejudice against living in towns. So communities like the ones I propose, on the peninsula and in the East Bay (Hayward, anyone?) would likely be embraced. And infill opportunities abound: Every time you see a big-box store in the Bay Area, whether you love them or hate them, imagine a few stories of residences on top and additional businesses lining the enormous "blank" sides of the store at street level.

Will this generate so much housing that no one will be tempted to take on debt at crazy terms they can't afford? Of course not. But if it can help keep that housing-cost-to-salary ratio from growing quite so fast for the folks we want (and need!) to work with, while bringing the ancillary benefits of denser communities, it seems like a no-brainer.

No Uber-Soft Launches and No Stealth Mode

Uber-Soft Launches and Stealth Mode are two common practices that are usually big red flags of impending trouble.

To be clear, an Uber-Soft Launch is not a classic, small-scale launch where you release a decent version (maybe beta) of your product, but don't blast every PR trumpet you can find until you get a first round of feedback and some perf stats. There's nothing wrong with that; it borders on a best practice.

On the contrary, an Uber-Soft Launch is when the CEO or entrepreneur starts hedging about whether this launch is really the product or really the big launch he's been working toward and talking up. "We're going to just try this out and see what happens ... "

That statement is legit if it's intended as faux-modest understatement from a guy (or gal) who's clearly going for broke to make the product succeed. But if the firm or leader is really this wishy-washy and diffident about the launch, forget it. It's game over.

But then, in that case it doesn't matter because what the entrepreneur is really saying is that he doesn't expect to succeed so he's simply covering himself so he doesn't look silly after the failure. And that CYA attitude is one of the key things that indicates impending failure. It's a symptom of lack of conviction, a fear of failure that drives systematic bad decision-making.

Stealth Mode is a little less black-and-white, as there are a few cases where it may pay off. A few. Meaning not many. Luckily, Web 2.0 seems to involve far less "stealth mode" than Web 1.0 so it's less of a problem.

When might stealth mode be useful?

(1) A company has a specific physical or algorithmic invention (no, not Amazon one-click), and intends to patent it and to defend the patent vigorously (= has the massive cash to do so). Company wants to make sure it's documented and filed before anyone else files. If this is you, then you'd better be working toward the patent filing as fast as you can, no excuses. And get a good lawyer. If you're not ready and planning to defend, then stealth mode doesn't matter. Someone else can implement your technique if they want, and even patent it. You'll win or lose on execution and customer acquisition.

(2) A company's value is going to be based on a "network effect" play rather than a "hard-to-duplicate" play, and already has big the PR for the launch you lined up. In this case, since you know you're not "hard to duplicate," you don't want to spill the beans until you can fire off the giant PR cannons, at which point, you'll either grab a big enough chunk of network effect to sustain you, or else you'll drift. An example of this is Ning, which was in stealth mode for a long time. Marc Andreessen's celebrity and connections were the big PR blast, timed to match Ning's actual launch. But what if you're not Marc Andreessen or Kevin Rose and you're not going to make any headlines with your launch? Then you're not going to get a big "pop" when you come out of stealth mode, so really you're just:

Afraid of someone stealing your idea

But that's not a good reason for stealth. There are very few new ideas. If an entrepreneur thinks he or she has one, it almost certainly indicates insufficient research to find the people with the same or very similar idea before (and now), and consequently ignorance of why they failed (or might fail).

If this is you, get over yourself. Make it part of your "leadership agenda" to systematically find the previous incarnations of your idea -- or related ones. Analyze the heck out of them. Do better. Or be more popular. (Pick one or both).

But here's the twist, and if you're introspective then you saw this coming: you're not really afraid of someone stealing your idea, you're really

Afraid of someone not liking your idea

and you don't want to deal with that. You think that by waiting until you have perfect execution you will stun disbelievers with the beautiful product. That's just a delay/procrastination tactic. The underlying fear (of the product falling flat) will just make you want to delay and delay, making the product more and more "mature," so as to defeat nay-sayers.

Doesn't work. There will be nay-sayers. Embrace them. Love them. If you have money, make them into a focus group and pay them! Separate the whining pessimists from the ones with specific advice. Don't waste your time on the former, but realize that the latter are creating value in your company for free.

They are doing what your best product managers and designers should be doing -- finding and clearing roadblocks to adoption. Listen to them and verify what you think they're saying, by checking with other real people. Then you have a real bug list to work on, not getting the that drop-shadow AJAX doodad the right shade of pink.

As an entrepreneur, you're already drinking enough Kool-Aid by necessity; if you hide from naysayers, it just leads to a Kool-Aid overdose death-spiral.

I've been involved with companies that have committed both of these sins (and many more) so of course my perspective is warped by that. But don't take my word for it. Find the companies and entrepreneurs that you look up and want to learn from. Read their stories or go talk to them (being careful to filter out the Spiel and the 20/20 hindsight). Whatever you do, don't hide out convincing yourself you've invented cold fusion.

Hazardous Attitudes: Disregarding VC Due Diligence

The FAA identifies five "hazardous attitudes" that have proven so dangerous to pilot decision making over the years that they are explained in the FAA "Pilot's Handbook of Aeronautical Knowledge" and included by reference in exams and regulations. These attitudes are Anti-authority ("Don't tell me."), Impulsivity ("Do it quickly."), Invulnerability ("It won't happen to me."), Macho ("I can do it."), and Resignation ("What's the use?").

Working with startups, I've seen entrepreneurs exhibit all of those attitudes when trying to convince others (and themselves!) that they needn't worry about VC due diligence.

I would advise those entrepreneurs -- and any wannabe entrepreneurs -- to read Rick Segal's fabulous post on due diligence. In addition to giving advice, Rick explodes a commonly held notion that VC due diligence is just a formality and that, if you get to the d.d. stage with a VC, you're all set, you can just wait for the wire transfer to hit your bank account.

Due diligence is real -- Rick suggests that one or more of three deals he's currently looking at will not close because of problems at the due diligence stage. Read that sentence until you believe it. Then, before you tell yourself that it doesn't matter because you're going to bootstrap, you'll never need a VC or a corporate investor, go back and read the five hazardous attitudes again. If you think success means believing in Plan A so much that you don't bother preparing a Plan B, the odds are you'll be laughing about this failure some time down the line over a beer.

Now that we've got that out of the way...

A couple of Rick's points that deserve emphasis:

• Financial Forecasts. Of course they'll be rosy. What's important are the assumptions. Where did you get your data? How hard did you try to get good data? Is the logic that ties the data together sound?
• Business Thesis and Assumptions. "... [W]hat do I have to believe?  What do you believe?  And, of course, what are the assumptions behind those beliefs. ... You have to have the same story, metrics, thesis, etc, from day one." If you change your execution plan a few times, that's to be expected. If your fundamental beliefs about the space are changing faster than you can execute, you have little chance.

At some point between the kitchen table stage of your startup, and the time when you walk into a VC meeting, the following things will become relevant. Plan accordingly:

• "Understandings" or "Gentlemens' Agreements" with investors or employees. Unusual terms can be changed or dealt with at VC time, but I wish I had a buck for every time a CEO told me these issues would just melt away because everyone would be so pleased at the prospect of making a big deal or closing a round.
• Questionable expenditures. This can either be a few big items or systematic spending that adds up. Don't do it, and if you do, don't try to hide it or hand-wave. I've seen a VC identify a six-figure sum missing from the books, and still make the investment. The firm identified the issue and decided they would arrange the deal so as to handle it and get it under control. It wasn't a showstopper for the company, but it was the end of the line for the guy who tried to cover it up.
• Team issues. Although Rick says that not every VC would talk to all the employees in a small company (he would), it's a good bet that your core exec team -- and probably everyone in your first 8 people -- will get a good grilling regardless of the VC. The team has to be a team, and you won't be able to fake it. This doesn't mean everyone needs to agree or be buddies, but they need to function properly as a group. If you don't have a team, the VC will figure this out, and your funding is unlikely.
• Product. Ok, this should be obvious. You can spin the marketing claims ("a better way to manage your contacts" could be anything) but you can't fake the technical claims ("syncs up to 5,000 contacts to any device" is either true or it's not).
• Customers. Although some VCs seem to be trying to get all the risk out of their portfolios by investing only in companies with a solid customer base, that is their problem, not your excuse to pretend you have customers that are fictional, occasional, or just plain unlikely.

If you still think this is all hypothetical, or won't affect you, then take another look at the five hazardous attitudes and ask yourself: are you really planning for success? just closing your eyes and hoping? or fooling around and enjoying the ride?

Double Black Diamond Software Projects

I've spent a good part of my career working on particularly challenging development gigs that I have come to call "Double-Black-Diamond Software Projects"

What exactly is a double-black-diamond project?

The name comes from ski trail markings, where a single black diamond indicates (at least in the U.S.) an "advanced" trail, while two black diamonds indicate "expert."

In reality, the difference between single- and double- black trails is that a strong skier can typically waltz onto a single diamond slope and have confidence that it may be interesting or challenging, but it will have a predictable outcome.

The double black trails, on the other hand, can feature hidden obstacles, cliffs, terrain features that vary with the snow conditions, and even areas which may be practically unskiable depending on conditions. (E.g., the cliffs in the background of this image are the double-black "Palisades" at Sugar Bowl.)

In software development, a double-black-diamond project is one where the outcome is in question from the beginning, not because of resource issues (e.g., too few developers or too little time), but because some fundamental unknowns are involved. Something new is being created, and it is sufficiently unique as to make it unclear whether it is even possible to succeed, or exactly what "success" will look like.

These unknowns might involve integration to an unknown external system, performance of problematic features like voice recognition, custom hardware, etc. If these challenges seem feasible enough, or success seems valuable enough, to make the software project worth a try (ultimately an investor decision), but the sheer implementation risk (as opposed to business risk) is clear from the start, you've got a double-black-diamond slope in front of you.

I will be writing a number of posts on these double-black-diamond software projects, and I plan to cover

• typical elements ("signposts") indicating a double-black project
• why, as a developer, you might ever want to get involved in such a project when there are lots of other opportunities
• gearing up: the skills, knowledge, and/or people to bring with you
• the art of keeping project sponsors properly informed (the subtle part is the definition of properly)
• how to handle risk and predict outcomes (as much as possible)
• maneuvers and techniques to gain leverage and minimize the odds of failures or surprises
• managing the definition of "project success" (and why it's essential to do so, even as a coder)

Mozy Keeps Your Data Safe ... Once You Get It Working

A while back I wrote about Carbonite, a consumer PC online backup solution. I thought the user experience was fantastic, but I didn't love the idea that my data could be decrypted with just my (low-entropy) site password.

More recently, I decided to give Mozy a try. Mozy is another leading online backup app, and they offer 2 GB of personal backup for free. Interestingly, Mozy seemed to me to have the opposite qualities (both positive and negative) as Carbonite in my trial.

The security is hard-core if you choose: Mozy generates a 448-bit encryption key from any chunk of text or file that you give it. Naturally that means your source should have some decent entropy in it, and you'd better have a copy of either the key source material or the generated key file if you ever want your data back. But the folks who really want to keep their own key will know this already.

Mozy does encryption (and presumably decryption in a restore) locally, and ships the encrypted files off to storage. So your data is pretty darned safe from anyone inside or outside of Mozy.

The "average user" experience, though, had a number of annoying snafus.

The GUI on the client tool that manages your backups and filesets is neither pretty nor intuitive. I'm tempted to compare it to some of the more mediocre Gtk front ends to Linux command-line tools. Perhaps that's too harsh, but it does have a number of similar quirks, like multiple widgets that control the same setting without being clear about it, checkboxes becoming checked or unchecked "on their own", etc.

More troubling was that the client appears non-robust in the face of network outages. When the network dropped during my initial config, the app crashed. Upon restart, it did not appear to have saved state: I had to redefine my backup sets. I then started a backup, and the app crashed again when the network momentarily dropped. This time when I restarted it did have my backup sets, but the history window showed no trace of my failed backup.

Then, during my next backup attempt, after getting several hundred megabytes onto the net, my machine rebooted itself (courtesy of a Microsoft "patch Tuesday"). When I looked at Mozy, its history again showed nothing. I would have liked some information about the failed backup, and a way to "resume." Instead, I had to start the whole backup from byte 0.

This latter time, I achieved success. But in an era of WiFi access (which can be flaky), I would expect not only robustness in the face of network connectivity issues, but also a really solid resume mechanism. After all, how many machines will succeed with the initial multi-gig upload in one go?

To finish on a positive note, I should point out first that for paranoid^H^H^H^H^H^H^H^H security conscious people, it's great to have a tool that handles strong crypto inline and gives me control over the only key. Also, a quick search suggests Mozy is ready to bring out the heavy guns to address customer problems. If they keep that up, they'll be able to overcome almost anything else.

Carbonite Keeps Your Data Safe ... But From Whom?

Plenty of online companies have leveraged broadcast advertising (Travelocity, Amazon, and Yahoo! all mounted serious campaigns). Still, when I hear about a new startup on the radio in these days of TechCrunch-driven marketing, it seems like it deserves a look.

Carbonite is a startup offering easy-to-use offsite PC backup functionality to average end users -- they've recently started mainstream media broadcast advertising in the Bay Area.

I immediately wondered about the security of my backup data, though. As a youngster, you have all kinds of "secrets" that might cause you social embarrassment or get you grounded. As an adult, though, your PC hard drive has tax returns, medical records, legal documents, banking info ... things that you really don't want compromised. So a security breach of a service like Carbonite is particularly frightening.

Notwithstanding the company's "security" FAQs, which talk about encryption and about protecting the data in transit, I started getting a sinking feeling when the password field let me choose a six-letter all-lowercase dictionary word.

Since Carbonite has no other data about me, is that password enough to get all of my data back out? I took the app for a test drive and verified that, yes, my email address and that password gets all of my PC data back. Moreover, someone could "restore" my PC files to another machine, switch my Carbonite account over to that other machine, and then change my password, locking me out.

My password can also be reset if I forget it. But I don't lose access to my backup data. That means that my password is not required to reconstruct the private key that decrypts the data. A close check of Carbonite's web site verifies that in future they plan to offer an option where only the end user keeps the private key. For now, however, they keep everyone's private key on file.

I'm not a security analyst, but I'm going to toss out a few recommendations and let the experts weigh in and improve upon this as necessary:

• User passwords (maximum risk exposure is one individual's data)
  1. Require a stronger password than "any six characters."
  2. Communicate to the end user that this password will protect access to all of their PC data, so it's worth spending a minute to pick a longer passphrase.
  3. At least encourage the user to not use the same password that he uses for every web site (namely the first one that's gonna get stolen when he sits down at a random PC in an Internet cafe and logs onto hotmail, flickr, and MySpace).
     
• Maintenance of customer private keys (risk exposure is potentially all the backup data of all customers!)
  1. For power users, get that you-keep-they-key version of the app up and running ASAP
  2. Until then, make sure best practices are maintained around the storage of the private keys and data.
  3. Presumably, the keys should not be all in the same system vulnerable to a single security compromise.
  4. The keys should not be in the same system as the data they're protecting, for the same reason.
  5. No one individual should have access to all of the keys or all of the data, on purpose or by accident.

The service definitely delivers on the ease-of-use promise, from the no-credit-card free trial to the dead-easy "it just works" client application. I just hope it doesn't come at an unreasonable cost in terms of security.

The Hardest Thing About Having Plan B is Realizing You Might Be Wrong About Plan A

The second law of thermodynamics describes why it's easier to break a glass than put it back together; easier to write the wrong code than the right code; and easier to metabolize nutrients than to create them. Wilfred Bion's group dynamics theories provide a bit of a social parallel -- some of the reasoning why groups and organizations persistently do the "incorrect" (by their own definitions of "correct"!) thing. By default, groups tend to devolve from their own goals in more or less spectacular ways.

Our social interactions don't rigidly follow laws of physics, we can occasionally climb out of the potential well of typical group dynamics. Doing so improves our odds of success on technology projects.

One of my favorite success stories is Intel's "Yamhill Project." Yamhill is why Intel is still in business. But it's also something few management egos could have lived with, and the Intel exec team's willingness to deal is why Intel is still a going concern.

Once upon a time, Intel wanted to clean up all the messiness that had evolved over the history of the x86 architecture. Make a clean break and launch Itanium, a new 64-bit architecture and instruction set. The new chips would not be backwards-compatible, so the gamble was that if Intel said that the future is Itanium, then no matter how painful the transition for customers and partners, they would have to go along.

Given the egos, and the "all-in" nature of chip development, the typical move would be to wave the Itanium flag, charge into battle, and either win the war or die trying. Lots of famous companies have died (or become irrelevant) fighting these battles.

But Intel's team did something much better. A few folks early on said that the market might not tolerate the change and ... if an alternative emerged from a competitor ... the result for Intel would be catastrophic. Officially, Craig Barrett backed Itanium / IA-64 all the way. But in secret he gathered together some of the brightest engineers in the company and sent them off to work in a remote location on Plan B, a non-Itanium 64-bit chip that would be backward compatible.

Barrett and his team possessed an all-too-rare willingness to come to grips with the fact that the big IA-64 play might possibly go wrong. Instead of ostracizing whoever made the suggestion (more typical organizational behavior), they integrated the information and took a decision about how to work with that possibility.

As it happened, AMD came to market with a backwards-compatible 64-bit implementation. The market loved it, and, outside of a few server niches, it might have been game over for Intel right then. If they hadn't had Yamhill.

In a Small Company, NIH is Just Paranoia and Crackpot-ism

If you meet a math or science professor at a party and you don't feel like you have any intelligent questions to ask or small talk to make, just ask about his or her "crackpot file."  You're guaranteed amusing stories about sometimes smart, sometimes crazy, and always ill-trained "amateurs" who write in with easy proofs of hard things (like Fermat's Last Theorem) and hard proofs of impossible things (like squaring the circle).

In the software world, full-on crackpot code ideas tend to be self-correcting -- the code doesn't run, or doesn't produce the desired result. But crackpot-ism has a cousin in software. In large entities, this is referred to as NIH, or "Not Invented Here." An organization becomes so impressed with itself that it starts re-inventing more and more of the world, believing that its own in-house solutions are always better and more clever that what is in general use in the industry. NIH does not apply to "core" intellectual property, like a new algorithm for a search engine, where the whole point is to build something new or better; instead it applies to well-known components, like building one's own "better" database, when there is no evidence that an off-the-shelf database wouldn't work.

There are rare cases of NIH being beneficial, and beliefs that some organizations (the NSA and military) do indeed have more advanced solutions than what is generally available. But in most cases, and, in small software companies, in all cases, NIH is just crackpot-ism.

It is not uncommon for a startup to have a "genius hacker" doing a lot of the heavy lifting. Which is great. The problem comes when the genius hacker loses touch with the industry and the overall goal of the startup (make a product, make money) and begins creating his or her own "clever" and unusual architecture components. Common examples are inventing a new data storage engine (because none of the existing ones fit your application or are fast enough, and you don't understand the way these problems are normally solved and/or you haven't actually done a proper performance test anyway) and inventing your own TCP layer (because UDP is "more efficient" ... but -- wait! -- actually you need the features of TCP and surely you can figure this out better than the folks that developed it, they're so old and stupid anyway).

This flavor of crackpot-ism tends to corrupt the organization: as the system gets more and more peculiar, the company is increasingly dependent on the developer. New outside job candidates who figure out what's going on become increasingly reluctant to join the firm. The company lives in fear of the crackpot developer, because he insists that any substantial remediation would be foolish or have terrible schedule consequences.

Management may get an inkling of what's happening, but are more interested in the business benefit of achieving the next milestone than in the expensive, painful transition that will result from trying to bring some sanity to the product architecture.

And so it goes, with the strange architecture gaining more and more control over the company until the feasibility of products and features are determined by how well they fit into the crackpot's technology stack. Ultimately, the wacky implementation is driving the entire product roadmap, and the whole company is pwned.

The Money Has to Go Somewhere: Ads as Boom Barometer

During the dot-com boom, it seemed as though every advertisement on the radio was for one dot-com or another. Some campaigns paid off (amazon.com had a big radio spend); some didn't.

This morning I heard a radio commercial for "pinger" ... which appears to be a voicemail site for when you want to leave a message and really don't want the other person to pick up the phone. Or when you want to spam a whole bunch of people with voicemail. I just don't buy it. I had heard of it before and it doesn't sound any more sensible now.

The commercial was on KCBS, an all-news watt-monster in the Bay Area that is not cheap to advertise on. Especially during morning commute hours. In poker, this is what they call "buying the pot" -- and pinger is lucky enough to be buying with Kleiner's money.

Having recently seen VC-backed mobile-YouTube-play Zannel placing large ads at art events in SF neighborhoods where the only dot-com you expect to see is laughingsquid.com, I realized the ripple effect is underway.

I was hesitant to promote anecdotal evidence as economics data, but my confidence was bolstered by the coincidental publication this morning that "VC Investment Hits Highest Level Since 2001"

The money has to go somewhere. Like free movie tickets just for applying for a job:

More Khakis: Build a Market for Near-Future Consumer Dealmaking

Here's an idea I've had for a while... if you're good with strategy (see Hey, Guys in Khakis) you might be able to fit the pieces together well enough to make a buck. I thought about building something like this at one point but I'm just not enough of a strategist or a consumer to have a real passion for it.

The premise is that most everyone always has some purchases they're planning, say two weeks to six months out in the future. The buyer has some characteristics in mind, a general idea of price, and is definitely going to buy in that time frame. But he or she doesn't have a specific item chosen nor a specific date when it's time to search out a deal and buy.

As just one example, if you like or need shiny gadgets, you might have thought

• I'm going to get a X-megapixel camera sometime this summer, I'm just too lazy to read all the reviews and sort it out right now.
  
  
• I'm want to buy my wife a bigger flat panel, but the prices are always bouncing around. I think I'll wait a while and see how much LCD real estate I can get for my money.
  
  
• I'm sick of encoding all these DVDs. When I see a deal on TigerDirect or techbargains I'll grab one of those DivX-capable DVD players and be done with it.
  

There's a market here: a lot of people are not actively searching today (using one of the many comparison shopping sites), but they are definitely buyers. Whether $150 is a good pricepoint or $1500, it's something they are comfortable with and have essentially already decided to spend.

Today, this is an inefficient process on both sides.

The customer waits around until eventually he or she happens to hear the Fry's ad on the radio, drives by a store, or sees a chipmunk on the way to work and figures it's time to get a camera and start posting lolmunks.

The seller has limited visibility into who is interested in what products, when they plan to buy, and how much they'll spend. If a site has an extensive profile on you (say, amazon) then maybe they could develop an algorithm to predict when you'll upgrade your camera, what you're likely to spend, and how you comparison shop. They could then communicate directly with you to try and close a sale. But most vendors have a fleeting relationship with the customer, so they spend lots on ads, make sure their products are listed on sites like pricewatch, and hope the customer comes.

The opportunity is to create a market that lets vendors go look for buyers who want certain kinds of products, and make them an offer. For example, Fuji revs their cameras constantly, so maybe I have a bunch of a particular model, and I know the next line is coming out soon. If I want to move the inventory, I put it "on sale" and pay to advertise.

What if I could go and find a bunch of buyers who have said they're looking for this kind of camera at a price point I can stand and they're buying soon? My goal is to (1) offer them a price they'll buy at and (2) make enough on the sale that I'm still ahead of where I would have been in the "put in on sale and advertise" scenario.

This system would be a win-win. But several pitfalls must be overcome. Principally: How can you tell a "true buyer" from someone who just wants to window shop some really great deals? It makes a big difference to the seller, because publishing these kind of targeted deals out into the ether (offering them to arbitrary unverified people) is essentially the same thing as just publishing a lower price. It's asking the vendor to show his cards without the buyer committing anything.

So, to make this work, one needs at least a way of limiting the pool of "true buyers" to those who are plausibly legitimate. At the same time, it cannot be a closed system of fully committed participants since a "true buyer" may sign up, see some great deals, and legitimately decide to just forget it and buys something else that catches his eye. The buyer is not likely willing to be obligated to buy through this system.

The whole mechanism needs some sophistication, and probably a few small but key innovations that will keep people (mostly) playing fair on both sides. These might include unique valid credit cards, online reputation mechanisms, social networks, and some things that haven't been invented yet.

I believe such a market can and will be built. I expect to see someone clever or lucky make a bunch of cash building this and then selling it to eBay. And although I don't love shopping nearly enough to want to build this product, I'd gladly be its first customer.