Founder Story: Ghislain Kaiser, Docea Power

Written by Sean Murphy. Posted in Founder Story

This interview originally ran Nov-4-2010 at “Docea Power Successfully Bootstraps As a New EDA Player.”


I had a chance to catch up with Ghislain Kaiser, CEO of Docea Power, a promising new startup based in France. Their product, Aceplorer, has been gaining increasing acceptance in the power and thermal management space. Ghislain was kind enough to share how they got started and some of the key things he has learned bootstrapping a new EDA startup. What follows is an edited transcript that I have added hyperlinks to for context.

Q: Can you talk a little bit about your background?

I’m CEO and one of two co-founders of Docea Power. The other founder is Sylvian Kaiser, my brother, who is CTO and R&D director.

I worked for STMicroelectronics as senior system architect on wireless applications and before that as project leader for the set-top box division. I have a Master of Science degree in Electrical and Computer Engineering from Supelec (Ecole Supérieure d’Electricité, France).

Sylvian worked at Infineon then TTPCom, covering multiple aspects of 3G/2.5G modem circuit design like system and algorithm definition, embedded software development and validation on FPGA and silicon. He has a Master of Science degree in Electrical and Computer Engineering from SupTelecom (Ecole Nationale Supérieure des Télécommunications, Paris, France).

Q: Can you talk a little bit about what led you to found your company, what was the problem that motivated you?

At ST I was in charge of defining power management strategy at system level for wireless applications like Application Processor engine. I had a second role which was to represent ST at MIPI consortium for system power management topics where I had the chance to work with the best power experts from the major semiconductor and system integrator companies.

Most of the time architects develop complex spreadsheets to estimate power consumption early in the design phase and drive implementation teams with specifications. But this approach is not scalable with the increasing complexity of the SoC and in an environment involving multiple teams over the world.

After visiting many companies and meeting many designers and architects I can say that the Excel spreadsheets represent 90% of the solutions used for power planning.  The spreadsheets are a
quite good solution when the system is not too complex and dynamic analysis is not required.

In 2005 Sylvian and I believed two things:

  1. The spreadsheet approach would be no longer be satisfactory for the next generation of SoC designs.
  2. Temperature issues would become a critical constraint for more and more electronic applications because of:
    • Increasing dependency of the leakage current with the temperature at each new technology node.
    • Increasing integration capability also increases the power density and the pressure on costs of chip packages.

This led us to found Docea Power in 2006. We collaborated with research centers for two years to develop our first product, Aceplorer, which helps architects explore low power/temperature architecture.

Q: How did you get started?

In 2006 we started with $400k by winning the national innovation award organized by the French ministry of research. We also received grants also from European and national Research projects as we are involved in several collaborative projects. We had service revenue as well from customer engagements during our first two years.

Q: Can you give me a brief overview of where the company is today?

Aceplorer and our methodology have been adopted and deployed by several major chip and system manufacturers, including ST-Ericsson. At DAC 2010 we announced a common laboratory with CEA-Leti around 3D chip design which raises new challenges like low power / thermal architecture exploration.

Q: What are the two or three things that you have been able to accomplish that you take the most pride in or satisfaction from?

First, we bootstrapped Docea for almost 4 years. Our first round of funding was done only this year. It was not an easy exercise to develop a product, get the first customers and drive our solution to industrial maturity

Second, we have managed to raise an investment round in a tough context for EDA start-ups. Fortunately our revenue growth and strong  customer references made it possible.

Q: What has been the biggest surprise? What was one key assumption you made, perhaps even unconsciously, that has caused the most grief?

The economical crisis was certainly the most unexpected event for us. Late 2008 corresponded to the launch of our first product Aceplorer but also to the beginning of economy slow down. The situation couldn’t have been worse. Fortunately we were able to get our first customers in 2009.

Q: What development, event, or new understanding since you started has had the most impact on your original plan? How has your plan changed in response?

In our original plan we didn’t anticipate the emergence of new standards related to power topic. In 2007 a new area of standardization appeared and two new standards started fighting : CPF first, proposed by Cadence, then followed by UPF driven mainly by Synopsys, Mentor Graphics and Magma.

We have modified our original roadmap to include support for both of these standards in our Aceplorer product.

Q: Any other remarks or suggestions for entrepreneurs?

Three things I have learned in the last four years:

  • Cash flow is key when you are bootstrapping: understand where  you are spending money, what commitments you have made on your  cash, and when you are likely to see revenue.
  • People make the difference, not the technology.
  • Be more than a vendor, be a partner to your customers: you must collaborate with your customers, not just sell to them.

Q: Thanks for your time.

Founder Story: Paul van Besouw, Oasys Design Systems

Written by Sean Murphy. Posted in Founder Story

This interview originally ran Aug 11, 2010 in EETimes online at http://www.eetimes.com/electronics-blogs/other/4206103/Interview–Paul-van-Besouw–Oasys-Design-Systems


I recently had the opportunity to sit down with Paul van Besouw, CEO of Oasys Design Systems, and interview him on lessons learned from his entrepreneurial efforts at Ambit and Oasys. I have added hyperlinks where I felt they would provide context.

Q: Can you talk a little bit about your background?

I am a founder of Oasys, along with Johnson Limqueco, vice president of R&D, and Harm Arts, CTO. We were part of the core R&D team at Ambit Design Systems, which was acquired by Cadence. At Cadence, the team focused on physical synthesis, connecting traditional synthesis to physical design.

I have a Master of Science degree in Electrical and Computer Engineering from the Eindhoven University of Technology in The Netherlands.

My entry into the EDA industry goes back to when I was at the University of Eindhoven. I was part of a group doing EDA research and I got an email from Rajeev Madhavan, who was starting Ambit. He was looking for software developers who had experience developing RTL synthesis front-ends. I was just finishing my Masters degree and trying to figure out what to do next, so the timing was perfect.

That was 1995. I talked to Rajeev Madhavan and he invited me to come out to California. I packed up my suitcase and came over, and that is how the whole thing started. It was initially meant to be a six-month project but it turned into 15 years.

Just coming out of University with no industrial experience, it was a great opportunity. There really was nothing there. Everything had to be built from scratch, and it was a great learning experience. We had a small core R&D team of about six that built the foundation of the Ambit technology.

Q: Can you talk a little bit about what led you to found your company, what was the problem that motivated you?

By building synthesis technology at Ambit and separately building physical technology at Cadence, we realized that we were forcing design teams to deal with a suboptimal solution. We saw how hard it was to integrate synthesis and place and route together in a way that produced the best quality of results. Traditional synthesis turns RTL code into a quick-and-dirty netlist and then runs a powerful but slow optimizer on that netlist. Our goal is to produce the best starting point for physical implementation by producing placed netlists that in turn enable the place and route tool to deliver the targeted quality of results.

It took two years to build a new chip synthesis technology from scratch, we call it RealTime Designer. The first prototype solution was qualified on an actual design and the engineer’s reaction was priceless. After they had verified the design and validated the quality of results on site they said: “Holy smokes! The run really did take less than 15 minutes.”

Q: Can you give me a brief overview of where the company is today?

RealTime Designer has proven itself in dozens of benchmarks and is in use in production flows. For example, Renesas in Japan has been working with Oasys for more than two years and its chief engineer considers it to be the most advanced synthesis technology. In fact, he thinks that it has the potential to change the usage model.

Design teams today are more sensitive about letting their company names be used as a reference. Most of the design teams we are working with have single vendor relationships, and several of these customers have EDA CEOs as their executive sponsors. That makes it tricky for them to come out and say anything about another competitive technology.

Just before the Design Automation Conference this year, we announced that Juniper Networks had selected RealTime Designer for the design of its next-generation networking chips. Juniper thoroughly evaluated RealTime Designer and concluded that it offers high-quality results and performed well in the Juniper design environment. Juniper approached us because the runtime of the existing tools was way too slow and took forever to get from RTL to GDSII. Debashis Basu, vice president for Silicon Development at Juniper Networks, gave RealTime Designer high marks, noting that it is a great tool that fits a very real performance need.

We followed this announcement with the news that we signed a multi-year strategic licensing agreement with Xilinx for our Chip Synthesis technology. Vin Ratford, Xilinx’s senior vice president of worldwide marketing, said that with programmable chip sizes growing and complexity mounting, Xilinx needed to look at a new generation of synthesis to support the needs of its customers.

Q: It has been reported that Xilinx is an investor in Oasys? Is either Xilinx or Juniper an investor in Oasys? Are any of the executives of either firm an investor in Oasys?

Juniper and Xilinx are customers and not investors. Neither has taken an equity stake in Oasys. None of the executives at Juniper or Xilinx is an investor in Oasys.

Juniper licensed our RealTime Designer software to use in its design flow. Xilinx licensed the Oasys Chip Synthesis technology and is modifying it to support FPGA designs; it will have the Xilinx brand.

Q: What are the two or three things that you have been able to accomplish that you take the most pride in or satisfaction from?

