San Diego, CA
4/30/2004

In Re: i2

The scene: a court of public opinion. The first case on the docket is i2. The charge: bad behavior, arrogance, irrelevance. The penalty for conviction: death by a thousand cuts.

Opening Statement: the Prosecution

Ladies and gentlemen, you have before you i2, once among the mighty, who willfully squandered its wealth, the respect of all, a competitive giant that promised its investors growth worthy of a Fedex or a Starbucks and now stands before you shrunken so far that it has been kicked off the NASDAQ. This is a company that has failed and disappointed for quarter after quarter, a company that is losing cash, that lets its license revenue fall to minuscule levels, that is beset with lawsuits, and under the cloud of the SEC.

These sins speak for themselves. We ask, gentlemen of the jury, only that you acknowledge the facts before you and render the verdict: pariah. Tell the world to look elsewhere for supply chain software, a supply chain partner, or a supply chain company.

Opening Statement of the Defense

Ladies and gentlement, to recommend such an action, you cannot just look to the sins of the past. You must look at the company today. You must recognize that despite its woes, the company has good software, loyal customers, and assets that it has not yet

The niche, for those of you who don't know the company, is what founder Bryan Stolle calls "component engineering.;" The core Agile software engine helps a company "engineer" the components of the products that it makes. More specifically, the engine helps them create the list of components (its Bill of Materials or "BOM") and change the list when necessary.

This is a necessary function in companies, but in most industries, it's one that is performed by the ERP product. The only companies that really >have to have a separate bill of materials manager (like Agile's) are those who have very complex bills of materials, containing lots of commodity components, which change very frequently.

Companies that make electronics boxes or electronics box components, in other words.

When Stolle started Agile, I don't think he realized that his idea was only going to take hold in a relatively small niche. He thought (I believe) that he would create a superior product, one that appealed immediately to people in high-tech electronics, then move out to other industries. But three things happened to him. First, he could never find other industries that really needed the product. Second, the high-tech industry went through vast changes. And third, investors in dot-bomb software companies didn't want anything as pedestrian as a BOM manager, which meant that he had to change his original plan.

The result has been years of floundering, management changes, unsatisfactory growth, unfulfilled promises, and losses. Much of this was probably inevitable, no matter what the ambitions of the owner. But watching this company over the years, I would often feel that the damage was self-inflicted.

Recently, Agile has morphed again--adding some management in key positions and once and for all trading in its old niche for a new one: PLM. Many of us would be reluctant to become yet another vendor in a crowded and unproven space, but for Stolle et al., I think it was a way of getting out of this bind.

In the rest of this article, I evaluate Agile's position as a PLM player and lay out a position (as usual, an equivocal one) about Agile's prospects. Bottom line: there's a lot of opportunity, more than most observers realize, but Agile's past inability to execute gives me pause.

Agile as a PLM Vendor

In the software business, all you have to do to become a vendor of "X" is to say one day, "Hey, I am a leading vendor in the X space" and show people some Power Points. Agile has come pretty close to doing this in the past, so it's appropriate to look askance at Agile's new claims about PLM. But in this case, Agile has done more than just issue some slides. They have bought a company that does provide some PLM capability and has customers in industries that Agile would like to enter.

The company is Eigner, whose core product is/was a CAD viewer that connects to many different design systems. Eigner's customers are in heavy industry--automotive and aerospace, for instance; they have particular strength in Europe.

Eigner's customers typically make complex mechanical products whose components are designed for the product (and hence aren't commodities). This means that design for their final product often occurs in many different places, using many different CAD systems, sometimes in many different organizations. Eigner's CAD viewer is useful to them because it allows everybody to at least see what is being designed, no matter what system has been used.

In itself, Eigner is not a bad acquisition. It allows Agile to say that it's a PLM company, and it gives Agile some access to new markets. But Agile isn't just trying to establish a new product line. They want to combine Eigner and Agile into a single PLM suite that is appealing in both electronics and heavy industry.

And unless they do that, it's not a terribly persuasive action. "Unless Agile can integrate Eigner," said one commentator to me, "it will be two small companies operating side by side. What's the good of that?"

