The Abstract Truth

Archive for the ‘work’ Category

T3Server, Tengah, BEA WLS, and now: Oracle WebLogic

Posted by rbpasker on June 12, 2008

According to this article, it looks like the B E and A have finally been purged from WebLogic.

BEA did everything in its power to conceal the fact that none of its other revenue-generating products ever amounted to much of anything.

With this widely expected move crowning WebLogic Application Server as Oracle’s go-forward appserver product, while “continuing to support” (shorthand for “silently kill”; see “PeopleSoft” and “Seibel”) every other revenue-generating product, Oracle tells us what we already knew from its last 8 years of near-stagnant revenue numbers : BEA couldn’t develop a product from scratch to save its life (literally).

That is not to say anything negative whatsoever about any of the individuals people who worked on the rest of the products: BEA had many talented engineers, but the culture was so political and full of fear, that everyone was always more worried about their next paycheck and pleasing the powers that be, rather than striving to build the best thing they could. And many BEA executives I knew who were talented and well connected in the organization were eventually jettisoned because of eventual clashes inside the power structure, only to be replaced by plodders. That’s no way to run a company.

The other non-surprise in the article is that Oracle is keeping JRockit. What an awesome piece of technology. The open secret about JRockit is that BEA barely paid anything it, either in acquisition costs (“BEA Acquires Appeal Virtual Machines”) or in ongoing development. Think about it: For a company that wouldn’t budge an inch on its $10K/CPU app server licenses, JRockit doesn’t generate a single cent in direct revenue. How did that happen? Intel paid for it. Lock. Stock. And Barrel.

Intel (an investor in WebLogic, Inc.) was concerned that Sun would poorly support Java on x86 architectures in favor of Sun’s own SPARC, so they funded BEA’s acquisition and ongoing development of a superlative Java platform for Intel hardware. Besides the fact that it was free to BEA, the other pieces of information crucial to understanding the JRockit’s success inside the company are: unlike most of the other products, it didn’t have any internal competition; it was located in Stockholm, Sweden, far away from the trenches in San Jose; and it has fantastically talented engineers and management. Certainly JRockit was crucial to the ongoing success of BEA’s Java “own the whole stack” strategy, but would BEA, who famously would only acquire companies that could be accretive within a year of acquisition, have continued to sink tens of millions of dollars per year into a non-revenue generating product?

At one point in time (before I turned 40 and started balding!), I had shoulder length hair. At the time of the acquisition, I told my colleagues that I would shave my head when “BEA Systems” changed its name to “WebLogic.” I guess that was pretty arrogant, but the point was that WebLogic would become the most important brand in BEA’s toolbox, and that nobody would remember its up-until-then flagship product “Tuxedo” or its CORBA-based successor “M3” (now called “Weblogic Enterprise”).

I don’t think there’s much chance that Oracle, one of the strongest brands in the technology world, will change its name to WebLogic, but there’s little likelihood that the product will continue on as “BEA WebLogic.”

Posted in work | 2 Comments »

Its Not About Open Source

Posted by rbpasker on January 20, 2008

Another blogger is using my post “JBoss Should never have happened” to bolster their claim open source won the app server war.

What I wrote was that BEA was tied up in its existing expensive pricing structure, and JBoss was cheaper. Even the JBoss people themselves knew this: when JBoss raised money, I assisted one of the VCs with due diligence. I saw the JBoss investor powerpoint presentation. It was not about open source being better for customers. It was about a lower total cost of ownership.

I don’t believe (and never wrote) that the “innovator’s dilemma attack” by JBoss on BEA was a result of JBoss being an open source product. And, indeed, IBM’s WebSphere is not an open source product, and unlikely will ever become one. Neither is SAP’s NetWeaver or Oracle’s OAS. IBM bought Geronimo to prevent JBoss from doing to WebSphere what JBoss was doing to BEA: undercut its prices.

There is another aspect that pundits attribute only to open source, and that is frictionless adoption.