We created a new technology with a small team, and little funding. At first, we were completely self-funded. We rented a small apartment where we spent about a year just coding everything from scratch. Later, we received some seed funding from several EDA-savvy angel investors, which allowed us to move into a “real” office.

We had a working prototype by 18 months to show other angel investors, which allowed us to secure a bit more funding. I was able to attract the attention of some of the best people in the industry. It took some convincing, but I was also able to attract Joe Costello‘s attention. He is now a member of our board of directors.

Joe’s keynote speech at the 43rd Design Automation Conference in 2006 outlined three rules for building a successful company in EDA. The rules talk about how to “think like a fish,” and that you should “write your press release first,” and to “fundamentally change the rules.” It was around the same time that I started my discussion with Joe. I talked him through the technology and how we did things. He definitely saw the potential of this kind of technology where it could fundamentally change the game rather than trying to play the game, which is basically what we had done at Ambit.

Q: What has been the biggest surprise? What was one key assumption you made, perhaps even unconsciously, that has caused the most grief?

From the very beginning, the team was focused on building a better implementation technology, and on getting better quality of results through place and route. We expected to improve the capacity and runtime as well, but really did not expect such a huge improvement. I think this must have been the biggest surprise, although a positive one.

On the negative side, the biggest surprise was when the economy weakened so much. It has made the funding environment challenging, to say the least, and has also caused customers to become cautious about considering new tools.

One big challenge is that we are competing in a mature market. That sets the bar extremely high since design teams only start to become interested once the tool is better than the incumbent technology in pretty much every respect. And, not just incrementally better, but compellingly better.

If you go back to Ambit, the motivation for design teams to buy Ambit was different. Synopsys had a monopoly. Ambit had a good technology, but it was more a “me too” implementation. We had the advantage of doing it from scratch and were able to do it a little bit better than what Synopsys had done at that time. Clearly, one motivation for design teams to go with Ambit was just to have a competitor in the market.

Ten years later, it is more difficult to innovate and come up with new technologies. Nobody got fired for going with Synopsys. Adopting a new technology in a critical path of your design tapeout is a big deal.

If you start a technology company and are able to compete in the market today, it is all about building a complete solution. It is one thing to have a promising technology that shows some good results on one or two designs. You have to be able to build out a technology with all the bells and whistles and still show that advantage over a large number of designs.

Q: What development, event, or new understanding since you started has had the most impact on your original plan? How has your plan changed in response?

Venture capital for EDA is pretty much non-existent. This was a new reality and we were forced to do things differently. We are working with less money and fewer engineers on a longer development time-line than we would have if we had started Oasys 10 years ago.

Nobody embarks on a startup thinking it will take six years just to get to market, but that was the reality we faced. On the other hand, it did allow us to focus on maturing the product before announcing the product and/or company. We were able to close some significant business, which is driving the company right now. We continue to focus on building our customer base and growing the business based their success.

When we started, we had a different perception than we have now. With my background from Ambit, I knew what it would take to build things from scratch, but we were still counting on the funding to be there. In hindsight it was a blessing because we were forced to do more with less. It was a core team that worked on the technology from the ground up rather than having some ideas, build something and then have a big team work it out. In the end, it has helped the technology mature in the way it did because it was a technology completely different from what we had ever done before.

However, it definitely took longer to develop the technology because of a lack of funding. It took us three years to get a prototype to work and to get to a point where we could start engaging with some design teams. However, when we did, we realized that we had something different that was even better than we had imagined.

Q: Any other remarks or suggestions for entrepreneurs?

Starting a company sounds glamorous but it is hard work and takes perseverance. The two pillars that allow the company to go through some of the tough times are the support of your family and a founding team that works well together.

Obviously the founders have to believe that what they are doing will make a difference. They need to learn to balance out the highs and lows to keep the team motivated.

I have been very fortunate in being able to key surround myself with great people. Oasys has extremely knowledgeable people as investors and on the board of directors. It is easy for a founding team to get absorbed by the technology, so it is important to balance it out.

What makes EDA both interesting and challenging is that it is not only about the software. In the end, you are building software to build hardware. You have to start with insights into both and learn a lot more along the way. In many cases it is the experience of what does not work that really allows you to focus on the things that do work. EDA software is built on a technology foundation surrounded by algorithms. Starting out, a lot of time is spent on finding out what does not work. There are many details that need to be incorporated to enable your technology to work in an actual production flow.

Starting with a great technology is not sufficient.

Q: Thanks very much for your time.

Slides from “Working For Equity” Panel at SVCC 2011

Written by Sean Murphy. Posted in Events, Founder Story, skmurphy, Startups

Here are the slides from today’s “Working for Equity” panel at Silicon Valley Code Camp. It was a standing room only crowd of over 70 that made for a very interactive session with the panel:

  • Liz Fraley founder of Single-Sourcing Solutions.
    Before founding Single-Sourcing Solutions, Liz Fraley worked in both high-tech and government sectors, developing and delivering technical design and strategy of content creation, management, and delivery. Specializing in practical development and deployment, she continually looks for new ways to share information and strengthen the ecosystem of professionals around her.
  • Apurva Mehta founder of RecordBox.
    RecordBox is a virtual notebook for music students which makes the creation, storage, organization, and annotation of educational recordings easy. Before RecordBox, Apurva worked as a systems engineer in the Cloud Platforms group at Yahoo! in Sunnyvale. He has been programming enthusiastically since his early teens and has only recently taken up the entrepreneurial challenge of transforming products into businesses.
  • Carl Ludewig CEO of  Ludewig Multimedia.
    Carl wants to change the way applications are developed by empowering designers and business users. In a world where the cloud, mobile and desktop need to fit together, Ludewig Multimedia looks to take a holistic approach with the next generation of software design tools. Carl’s prior venture was the mobile advertising company Ad Infuse, which was sold to Velti in 2009. Carl is a software engineer and musician who believes that creative talent is the key to success.

B.V. Jagdeesh on “Startup Leadership Lessons Learned”

Written by Sean Murphy. Posted in 4 Finding your Niche, Events, First Office, Founder Story

Mr. B.V. Jagadeesh gave a great talk on “Lessons Learned Starting, Leading, and Succeeding at Multiple Startups” tonight at the GITPRO meeting.  Mr. Jagadeesh co-founded Fouress (a bootstrapped consulting firm), co-founded Exodus Communications, was CEO at NetScalar (and stayed on after  its acquisition by Citrix as a VP/GM),  was  president and CEO of 3Leaf Systems, and is today  president and CEO of Virtela.  He is an accomplished entrepreneur (more details on LinkedIn and CrunchBase) and he gave a very candid talk on his entrepreneurial journey starting with his arrival in the United States in the early 1980′s to work at Novell.

I have had the privilege of hearing experienced entrepreneurs talk about lessons learned but it’s normally been a small group, a half dozen or dozen folks in a conference room or 15 or 20 around a Bootstrappers Breakfast table. This had that same sense of practical candor but there were perhaps a hundred to a hundred and twenty folks in the Oak Room.  It was a candid an insightful talk punctuated by frequent questions from the audience.  What follows are a few stories that I thought had a particular emotional resonance with the early stages of a startup.

He came from a family of teachers and professors of modest means. They were delighted when he graduated with bachelors degree in engineering and went to Bombay to earn a Masters degree. When he  was able to get a job in America it was unprecedented success. His new job allowed him to buy a used car which was one of the first owned by his family.

This made for a difficult phone call when he called his father to tell him he was going to quit his job to start a company. He had tried to work on it on the side with his future co-founder but came to understand if it was going to move forward he would have to focus on it.

“How much will this new job pay?” his father asked.

“It’s a startup, once we get clients I will be able to make some money” was Mr. Jagadeesh’s answer.

Needless to say his family thought he was making a mistake, but his calculation was that he had enough money saved to live simply for a year, he would pursue his dream of his own company and if it didn’t work out he would go back to being an engineer for a while.

Exodus went on to spearhead the concept of offsite co-location datacenters, changing the model from on-site data center served by an ISP. It enabled a number of companies large and small to establish a significant presence on the Internet.

His tenure at NetScalar saw the company narrowly avoid shutdown and go on to establish a  new paradigm for Internet connectivity management. He had to prepare two speeches for the employees, one where he announced that the company was getting shut down, and one where they announced  new round of funding (from Sequoia as it turns out). He was able to give the second speech and returned 8x to Sequoia when Citrix acquired NetScalar two and half years later.

He had to give the other speech a few years later as CEO of 3Leaf Systems when a key ASIC needed another spin and he was not able to convince investors to help. His point was that in both cases you had to prepare for the likely outcomes and take responsibility as CEO for what happens, doing the best that you can for your employees and investors.

