Lady Windemere's FAM

I agree with Les and Hardtruth. Trying to account for each R&D is actually core to the premise of Innovators Dilemma. Pricing is subject to mostly external factors like competition and what the market with bear and how differentiated the position of the product is. Often times the price a product will command is not well correlated to its engineering complexity. Take Verilog simulator vs logic synthesis, which are comparable technologies but with 2-3x price difference. Tracking revenue to products is like hanging an Albatross on innovation, as the more complex technologies which take investment yet have a long lead time and slow ramp are not getting funded. If vendors actually believe in integrated platforms then there is very little merit in associating revenue to specific product entries. The best metric is customer usage, their technical feedback and the performance of the software. Within EDA companies there is endless fighting and bickering over revenue allocations to products and who gets credit for which piece of code. The end result is gaming the system and escalation of list prices with aligned escalation of discount rates which starts to look like Argentinian currency. The sensitivity to revenue runs rampant through product teams to such a degree that individual developers filibuster basic product improvements waiting for proof of revenue impact. In majority of cases customers are eager to give product feedback and give ample warnings and assistance to help the product improve before swapping it out as they have to go through switching cost and take risk to change. Many times there are courtesy benchmarks with a load of feedback on how well the product performs versus competition. True technology companies like Google, or maybe even Apple or IBM there is far less of this anal retentive analysis on the revenue recognition to specific components. Again there needs to be a model change away from this focus on the dollar exchange and more focus on the task at hand which is designer productivity and QOR. If a product manager does not know what to build then he has his eyes and ears closed or truly does not understand the marketplace. A model change is sorely needed, but likely not going to happen without some major industry shakeup.

It's really a straightforward explanation and links to a number of Paul's previous posts: The EDA model is broken; Sales quota levels combined with 90 day reporting cycles and savvy buyers purchasing in the final week of the quarter; Make versus buy blurred; Unsustainable ROI for both vendor and procurer. It is only the niche EDA guys who will take the time to embed and drive the product adoption technically into the customer because that is their raison d'etre (actually in the case of Synopsys this the exception that proves the rule). Does anyone remember the $1M commission EDA sales guy from the late 90s? He's still very prominent in the EDA world. Do you think that commission got earned fussing and deep diving over the technicalities, vagaries, bugs and trade-offs of compiled Verilog versus XL? Exactly.

This situation is a bit more complicated than you're describing. Lets say you run a rental shop and three people come in to rent mowers. One is mowing a massive weed choked lot, another is mowing a 'standard 50'x100' house plot, and a third is mowing the sliver of grass between their bungalow and the front hedge. What can any of them tell you about the value of this particular rental? ~~~ Buying lumber means someone cuts down a tree, cuts it up, ships it to you, and stocks it in a store. The trail of costs that follow that board are easy to document. When someone defends you in court, the allocation of costs is far more arbitrary: he or she kept your rear out of jail. What that's worth is dependent on the nature of the preceived offense and what you would be doing with the time if you weren't in the slammer. The attorney might charge you by the hour or a fixed fee, neither of which is remotely relevant to the value of your freedom. ~~~ Software is like a rental in that over time, you're using a progressively upgraded product, so the instance that you use at any particular moment is 'different' in the way that you might rent different mowers on different days. It's value can change during it's use as you discover your design has fundamental constraints or newly recognized opportunities, the first kills your project and perhaps your need for the tool, the second makes the tool priceless. You don't find this out until you're pretty deep into the design, and time has allowed extraneous factors to intrude. You take your constraint back to the developer, and they look at it and say, "Oh, that's easy to fix" and they fix it. Your tool doesn''t look particularly different, but you can now design something in a way no one else could ever do cost effectively. Software, in this respect, puts the cart before the horse, you don't know what you can do until after you have the product. ~~~ It is very common for a fresh IT staff or consulting group to move in on a company, un-jam what is pretty close to a state of paralysis, and then move on. Prior to their arrival, the company's continued existence was in doubt. In an EDA context, no customer knows what they can do in advance, and the vendor has no idea of the customer's intent, and the customer flails around for awhile before getting into their groove. Suddenly something magical happens, and everyone is running round saying 'of course'. The vendor comes and looks at the way the user used their software and breaks out into a cold sweat: "You did WHAT with this program?". I.e., Volkswagen Beetles float, but they are not boats. ~~~ If someone is looking for a new subatomic particle, they write a massive amount of software to capture enormous amounts of data, but they have no idea what kind of data they're going to get. Once they see data, they start refining the program to make more sense of it. Eventually the data and the understanding converge, and the software exposes new knowledge. If you can price the value of that knowledge in advance, you're a genius (and probably not selling software for an EDA firm).

I still use Dracula.

The problem isn''t accounting. I''m sorry, its extremely easy to know how your product is doing... its called SUPPORT. When customers are mad at you, or are looking elsewhere, you sure as hell should know it. If a customer switches from Dracula to Calibre on you and you don''t know it, its because you weren''t spending enough time with them to care. Evaluating EDA tools takes time and costs money. An engineer doesn''t just decide today, "Hey, let me go buy some Calibre licenses". There is plenty of advanced warning. These companies are arrogant and just refuse to acknowledge it. They call their customer''s bluff, and it turns out they weren''t bluffing. Then the local support team tries to hide it so they don''t look like complete morons, then the product GM tries to hide it so he doesn''t look bad. Accounting is a lagging indicator. If I switch from Design Compiler because BuildGates works for me, I''m going to evaluate and transition... its about a 6-18 month thing, plus I''ll have a multi-year deal with Synopsys anyways (and its not like I''ll tell synopsys I dropped dc and they should just void the contract). If you look at the $$, by the time the money drops, you will have lost my business to the point of no return, and probably lost others as well.

I'm not sure that the EDA companies know much about price either. Greater price transparency would lead to more accurate pricing.