When we made our products available for a free download, all you had to do was click through an ELU and register. But there were a few things we could have done to make life more difficult and chose not to do:

  • We never changed the URL of the download page. If you had the URL, you could download the software without going through any hoops, and we never prevented anyone from downloading new versions.
  • You could type anything into the registration page. We never validated any of the fields. Lots of people put in junk, but plenty more filled the boxes in with correct info.
  • The license manager was easily defeated. We never tried to make it foolproof. People who wanted to hack it found it pretty easy to do, and we were flattered when instructions turned up on a warez site!
  • We never used an obfuscator. Paul Ambrose used to say that because of the decompilers, writing software in Java was like playing open-faced, naked poker. Some people sent in workarounds to bugs which were obviously made through decompilation. We didn’t care. We even had a joke about customers decompiling the software: “It looks like this guy used transcendental meditation to figure out what’s wrong.” (We did obfuscate some code which we had licensed.)
  • All the documentation and tutorials were online, and that was one of our best marketing tools! Even before they tried the product, prospective customers could read everything about it and decide for themselves. Some people using competitive implementations of standard APIs wrote to us to say how much they appreciated our putting the documentation and tutorials online!

Should we have become an open source product? Well, we did talk about it, and there were a few strong proponents in engineering. But at the time, open source enterprise software was still a few years out, and there didn’t seem to be a compelling reason.

When JBoss started to show up, BEA should have taken proactive (rather than dismissive) measures by lowering the TCO and making adoption frictionless again. They didn’t necessarily have to open source the product (although they could have); they just had to get rid of the cost and friction motivation for new adopters. Hindsight is almost always 20/20. I’m not sure what we at WebLogic, Inc., would have done under the same circumstances.

Posted in personal, startups, tech, work | 1 Comment »

Respect your Competitors

Posted by rbpasker on January 20, 2008

Some people have used my post “JBoss should never have happened” to gloat about the demise of BEA and the rise of JBoss.

I’m sorry, but that’s bullshit.

Rather than being paranoid at our competitors, Paul Ambrose kept in touch with them. He had good working relationships with Ofer Ben-Shachar and Zack Rinat of Net Dynamics. He knew Joe Chung of ATG, paved the way for alliances with Vignette, and always spoke in awe of the big deals that Kiva Software landed. He never said a bad word about anyone, and always made sure that our database drivers worked as well with competitors’ server products as it did with ours. As the market shifted towards our standards-compliant product (which was the template for J2EE), he championed discussions with competitors about licensing our core server code to them.

That is not to say that he was not fiercely competitive. But the energy he gave off was always positive, and he drove us all to compete fairly and squarely by building better products and winning deals. He never saw it as a zero-sum game, where the only way we could win is if everyone else lost.

So imagine my surprise when, one day in 1998, after we uprooted a competitor in a big account, one of the engineers who had worked on the project came to me and said something to the effect of, “this is another nail in their coffin. We’re going to kick their ass, and drive them out of business.”

I was floored! I knew the both CEO and CTO of the company, and they were good people. We had met at conferences and sat on panels together. I didn’t want them to go out of business, and I channeled Paul and told him that if he wanted to keep winning, to go back to his desk and fix some bugs.

More recently, I was shocked to read the blog of a guy whose company was recently bought, as he lay into his (admittedly combative) competitors. He wrote (I’m paraphrasing here): “To all my competitors who didn’t get bought: you’re in trouble because there’s nobody left to buy you. It must be scary for you if your exit strategy is acquisition.” (Many details purposely left out for obscurity)

Here’s what I wrote him in private email:

dude, please be a little more gracious. there are still a hundred or more people out there who have been working their asses off for years and will have little or nothing to show for it. if they pull your beard, so what? maybe they’re desperate. but there’s no reason to rub it in their faces.

He wrote me back:

I wish I could be more gracious. Unfortunately, my graciousness now gets translated by our competitors as an invitation to attack us, and when that affects the people that work for me, I feel like I have a choice other than to kick them sufficiently hard in the teeth so that they don’t do it again.

Five hours later, he wrote me back again, and said he’d taken the post down.


The proper way to demonstrate leadership to your employees is not to lash out at your competitors. Learn to be a good winner. Tell your employees to go back to work: write some code, get out in the field and win deals, think up a winning marketing strategy. By showing respect towards your competitors, your employees will respect you more, not less.

Posted in personal, startups, tech, work | 1 Comment »

The Impact of Culture on Innovation

Posted by rbpasker on January 18, 2008

