Reflections on AmberPoint, Inc.

A year has now passed since I left AmberPoint, and I've decided to put together a short re-telling of the company's history, at a very high level. As startups go, it was nothing special, just another company that tried something, didn't quite succeed, and has now passed on. But it was the only startup that I ever participated in from start to finish, and I spent nearly a decade there, and so it was a major part of my life. Hence, these brief notes, not so much because I think you'll find them interesting, but because I wanted to write them.

1. The company was formed in the summer of 2001, as Edgility Software, by Paul Butterworth and John Hubinger, who had worked together at Forte Software, and continued working together at Sun Microsystems. A team of 10 or so founding engineers was recruited. An initial ($9.1M) round of funding occurred; the early investors were Promod Haque of Norwest Venture Partners and Bill Younger of Sutter Hill Ventures.


2. I joined the company soon after it started, in October, 2001, just as the company was setting up offices at 155 Grand in Oakland, CA. (As a bit of nerd humor, we were at Suite 404, which led to a fair amount of joking about how that caused us to be "not found".) I had just turned 40 years old, and I thought this was my last chance to try to participate in a "real" startup: helping to build a company from the beginning, watching all the phases of how a company is born.


3. The first 6 months of the company involved a lot of recruiting and staffing; by December 2001 we were more than two dozen employees, and by winter's end 2002 we were more than 40. The company grew quite rapidly during its first year; there was a sense that this was a big potential market, and we needed to own the market early before any competitors could develop.


4. During this time we also completed the principal engineering work on the company's core product, the AmberPoint Agent. The agent was a programmable XML message router, which could observe and/or alter XML message traffic, and could call out to arbitrary Java code to take action based on the message flow. The agent was designed to be inserted into the XML message streams at the main processing points, such as application servers, web servers, firewalls, gateways, message queues, etc.


5. In May, 2002, the company renamed itself from Edgility Software to AmberPoint, Inc. The new company name was the result of a contest, and was chosen from various candidates submitted by employees; Greg Batti, our VP of Engineering, was the one who coined AmberPoint.


6. In November 2002, we had our second round of funding, of $13.6M, from the same core investors, joined by Crosslink Capital.


7. During this time we developed a very clever internal engineering technique that allowed us to write our software in Java, but post-process it with a tool of our own design that emitted a corresponding set of code in C#, thus giving us both a Java product and a .Net product from a single source base. This technology was extremely clever, but extraordinarily expensive to build and operate; basic product build times soon ballooned to over an hour to compile and link the product. However, it did make us, immediately and, as it turned out, for all time, the only company in our space which had both a Java and a .Net version of Web Services Management software.


8. In the winter of 2003, AmberPoint merged with / acquired CrossWeave. CrossWeave was sort of a sister company of AmberPoint: both companies were Forte spinoffs, Bill Younger was also the primary investor in CrossWeave, etc. The merger with CrossWeave added about 10 employees, mostly in Engineering, bringing the combined company to more than 50 headcount.


9. During the summer of 2003, we embarked on a re-engineering effort. The original AmberPoint Agent was an isolated piece of software; the new architecture made it possible to collect a set of agents together into a larger unit called a Sphere, allowing enterprises to tie multiple XML message flows together and see a larger view of their overall network flow. We also made the decision to revise our UI technologies and base our UIs on dynamic HTML, rather than on Java Swing, and we retained Cooper Design as consultants to help us with the redesign. The revised architecture was much more powerful, but also much more complex.


10. By the end of 2003 we had some of our first European revenues and we were competing for a number of enterprise sales. However, we were also burning cash rapidly, and we were losing a number of sales to competitors.


