Version 10/23/01
You will note that there are links from many of the words and phrases in this text (hyperlinked.) By clicking on these links, an additional browser window will open. Many of these links will take you to a Dictionary of Terms, in order to explain the word/phrase (other links take you to other relevant documents.) The purpose of the Dictionary of Terms is to allow many users, with different levels of knowledge, to benefit from the text. If there is a term in the text you feel should be better explained, please email me at alex@udel.edu and I will include it.

The goal of this session is to familiarize you with the notion of ecosystems and how it relates to Silicon Valley. The Venture Capital process, essential for early stage funding, and product development issues for digital products. The contents for this session are:

History of the Venture Capital Industry, Silicon Valley and Ecosystems

The Venture Capital Industry emerged from the successes of technology efforts, post second world war. As the industry emerged, it split into two sectors, the east coast and the west coast. Much of the industry is now based on the west coast, in Silicon Valley. Silicon Valley, a region of Northern California, close to San Francisco, is the hotbed for entrepreneurial activity. It has been referred to as an ecosystem that has evolved over a number of years. The ecosystem is comprised of the symbiotic relationships of the venture capital community, the entrepreneurial community and intellectual capital, provided by Stanford University. This ecosystem has evolved over a number of years, since the inception of Hewlett Packard (1930s). As each element of the ecosystem benefits from each others' inclusion (entrepreneurs, venture capitalists and the university) the system becomes very robust, and therefore attractive for more venture capitalists, entrepreneurs and students. This is another example of network effects at play, as the greater the strength of the system, and its overall community, the greater the value of that community to each constituent. This makes it more attractive for new entrants. It also makes it more complicated to start an entrepreneurial business, that would require significant support to get established, outside of this ecosystem.

The success of Intel and the semi conductor industry provided significant momentum for this ecosystem. This has been further accelerated by the innovations developed by the internet.

Many regions have tried to emulate the phenomena of Silicon Valley, but due to the network effects of the ecosystem, it is very difficult for these regions to get a foothold. Essentially, Silicon Valley had first mover advantage in creating an ecosystem designed to breed entrepreneurship. Other regions (Silicon Alley etc.) are not able to offer players the same return on participation, thus as Silicon Valley gets stronger, other areas flounder. Noted in the text were issues with relation to where to locate. The author realised, that after some time, his venture capital firm did not have the connections of the west coast VCs in order to help recruit the right management team. This is a classic example of the risks associated with being on the outside of the ecosystem looking in.

Discussion Topic: As our environment becomes more connected, the notion of ecosystems becomes more relevant. Can you think of other examples of ecosystems?

Venture Capital Process

Venture Capital is a major source of funds for development for companies pre-IPO. A Venture Capital firm will raise a fund for investment over a ten year period. They typically invest in few, large investment opportunities, of the order of $2 - 5 million each. Since each investment is labor intensive in terms of additional resources provided by the Venture Capital firm, it makes more sense to invest in fewer, larger opportunities. In return for the investment, a Venture Capital firm will receive an equity stake in the firm, a seat (or possibly number of seats) on the board of directors, and will help in the recruiting process of the management team. Thus Venture Capital firms not only provide a source of funding, but also a network of human capital that the company now has access. This was the sole reason for Ebay to raise Venture Capital. From the beginning, they were able to make a profit, but they found it hard to recruit a CEO. Benchmark Capital were the Venture Capital firm that invested, the money was banked, and a CEO was found!

Venture Capital typically invest at different stages, pre-IPO, from pre-product, to close to IPO. Depending on the timing of the investment, the risk reward ratio changes. The earlier the investment, the higher the risk, the greater the equity stake the Venture Capital firm will receive. The Venture Capital firm will focus on the business plan of the firm, and particularly on the current management team (quality of human capital) and the scale of the business opportunity. While the financials of the business plan are understood to be "estimates," it is important that the size of the market opportunity is considered. Once invested, the Venture Capital firm will be focused on its ability to get return on its investment. Due to the risky nature of the investments, it is understood that some of these businesses will fail. The key for the Venture Capital firm is that one of the businesses, in the fund, is spectacularly successful, with returns x50 or more (no doubt Ebay returned Benchmark greater than x50!) The exit strategy for the fund is typically the IPO stage, although subsequent rounds of funding may offer some liquidity options.