Like most people, I suspect, how I feel about what I’m doing has a lot to do with the culture of the place I’m working. When I’m working with great people (or alone!) on an interesting project, I can be amazingly productive.

But in an environment where I feel undermined, or I am competing with other groups in my own company, or the company seems to be driven by raw power and power relationships, then I feel like I have no choice other than to bail.

This has happened a few times.

For example, when I was at Ingres in 1989, I worked in the Ingres/Net group, which was comprised of an eclectic group of 5 or so talented people who couldn’t get any of their ideas implemented because all of the decision-making power in engineering was held by the (also extremely talented) database server group and a few people in the front-end group who had been at Ingres for a long time. Ideas, no matter how good, that did not originate inside the power structure were summarily ignored. I don’t think any of the people in this powerful group thought there was anything wrong with the way things were. They just knew what they wanted to do and how they wanted it done, and everyone had to follow suit. I left after 9 months.

On the other hand, at WebLogic, we had a pretty good free flow of ideas. Over the course of 18 (very long) months, I single-handedly wrote most of GA server code that BEA bought (the database and html code was written by others, and we had a major release in the works at the time of the acquisition which had many contributors). The question I had to deal with as we started to hire people in January of 1997 was, how was I going to give all the new people coming on board a feeling of ownership over the server code.

Well, we had a bunch of things going for us:

  • a talented A-Team of new hires, who believed in the company and our mission of “Elevating Java to the Enterprise” [1], and were itching to get to work
  • I couldn’t continue to write code because I needed to hit the road and pitch customers. We were evangelizing a new category, and many of the sales people and Sales Engineers initially struggled with the presentation, although they all eventually became wildly successful at it
  • unlike a lot of one-person crash programming projects, the code base was in reasonably good shape
  • I had promulgated a hands-off testing framework, which was developed by BobA (who we lost many years ago in a swimming accident). This kind of testing framework is now institutionalized as “Continuous Integration,” and some of the WebLogic engineers later built and sold a company around this concept.

The result was that we had a very independent, yet cooperative, development team all working under one roof. People adopted or were assigned pieces of the system, like RMI, httpd, EJB, JMS, etc., and they worked on them independently. To provide consistency across the product, I instituted a set of “councils” on each subsystem, as well as on broad topics like security, management, and networking, that included me (as the chief architect) and a cross-section of 3 or so other members of the engineering team. Everyone in engineering was on at least one council, the monthly agendas and minutes were published, and anyone could come to any council meeting and contribute. I can’t say that every council functioned successfully, but what the councils did accomplish was to set a tone of of collaboration and the free flow of ideas across the engineering team. I didn’t need to make or approve every decision, and people learned to rely on their peers. That tone, I feel, spurred people on, because (unlike Ingres), people could get their ideas heard and incorporated across the product.

Following the acquisition by BEA, we faced something we had never experienced before: competition from the inside.

A week before the offer was announced, as part of the secret acquisition discussions, I went to a hotel conference room down the street with my laptop, and sat at one end of a long table filled with super-smart BEA technical people who were there to conduct technical due diligence. Eight hours later, I was flabbergasted. Nobody, except maybe one person, really knew what BEA was buying in WebLogic. They thought they were buying some sort of fancy web development system, like Cold Fusion, to act as a front-end to BEA’s leading product Tuxedo. Nothing I said in that room (“we have transactions, we have clustering, we have connection management, we have remote objects, we have message queueing, we have TP monitor underpinnings, etc.”) or showed them (I had my laptop open running Emacs on the source tree), would sway them.

This was quite a personal disappointment, because of all the possible acquirers (Sun, Netscape, Oracle, SAP, IBM, etc.), surely the BEA people would understand that what we had built was a Java-based TP Monitor. In fact, a group of us had gone up to IBM in ’97 to talk about WebLogic with the IBM software group, including Don Ferguson, the father of WebSphere. I have to say, the IBM folks really got it when we talked to them that day. Of course, we were dissapointed that they didn’t license WebLogic. Years later, I heard that IBM eventually spent a billion dollars to catch up with WebLogic.

Up until that point, BEA had been assembling a CORBA-based successor to Tuxedo, called “Iceburg”, first renamed “M3”, then, hilariously, renamed “WebLogic Enterprise.” M3 sold about 8 copies in total (I don’t have anything to back this number up, but I think its close to accurate!). The idea that a puke-y start-up from San Francisco with 20 developers could challenge the supreme legacy of Tuxedo was the rain shadow under which the acquisition took place.