One theme he stressed repeatedly was the need to impose the discipline on yourself and your team to prepare and act with the professionalism that your competitors are going to bring to the market. He talked about one team that he is advising that has met with some initial success. They realized that treating their offices as dorm rooms had been OK when there were a few founders, but now that they were growing and had two dozen  employees they needed to establish a more professional tone–without spending a lot of money. So they spent a few thousand dollars at IKEA and held furniture assembly parties. The new look changed both internal attitudes toward the workplace and those of  customers and potential investors who visited their offices.

He talked about volunteering to help the IEEE Silicon Valley put on events and conferences while he was still working at Novell. They met more than two decades ago in the Oak Room where he was speaking tonight .  By volunteering to find speakers he was able to have conversations with managers and executives at many companies that allowed him to develop a network that helped out as he was growing Exodus and NetScalar.  He felt a sense a coming full circle: he was now the invited speaker in the same room where he first started out as a volunteer.

It was a candid and reflective talk, Mr. Jagadeesh not only offered a wealth  of practical advice, answering a number of very good questions,  but he also communicated a fundamental sense of what it means to be a CEO: you need to take action and take responsibility for outcome of your actions.

Isaac Garcia on “Bootstrapping Central Desktop” at Feb-11 BB in Milpitas

Written by Sean Murphy. Posted in Events, Founder Story, Funding, skmurphy

steaming hot coffee and serious conversationIsaac Garcia, co-founder and CEO of Central Desktop, will share “Lessons Learned Bootstrapping Central Desktop” at the Milpitas Bootstrappers Breakfast® on February 11, 2011 at 7:30am. Central Desktop delivers a SaaS collaboration platform that helps businesses manage projects and documents in the cloud with colleagues, customers and partners.

Isaac Garcia (@isaacgarcia) oversees business strategy and sales for the company. Isaac’s talk will draw on his experience at both early-stage technology companies and in enterprise sales & marketing. He was a founding partner at Upgradebase, where he oversaw all business development and sales for the company. Isaac served as a Director of North America Enterprise Sales for CNET Channel. He was responsible for the acquisition, sales and management of global partnerships with Microsoft, Google, eBay, Yahoo and Best Buy. Isaac led and managed CNET’s global partnership with Microsoft to launch the Windows Marketplace campaign in 14 countries. He received a BA in English from Ambassador University and a Masters degree in English Literature from the University of Northern Colorado.

Isaac and Arnold Hsu, CTO of Central Desktop, were interviewed by the Techzing in February of 2010 on the need for relentless execution, see 34: TZ Interview – Central Desktop / Relentless Execution by techzing

Isaac noted the following in an E-mail exchange with Phil Wainwright in 2007 in answer to the question “Do SaaS Ventures Need VCs?

“In many ways, SaaS companies are not VC plays — at least, not in the traditional sense. Once established with a product to market, a properly run SaaS company can accurately predict its revenues and growth — which means that it can also predict, with relative accuracy, exactly how much cash it needs for expansion and when and how much of an ROI the lender/investor will receive. This time frame is usually much shorter than traditional VC horizons and less risky. This also means that the terms are different than most deals.”

When: Feb-11-2011 7:30am to 9:00am
Cost: $5 in advance / $10 at the door (plus breakfast, tax, and tip).
Where: Omega Restaurant, 90 S. Park Victoria Milpitas, CA, 95035

Register for Feb-11-2011 Bootstrapper Breakfast in MilpitasJoin other entrepreneurs who eat problems for breakfast® on February 11 in Milpitas.

Keep on Walking

Written by Sean Murphy. Posted in Founder Story, skmurphy, Video

My brother told me about “The Man Who Walked Around the World,” a 2009 long form commercial for Johnnie Walker that stars Robert Carlyle in a six minute single take.  I am not a scotch drinker but I found Carlyle’s delivery of story of the entrepreneurial Walker family very inspiring.  In particular I liked this line:

And because there is nothing like a commercial proposition to stir the Scottish heart it quickly grew into an industry, filled with ambitious entrepreneur distillers.

Go ahead, watch the whole thing:

It really is a single take according to an interview with director Jamie Rafn:

How many takes did you have to do to get the whole thing perfect?
The take that you have seen is the very last take we did at 8pm on the last day of the shoot. Take 40. The tension as we watched Robert do this take was unbelievable. It was such a good take at every stage and so the longer it went on without any fluffs the greater the pressure grew for nothing to go wrong. When he got to the end and I got to call cut there was this huge roar and applause from the crew and agency and I knew we had it.

Where was the film shot and what did the location add to the film?
It was shot near Loch Doyne in Scotland. The landscape is a huge part of it. It’s like another character. Its hauntingly beautiful up there and we were blessed with these lovely clouds that gave us this really lovely brooding look.

What was the most challenging element of the job?
By 5pm on day one we hadn’t managed to do one complete take. We therefore had nothing. We soon worked out that the reason for this was the huge bank of TV’s which we’d placed 2 meters in the wrong position. Robert was having to slow down his walking and speed up his talking in a way that was artificial and was throwing him. There was nothing we could do but rebuild the TV’s which meant wrapping and staring again the next day having achieved nothing on the first day. The following morning there were a lot of anxious faces and murmurings of “fixing it in post”. Then Robert turned up and did the very first take of the day in one. As I said – the man’s a genius.

Ken Imboden on Lessons From MMC, Candlestick, and NuSym

Written by Sean Murphy. Posted in 3 Early Customer Stage, Founder Story

I worked with Ken Imboden at  MMC Networks (acquired by AMCC in 2000). He managed a key group of microcode and embedded software developers whose efforts drove the successful adoption of MMC’s network processor chips. His role required him to manage both development and key customer issues and his judgment was sound across the board. He hired, developed, and motivated a very talented team and successfully buffered them from most of the chaos you would expect to find in a startup.

Ken went on to work at Candlestick Networks (acquired by Nortel in 2001) and co-found the now defunct NuSym Technology with Chris Wilson and Dave Gold. I reached out to him this week to get his perspective on lessons learned from working in software startups and he was kind enough to reply with this list of what he has learned from several startups over the years:

  1. Focus obsessively and relentlessly on providing measurable value for the customer. Ensure that your daily activities reflect this.  Insist that your co-workers do likewise.  Any effort you expend must be justified by value provided to the customer.
  2. All software is crap. (No?  Provide me with a counterexample.)  Most of the training that software developers receive, and most of the effort they expend, does not alter this fact, and in fact is perversely designed to ensure this result.  Decide what you can do to alter or ameliorate this fact.
    Humility is of great benefit in a software developer; hubris is of great detriment.
  3. Aggressively manage multiple development sites. Otherwise the sites will drift their separate ways, often to cross purposes.  Excessive interaction among the sites is a must.
  4. Periodically step back and dispassionately assess your company’s progress. Your goal is to generate profit — obscene amounts of profit.  (If you disagree, be sure to inform your prospective investors of your goals.  When you have gone long enough without funding, correct your goals and come back here.)
    • For a software firm, subgoals working backwards:
      • revenue,
      • purchase orders,
      • customer endorsements,
      • customer use,
      • customer use in a services model (taxicab mode),
      • in-house use,
      • development,
      • customer affirmation.
        (Note that software development is a small portion of the process.)
    • Periodically, ruthlessly measure your progress along the path of these subgoals.
  5. Stop doing the wrong thing. If your periodic assessment reveals you’re on the wrong path, change something in your process.  Otherwise, plan to keep getting undesired results; do not be surprised by this.
  6. Your initial idea is not your final product. Your first several ideas will not be your final product.  Customer affirmation of your idea is a necessary starting point.

Ken noted in closing:

I don’t think I’ve given you anything most folks did not already know.  The challenge is, of course, in the execution, especially reorienting the mindsets of egocentric and introverted software developers (pardon the redundancy), driving home the fact that the customer does not give a damn about their cleverness, the algorithms they implement, or their credentials.  The customer cares only about satisfying their own need.

Interview with Rajeev Madhavan, CEO of Magma Design Automation

Written by Sean Murphy. Posted in EDA, Founder Story, skmurphy

Rajeev Madhavan is Chairman and CEO of Magma Design Automation, a public EDA company that’s a broad supplier. Madhavan is a serial entrepreneur, helping to found Logic Vision, Ambit, and Magma in the last 17 years. Ambit in particular was an ambitious startup, Rajeev went head to head with Synopsys and carved out a chunk of the synthesis market. But it was hard to get started, after he came away empty handed on Sand Hill Road he did an angel round with 25 seed investors who four years later were happy to have taken part when Ambit was acquired by Cadence for $260 million. He decided to found Magma in April 1997 after a disagreement with the board of Ambit. At Magma he was even more ambitious, aiming to be a broad line EDA supplier. Although the fund raising was easier, after the 2001 IPO Magma, like many EDA firms, has been faced with a challenging environment.

I was delighted when he agreed to an e-mail interview about his entrepreneurial journey. The words are his but I have added hyperlinks for entrepreneurs outside of EDA who may benefit from some more context to his remarks.

Q: Can you talk a little bit about your background?