Even that comment probably understates the problem. It isn't just integration that's required these days for a PLM vendor. It's process management.

As both PTC and Dassault have found out, just having a viewer doesn't make you into an effective manager of product lifecycles. You also have to be able to embed the views that you have in a process. Say you have a view of a radio console that's going into a car. Is this the proposed view, the approed view, the final view, the vendor's view? What changes has it gone through to get to this point? Etc., etc. If you don't have a defined process for managing the view, and if the view doesn't locate itself within the process, it doesn't have too much utility.

So Agile can't just integrate the viewer. It also has to build persuasive process management. And that will take a long time. So unless there are other synergies in the meantime, it's time to worry.

I talked at length to Agile last month, and while I don't think they have answers for everything, I do begin to understand why they think that it is possible to make this pairing make sense. They make the following points:

• Integrating Eigner is simple. The basic plan is simply to make the Agile BOM manager be the point of integration. An Eigner view of a BOM or a component will simply be attached inside the engine to its corresponding item. There are issues with this, but despite these issues, the basic idea is startlingly simple and easy to implement. It isn't full-fledged process management. But it is a very good base.
• Eigner gives them entrée and industry expertise. The Agile BOM manager hasn't been able to penetrate even the industries where it ought to do well partly because Agile doesn't know how to sell into those industries. The Eigner acquisition opens doors and may show them how to modify their product. This is the kind of synergy that provides immediate benefit.
• B2B matters. Agile is betting heavily that outsourced design is going the way of outsourced manufacturing. As part of what they do, in all industries, component manufacturers will try to differentiate themselves by offering design service, and they'll need both a viewer and a BOM manager to make this work. So Eigner will help Agile in electronics as much as Agile helps Eigner in heavy industry. Again, you don't need a full-fledged process manager to provide capability that will be useful.

Exploiting these opportunities isn't trivial. Success depends on execution, of course. It's easy to say, for instance, that open doors in one part of an engineering organization mean open doors in the part that you're trying to reach with your new product. But as Matrix One has found to its pain, it ain't necessarily so. Still, all these points seem to me plausible.

The eventual plan, of course, is to build full-fledged process management and be the system of choice for managing design and development of product, in either heavy industry or electronics, with a system of record that includes both data and pictures, one that is able to cross corporate boundaries with multiple processes. The point Agile makes is that they don't need to get there today.

The Short Term Prospects

In fact, after talking to Agile, what I like most is not this ultimate vision: it's the fact that the short term has plenty of potential.

You expect growth from a software company when they have a new version or new products to sell into the old installed base, when they have an entirely new kind of product they can sell to early adopters, or when they have an adaptation of their old product that they can sell into previously closed markets. As it turns out, Agile is in a kind of triple-witching period; they can do all three.

As for the first, Agile has just released a new version, Agile 9. This contains some improvements on the old BOM manager, as would be expected. The procurement and cost management capability, for instance, that Agile has sold for some time has now been significantly improved and extended with the acquisition of Tradec. Other improvements are designed to help Agile in markets like medical devices, where it has found some limited success. New versions always help you sell new software to old companies, because they buy more when they upgrade. But this new version should do a little more; it may help reach some companies (possibly mostly in medical devices) that hadn't found the product compelling before.

As for the second, there are several new products. One is a product that tracks components after sale and provides quick feedback on whether the components worked to the people who are managing that product or later versions of that product. This is a good idea, but it requires new processes to be put in place, so it's likely to have a slow start. A second is a regulation and compliance manager, something that allows you to measure whether the components you have meet requirements of many different kinds. It's hard for me to gauge the acceptance this is likely to get; it's included as an example of the ingenuity that Agile is bringing to the problem of broadening its suite.

As for the third, there is a product for early adopters, the program manager. This is the product that will eventually embody the vision that Agile lays out.

The basic problem of program management is this: how do you make sure that all the pieces and parts of a new product are being created and put in place in the right way and the right time. Agile wants its program manager to be the solution of choice in industries where the system of record for components needs to be the basis of your program management. In the film industry, for instance, that's not at all how program management should work, but in automotive, it probably is. Right now, this product appears to be too lightweight to get proof points in many of the eventual target industries (such as automotive OEMs). But it has gotten acceptance at a pharmaceutical company, where they use it for packaging. And the idea appears to be persuasive at several other companies.