At our first integration meeting, which included about 40 technical people from both companies, the topic for discussion was how were we going to turn WebLogic into a “web front-end” for Tuxedo. BEA’s Jolt Java client product for Tuxedo would be the lynchpin.

As you might imagine, I didn’t take well to this dicusssion. Having been one of the principal developers of a powerful TP monitor for VMS (which, after 20+ years, still powers the Citibank Funds Transfer Network and the Bank of New York’s Government Security Clearance System ), and having read the Tuxedo book, I knew what Tuxedo could do, and WebLogic was well on its way to being the web-based, OO successor to Tuxedo, TopEnd, and Encina. And I was right.

It was not only the technical people at BEA who were predisposed against WebLogic. Six months after the acquisition, I went to a strategy meeting at a Very Large Manufacturing Company, with a large group of BEA sales executives and technologists, and the local former WebLogic sales rep. In the pre-meeting meeting, it was predetermined that we were there to sell them M3 because they were a CORBA shop. Never mind that WebLogic had had many customers using CORBA successfully with our server product; the corporate mandate was sell M3, and no one in the room wanted to hear anything else.

I figured that if I was going to stay at BEA as Chief Architect of WebLogic, I would have to continue to deal with these kinds of issues. But endless political fights with closed-minded people was never my strong point (to say the least). I had to find something else to do.

WebLogic had had very good success selling WebLogic to ISVs as the underpinnings for eCommerce and content management products such as Moai, Vignette, and e.Piphany. But we decided that we were not going to compete in those markets because it would make it more difficult to acquire new ISVs, a major indirect channel for us.

At BEA, however, there was no such compunction. In early 1999, I lobbied to head up a new group that would accelerate the development of “verti-zontal” applications, that is, vertical apps that could be applied across many different industry sectors, such as a portal and eCommerce and content management systems. It took another month of lobbying to get even 2 developers. We all moved into one office. We started whiteboarding.

Then the calls started.

The rumor had gotten around about what the Vertizontal group was trying to do, and I got phone calls and visits from engineers, managers, directors and VPs from San Jose, Texas, and New England, who were tasked with building the exact same thing! Four separate groups, in 4 separate states, from 4 separate acquired entities, all within one mid-cap company, were now in competition. We were all starved for resources, we all had different ideas about what we wanted to do, and we all reported into different parts of the organization.

I attempted, obviously unsuccessfully, to get everyone working together, but the politics took over. Who would be in charge? Who would lose headcount to this group? What would be the underlying platform? What would happen to the managers and directors who were no longer needed by this consolidated group?

In the end, I don’t know what happened to the other 3 groups. I left.

BEA eventually built a portal product and acquired another one, and an early opportunity to build a suite of now-indispensable products on top of WebLogic evaporated.

Posted in startups, tech, work | 4 Comments »

JBoss (and possibly TomCat) should never have happened.

Posted by rbpasker on January 17, 2008

BEA made a lot of mistakes. Letting JBoss out of the box was probably its biggest.

While BEA was looking “up” at its biggest competitor IBM, JBoss was busily undercutting BEA at the bottom end.

The old mantra for enterprise software companies was that in order to have high gross margins, the labor-intensive services part of the business had to remain well below 40% of revenue. And since middleware was so critical to the F500, license costs had to be suitably high. BEA’s business was tied big deals at $10K/cpu.

JBoss launched an innovators dilemma attack against BEA, not with a revolutionary product, but with a revolutionary business model, one that BEA couldn’t hope to copy without cannibalizing its existing revenue stream. BEA fell right into the trap.

Also, at the time WebLogic, Inc., was acquired we had two server offerings, which became known as WebLogic Server and WebLogic Express. They were in fact identical code bases, but the “Express” product was a Servlet engine with JDBC, and no clustering, EJB, or other fancy stuff. It cost about $2500.

The great thing about this product was that if you were building a web-based application, you could get on board cheaply. This product was effectively killed off because BEA (and the sales team) didn’t think a billion dollar company could have $2500 product, especially when they could sell a $10K/cpu product wrapped inside a 6- or 7-figure deal. Enter JBoss, with its low price of adoption, and a 2-horse race became a 3-horse one.