Madhavan: I grew up in Southern India. I went to college and earned a B.S. in electronics and communication from KREC (Karnataka Regional Engineering College) in Surathkal. I went on to graduate school at Queen’s University in Ontario, Canada, earning an M.S.E.E. While completing my thesis, I went to work for BNR (Bell North Research), the research arm of Nortel in Ottawa, where I found I needed to create some CAD software applications to help complete chip designs I was involved with. I had no traditional background in EDA or computer science, but while working at BNR, I ended up developing a lot of EDA tools.

By 1991, I was working at Cadence Design Systems in San Jose as a BNR engineer involved in a long-term partnership between the two companies called the Analog Alliance. Jim Solomon was also at Cadence at that time, leading the Analog Division. Jim convinced me to join Cadence as a full-time employee in 1991, and I worked intensely on Cadence’s Spectre HDL for a year and a half.

See below: “For More Info on Rajeev Madhavan” has more on this period from other interviews.

Q: Can you talk a little bit about what led you to found your company, what problem or situation motivated you?

Madhavan: While I was at Cadence, Vinod Agarwal talked to me about licensing BNR’s BIST software since I had worked on it. Ultimately I helped to co-found LV Software with Vinod Agarwal and Michael Howells in July 1992, which became LogicVision in 1996.

While I was at LogicVision, I had an opportunity to integrate LogicVision BIST into Synopsys tools. Having worked on synthesis at BNR and watched the failure of Cadence and Mentor in synthesis, I felt there was room for another synthesis player to compete directly against Synopsys. I looked at Design Compiler, and felt I could do better. So, I left LogicVision and founded Ambit Design Systems in 1994.

After Ambit, I realized that simply building a better synthesis tool wasn’t enough. To truly advance IC design, synthesis and physical design needed to be integrated. We started Magma in 1997 based on that simple idea.

Q: Can you give me a brief overview of where the firm is today?

Magma was founded in 1997 and is my third “official” startup. Magma had a very successful IPO two days before Thanksgiving 2001, at a time when other companies were shelving IPO plans.

Magma is now one of the largest EDA software providers with products used by major semiconductor manufacturers to design the most complex, high-performance analog and digital chips made today. Our revenue for Fiscal Year 2009 was $147 million and we have approximately 730 employees worldwide.

Q: What are two or three key things you have learned?

I’ve learned something from each of the three startups.

  • At LogicVision, I learned that creating great technology is not the only key to success. You have to know how to sell the software to the customer. We were woefully bad at licensing.
  • After Ambit, I looked at myself to see what I could improve. I went over the mistakes I made and looked at how I could correct them. I had fought with some of the board members at Ambit and found that I had had limited ability to communicate with employees. It was a revelation to realize that I was a bad communicator. I learned that I had to be more extroverted and outgoing. This was a life-changing shift and changed the way I ran Magma. Because of this change, I have been able to build a much tighter community at Magma than at Ambit. And, personally, I am glad that I made the transition. I enjoy being part of the community and find that I’m happier.
  • At Magma, the number one thing that I have learned is that, in spite of taking precautions and talking with employees about clean code development, we still had one bad apple. I learned very clearly to trust but to verify more than you think you need to!

Q: How have you changed since you started? What key skill or experience did you lack when you started that has caused you the most problem?

I now try to figure out what a person is all about and use that to help motivate them to do something great for the community. At Ambit, I didn’t. At Magma, I’ve built great relationships. If I disagree with someone, I can agree to disagree without holding a grudge. It’s been a good experience to change in this way.

Q: What are the two or three things that you have been able to accomplish that you take the most pride in or satisfaction from?

First, I’m very proud of creating the first physical synthesis system. Others may now claim to have a similar system, but clearly Magma was the first to deploy one.

Secondly, we survived an unfair litigation. I learned a lot from that experience that I wish I hadn’t had to. And, while I’m happy to say we won one of the key arguments on ownership, we still suffered from the litigation. Early on, I made the painful decision to order the complete rewrite of the Blast Fusion tool. In the end, it wasn’t necessary. The court upheld our position that IBM co-owned the technology and that we could use it because of a cross-licensing agreement we had with them. Given the risks, though, it was the right decision to make at the time.

After the lawsuit ended, we could have continued with Blast Fusion, but we had already launched Talus. I knew that when we had reached a few critical milestones with the new product, our technology lead would be even stronger.

Developing a production worthy version of Talus took some time and meant that we had to support two systems until we could migrate our customers to Talus. The last 18 months have been really tough, but now we’ve migrated our customers to Talus, and reached significant milestones in combining new routing and optimization technology into Talus. This new technology is as innovative as our original physical synthesis was.

Q: What has been the biggest surprise: what was one key assumption you made, perhaps even unconsciously, that has caused the most grief?

One of the biggest surprises in my years in this industry is how short-sighted the large EDA companies are. They shoot themselves in the foot with their licensing models. They literally give away “me too” tools in these “preferred EDA vendor or Flexible Access Model (FAM)” deals. Customers are never going to start paying for tools that they’ve been getting for free. This practice makes it impossible to grow the market. It hurts the large EDA companies, and the smaller companies and it hurts the industry.

It’s amazing that the brilliant technical minds at the large EDA companies continue to make bad business decisions. The good news is that semiconductor companies will always need EDA tools. I believe the EDA industry will transition away from these bad licensing models, but it will be a painful process and everyone will suffer.

What development, event, or new understanding since you started has had the most impact on your original plan? How has your plan changed in response?

For a while, Magma had the intention of becoming a full line supplier, just like the other larger EDA companies. But, I realized that customers won’t buy tools from me that they get free from somebody else –– UNLESS, it’s a truly superior tool. Now, Magma has put its focus back on developing truly differentiated products, rather than “me too” products.

Q: Any other remarks or suggestions for entrepreneurs?

While there’s turbulence in EDA right now, it’s not because we don’t provide critical technology. Once the industry has learned how to properly run a business, EDA will thrive again. So, I would encourage EDA entrepreneurs to hang on!

And for the entrepreneurial community in general, this is actually the perfect time to start a company, if you can get funding. Don’t get dazzled by your technology, make sure you and your team have solid business sense, as well.

Q: Thanks very much for your time.

For More Info on Rajeev Madhavan

I met Lucio Lanza when he was Vice President for Business Development at Cadence and a General Partner at USVP. Lucio gave me several start-ups’ business plans to look over and evaluate. By showing me those business plans, he helped me to understand the venture capital business and how ideas are funded. Specifically, Lucio was instrumental in funding EPIC. Reading their business plan and meeting with some of EPIC management made me realize a few things.

It was interesting to me to learn that you could earn a salary working at a start-up and that you didn’t have to be self-supporting. I wasn’t a rich kid and I had no idea that anyone could work for a start-up if they couldn’t support themselves on family money.

Interview with John Sanguinetti

Written by Sean Murphy. Posted in EDA, Founder Story, skmurphy

Co-founder and chief technical officer of Forte Design Systems, John Sanguinetti talks about his experience of turning an idea into a business. He was the principal architect of VCS, the Verilog Compiled Simulator, and was a major contributor to the Verilog’s resurgence in the design community. He has 15 publications and one patent. He also developed the Verilog Online Training course. He holds a PhD in computer and communication sciences from the University of Michigan, 1977.

Q: Can you talk a little bit about your background?

I worked for several computer manufacturers: DEC, Amdahl, ELXSI, Ardent, NeXT, doing first performance analysis and later design verification. My PhD was in Computer Science (operating system design methodology), not Electrical Engineering. In 1991, I left NeXT and started Chronologic Simulation, the company that made VCS. VCS was the product of several technologies: language compiling, logic simulation, design verification, and performance analysis. We sold Chronologic to Viewlogic in 1994.

Q: What insights did you take away from the sale of Chronologic to Viewlogic?

  • Take your time. We got rushed into doing the deal and didn’t take enough time to get to know the acquiring company.
  • When a smaller company is acquired by a larger one, expect that the smaller company will lose its identity and disappear. If that’s not what you want, don’t do the deal.
  • Corporate culture matters, and it starts at the top.

Q: As a result of the sale you were subject to a non-compete in EDA until 1998. In California non-competes are enforceable when they involve the sale of a business, on the theory that the seller is reducing the goodwill associated with the company being sold. What advice would you have for entrepreneurs contemplating the sale of their company to a larger firm?

A non-compete agreement is perfectly justifiable, but it should not be too long. Mine was four years, and that was about twice as long as it should have been. It should really be up to the acquiring company to make you want to stay, rather than having a legal agreement forcing you to stay, or at least not compete. I was never going to make a product to compete with VCS –– I loved it. However, I would have liked to do other things in EDA after leaving Viewlogic, and I couldn’t do that for several years.

Q: Can you talk a little bit about what led you to found CynApps: what problem or situation motivated you?

Chronologic and VCS was a great learning experience. I learned that there were two big problem areas in EDA––logic verification and logic synthesis. I also knew that the change in level of abstraction from gates to RTL was a great improvement in both design efficiency and verification efficiency, and that was enabled by logic synthesis. I was familiar with behavioral modeling from my verification days, and I was familiar with different levels of abstraction in system design from my graduate school days. It was quite apparent that the industry would undergo another change in level of abstraction, and that would again depend on synthesis.

In 1998 I got together with Andy Goodrich and Randy Allen to start CynApps, the company that is now Forte Design Systems. We set out to first create a higher level design environment rich enough to be usable, and then to create a synthesis product that would produce RTL from higher level designs.

Q: Where is the firm today?

Forte Design Systems is the result of two mergers, first CynApps and DASYS, then CynApps and Chronology. The company is now 11 years old. The original vision of high-level design is unchanged. The high-level design environment morphed from C++/Cynlib to C++/SystemC, which was a change in form, but not function. The Cynthesizer, our synthesis product, has been in customers’ hands for over six years now, and there are quite a few end products –– cameras, TVs, printers, and even cars –– which have chips designed either in part or in whole with SystemC and Cynthesizer.

Q: What are some key lessons you have learned?

I have re-learned the value of focus.

When we started CynApps, we knew there was no point in making a high-level synthesis program if no one was writing high-level code to synthesize. That meant that we had to develop and promote a design environment and also develop and sell the synthesis product. This was beyond the resources of a startup. We didn’t really start making progress on the synthesis product until we switched our input from Cynlib to SystemC, and let other people promote the design environment. If I had it to do over again, I would have gone with SystemC originally and done nothing but work on the Cynthesizer.

Having too much money can be a distraction. There is a real value to being lean –– it forces you to stay focused. The single biggest mistake I made with CynApps/Forte was spending too much money before the product was ready.

Q: How have you changed since you started?

One surprising way I’ve changed is that I have become even more optimistic than I was before. You have to be optimistic to start a company, and I’ve always been a glass half-full kind of person. But I have become even more-so over the years. Chronologic was a success, and Forte is an emerging success. After 11 years, and surviving through two bubbles, I think we can say that Forte has been a success, even though our overall impact on the industry has not reached its peak yet. On a personal level, I’ve had to become much less of a technical contributor than I used to be as I’ve gotten older.

Q: What key skill or experience did you lack when you started that has caused you the most problem?

When I started Chronologic, my biggest lack was understanding the EDA industry. I did not realize the staying power Verilog had as a design language, and this caused me to underestimate the importance of Chronologic and VCS. We could have stayed independent a lot longer, and I would have grown a lot more. When I started CynApps, I had never raised money and run a venture-backed company before. I made several mistakes as a result, trying to do too much, too soon, which cost a lot of money.

Q: What were some things that were “too much, too soon”?

I hired marketing and sales people before we had a product that was generally useful. This was when we were trying to sell the Cynlib/C++ design environment, before the Cynthesizer was finished. They were frustrated, the customers we did have were confused, and we drained our cash. We should have stayed in product development until the synthesizer was ready, let other people promote the C++ design environment, and developed sales resources organically.

Q: How do you tell when a product is ready? Where is money well spent before a product is ready?

I am not sure there is a general answer to when you know the product is ready. At Chronologic, we knew it was ready when it ran a particularly large model from Sun. At Forte, we knew Cynthesizer was ready only after it had actually been used to produce working silicon. While you are in product development, money should only be spent on engineering and market development. Market development basically means go talk to customers, tell them what you are doing, let them tell you if they like it, and repeat. It doesn’t take a lot of resources to do that, but it is very important.

Q: What are the two or three things that you have been able to accomplish that you take the most pride in or satisfaction from?

The success of VCS in the market is by far my most satisfying accomplishment. In a few years, I hope that Cynthesizer will rate up there in the same category. There is nothing like knowing that engineers have used your product to make the products that define our age. There is still something magical about your laptop computer, your camera, your iPhone, and your satellite HDTV and DVR. Knowing that your work made those things possible is really gratifying. When I bought a camera at Fry’s for my daughter, I could tell her that a chip inside was made using Cynthesizer. She didn’t much care, she just thought the face recognition feature was neat, but for me, it was a real kick. I think everyone in the EDA industry feels that way to some degree.

Q: What has been the biggest surprise? What was one key assumption you made, perhaps even unconsciously, that has caused the most grief?

The most surprising thing I learned was how hard a problem high-level synthesis is. There are many more degrees of freedom in synthesis than there are in simulation. If I had known that it would take eight years to get a mature product on the market, I doubt that I would have embarked on the project (and I doubt that I could have raised money to do it).

Q: What development, event, or new understanding since you started has had the most impact on your original plan? How has your plan changed in response?

Surprisingly, Forte’s business plan has changed very little since the founding of CynApps (except the time frame). The only real change we made was in going from Cynlib to SystemC. While we felt that Cynlib was more elegant than SystemC, the value of a standard is undeniable. We should have tried to influence SystemC from within sooner than we did. Andy Goodrich, who was the original author of Cynlib, is now the principal developer of SystemC.

Q: As we start to wrap up I wanted to ask you a personal question if I may. You are a cancer survivor. How has that changed your outlook on life?

Being diagnosed with cancer is a life changing experience for everyone who goes through it. You pretty quickly end up asking yourself what you are doing with your life, and if that is what you really want to be doing. I came to the conclusion that I was doing what I want to be doing –– I like EDA, I like small companies, I like our technology, and I like the people I work with. The only real change I made was to slow down a little and take more time off, but it has been a quantitative change, not a qualitative one.

Q: Any final remarks or suggestions for entrepreneurs?

It’s easy to give advice to first-time entrepreneurs. Lots of people will do it. Some of it is even useful. In a technical field like EDA, understanding the problem, and understanding the technology are prerequisites.

This industry is all about credibility. When you speak, you have to know what you are talking about. To be successful, you have to have credibility, and for that, you have to be a techie at heart. With credibility comes vision. If you know what you know, and understand what you are trying to do and why, then you can successfully resist the forces that will inevitably try to change your course.

Don’t believe the conventional wisdom that your startup needs a “seasoned business professional” to step in and run the company at some point. This is part of the VC formula, and it seldom works in EDA. The guy with the vision, and the credibility, is the guy for the job, and that is you. All the other stuff can be learned on the job.

For more information on John Sanguinetti

Update June 2: Welcome EE Times Readers. This post was selected as our first EETimes “Trusted Sources” Blog post. If you found this interview useful, we have other interviews with entrepreneurs in our Founder Story posts.

John Sanguinetti on an EDA Startup’s First Product

Written by Sean Murphy. Posted in EDA, Founder Story, skmurphy

John Sanguinetti was the founder and CEO of Chronologic Simulation, a startup that developed a compiled code approach to Verilog simulation. I am working on an interview with John and came across a very interesting position statement he gave as a part of a panel at DAC 98 called “The EDA Startup Experience: The First Product.

The key ingredient to launching a successful EDA startup is customers.

Having a particular type of customer in mind, and a particular customer if possible, and knowing what their needs are is the key. In my case the original customer prototype was myself, since I had been a design verification engineer and used Verilog for regression testing. Very early on, we identified a particular customer, Sun, to be our target customer. We figured that if we made Sun happy, we would make other people happy, too. This turned out to be true.

We also identified the problem we were solving–simulation speed. We focused almost entirely on that, from company slogan (The Fast Verilog Company), to advertising, to customer benchmarks. The acceptance criterion for our product in competitive benchmarks was always “how much faster is it than the competition.” This focus was used internally in making design decisions as it was externally in  positioning the company and product against competition.

If there is anything that can be generalized from Chronologic’s experience it is the value of a single focus on a real customer problem.

Interview with Ivaylo Lenkov part 1

Written by Theresa Shafer. Posted in Founder Story

This is part one of Anthony Scampavia’s interview with Ivaylo Lenkov, CEO and Software Architect at SiteKreator. Lenkov explains his team’s technique for doing daily releases. Look for part 2 on “Feature Management in a SaaS World” next month.

Anthony Scampavia: Will you provide a brief overview of your company SiteKreator?

Ivaylo Lenkov: We started SiteKreator in 2002 for business owners with no knowledge of programming or web design to be able to build and modify their own websites. Recently we introduced the first SaaS platform for creating custom web designs without coding. We work with many designers who use a private-labeled version of SiteKreator to deliver complete web solutions to their clients. Our technology powers more than 100,000 business sites and we operate from 10 global data centers with hundreds of servers.

Scampavia: What made you re-evaluate your release cycle and abandon traditional software development release cycles?

Lenkov: When we started SiteKreator, our release cycle was almost a year. We were spending more than half of that time in stabilizing and polishing the release, because there have been hundreds of new features. During that time our customers weren’t able to see anything new and by the time we finally released the new version, many of the cool new features were no longer cool and some were not even needed. The web is a very dynamic space and the annual release cycle was limiting our ability to be ahead of the curve and to deliver innovative solutions to our customers. We started looking for ways to shorten our release cycle, by reducing the features going into each release. We first tried a three-month release cycle, then one-month, then one-week and we ended up with daily releases.

