One of the common traits with startups — especially early-stage ones — is the constant worry about cash flow.
Unlike a small business that operates on fixed assets, a startup is dead when it runs out of cash. Salvage value is almost always zero since most of the assets of the company are invisible and probably as good as nothing if no reliable revenue stream is established.
Thus, when the startup team with limited cash available gets together to evaluate a project that requires capital investment to realize the potential upside, usually a lot of the time will be expensed on talking about what might go wrong.
I call this the downside bias in decision making in startups.
On the other hand, big corporates might have upside bias in their own capital budgetting processes. By default a project manager is only useful when the project exists. And since the company has a capital pool large enough for multiple projects and since individual employee is used to the company generating stable top line numbers every month, the project evaluation becomes a beauty pageant where project managers have the tendancy to exagerate the upside and downplay the cost and risk.
Needless to say, the upside bias in a big corporate is much less dangerous than the downside bias in a startup. A project in a startup is by definition highly risky. It's much easier — and more natural to the risk averse human beings — to list a lot of potential problems side by side with rather ephemeral upsides. And if the decision process boils down to a democracy vote on the project, the startup might as well pack up and dissolve, since no real startup projects will ever be kicked off.
I remember during the darkest days of my startup years, when we're struggling to ramp up the revenue and the competition was catching up, every investment decision would trigger a lot of yelling back and forth between the R&Ds and the sales. The former blamed the later for not bringing in more revenues while constantly asking for expenditures to support their clients. The later blamed the former for not investing enough earlier in backend services, therefore preventing them from winning the businesses.
What was lost in all those yelling was the upside analysis. And as the same drama replayed another 3 or 4 times, talented R&Ds and sales started to submit their resignations for exactly the same reason, despite being seemingly on the two opposite ends of the argument.
Bottom line: in a project evaluation if you find a lot of downsides with a project but only a few upsides, try to unbias a bit. For example, the few upsides could exponentially big while the many downsides are controllable and with enough visibility. A potential solution in this case would be to put down the upsides on the whiteboard in large letters, instead of just on a powerpoint slide as bullet points. This way people can visualize the expected values of the upsides when compared to the numerous but fixed-value downsides. Unbias is achieved then in this process and the startup can make better and more meaningful investment decision.