Once funds are received, the entrepreneurial venture needs to consider its burn-rate, the amount of funds the company requires to remain liquid, per month, less any current incoming cash-flow. Controlling the burn-rate will allow the company to reach a mile stone at which point additional funding may be required, or profitability is reached. Many "dot.com" companies are currently closing their doors since their burn-rate was out of control, and the second round of funding, that appeared likely when they received their first round, was not available due to the down turn of the capital markets.

The other term of note, is the pre-money valuation. This is the value the Venture Capital places on the firm, before the investment is made. This then determines the percentage equity stake the Venture Capital firm will receive.

Discussion Topic: Discuss the recent spate of dot.com distasters, do you believe this is a market correction, or the end of the new era?

New Product Development

Front Page. Opportunity: Flaw structure of online services
The online service industry was fragmented with a number of proprietary standard legacy systems that limited its use as a marketing/business medium. If a company wanted to use online initiatives, then it would have to port all its business information to multiple platforms, cleary very expensive and inefficient from a business standpoint. Therefore the business opportunity was to create a standard online platform that would be open, and therefore used by everyone. This would then limit the need to use the multiple proprietary systems. We know now that this was already under development as it was being considered by Ferguson. Ferguson's idea comprised three related technologies:
  1. A Server-side to host the information
  2. A Client-side to view the information
  3. A Publishing tool to develop the information
The server and client tools were already being developed (the web, web servers etc.) but the development of these applications increased the opportunity for the publishing tool. Ferguson established a simple goal (for the development of the publishing tool) and a number of stategies to achieve the goal, that were considered before the development cycle for the tool began (clearly this is necessary if the tool is architected effectively.) The goal was:

Become the Proprietary Industry Standard in the Market.

In order to achieve this goal, the following strategies were proposed:

  1. Create the best possible product, reaching the broadest possible market, with the best and most flexible architecture to accomodate future changes.
  2. To create Lock-In to the product and architecture, so neither users or the industry could easily switch to a competitor
  3. To maximize proprietary control and value relative to other firms and segments of the industry
  4. To make it difficult to clone the product
  5. To do this cost effectively and within schedule
It is important to note that the above goal and subsequent strategies must be developed before coding begins. The product then needs an excellent architecture, that is flexible for future requirements, to avoid development issues during subsequent releases. For more on this go to Brooks.

A classic example of a mistake in this area was the development of the Netscape Browser. The Netscape Browser was developed by a young team of engineers, primarily directly out of the University of Illinois. They had developed the first graphic browser, Mosaic, and were now working on the first commercial grade browser. Their overriding goal appeared to be speed to market in order to establish first mover advantage. Clearly they were very successful in accomplishing their goal, and marketshare grew to upwards of 90% of the market. Two things they neglected however were:

  1. No lock-in
  2. Poor architecture
Since there was no lock-in, and actually Netscape was very open about its APIs once it developed some, it became very easy for Microsoft to clone. Microsoft was able to license the Mosaic code from Spyglass, and develop its own product from the code (same as it is doing with Real Networks and Media Player!)

The rush to speed the product to the market did not allow for future planning into the architecture, and for some ugly code. As each version was to be released, it became much more complex, and therefore took longer to release. Microsoft, on the other hand, learned from their mistake when developing the original Windows code (young programmers, shoddy code) and developed a well architected product, that they were then able to release more quickly. This allowed them to start from a loss of a year or so, but to catch up very quickly, and soon produce a better browser.

Text Issues, Chapters 6 - 9

Hiring the CEO
Identifying the CEO became a real issue, and only reinforces the idea of the Silicon Valley's ecosystem and the costs associated with being outside the system. The Venture Capitalists had a hard time identifying a CEO, and helping with human capital is a key task for Venture Capitalists! Once the CEO was identified, terms of employment were established, which (typically) includes a salary and stock options, these options included a one year cliff. Clearly the options are used to incentivize employees to be motivated to increase the value of the company, and a cliff is used so someone cannot start vesting their options as soon as they are hired.