Scampavia: So how you accommodate long-term project planning while doing daily releases?

Lenkov: Well, that’s not easy. When you are focused on a very small feature-set, you sometimes lose the big picture. You just can’t see the forest from the trees. We had to change our planning process. We still maintain a product roadmap with milestones and everything but we chop each milestone into many small releases. This way every day we have a working product. We also review our priorities every couple of weeks and adjust them as needed.

Scampavia: How you actually do these daily releases?

Lenkov: Our team is distributed between two locations: one in California and another one in Bulgaria. This has many cons and few pros, one of them being that we can work in two shifts using the so called “follow the sun” model. Our engineers in Bulgaria finish the coding for the daily release around 11am PST and deploy on several staging servers. Then our product managers, marketers and usability experts based in California review the release and file their comments in our defect tracking system. After 11pm PST our engineers in Bulgaria come to work, fix the reported problems, if any, and push the release to the production servers worldwide. Sometimes we may skip a release if we need a little more time to fix something, but this does not happen very often. When you make small changes, it’s hard to break something big.

Scampavia: How do you ensure the stability of the release?

Lenkov: The daily deploy model would not be possible without a large-scale automated testing. We run a big farm of screen-capturing and comparing servers. We basically compare thousands of sites before and after the deploy on our staging servers. This takes few hours as we capture all possible browsers, both on Mac and PC, and in many screen resolutions.

Scampavia: Visually. So, you are doing just a Pitman comparison really.

Lenkov: Yes, but on a very large scale. The rule of thumb is that by doubling the number of sites we compare, the probability of catching new problems increases by one percent. But every increase in the number of sites also increases the number of false positives that has to be manually reviewed. So we tweaked our comparison algorithms to be more tolerant towards small differences in the screenshots. We still do human review of some screenshots that do not match, but at least it’s manageable.

Scampavia: What happens when you find a problem after the software has been deployed on the official servers?

Lenkov: This does not happen that often, but if needed, we have a single button roll-back to the last stable version. It takes about 2-3 min and it rollbacks all datacenters. But we use this for only really critical problems. For non-critical or cosmetic issue, we just fix the problem with the next deploy. That’s the advantage of having a daily release cycle.

Scampavia: How do you handle larger features that cannot be implemented in a day?

Lenkov: We implement the larger new features as modules, which are initially in stealth mode. We enable these modules only for specific users, so they can be tested. Of course we start by eating our own dog food. Then we enable the new features for users who have signed up as beta testers, as well as for our reseller partners. Once we feel confident with the stability of the new features, we begin bucket testing with real users. We start with a very small bucket (usually top 100 most active users), while keeping a finger on the Off button. Then we expand the bucket few times and at the end we enable all users. After a few weeks of running everyone on the new modules, we decommission the old modules.

There are two potential complications from this approach:

  1. If there are differences in the interfaces between the old and the new module, we need to create some throw-away glue code that “talks” to both interfaces.
  2. If there are backward incompatible changes in the database schema, we usually need to add a wrapper on the database level.

Of course this approach could not be possible without having tens of thousands of users using the software on a daily basis. Even if we miss a defect or a use-case, it always pops up during the bucket testing.

Scampavia: What do you use for version control?

Lenkov: Subversion in combination with Trac.

Scampavia: You have been doing one-day release cycles for two or three years now. Has it been worth it?

Lenkov: Initially, I thought it would be very inefficient but it turned out that shortening the release cycle resulted in reducing the time we spend on bug fixes, stabilizing the release from 50% to about 20%. Also, now we can introduce new features in a matter of days, while before it was taking months even a year for the smallest new feature to become publicly available. Our users very much appreciate that. In the SaaS world, the ability to show something new every day helps a lot in building a loyal customer base.

Scampavia: I want to thank you for your time and your thoughts. This is valuable to the SaaS world for people to realize that there is information they should at least think about for their methodology. You have put in much thought in this through the years. I will say that not all SaaS companies have done that. My experience is many companies are too busy to get to the market and do not consider the method. If they do not have the stability and methodology in place, things start to tear apart.

Lenkov: Thank you for having me. I am happy to share our experience and hopefully it will be useful to other SaaS vendors.

Scampavia: Lenkov, thanks for your time.

Francis Adanza on the Entrepreneurial Roller Coaster

Written by Sean Murphy. Posted in Founder Story, skmurphy

Francis Adanza worked for us in a project management role for the better part of two years  before taking a business development role with Global West Communications. He was back in the Bay Area last week and attended last Friday’s Bootstrappers Breakfast and we had a chance to catch up. He sent me a short e-mail on his perspective on  “entrepreneurial roller coaster” afterward. It’s a topic I have blogged about in “We Don’t Encourage Individuals to Form a Startup” and “Hugh Macleod’s Thoughts on Being an Entrepreneur 2” but I think Francis has done a better job of explaining it and with his permission I reprint it below:

The funnest yet scariest part about riding a roller coaster for the first time is the unknown knowns. You know there are going to be highs and lows, but you don’t know when they will occur. You know there will be twists, turns, even sporadic upside down thrills, but its hard to forecast them. Sometimes the adventure seems fast, and sometimes it seems long, dragging on forever.

Regardless of how scary the ride may be, we all have choices that can alter the experience. Some people keep their eyes closed the entire ride, trying to mitigate their fears. Others dare to keep their eyes open, embracing each turn of events. Some folks find reassurance and control by holding on to the safety bars. While others fly by the seat of their pants, hands waving free in the air.

At times the ride becomes so frightening, you wonder why you even got on. It doesn’t matter how much you yell or scream, all you can do is wait until it ends. Although you might walk away a little shook up with a few scratches and bruises, you know in your heart that you had the guts to give it a try.

Jeff Bezos on Strategic Planning

Written by Sean Murphy. Posted in 4 Finding your Niche, Founder Story, skmurphy

Jeff Bezos was interviewed in the Harvard Business Review in an  October of 2007 article “The Institutional YES.” The focus was on Amazon’s strategic planning process. I had a chance to hear Bezos speak in 2004 at a Stanford Entrepreneur Conference and was impressed at how relentlessly inventive and experimental the culture he had created at Amazon was. It made it less of a surprise that a firm that started by revolutionizing the book selling business is now a leading provider of “cloud computing’ infrastructure.  Here are some excerpts that I found thought provoking and useful (bold added).

  • First, we are willing to plant seeds and wait a long time for them to turn into trees.
  • We may not know that it’s going to turn into an oak, but at least we know that it can turn out to be that big. I think you need to make sure with the things you choose that you are able to say, “If we can get this to work, it will be big.” An important question to ask is, “Is it big enough to be meaningful to the company as a whole if we’re very successful?”
  • What I have found—and this is an empirical observation; I see no reason why it should be the case, but it tends to be—is that when we plant a seed, it tends to take five to seven years before it has a meaningful impact on the economics of the company.
  • It helps to base your strategy on things that won’t change. When I’m talking with people outside the company, there’s a question that comes up very commonly: “What’s going to change in the next five to ten years?” But I very rarely get asked “What’s not going to change in the next five to ten years?” At Amazon we’re always trying to figure that out, because you can really spin up flywheels around those things. All the energy you invest in them today will still be paying you dividends ten years from now.
  • Whereas if you base your strategy first and foremost on more transitory things—who your competitors are, what kind of technologies are available, and so on—those things are going to change so rapidly that you’re going to have to change your strategy very rapidly, too.
  • I think most big errors are errors of omission rather than errors of commission. They are the ones that companies never get held to account for—the times when they were in a position to notice something and act on it, had the skills and competencies or could have acquired them, and yet failed to do so. It’s the opposite of sticking to your knitting: It’s when you shouldn’t have stuck to your knitting but you did.

It can be hard to cultivate a five to seven year perspective in a startup, but I do think the asking the question “What’s not going to change in the next five to ten years” is a good way to try and develop one.

Odd Jobs With an Even Temper

Written by Sean Murphy. Posted in 2 Open for Business Stage, Founder Story, Rules of Thumb, skmurphy

When you are very angry, think about how momentary a man’s life is.
Marcus Aurelius

I worked in the router software marketing group at Cisco in the early 90′s. I had left engineering and taken up residence in the marketing department. I was playing asteroid to a number of dinosaur protocols: we had realized that it wasn’t about supporting as many different protocols as possible (PUP, Chaosnet, Arcnet come to mind as examples) but to be really good at supporting IP. At one point I sent out an e-mail with the subject line “The following protocols are ‘on the roof‘.”

We had male admin named Ken. Cisco was a rapidly growing company then, with the stock doubling every year, and the culture was tolerant of a high level of direct conflict, what we would refer to as “a full and frank exchange of views.” Ken maintained a small but durable force field of calm in the midst of the frenzy.

I made him a sign for his cubicle wall (clearly I didn’t have enough to do):