In February 2003, BEA finally had to backtrack, and reintroduce the Express product.. A month later, they lowered the price from $695 to $495, a silly move in a market that is not price sensitive at that cost. Unfortunately, it was already too late.

Please read this update.

[Its also interesting to note that C|Net erroneously called this a “introduction,” not a re-introduction, and that it was in response to IBM’s “express” product.]

Posted in startups, tech, work | 5 Comments »

Oracle (ORCL) to Acquire BEA Systems (BEAS)

Posted by rbpasker on January 16, 2008

While the west coast sleeps, the east coast filled my inbox this morning with the news.

I have two initial reactions:

1. I hope the WebLogic brand survives, rather than being folded into Fusion. “WebLogic” has always been well recognized as an excellent product and a pioneering product in the application server space , and “BEA” has little cachet, unless your name starts with B, E, or A.

2. Arrogance is as arrogance does. Carl Icahn, well done.

Much has happened in 12.5 years since we started WebLogic, Inc. and in the 9 years since WebLogic was acquired by BEA Systems, and I need to think more about what I want to say.

Posted in startups, tech, work | 1 Comment »

How to Screw Up a Product Testing Cycle

Posted by rbpasker on January 2, 2008

Dear Product Manager,

Thanks for sending me your product! One of the most rewarding things I get to do in my professional life is get an early look at new products, and because I consider these early looks a privilege, I promise to reciprocate to you by providing quality feedback as quickly as possibly.

I know that your product may be raw, and might lack the stability, richness, or completeness that the ultimate product will have. I won’t ding you or your product for features or stability you didn’t promise me!

And thanks for setting up an email responder and forums and bugtrackers and mailing lists to collect feedback. And I’m glad your management identified you as the point man for this testing cycle. Both of these are very important.

Nevertheless, because our interaction during this testing cycle has been so poor, I have filed your product in the Bit Bucket, and I won’t be sending you any more feedback.