11. In early 2004 we struck a deal with Microsoft to build a web services product to be included as part of Visual Studio. Internally, this was code-named Kestrel (one of our engineering managers had decided to use birds of prey as code names); externally it would come to be known as AmberPoint Express. The idea was to give a low-end version of our product away for free to developers, with the hope that they would upgrade to our commercial product once they had their applications in production. As part of the deal with Microsoft, we also did a fair amount of custom programming for a model-based development tool that they were building; we had some model-based programming expertise (notably from CrossWeave's CTO, Sean Fitts) which Microsoft was interested in learning from.


12. Annual revenues during this time were about 2.5M to 3M.


13. During 2003-2004 we were rapidly expanding our direct sales force; we felt that we now had a product to sell and so we built a team to sell it. By spring of 2004 our headcount was at 62; our plan was to add 15 more people during the year and try to get to 8-10M in revenue that year.


14. In early 2004 the company decided to open an off-shore engineering office in India, and building this office occupied Engineering management for most of 2004. By summer 2004 we had selected the general manager for the India office, and through the summer and fall we were interviewing for early hires for that team.


15. To fund the growth of the sales team and the India office we had our third round of funding in June, 2004, a $8.2M round from the existing investors as well as new investor Motorola.


16. By the fall of 2004 we had grown sufficiently that we held our company meeting offsite, and we were negotiating with our landlord to expand our space to the entire 4th floor of 155 Grand. After 18 months of development, our re-designed Sphere architecture was finally going to be released. We believed we had 40 actual customers at this point; several of them were large enough that we were realizing some follow-on services revenue.


17. By the winter of 2005 our quarterly revenues were $1.5M or more but our sales force was pursuing a number of deals; during our fiscal 4th quarter we had 5+M in bookings and surpassed $9M for the year. It would turn out that this was our best quarter. It also turned out that a large part of this revenue was a special licensing deal for the technology we built for Microsoft, not a sale of our regular product line. We opened sales offices in Dallas, Atlanta, Washington DC, Boston, and Chicago, expanded our European operations, and started negotiating with possible Asian and Indian partners to open sales offices there.


18. The summer of 2005 was the make-or-break time for AmberPoint: we had a fully-staffed sales force, we had released our intended product line ("Release 5"), and the economy was fully recovered from the "dot com" bubble of a few years earlier. By summer we were at 99 employees, including 10 in our Pune India office.


19. By the fall of 2005 we were achieving quarterly revenues of $3M; we had 10 separate sales teams; we had achieved our first production customer in Europe.


20. By winter 2006 we were tracking sales metrics and trying to make forecasts. However, there was severe internal dissent: sales felt that the new R5 Sphere architecture was unreliable and poor performing, and had been very late to market; engineering felt that sales had made excessive promises, and also felt that engineering resources had been diverted to custom programming projects for several of our major customers.


21. Many people felt that the major problem at this time was that enterprise sales required a large sales effort, as we were involved in deals with companies typically used to working with vendors that were ten times our size. So the company's basic strategy was to find a friendly partner that could include us in these deals, but this was complicated because the company's core strategy, dating back years to when we had built our Java-to-C# translator, was to emphasize our cross-vendor, cross-platform breadth. In a time when each vendor was pushing their own Web Services engine, we worked equally well on all of them, which meant than none of them was particularly interested in pushing our software.


22. In the spring of 2006 we raised our fourth round of funding, a $10.3M Series D led by new investor Meritech Capital Partners. Our headcount in the spring was at 121; sales were growing, but so were expenses.


23. In the summer of 2006 we started working with a major new customer: Lehman Brothers, who would quickly become our largest customer.


24. In the fall of 2006 we had a $5M quarter. We changed our financial accounting procedures to handle deferred revenue recognition differently. We were hoping for a $18M fiscal year.


25. By the winter of 2007 we were still hiring, but we had greatly slowed the rate, and we had reduced our forecast to a $15M year.


26. In the spring of 2007 we raised $9M in a fifth round of funding; the Series E round added SAP Ventures as an investor, together with the existing investors. This brought us to $50.1 million raised in total. We held our annual meeting at the Claremont hotel in Berkeley. The sales team felt they could sell our product, but they were desparately in need of "Release 6", a substantial re-engineering of our Sphere architecture to try to address the performance and reliability problems, as well as to introduce a fair amount of new functionality (such as the SAP support).


27. By the end of summer 2007 we had finally accomplished a partnership arrangement with BEA, and we were starting to see substantial sales growth on the WebLogic platform. We were nearly 140 employees in headcount, with almost 30 in our Pune India office.


28. From here on out the story starts to become very sad, very fast, can be summarized pretty quickly:
    
    
    
    1. In Fall 2007, Oracle bought BEA, and immediately cancelled our partnership deal with BEA. Sales of our product to WebLogic sites essentially stopped.
    
    
    2. In the winter of 2008, some of the first rumblings of the credit crunch occurred, and enterprises worldwide began to scale back spending. We all took company-wide across-the-board pay cuts.
    
    
    3. By the spring of 2008, we were still burning cash and could not raise any additional investments.
    
    
    4. In the summer of 2008 we had a substantial layoff
    
    
    5. In the fall of 2008, the credit crunch was real. Most of our sales force had quit; engineering and support were still trying to satisfy our existing customers.
    
    
    6. In the winter of 2009 we had another company-wide across-the-board pay cut.
    
    
    7. In the summer of 2009 we shut down our India office.
    
    
    8. In the winter of 2010 the company was sold to Oracle for $49M. Many employees were offered jobs with Oracle, and a number of them still work there now.

So there you have it. What do I think I learned?

• Building a startup is a fascinating process; everyone should try it at least once.


• Our Sphere architecture was over-complex and under-implemented. Releasing a shoddy piece of software is an unrecoverable mistake. You can't re-implement fast enough to make up for a big stumble like that.


• Our cross-vendor strategy was an elegant bit of technology, but it made our engineering teams much less productive; worse, by trying to work with all Web Services vendors in the marketplace we ended up being that software that tried to do everything, and did it all in a mediocre fashion, rather than doing a smaller set of things, and doing them well.


• Building an India office distracted the executives at a crucial time.


• The credit crisis, having your largest customer suddenly go bankrupt, and the Oracle/BEA buyouts were pieces of particularly bad luck that hastened an unavoidable outcome.

I loved the people that I met and worked with at AmberPoint. I worked there for 8.5 years, longer than I've worked at any other company. For years I felt empowered and engaged, and I really wanted the company to succeed. But after the R5 release it all changed for me; I was puzzled and confused by many of the decisions that the company made, though I tried my best to contribute where I could. Overall, it was a memorable time, and I wish all ex-AmberPoint people the best in their future endeavors.