“Boy Scout in Residence: Odd Jobs With An Even Temper”

He was always prepared and never rattled. He came from a family of four boys raised by a single mother. He told me a story of the time that his mother had saved up and bought a couple of gallons of yellow paint to re-decorate the kitchen. The boys woke up early and decided to paint her Volkswagen bus with the latex paint. He said “she went right past anger to tears. She was so angry and then she just started to cry. It took a while to get most of the paint off the windshield and windows, the rest of the car stayed more or less yellow.”

Ken passed away a few years later. It was a sad death for so young a man. I am not sure how he maintained his calm, perhaps it was such a huge opportunity for him compared to where he started that he was just grateful to be there. Or he may have been blessed with equanimity.

I think every startup above a certain size needs someone who can do “odd jobs” with an even temper. Especially as things get tougher in Silicon Valley, don’t underestimate the value of small kindnesses, a sense of humor, and cultivating calmness.

Update June 20, 2014: I think everyone on a startup team needs to do “odd jobs with an even temper.” It’s useful to bring on someone, even part time, who is detail oriented and can tackle the swarm of small tasks that need to get done.

Scott Sambucci on “An Entrepreneur’s Lessons Learned”

Written by Sean Murphy. Posted in Consulting Business, Founder Story, Rules of Thumb, skmurphy

I met Scott Sambucci when I spoke at TVC in July of 2007 in Menlo Park as a part of their “Entering the Entrepreneurial World” seminar. He was kind enough to blog about his take away from the talk in “Definition: Entrepreneurship” where he concluded that even though it was a noun it should be defined as a verb:

“Leveraging resources to get things done” & “Prudent risk-taking.”

We had several conversations and came away very impressed with his business savvy. We retained him to help us with a planning session for our business later in 2007 and profited from his suggestions. He recently blogged about a business he was bootstrapping that he shut down in “An Entrepreneur’s Lessons Learned.” It’s candid, insightful, and makes for good reading for bootstrapping entrepreneurs. His key take aways:

  • Start a blog not a website, you can publish immediately and anytime you need to without a webmaster.
  • To leverage Google Adwords or any other search marketing vehicle you have to know how your prospects will describe their needs as search terms.
  • Find something small to sell early.
  • Maintain accounting records from the start.
  • Know when to quit.

On that least point he has some excellent thoughts (emphasis added not in original)

Usually, you’ll hear from successful entrepreneurs that the mistakes were the most beneficial to their long term growth. That’s sort of true. It’s not the mistakes that offer the opportunity for growth, but the acknowledgement and deconstruction of mistakes.

There’s a difference between believing in something, and knowing it…Being blind to the obvious signs that your venture isn’t working is downright foolish.

I believe in myself, and that’s why I decided to close the shop. Good entrepreneurs know that there’s more than one good idea. Let the failures work for you, not against you.

Go ahead and read the whole thing, it’s candid and insightful.

I’ve written about knowing when to quit a few times, here are a couple of blog posts that are related:

The Dip does have “Three Questions to Ask Before Quitting (on pages 66-71) that are worth answering now if you haven’t already.

    1. Am I Panicking? Decide in advance when you are going to quit.
    2. Who Am I Trying to Influence? A person or a market? Markets value persistence far more than an individual.
    3. What Sort of Measurable Progress am I Making?

Norm Brodsky’s Guidelines For Entrepreneurs

Written by Sean Murphy. Posted in Founder Story, Rules of Thumb, skmurphy

The October issue of Inc. magazine made it to the top of my reading pile today and I was delighted to read another great “Street Smarts” column by Norm Brodsky “Secrets of the $110 Million Dollar Man” which offers ten guidelines for starting a successful business. Brodsky’s definition of success should be familiar to anyone who is bootstrapping:

By successful, I mean a business that lives off its own cash flow, provides a good living for its owners and employees, and generates the profit it needs to keep growing.

He offers ten rules from 30 years of entrepreneurial efforts that he continues to rely on. I have picked what I think are the top three for software entrepreneurs and encourage you to read the rest of the article

Numbers run a business.

If you don’t know how to read them, you are flying blind. A business is a living entity with needs of its own that the leaders must pay attention to or it will fail. the business will fail. The only way to determine business needs are to look at key numbers and the relationships between them. We spend a lot of time with clients on determining what the dashboard for their business should look like, typically starting with their sales funnel, and tuning strategies and tactics in response to the numbers.

A sale isn’t a sale until you collect.

You don’t collect on bad debt and how long it takes to collect can leave you short of cash even though you’ve made a lot of sales. Every business with receivables is in effect a bank. As I have written previously, every business that generates receivables is, in effect, a “bank.” When you deliver a product or a service in the belief that the customer will eventually pay you for it, you are making a loan. You need to determine whether a customer is creditworthy and monitor your average collection time on outstanding debt. Understanding cash flow and the credit risk you are assuming is key to getting through the downturn we are currently experiencing.

Forget shortcuts.

Everything a great business needs takes hard work and time:

  • a diversified base of loyal customers
  • experienced managers
  • a vibrant culture
  • efficient systems throughout the business
  • a sales force that works as a team
  • a great reputation in the industry.

This might also be called “the old man’s business model” in contrast to Paul Tyma‘s “The Young Man’s Business Model.”

So why was Brodsky a $110 million dollar man? He is as frank about his shortcomings as his success:

I am more impatient than most and tried just about every shortcut in the book — like hiring salespeople from competitors and promoting employees just because they are available. It finally dawned on me that my shortcuts were serving only to prolong the process of building the great company I wanted. Why was I in such a hurry, anyway? A great company is one that can last forever, and I needed to make decisions in that frame of mind — even though I fully expected to sell the business someday. My records-storage business, CitiStorage, would be worth more if I took my time and did what was best for the company in the long term. Indeed, it was. As you may know, I ultimately sold it and two related businesses for $110 million.

Diane Green Out At VMWare

Written by Sean Murphy. Posted in Founder Story, skmurphy

I was sorry to read the “VMware Announces Change in Executive Leadership” press release today from EMC.

VMware’s Board of Directors announced today that it has made a change in the leadership of the company with the departure of Diane Greene as President and CEO. VMware’s Board of Directors has appointed Paul Maritz as President and CEO of VMware effective immediately.  Maritz was also named to VMware’s Board of Directors.

I heard her speak at a October 2006 Fireside chat at TiE and was extremely impressed by her low key style and forthright manner. She also said a number of smart things and as I blogged back then “I got a real sense of her as a genuinely caring leader (what Jim Collins would call a “Level 5 Leader” ).”

I always hate to see a founder get ousted from a company, especially one that’s still wildly successful (VMWare is expected to grow revenue almost 50% this year over last). I am interested in her perspective on events: she was against VMWare being acquired by EMC, mentioning it as one of the two “blackest days” she faced at VMWare during the Fireside chat, so I look forward to her being able to speak more candidly about the last few years once she is fully separated from EMC.

Update July 12: Ho Nam at Altos Capital has an interesting take–especially for a VC, but Altos is an unusual shop–in his post “Ousting the Founder.

I was shocked to learn this week that Diane Greene, the co-founder and CEO of VMWare was ousted. I was not alone. Except for senior management (who found out very late, the night before) the employees of VMWare read about it, just like I did on Tuesday morning. [...]

As co-founder and CEO, Diane Green built one of the all time great successes in Silicon Valley. Very, very few companies ever reach $1B in revenues. Even fewer in the technology industry. Even fewer in the software industry. And even fewer ever exceed $10B in market cap.

Why the hell would you fire her?? No, don’t tell me…I’ve heard all the reasons. VCs oust founders all the time. I’ve been in plenty of board level discussions around this topic! It’s almost a rite of passage in Silicon Valley. As a founder, you start a company, get VCs to fund you, recruit a “world class” management team…and eventually, find your replacement (or get ousted).

What people seem to miss, however, is that just about every great company ever created – in technology as well as low-tech, was built by a founder (or a CEO who happened to join the company very early in its growth phase) and a team of dedicated people who grew with their companies.[...]

I’d rather take my chances with the people who built the business and grew their companies than the “professionals” – the hired guns – the mercenaries – coming in, after the fact, to “fix” things or to “take it to the next level.”

We tell all of our companies this – if you want to build the leader in your industry, you have to have the world’s leading experts in your field working for you. But do NOT expect to find them outside of your company. Someone senior from the outside won’t come in to show you the way. They won’t save you.

Five Questions to Ask Yourself Twice a Year

Written by Sean Murphy. Posted in Blogging, Founder Story, skmurphy

  1. What have you learned?
  2. How have you changed since you started?
  3. What key skill or experience did you lack when you started that has caused you the most problem?
  4. What has been the biggest surprise: what was one key assumption you made, perhaps even unconsciously, that has caused the most grief?
  5. What development, event, or new understanding since you started has had the most impact on your original plan? How has your plan changed in response?