Here are some of the most common reasons:

  • You didn’t read my email / forum post / bug report. I told you that I read all the FAQs and docs, and I even gave you a list of things I tried. Why, when you responded, did you send me a link to another FAQ or doc page, or ask me if i tried this or that? Don’t send me a canned or ill-thought out response. I did my half of the job, now do yours: read my email.

  • You didn’t get me to the point where I could really try your product. When I sent you that note that said, “I’m still stuck on step 2 of the install,” I put your product aside, waiting for a response. Its took you 6 days to get back to me! Now I have to swap the whole mess back into my brain’s working set, and start over. You should have sent me the missing file, answered that one question, or fixed that little bug, so I could at least try your product out.

  • You didn’t test your product yourself before sending it to me. Yes, I know it works for you, but I have a “customer” environment. The URLs are hardcoded to point to a server behind your firewall. You’re referencing a file in your source code repository. You should have taken home a pristine laptop, and tried it yourself before sending it to me.

  • Your product has platform or version dependencies, but you didn’t try my configuration before you sent it to me, or you didn’t ask me if my configuration matches what your product requires.

  • You said you would send me a fix, but you didn’t. I’ve waited a week. I can see the bug in Bugtraq. How much longer do I need to wait?

  • You sent me a new release, but you didn’t mention the showstopper bug I reported. Is it fixed, but you didn’t add it to the release notes? Has it been forgotten? Is it in the queue?

    Hopefully, you get the point by now: when you’re in the role of testing program manager, you have to keep us testers productive and informed! If you do, we’ll work hard for you, and help you make a better product.

    Best, bob

  • Posted in startups, tech, work | 2 Comments »

    Tech Support, circa 2007

    Posted by rbpasker on October 21, 2007


    Posted in tech, work | Leave a Comment »

    A High-tech Entrepreneur’s Guide to Surviving Technical Due Diligence

    Posted by rbpasker on August 28, 2007

    The purpose of technical due diligence is to investigate the technical aspects of an investment opportunity. But tech diligence is done infrequently enough that few people get really good at it, and in the absence of being good at it, its worthwhile to have some guidelines. This survival guide just that: a guide. But a thorough reading should get you in the right mood, and if you prepare well, you’ll have a much better shot at “wowing” your audience. You’ll know you’ve done a solid job if the person you met with offers to invest himself or wants to join your advisory board!

    There are typically two different kinds of companies I come across: true high-technology companies that have a unique technology that can be applied across many different markets, such as Tervela and Mocana; and vertical companies which use (often novel) technology to deliver their product, such Mint, a new personal finance site, and MedCommons, which makes it possible for individuals to take control of their healthcare records. I’m only going to cover technology product companies in this post, but many of the same lessons will apply.

    Some people who conduct technical diligence sessions (or any diligence, for that matter) see themselves as gatekeepers, wherein every company starts out as a “NO!” until proven otherwise. But I prefer the “all students start with an ‘A'” method, which means that my job is to help them get through the process as successfully as possible, just like when interviewing a job candidate. Indeed, treat the diligence session like a job interview or an oral exam, with the except that your company and technology are as much under review as is team.


    Set aside a day or two to prepare for your first technical diligence meeting. You’ll be doing research, gathering materials, preparing illustrative slides, and, perhaps most importantly, getting yourself mentally prepared. If you’ve ever taken an oral exam or made a thesis defense, the technical diligence process should be a snap.

      Know your audience – Find out who is conducting the technical diligence and what that person’s background is, including work history and technical background. Typically a VC firm will try to find someone who knows your business, technology and ecosystem (e.g., SAP or MSFT) well enough to do a good evaluation, but that’s not always possible. Sometimes the VC will get someone who built or used the current generation of the product you’re building. And if your product is in a narrow technical area (security, embedded systems, etc.) or in a an area that is highly regulated, the person doing the diligence will hopefully have that experience as well. In any event, be prepared to give your audience some education on the intricacies of your domain.

      Bring your “A Game” – Amazingly enough, some companies don’t send their technology leadership to a technical diligence meeting! I’ve had non-technical CEOs come alone, put up the architecture slide from his VC pitch, and proceed to echo the party techno-speak and provide shallow or uninformed answers. Always send your CTO, VP Eng, Chief Architect, etc., to the meeting, so you don’t waste time.

      Provide documents in advance – If you will be referring to documents (patents, whitepapers, etc.) or drawings during the meeting, provide them beforehand, but don’t worry if they’re not reviewed in advance. I prefer to have the documents before the meeting so I can brush up on the domain. Having to photocopy, email, locate, or thumb-drive documents can be a distraction and slow down the meeting.

    Introduction: Company and Product

    Remember, this is a technical diligence meeting, so don’t give a investor pitch. But you’ll still want to cover a few non-technical areas in the introduction.

      Company – This is where you get to tell your “garage” story. Keep it short, but a good human interest story is key to drawing your audience in. Include the genesis and evolution of your product, too. This is where you also review the company status: headcount, previous and proposed funding, existing investors and advisors, etc.

      Problem – In an investor pitch, you would explain the business problem you’re solving, but in a tech pitch, you’ll also have to describe your customer’s technical problems, such as scalability, latency, volume, complexity, etc.

      Your solution – This is where you have to be very specific about what your product does. If your product is a DBMS, for example, say, “we’re building a new kind of DBMS,” rather than “our product fundamentally changes enterprise corporate data management.” You don’t want to get into a game of 20 questions while your audience tries to figure out if “enterprise corporate data management” means ETL, BI, integration, or something else entirely.

      Business model – Describe how your product will be marketed and get sold (direct sales, OEM, VAR, etc), and how your company will get revenue (licenses, support, consulting, etc.) If you are in the commercial open source space, now would be a good time to talk about licenses.

    Main Presentation

    You have a lot of freedom here to describe your product, but there are a number of areas which you have to address:

      Technology – This will be the longest part of the discussion, and should be done top-down, starting with an overall architecture slide, and going through every piece of your technology. If applicable, also describe the technology from a historical perspective, including previous failed attempts to solve the problem, and the overall industry environment that now make the problem solvable (e.g., increased processor speed, new algorithms, or availability of wireless spectrum).

      Underlying Infrastructure – Explain all your underlying technology choices, including programming languages, databases, app servers, and other tools and technologies that are part of your solution.

      Defensibility – describe the state of the intellectual property (IP), including patents, trade secrets, prior art, and the legal status of the IP ownership, rights, or licenses. You can also demonstrate defensibility by showing how hard it is to solve the problem using some objective measure like complexity theory, amount of code, exclusive resources, etc.

      Compatibility, Migration, and Standards – since no product is an island, you’ll have to go through how your product fits into the larger picture from a compatibility standpoint (intranet, extranet, internet), how customers are going to migrate to your solution, and what standards your product will support or require. If you’re dependent on the work in standard bodies or if you are going to promulgate standards around the product, then describe that here, too.

      Competition – Not only will you have to talk about competitive products and competitive companies vying for the same dollars, but you’ll also have to address build-versus-buy, and the biggest competitor of all: inertia.
      Customers that have something “good enough” present a huge obstacle to the adoption of new products, so you’ll have to explain how your customers solve the problem today, and of course, what (technical or business) impetus will drive adoption of your product.

      Team and Staffing –Demonstrate the technical team’s credibility and capability. A “dream team” usually has a successful track record of building a similar product for a similar customer base, but not every company can make that boast. One “dream team” example is Michael Stonebreaker, who has successfully launched any number of new companies related to his research and scholarship in the database space, including RTI/Ingres, Illustra, and Streambase. Try to show as best as you can that your team has (yes, I know its cliché) “been there, done that” in your product area.

      You’ll need a slide with the technical team org chart showing 6-quarters of hiring projections across all technical areas, including development, QA, product management, support, operations, etc. Each box on the org chart should show that person’s expertise (“java developer for streaming server”, “Windows developer for desktop client”), rather than generic “engineer” titles. You’re trying to show that you’ve actually though through your hiring choices, so avoid the temptation to use the headcount spreadsheet from your financial presentation.

      If you are doing any outsourcing or relying on an open source community to compete the project, you should have a slide for that too.

      Roadmap – Provide upto a year’s product history, plus the next 6-quarters of future product milestones. Tie the product roadmap to the company’s business and funding milestones, and to your hiring plan. This last point is key to showing your audience that the management team is working in sync.

      External dependencies – Almost every product relies in some fashion on other products, such as databases, app servers, etc. But some products or companies are dependent on products, consulting, or manufacturing that are not “commercial off-the-shelf” (COTS). You’ll need to describe any non-COTS dependencies, what the risks and alternatives are, and the state of the relationship with your suppliers.

      Product Development Process – I like to get a sense of what kind of development environment will be in place because it is well correlated with product quality. The process discussion should include “methodologies” such as waterfall, scrum, XP, etc., but also the product management process, development processes/tools, bug tracking, testing, etc.

      Consulting, Support, and Training – although these are primarily business issues, if your product has special requirements in these areas, you’ll need to cover them, too.

    Do’s and Don’ts During The Meeting

      Don’t Derail the Conversation – Non-technical people at these meetings should be introduced and say good-bye, and leave the discussions to the technical team. Having someone bring up extraneous points in a meeting so they can “add value” doesn’t.

      Don’t argue politics – If you feel really strongly about something, express it, but don’t get lured into a debate for or against any hot-button issues (open source v. Microsoft, Java v. Ruby, Spring v. J2EE, etc.) Its still your company and product and you get to choose whatever technologies will make it work, but you may still have to defend your choices. Do so with grace and respect.

      Don’t Snow – “You can fool some of the people some of the time…”, but you will hurt your credibility with anyone who doesn’t buy your story. I give higher marks to people who are up front about what they don’t know versus those who blunder through a poorly thought out answer.

      Assume your Audience is Intelligent but Uninformed – This was the best writing advice I ever got from a college professor, and it works just as well in presentations. Inform, don’t educate, unless asked, otherwise you might come across as condescending.

      Spark Discussion – Don’t expect to stand up and make a long-winded presentation, then finish with a Q&A slide. Invite discussion, have interesting and important digressions, go into detail, and ask your audience members question,and solicit their opinions.

      Use Pictures and Diagrams – Slides are an aid to your discussion, not your lecture notes, so weigh heavily towards pictures and diagrams, rather than endless bullets. Don’t use any type face under 30 points.

      Draw on the Board – I always take the chair closest to the whiteboard because I’m always drawing and illustrating. You should, too.

      Make a List of Open Issues – Email the answers the next day.

      ABC: Always Be Closing – This “sales” advice comes from The David Mamet play “Glengary Glen Ross.” Don’t wait for the last slide or the good-bye handshake to close the deal. Every thing you say and do should purposefully move you closer to a successful conclusion.

    The Aftermath

    When the meeting is over and everyone is standing up shaking hands, make sure you ask appropriate closing questions, like “Did we answer all your questions?” and “What do you think of our product?” Personally, I prefer to make a rallying statement (“I hope we can count on your support.”) versus a question (“So, can I count on your support?”), but that’s a style thing.

    After you leave the meeting, research and answer any open questions via email. A thank-you note is nice, but don’t ask questions about when they the feedback meeting is, and can they please tell you the status of the decision-making process. Those are questions for the VC, and the diligence guy is rarely in a position to provide the answers.

    By now, you should have a good idea of how to conduct a successful meeting. Ultimately, the product and technology should carry the day, but being prepared, demonstrating credibility, and showing that you’re an integral part of the overall management team will get you many extra well-deserved points.

    Posted in work | 3 Comments »

    Reducing Risk in Software Development

    Posted by rbpasker on August 21, 2007

    Have you ever heard the expression, “Ready! Fire! Aim!” ? Scoping projects has a natural progression: (1) figure out what you’re going to do (2) figure out how you’re going to do it (3) then do it. Confuse the order, and your asking for trouble, like slipped releases, incomplete features, and poor performance.

    All of these problems hurt the overall business as the company and customers lose confidence in engineering’s ability to deliver product. Confidence is inversely proportional to risk – less risk means higher confidence, and vice versa – so reducing risk in a release should increase its confidence.

    One way I have found to reduce risk is to categorize projects or tasks into three risk categories – low, medium, and high – which follow the 3 stages above:

    1. high risk – tasks which you don’t know what to do or how to do. High-risk tasks might also be labeled research projects. There’s a grad school joke that research is the process of going up alleys to see if they are blind, and finding the right alley can take a long time. From a product defensibility standpoint, however, these kinds of features are great because they are notoriously difficult. But from a product delivery standpoint, these are schedule-destroying tasks. If you have research projects on your product schedule, there is significant risk of failing to deliver.
    2. medium risk – tasks which you know what to do, but not how to do it. The risk here is in how long it takes to figure out how to complete the task. This is one of the mains reasons why smart and experienced people are so valuable: they know how to do stuff.
    3. low risk – tasks which you know what to do and how to do them. These tasks are not necessarily simple or less complicated tasks, but they are ones which can just be implemented.

    Reducing risk then becomes an exercise in turning high-risk items into medium-risk ones, and medium risk into low risk by answering the unanswered questions, and by dividing higher risk tasks into a number of smaller lower-risk ones. Preferably, this should be done outside the release cycle, but that’s not always possible. The release, then, includes only lower (although not necessarily lowest) risk items.

    To convert a high-risk project into a medium risk, you have to know what you’re going to do to solve a problem. For example, imagine you have a system that process 100 transactions per second, but you need to increase throughput to 200 TPS. There could be many different ways to achieve this goal, such upgrading systems, adding disk spindles, partitioning the application, implementing a SAN, converting from a scripting language to a compiled one, or some combination thereof. Say, after a month’s worth of research and experiments, you decide that partitioning and converting to a compiled language are going to have the greatest impact. You have now converted a high-risk task into two medium-risk ones.

    To convert a medium-risk task into a low-risk one, you need to answer the question “how?” In our example, we have “partitioning” and “compiling,” so then you have to figure out how you are going to partition the application and what techniques you might use to convert your scripting language to a compiled one. A number of additional experiments might be in order, and you might also evaluate helpful third party products. But at the end, you have to know pretty much what you’re going to do, and create a new set of low-risk tasks to complete the project. The better you define how you’re going to do something, the less risk there is.

    Reducing risk is not an exact science, but what I’ve tried to do is create a paradigm which you might adopt to your own work habits, whether you’re running a huge engineering project or you’re working on your own. Doing what you say you’re going to do when you say you’re going to do it gives you great credibility among your colleagues, and its also a huge confidence builder. Identifying and reducing risk is a great way to achieve it.

    Posted in work | 2 Comments »

    %d bloggers like this: