The VP was obviously impressed. In fact, “blown away” wouldn’t have been overstating it. The demo had gone perfectly, and even when he’d asked questions that took us off script, we were able to show what he wanted to see. His excitement was palpable. I knew before he walked out the door that we’d get what we wanted.
Funding.
Our little team, made up of some of the most talented software engineers I’d ever met, had been working 12-14 hours per day for the past two weeks to get this demo ready. In reality, a lot of it was smoke and mirrors. We’d cobbled together TCL scripts to fill in holes in our system where development hadn’t even been started yet. There were some places where the “values” that showed in the GUI were hard-coded. But, behind the scenes, the engine was actually running and doing its job. Databases were being written and read. Actual output files were being generated. It was REAL.
Or, probably, at least 90% real.
In EDA, developing a new tool is the least expensive part. Give me six great engineers (bonus if at least two of them are recent PhDs in the area of interest), a roomful of computer hardware, and one uninterrupted year, and I’ll give you a kinda’ usable new EDA tool that does whatever you want. In the world of developing new leading-edge technology products, that’s about as cheap as you’re gonna get.
That fact is what, in the old days, brought venture capitalists flocking to EDA. Tiny investments, it seemed, could reap huge rewards relatively quickly.
The problem is, that one-year-baked EDA tool (and this extends beyond EDA to most new software products, actually) isn’t ready to sell broadly. (SPOILER ALERT: It won’t be to that stage for at least five more years, if ever.) After one year, you generally have something that is ready to expose to one or two beta customers – each supported by a dedicated applications engineer who is an expert in avoiding the numerous known holes in the new tool’s capability. Those first two “customers” are sacrificial, by the way. They’re generally doomed to leave the party disappointed. No matter how many designs you’ve run through your new tool back in the regression lab, it’s pretty much guaranteed that the very first “real” customer design will break it. And, the second design as well. And, the third.
This well-known phenomenon is a real problem for large, established EDA companies. It’s really inexpensive to send of a half-dozen engineers off for a year to develop a new product that could eventually bring in hundreds of millions in revenue. But what you have after that one year isn’t something you want to risk showing to your valuable customers. In fact, your sales team, who works with your top multi-national systems-house customers, won’t let new, unproven products anywhere near their commission cows. New products suck up valuable AE resources and risk alienating key influencers at the customer site.
As a result, there is a low bar for EDA companies to start new products, but a pretty high bar for them to actually deliver them to market (when the real costs and risks begin). Getting a pilot project funded internally is pretty easy. Getting it past the rough proof-of-concept stage is exponentially harder. That’s why our demo was so important that day. We needed to convince our VP that our project was one of the few worth continuing past the original proof-of-concept demo.
This is why most EDA innovation has historically been done in small startups. Software startups are cheap, and they can get something ready to throw at customers pretty quickly. If the customer is unhappy, only the startup’s reputation is damaged. Make several real customers happy and get your product past the toddler stage, though, and you’re a target for acquisition by one of the big companies – one who could actually afford to market, sell, and support your product globally.
But some EDA innovation does take place inside big EDA companies, and the process for making that happen typically involves an early executive demo. That’s the point where fates pivot on a dime. That’s where the go/no-go decision is usually made about the continuation of the project. And it isn’t always clear whether, as an engineer, you’re better off in the long run if demo day succeeds or fails.
As every software engineer knows, getting a demo to look like the thing you’re building is a pretty quick and easy task. Really, you’re just mocking up a UI and putting some basic level of functionality behind it. Unfortunately, when you do that, you create a management phenomenon I call the “90% Trap.” No matter how much disclaimer you present to an executive, seeing a plausible demo gives them an incredible (and unjustified) sense of success. The product looks 90% done. Sure, there may be a few things to tidy up here and there, but obviously the thing is real and almost working. Right? Right?
As every software engineer also knows, that point where the demo looks 90% done is typically the point where the actual software development is about 1% done. By presenting the demo to management, you have just created a chasm that will most likely never be closed. At that moment, you become 89% behind schedule (more or less, depending on how you do the math). If the demo magically appeared after one month of development, management will be quietly stressed to know that three months later, the demo looks exactly the same. In fact, it might even look worse as reality has set in and putting “real code” behind some of the features that were only mockups has led to instability, poor performance, re-thinking of the user experience, and countless other issues. As the reality of software development and testing slowly sets in, It just goes downhill from there.
That first demo day is generally the best day in the entire product life cycle for a software development team. On that day, there are no customer bugs. On that day, they are perceived to be FAR ahead of schedule. On that day they are heroes.
It will never happen again.
From demo day forward, management will be disappointed. Development will take longer than forecast. Costs will be higher. Features will be less flashy. Early customers will be unhappy. Sales people will be disillusioned. Bugs will pile up. Team members will leave. Sure, there will be some good days as well as bad days. Eventually, if the team persists and overcomes the adversity of the initial development process (which can extend into many years), there may be the long-lasting satisfaction of real success – where the fruits of your efforts are enabling engineering customers around the world to do their innovation.
But the grizzled and wizened engineering team that arrives at that day bears little resemblance to the bright-eyed optimists who gave that original demo. Sunrise and sunset can be similarly beautiful, but they are horizons apart – separated by the experience of a day.