Take 30 minutes and write down the answers to these questions for your current business (you can take another 30 and write them down for you last one as well if you like). Share the questions with your co-founders and ask them to do the same. Compare notes. Put the answers away in a safe place, answer the questions again in six months, and compare your first and second set of answers. Repeat as necessary.

I came up with these in response to “Need good interview questions for startup founders” on Hacker News, deriving them from questions we have been asking in our Founder Story series.

Inspired as well by “Forget your Blog: 5 Reasons to Keep a Personal Log

There is a scene in the movie Weird Science where the main character looks up something in his so-called “log.”

“You keep a diary!?”, the other geek asks.
“No, of course not! Teenage girls keep a diary, I keep a log”.

  1. Full Freedom of Thought
  2. Spot the Connections
  3. Sum it Up
  4. Backtrack Feelings
  5. Make Growth or Decline Visible

Founder Story: Debra Willrett on Inventing MacProject

Written by Sean Murphy. Posted in Founder Story, skmurphy

I first met Debra Willrett, founder of Expert Software Consulting, at the IEEE Consultants Network for Silicon Valley (CNSV) when she gave a  great talk on the new CNSV website in February of 2006. When Francis and I learned that she was the  inventor of the Macintosh application MacProject, an application that has defined a paradigm for interactive graphical project management tools for the last 25 years, we asked her for an interview for our Founder Story series. What follows is Debra’s experience of turning an application into a business.

Q: Inventing MacProject is quite an accomplishment. What problem were you trying to solve when you started?

The initial motivation was to manage software projects. I was working in the lab at Hewlett-Packard, and my manager at the time was drawing large Pert charts by hand and taping them to the walls of our cubicles. But having a project with multiple people and complex dependencies between the components is a universal problem which applies to building nuclear reactors, bridges or software systems.

At HP , I was the user interface developer for a PC-based CAD system, one of a number of similar projects at HP at the time. My job was to build a graphical layout program for printed circuit boards.

When I saw a pre-release of Apple’s Lisa computer, I realized I had the components in place for a business. I had the problem to solve, the system to build it on, and the skills to build a WYSIWYG application with broad appeal. I proposed my product to Trip Hawkins, a member of the Lisa marketing team at Apple. Trip immediately understood the concept and we worked out a contract to develop the first implementation of my idea, LisaProject. This contract gave me the courage to quit my job at HP and work full time on pursuing my dream. By the time the Mac was released I was on my second revision, MacProject.

Q: What aspects of the process were a surprise?

The process was more challenging and exciting than I anticipated. Within the space of a couple of years, I started my first business (SoloSoft), negotiated my first contract, became the first Independent Software Vendor (ISV) for the Lisa, and shipped the first ISV application on the Mac. On the technical side, I wrote the first version of LisaProject in 6 months and released it to a community of users which grew to number 5,000 within 2 years. While I was supporting LisaProject, I wrote a new version, MacProject, for the yet-to-be released Macintosh.

Q: What alternatives existed when you started? What differentiated MacProject from your competitors?

First of all, Microsoft Project did not exist when I wrote either LisaProject or MacProject. The competitors at the time were complex non-graphical products. It took a specialist to understand how to apply them and consultants to help you figure out the data. I wanted to build something clean and elegant that anyone could understand and apply, even on a very small scale. Whether you are building the space shuttle or planning an event with friends, you are working with a group of people on a schedule and you need a vehicle with which you can communicate and monitor your plan.

Q: Today are many project management tools on the market: do you use any of them? What do you see as some of the aspects of project management still to be addressed by software?

I’m not a project management specialist today, but I have been asked for recommendations about what to purchase. More often I get asked the question, where can I get something like MacProject today? I think the tool that you pick should be easy to use and quickly be of value to you. Many solutions are more complex than they need to be. Also, project management is not done by one person working alone, so the social networking of the Web should revolutionize the way we approach the problem. I haven’t seen anything which I really like, so I’m thinking about getting back into the business. Stay tuned.

Q: It is very challenging to be both the inventor and the entrepreneur. Can you talk about your experience at SoloSoft and how you successfully structured the Apple deal? At the time, what were SoloSoft’s biggest challenges in negotiating the Apple deal?

My first contract with Apple for the Lisa was enough to pay the bills and keep the lights on. More importantly, building LisaProject gave me experience and relationships with people in Apple. I was in the right place at the right time when the Macintosh was developed. It can take years of work to make your investment pay off and many people get discouraged too early.

Another problem occurs if you ask for too much at the beginning. Until you demonstrate both your ability to deliver and the viability of your idea, you don’t have much leverage. The terms of the customer’s proposal for the first contract will reflect this. when They often feel that their work is worth more than it really is, and they walk away from a deal. I have also seen things fall apart when people get too fussy about every line on the contract.

You need to be flexible and realistic. In exchange, you can be firm about the issues which are important to you. One of the key terms of my contracts with Apple was that I would retain ownership of the software.

I also found that I could profit from being underestimated by others.

I requested a number of significant bonus incentives for meeting scheduled deadlines. Since software schedules are routinely slipped as additional features are added or the scope of the project changes, no one believes you when you say you will deliver something on time.

They will happily add terms in the contract which pay more for meeting delivery dates. And I happily collected on every one of my bonus payments. Of course, the customer also won, because having the new features earlier increased sales.

Once MacProject became a big success, there was pressure to restructure my agreement. Since I was making significant money, Apple wanted to reduce the royalty rate. Another consequence of success was that as the user base expanded, the list of desired features grew rapidly. I rejected many of these feature requests to maintain the elegance of the user interface. Nevertheless, the list of good ideas for new features eventually exceeded my ability to write the code. Tension developed between SoloSoft and Apple over this issue. I considered scaling up SoloSoft’s development team by hiring its first employee. Apple wanted to control the development by bringing it in-house. Apple offered to buy out the royalty stream. Any successful contract has to keep working for all the stakeholders. I was torn between my ambitions to grow SoloSoft into a large business and the demands of my growing family. I ultimately decided to sell MacProject to Claris, Apple’s spinoff of its software business, and went into a period of professional semi-retirement.

Q: You have started a new firm: can you tell us a little about what you’re doing with Expert Software Consulting?

Expert Software Consulting builds web applications for various types of clients. I like being my own boss. I enjoy the challenges of running a business, and I hope that some of my ideas today will enable me to make a larger contribution in the future. Recently a group of Stanford students led by B.J. Fogg created Facebook applications and found out that they had an installed base of millions of users within weeks with applications like “Kiss Me” or “Hug Me.” The Web is a phenomenal playground, and things are changing all the time. It’s exciting and fun to be a part of, and I enjoy going to work every day.

HP Way: Seven Objectives For Your Startup

Written by Sean Murphy. Posted in Founder Story, skmurphy

I re-read David Packard’s book “The HP Way” recently and was struck by the “Sonoma Meeting” section in Chapter 5: “From Partnership to Corporation”

Another significant event that occurred early in 1957 was the company’s first off-site meeting of senior managers. This was a two-day meeting that took place at the Sonoma Mission Inn, about 70 miles north of San Francisco. About twenty people attended.

Packard lists three reasons for the meeting:

  1. Get key managers together at least once a year to discuss policies and problems, to exchange views, and to make plans for the future.
  2. With 1200 people in the company, the founders could no longer personally manage all of the key issues. They still wanted to maintain a small company atmosphere.
  3. Get agreement on key objectives so that they would steer in a common direction. Allow everyone to comment and have a hand in developing them, with an eye to periodic revision.

They started with six but in 1966 they were revised into the following seven; reading them again I thought this would make a good default set for any technology startup:

  1. Profit. To recognize that profit is the best single measure of our contribution to society and the ultimate source of our corporate strength. We should attempt to achieve the maximum possible profit consistent with our other objectives.
  2. Customers. To strive for continual improvement in the quality, usefulness, and value of the products and services we offer our customers.
  3. Field of Interest. To concentrate our efforts, continually seeking new opportunities for growth but limiting our involvement to fields in which we have capability and can make a contribution.
  4. Growth. To emphasize growth as a measure of strength and a requirement for survival.
  5. Employees. To provide employment opportunities for HP people that include the opportunity to share in the company’s success, which they help make possible. To provide for them job security based on performance, and to provide the opportunity for personal satisfaction that comes from a sense of accomplishment in their work.
  6. Organization. To maintain an organizational environment that fosters individual motivation, initiative and creativity, and a wide latitude of freedom in working toward established objectives and goals.
  7. Citizenship. To meet the obligations of good citizenship by making contributions to the community and to the institutions in our society which generate the environment in which we operate.

Obviously the management team would have to decide how they were going to keep score in detail on each of these (#1 is fairly obvious but the others are a little more complex). For more background see the HP Memory Project and HP History Links at the HP Alumni site. It’s also interesting to compare the seven from 1966 with HP’s current corporate objectives which feel padded and much less action oriented.

Quick Links

Bootstrappers Breakfast Link Startup Stages Clients In the News Upcoming Events Office Hours Button