I think all of us would like to be able to say now how this program management product will play out, how it allows Agile to differentiate itself against the other PLM vendors, and what kind of growth Agile can expect. But so far, I think it's just too early to say. The fact that the product exists and has some customers is certainly not a negative; that's about all that one can be sure of.

Macroeconomic Forces

To some extent, the long-term success of the company depends on the viability of this last product. But not entirely. To some extent, it only depends on Agile's ability to go to its Eigner customers and sell Agile products and vice versa.

And, to a degree that I think is not generally recognized, Agile can succeed over the long term even if this product never really plays out, if one other thing happens.

Agile is hoping that macroeconomic forces (read: outsourcing) will create new kinds of "PLM" buyers for its product set.

In high-tech electronics, for instance, the whole system of contract manufacturing (outsourcing manufacture of the boxes) is putting so much pressure on the middle tiers that something has to give. One response for these companies is to provide more outsourced design as well as outsourced manufacturing. Agile is trying to anticipate this and provide a solution that people who want to offer or receive this service. The solution would require Eigner (for viewing) and Agile (for the product record), but it wouldn't necessarily require full-scale program management.

In other industries, where the contract manufacturing system is less well established, Agile is hoping for something else. These industries are only just discovering the need to keep control over the various design and change processes that are involved when you outsource manufacturing. With the highly flexible Eigner viewer and the ever-improving BOM manager, Agile hopes they can become the natural supplier for many of these companies.

Making products for industries that are in flux has always been part of the Agile strategy. You can make a lot of money if you are sitting there with the only software that really works and a lot of companies trying to adapt. But over the last three years, Agile's record with this strategy has been spotty. They've seen the trends correctly, but other companies (for example, recent acquisition Tradec) have been better able to meet the customer nees that have emerged.

New Management

In the short term, Agile might get a boost from its new release, from its new products, or from its early adopters. In the long term, it might be able to take advantage of any number of the changes that are roiling manufacturing in many industries. A lot of good things could happen to this company.

But the company today doesn't look like one that's about to take off. It is only on the edge of profitability; it is trying to manage two new acquisitions; it is trying to enter two new industries; it and is trying to run a newly complex product suite. The execution challenges are not trivial, and execution challenges are not something that Agile has overcome in the past.

I wouldn't even be writing this if there weren't a new player in the senior management, Chris Wong. Chris has been in this game for a long time; he was at ASK, PeopleSoft, SkillsVillage (which he founded), and PeopleSoft before coming to Agile.

As I understand it, Chris has been given broad responsibilities around sales and operations. In our brief conversations, he has told me he is doing what any competent, experienced software person would do: repairing holes with new people, coordinating efforts, putting in discipline, and generally making the company look more like well-run PeopleSoft.

In my view, Chris has several things going for him. He knows the business. (He has been in manufacturing software for almost as long as he's been playing golf.) People like to work for him. He knows lots of people who have been on the shelf for a while and are eager to get back into the game. With these strengths, I think he has a good chance of improving the operational effectiveness of the company.

Last Notes

But Agile doesn't need to be a $1 billion company. Growth of 50% over the next 2-3 years would be good in most people's eyes; 100% growth in 4 would still put them ahead of most comparable vendors.

With excellent execution, this is by no means out of the question. The product suite is buildable, and as currently envisioned, it provides a differentiated offering within the PLM space. Some early adopters have already accepted the vision and are cooperating in helping to build it.

If the world cooperates and behaves the way Agile envisions, there will be buyers to follow those early adopters.

Over the next few months, how will we be able to tell? I would look first and foremost for operational improvements: profitability, increased license revenue, etc. Then, I would look for significant sales outside the core: proof that the cross-selling strategy is making sense and working.

Over the next few months, I'm going to watch Agile closely. I will try to spend some serious time understanding how all these products are being used at customer sites. I will report back when I know more.

To see other recent Short Takes, click here for a listing.

The i2.