Second Round Funding Issues
Once Venture Capitalists have participated in the first found of funding, and it is apparent that the product/company has identified an excellent market opportunity, such that the value of the initial investment is increasing significantly (as was the case) the first round funders are incentivized to keep the valuation of the company as low as possible, until it is time to liquidate their holdings, either at a buy-out or IPO. This then enables the initial investors to take a larger stake in the company as the company seeks subsequent funding. Clearly the company seeks to give up as little equity as possible for any subsequent investment. Thus there is a conflict of interest, which is compounded by the fact that the first round investors have representation on the board. The board is charged with taking care of the interests of the owners of the company, and not serving their self-interests. Clearly this was an issue Ferguson took very personally. He identified that if the first round investors were able to take an increasing portion of the company through subsequent funding (increasing their overall stake after second round funding) they increased their incentive to keep the valuation small for subsequent rounds of funding (so they could repeat this strategy.) If they used their pro-rata clause (a clause that typically allows first round investors to maintain their holding in subsequent rounds if they wish to) then they are indifferent to valuation for subsequent rounds. The only scenario that investors are incentivized to maximize the valuation is if their percentage of holdings reduce over time with subsequent rounds.

This dilemma creates scenarios of possible delay tactics by the first round investors as second round funding issues are raised on the board etc. Clearly an unhealthy situation in the case of Ferguson. After much game playing (prisoner's dilemma ---clearly both parties are better off by cooperating, especially given a long term relationship where one party understood the other was intollerant to ...) the total new money to be raised was $7.2 million, and the first round funders did exercise their right to sustain their stake in the company through additional investment. Thus Vemeer's pre-money valuation was $32 million. This contrasts with Netscape's second round funding, which was done at a valuation of $150 million, x10 higher than first round funding. This all became a non-issue when it was clear Vermeer was to be purchased.

Launching the Product
Relying on a platform, that is outside your control, is an issue many software developers will face (a strong case for an open source alternative like Linux.) For the software to work, it has to work with the platform. Clearly, the owner the platform (Microsoft in the case of Windows and Internet Explorer) has an advantage in terms of developing software to function from the platform, and an advantage in restricting functionality of other developers' products. This can only work if the platform has a monopoly (or close to it) and therefore considerable power in the marketplace. Thus, for the software to function (Front Page to function) then the combinations of Front Page and the Platform must function. If this combination does not function, then by default Front Page does not function (from your customers' standpoint anyway, which is the only important issue!) This became a problem for Vemeer, even though the technical issues were related to Windows and not Front Page itself. However, this only further highlighted the bigger issue, not being in total control of the functionality of your product, ceding much of that control to a competitor who you fear! Not a healthy situation for any commercial software developer!

Pricing was another issue for the launch of the product. The established price was very high, clearly limiting the ability to gain market share very quickly (as Netscape had done with its browser!) Once the company was bought by Microsoft, they were able to reduce the price significantly (it was a digital product with high fixed costs and low marginal costs!) Microsoft could also take advantage of bundling the product with their office suite franchise.

The distribution strategy for Front Page were clearly not effective. The traditional retail channel, while prohobitive to use, was not used. There were no downloads available on the web to help introduce the product. The deal that was struck with AT&T clearly was short sighted, and exposed the business to on going customer service support that was not accounted for in the price structure of the contract! In all, Vemeer managed to sell 289 copies of Front Page before Microsoft purchased the company.

Discussion Topic: What advantages do Microsoft have in the distribution of digital products over other companies, especially small, one product companies like Vemeer?

Dicussion Topic: Discuss the issues with respect to the choice Ferguson had with Front Page: to remain alone, be bought by Netscape or Microsoft. What were the pros and cons of each choice?

In order to get a perspective of Ferguson's understanding of the internet, during the time this book is set, you can view his Upside article: Fertile Ground, October 31, 1995 ---pretty accurate!

Interview Scheduling System, A Case Study in System Development and its LifeCycle

Wharton School's MBA Program interviews its candidates on an open enrollment basis, before they apply. Approximately 8,000 interviews are conducted each year by admissions officers, graduate assistants and alumni of the program. The scheduling of these interviews was problematic, and identified as a "frustration point" for candidates and staff alike. The method of scheduling was:
  1. Wharton determines the interview schedule for admissions officers and graduate assistants and recruits alumni volunteers around the world. Admissions officers interview both on-campus and in locations around the world. Graduate assistants only interview on campus. Alumni interview around the world.
  2. Once a candidate decides to schedule an interview, the candidate needs to call the office (average length of time on the phone is 5 minutes)
  3. Once on the telephone, the candidate has his/her options articulated, they can then make a choice:
  4. Interview on campus, off campus with an admissions officer, off campus with an alumni
  5. If one of the first 2 options, the receptionist will schedule the interview, then each evening mail confirmations out to each candidate scheduled that day
  6. If the alumni option, an alumni directory is mailed to the candidate
The above process has the following significant limitations: The challenge was to develop a web-based scheduling system that: In developing this system, the first issue for Wharton was:

The Make or Buy dilemma?

The options were:

  1. Use a current commercial software product from another vendor
  2. Develop the product internally
  3. Outsource development to a vendor
Option 1 was not a consideration, as there really was not a product that was available that could satisfy our needs. The closest we could identify were event scheduling systems (allowed many to schedule for one event, an interview is a one-to-one scheduling event) and doctor's office scheduling systems. While both these alternatives were deemed inappropriate, studying these systems allowed us to consider some of their functionality. Thus the options remaining were to develop internally or to outsource development to a third-party vendor. The following factors needed to be considered to make the choice:
  1. Did the product offer a competitive advantage for our program?
  2. Were we planning to simply use the product, or to also resell it to others?
  3. Do we have the resources available to develop AND support the product internally?
  4. Is there a vendor willing to develop AND support such a product?
In answering the first question, while clearly it helped us develop a better relationship with our candidates, we perceived that there really was no significant competitive advantage of being the only MBA program with this technology. We also considered that while we could develop internally, and have a year's lead over other schools, the technology required would be easily imitated. Thus there was no advantage to us to be the sole developers of this product on the basis of developing a sustainable competitive advantage.

For question two, the issue is, are we in the commercial software development business (as some business schools appear to be.) The simple answer was no, clearly this would have significant resource issues. Thus to develop ourselves, we have to consider we will be the sole client. This may simplify the development process but the cost benefits did not make sense for us.

The third issue was again a resource issue, and given the resources we had available in IT, it was soon decided that we could not develop this product internally. Internal development not only required the development of the initial product, but we would need to ensure the product was well architected and documentation well written, such that the life of the program can be extended beyond the tenure of the initial developer of the product. This is becoming more of a problem as the demand for systems programmers increase, and the supply is limited (and the salary structure within a University is limiting!)

In addressing the fourth question, there were potential vendors who could do this who had already developed products for the MBA applicant market (online applications etc.) One vendor, embark.com was a vendor we had an existing relationship with using their commercially available online application. Discussions began, and they agreed to build the product for us, as long as they owned the code, and could market it to the wider MBA business schools. We would serve as their initial client, and would be involved with developing the architecture for the product. This was agreed. The benefits of this relationship were:

The timeline for the product bacame very tight as it took time to come to agree on these terms (this turned out to be a big problem towards the end of the development cycle.) We had a fixed deadline when the product needed to be ready, the monday after labor day, when our interview schedule needed to be live. We had included this in all our marketing literature! An additional complication in the development was proximity, we are located in Philadelphia, they in San Francisco. The internet, conference calls and one visit to San Francisco would serve as the media of communication between the vendor and the client.

Step one was to establish the goals of the system, and develop a scheme (flow diagram) that established how the system would work to accomplish our goals. We would develop goals specific to our needs, embark would develop goals that allowed the flexibility of marketing the product to other clients. This is an extraordinarily important phase of the overall development. Once the coding of the product begins, the architecture has to have been established, and goals satisfied. Important considerations for Wharton were:

Important considerations for embark were to make sure the requirements, and therefore specifications of the product were broad enough to meet the needs of other types of potential clients. Thus while working closely with Wharton, they needed to spend time understanding the needs of other potential clients by understanding their current processes. This knowledge is acquired through multiple client interviews.

Once all considerations were understood, and compromises made, the product was architected to satisfy them. We developed the initial architecture, and then flew to San Francisco to meet and agree on the overall architecture. As each party better understood each others goals and common architecture was established and implemented. The architecture also needed to be flexible to include future innovations that are realised important once the product is tested and in use. Included at this stage were:

The next step was the coding of the product. Thus we were in limbo at this point, and any new ideas for the system had to be shelved for future consideration. This was a time that could work more closely on the design usability of the system, developing text, and considering the overall design.

Once the initial coding of the product was complete, a beta version of the product was available. This then needed to go through an extensive debugging process within embark, before it was to be released to the client, Wharton. Initial debugging identifies some issues that occur as a system like this is very interrelated, thus one module of the system has an impact on another module of the system, and the real impact can only be uncovered once the entire system is developed and tested in this fashion. Thus the debugging process has to be built into the development timeframe. Once this is complete, the product is available for the client.

Once the product was available, the system needed to be updated to include all the information of the schedule we had proposed for the current recruiting year. This had to be completed, along with testing of the schedule to make sure all elements of the system functioned in the fashion we had (hopefully) architected. A couple of problems emerged in this process, and the time frame of release was becoming very important. In order to go live training of the staff, using the system, had to be completed.

