What can we learn from Cassatt’s demise?

There’s an interview with former BEA co-founder Bill Coleman in Forbes about the last days of his company Cassatt.

Bill Coleman is now the founder and CEO of Cassatt Corporation, a San Jose based software maker focused on data center management.

When thinking about software companies, it’s hard to think of one that had such a good pedigree, so much funding ($100,000,000) and such a large market opportunity. Bill is a true Silicon Valley veteran, having had senior positions at Sun and then co-founding BEA (he’s the “B” in BEA). Other members of the management team are no slouches either.

But the interview is quite telling in what may have lead to Cassatt’s sad ending. And in a couple of cases, it’s surprising that a rock-star management team and sophisticated investors would get caught the way they did.

First off, I love the subhead of the article:

Software maker that vowed to topple giants hit by economy, slower sales–and giants.

It almost reads like a headline from The Onion. Reminds me a bit of the failed Cuil launch.  You know, the search engine, founded by some ex-Google folks, that stated it’s goal was to take out Google. Why do people think they can pick fights with and bring down industry giants? Maybe it gets you some press, but how much is that worth if your product or service doesn’t live up to the hype(rbole)? Time for a Product Management Axiom:

Nail it, then scale it!

Find a good meaty problem, solve it really well, make sure you know why people will pay for it (by actually getting people to pay for it!) AND then figure out how to scale it up and take out the big guys. Seriously, why get on a big competitors radar when you have no way of defending yourself against their attacks?

Bill has a few choice lines in the article. Here’s one:

“The big guys copied my story,” says Coleman.

Yeah, so… Isn’t that what the “big guys” always do? When the “little guys” innovate and create something potentially valuable, the “big guys”  either buy the little guys, or barring that, copy them.

Or barring that, the big guys spread FUD, until they can either copy them or buy them or buy one of their competitors, thereby copying them. That line sounds a bit too much like a high-tech version of “the dog ate my homework” excuse.

And then there’s this line:

“I thought I could give companies something radical that had a proven return on investment, and they would be willing to change all their companies’ computer policies and procedures to get that.

Huh?  Give companies “something radical” and they would be willing to “change all their policies” to buy Cassatt’s product? Who can give me examples of when this ever happened. I’m saying “examples” because it may have happened once, somewhere. But really, this line in the article shocked me.

Lesson for anyone who thinks this could possibly happen:

Change is a process, not an event

It’s another Product Management Axiom, and one no product manager or executive should forget.

Nobody, and I mean nobody, gets up in the morning and thinks, “I’m willing to change everything about how my business operates because a vendor has a really great product that could save me money.”

Seriously, what’s the risk/reward ratio here? Huge risk, and maybe a medium sized reward?  And the real cost, not just the cost of the software, is enormous.

I once worked on a product where the architecture and GUIs were radically changed in a major release. It was absolutely the right thing to do.

The architecture went from 2-tier to 3-tier and provided great scalability improvements for customers. Customers had been complaining about performance and scalability in the product. And the GUI changes were primarily driven by user requests for a more sophisticated workflow mechanism in the product. Overall customers loved the new product, but the biggest complaint about the upgrade had nothing to do with technology.

As one large customer said:

“It took us 2 weeks to upgrade and test the new release to ensure it was working properly. It took us one year to retrain everyone on how to use the new GUI and capabilities. Please don’t make that kind of change again.”

So in the end, what did Cassatt in had little to do with technology. In fact, what does most  high-tech companies in usually has little to do with technology. In Cassatt’s case, as in most cases, it has to do with underestimating their competition, not understanding the psychology of their customers and buyers, and compounded with what looks like a case of overconfidence by the management team.



5 responses to “What can we learn from Cassatt’s demise?

  1. >> I thought I could give companies something radical
    >> that had a proven return on investment, and they
    >> would be willing to change all their companies’
    >> computer policies and procedures to get that.

    > Huh? Give companies “something radical” and they
    > would be willing to “change all their policies” to
    > buy Cassatt’s product?

    Companies do eventually change their policies, but definitely not fast enough to make a sale.

    I also thought it was funny that he was essentially talking about something radical with a good track record. I’m not sure how to manage that, because “radical” often means “too new to have a track record.”

  2. Max,

    Agreed. And that’s why change is a “process”. Companies will change policies — look at how SaaS applications caused companies to change their policies around how and where corporate data is stored — but it takes time. It’s always evolutionary and not revolutionary. Cassatt was trying to be revolutionary. A tough battle to fight.

  3. Pingback: The Long Tail of Cloud Computing? «

  4. I find it interesting that someone (you) who has no direct contact or experience with Cassatt could sit at their computer, read an article in Forbes with a CEO of a company that just failed after burning through $70 million dollars (that is the real number) and think you could accurately diagnose why the company failed. Having worked at Cassatt for 5 years I can say the forces involved with the companies failure had little to do with “the Big Guys” or customer adoption (although widely successful sales would have killed the company in a different way).

    The factors involved were more along these lines:
    – The original company from which Cassatt was born, Unlimited Scale, which was suppose to be a cash cow that was to fund the cloud computing development was a bust, producing no real revenue (thus additional funding was required). The 50 odd people that came with Unlimited Scale have few skills that were transferrable to building enterprise grade software.
    – Three development sites with 3 types of developers and development styles producing quite a bit of internal angst.
    – A “go big or go home” sales model. If a customer did not present a million dollar plus contract opportunity it was not pursued. Such contracts take time to close and the associated customers demand changes since no product perfectly fits each specific need and since they are paying a lot of money they want the changes or contractual obligation for the change before signing the contract (we spent 3 months making changes for NetApp which subsequently decided not to move forward with the contract).
    – A continuous rollover over of “top executive talent” who could translate their big company successes to a small company business model – such people are not doers, they are merely sayers.

  5. Pingback: Bill Campbell says, It all starts with great products! « On Product Management