It is important to understand the system includes all those who interact with the system. This includes candidates for the program, and the receptionists and staff who may receive phone calls from candidates having problems with the system. This required a keen focus on product usability for the front-end (how the candidate interacts with the system) and the back-end (how the staff interacts with the system.) Thus for the system to be functionally proficient (and serve our goals) it has to accomplish the following:

  1. Execute the transactions to satisfy the goals of the design.
  2. Design usability so end users could easily understand the systems goals.
  3. Design usability so staff could easily aid in user questions.

Final testing of the system, and decision to go live, was completed at 5 AM on the tuesday morning after labor day (on schedule!)

Product development does not end once the product is released. This is simply the first version of the product, with additional versions planned, with additional functionality. In fact, the first version was stripped of some required functionality, in order to match the time deadline which was clearly fixed to our market needs. From embark's standpoint, development needed to continue, and customer support needed to be developed as the product went live. They also needed to consider how to roll out this product to other clients. The product is clearly scaleable and thus with limited marginal cost can be offered to additional clients. This therefore had an impact on the pricing of the product. Clearly a lot of cost was associated with the initial development of the product, but this cost is sunk. A secondary cost to factor (and very important costs!) is ongoing customer support. It is important that customer support is not perceived as a cost center, but as a revenue generating part of the enterprise, and therefore should be costed accordingly. If it is considered a cost center, then the resources allocated to it are reduced, and thus the ability to provide good customer support is limited. Customer support becomes the relationship between the vendor and client, and if the client is not locked-in to the vendor for more than a short period of time (a year) then the relationship and customer support needs to be a priority. As embark considers extending the product to other clients, the scaleability of customer support has to be considered, rather than simply the scaleability of the core product. The pricing structure of the product includes a fixed element for the initial implementation of the product, and an on going yearly service fee to cover customer support. For each additional client embark acquires, the ongoing fee must more than cover customer support, and the fixed fee directly contributes to the fixed costs of development that are sunk, and the ongoing overhead of the enterprise.

Discussion Topic: What are the critical differences between the product development process for digital goods (above) and tangible goods (such as cars and cameras)?

Discussion Topic: Consider customer support for your company, is it considered a cost center or a revenue generating opportunity?

Mythical Man Month, Frederick P. Brooks

Mythical Man Month is an excellent work, although a little dated, it is often cited when referring to issues related to systems development. A few important maxims uncovered in this work bear significant relevance today for large scale systems design:
  1. Adding people to a development project delays the outcome of the project further
  2. Timelines are always optimistic
  3. Early bugs become big bugs
  4. Architecture and implementation are seperate tasks
  5. A commercial system is 9 times more complex than a "garage" system
Issue one refers to the need to train additional software developers as they are added to the project and to manage the additional lines of communication added as more people are added to the project. Thus the benefits of network effects discussed last week actually work against a development project, where the number of communication opportunities turn into communication needs. Thus additional people add to the overall complexity of a project, further delaying its outcome.

Issue two refers to the inevitable issue of developing to a strict timeline is often fatal, and can either lead to a product with reduced functionality, or delays in the roll-out. It is inevitable that parts of the project's timeframe are not accounted for. Brooks recommends:

Typically projects will over budget for coding, and under budget for planning (developing the architecture) and testing.

Issue three refers to the importance of getting the code (and architecture) right for the first release. As additional releases are developed, early mistakes get magnified and can significantly delay and complicate updates (One of Netscape's problems!)

Issue four refers to the seperation of tasks between architecture and implementation. It is important that the architecture is developed by understanding the user requirements of the system as well as the coding issues related to developing the system. Once the architecture is developed, this serves as the guidelines for systems developement. This becomes easier to understand if we consider a building, an architect designs the building, and builders actually build the building to the specifications of the architect (code the product.)

Issue five refers to the complexity of developing an integrated system that needs to run on multiple platforms, versus a piece of software developed by one person for his/her own use. The additional complexity of developing a software that is part of an integrated system (x3) and needs to run for multiple users (x3) equates to complexity of the order of a factor of 9.

Discussion Topic: Relate your own experiences in software/systems development, the successes and "failures!"

Now go to the discussion board http://www.delphi.com/alex1 and be prepared to contribute to ongoing discussions under the Week 8 Folder, with regard to this material, paying particular attention to the suggested discussion topics, highlighted in red.