Startup Founders Announced for Working For Equity Panel at SVCC 2012

Written by Sean Murphy. Posted in 1 Idea Stage, 2 Open for Business Stage, 3 Early Customer Stage, 4 Finding your Niche, Events, Founder Story, skmurphy

For the third year in a row I will moderate a panel of startup founders sharing lesson learned bootstrapping a technology startup at Silicon Valley Code Camp. This “Working for Equity” session will be on Sunday Oct 7 at 9:15am.

Here is the announcement

Many of us in Silicon Valley seek to found or be an early employee at a technology startup. If you aspire to create a startup come take part in a conversation with four  startup founders about what’s really involved in leaving your day job and striking out on your own or with partners. The startup founders range from serial entrepreneurs to first-time CEOs, they will share their vision, drive and passion as they discuss the nuts and bolts of following their dreams to building something that will change the world.

  • Lenny Greenberg CTO of Assityx, Inc.
    Lenny Greenberg is founder and CTO of Assistyx, leading developer of assistive communication products, including the award-winning TapToTalk app that help individuals with physical and mental challenges reach their full potential. A serial entrepreneur, Lenny has led organizations in planning and developing advanced technology-based products.
  • Ruoting Sun, co-founder of Temvi, Inc.
    Ruoting Sun is co-founder of Temvi, a Mountain View based startup focused on simplifying social discovery. Temvi enables users to easily find, share, and experience cool events that are happening around them, based on their interests and passions. Routing is a first time entrepreneur heading a team of 5 others in creating a mobile app for social discovery.
  • Sam King, CEO of ExpressMango, Inc.
    After working as a key contributor to many startups, Sam King co-founded Express Mango, a the social networking appointment system. Express Mango’s online scheduling and appointment reminders reduce no shows. The facebook virtual receptionist helps grow your business 24/7/365.
  • Giacomo Vacca, CEO of Kinetic River, Corp.
    Giacomo Vacca founded Kinetic River to focus on products and services at the intersection of laser optics, microfluidics and medical diagnostic devices. He earned his B.A. and M.A. in Physics from Harvard University, and his Ph.D. in Applied Physics from Stanford University. His most recent honors are having been elected to Senior Member of the Optical Society of America and to Research Fellow of the Volwiler Society at Abbott Laboratories.
  • Moderator: Sean Murphy, CEO of SKMurphy Inc.
    Sean Murphy has taken an entrepreneurial approach to life since he could drive. His firm specializes in early stage and emerging market technology companies who are challenged either by new product introduction or the need to diversify beyond their initial success.

Silicon Valley Code Camp is an amazing experience that has improved each of the five years that I have attended. It’s held at Foothill College (12345 El Monte Road,  Los Altos Hills, CA 94022) and this year will convent the weekend of Saturday October 6th and Sunday October 7th. There is no charge to attend.

Register your interest in attending Code Camp at

Register your interest in attending the  Sunday Oct 7 9:15am “Working for Equity” session at

“Working For Equity” Panel Session Returns to Silicon Valley Code Camp For Third Year

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

I am moderating a panel at Silicon Valley Code Camp 2012 on “Working For Equity.” Here is the session description:

Panel discussion with three software startup CEOs offering their perspective on the practical realities of starting and growing a company. This session is for both aspiring and active entrepreneurs, it will outline important tips and issues to consider if you are investing your time in a startup. Each panelist will give a 5 minute lightning talk on background and lessons learned, followed by a group Q&A session with the audience.

This will be the third year I have moderated this panel; the last two years it’s been very popular and we normally have a great conversation with the audience after some brief introductory remarks by each panel member.

Silicon Valley Code Camp is an amazing experience that has improved each of the five years that I have attended. It’s held at Foothill College (12345 El Monte Road,  Los Altos Hills, CA 94022) and this year will convent the weekend of Saturday October 6th and Sunday October 7th.

Register your interest in attending Code Camp at

Register your interest in attending the “Working for Equity” session at

Here are blog posts about the panel sessions from 2011 and 2010

Founders Story: Arun Kumar of Kerika

Written by Sean Murphy. Posted in Founder Story, skmurphy

The following interview is constructed from e-mails and skype calls from February to April 2012 with Arun Kumar of Kerika. See also this video: and the Kerika blog for more info on Kerika.

Q: Can you talk a little bit about your background

I started off as a Physics major at IIT Delhi, a little too young to make sensible life decisions.  After three years, I decided to pack it in and move to the US for a variety of reasons.  I ended up at Washington State University where I graduated in Comp. Sci., took some grad courses in Comp. Sci. and business before dropping out of the MBA program to move to NJ to work as a UI developer at AT&T Bell Labs.

After a couple of promotions I found myself a pointy-haired boss at the ripe age of 27, managing a staff of ~40 — all of whom were older than me, which made for an ironic situation since I was supposed to be giving them career advice, so I quit and traveled for a while in India and Europe and then returned to the US to work at a tiny software company in Staten Island that was building state-of-the-art software for handling financial market data in digital form.

I was a manager of all trades: helping to build the business, design products, build teams, etc.  I spent 2.5 years completely rebuilding the back-end and front-end systems a German news agency that required a monthly commute to Frankfurt, but that was one of my best projects ever because I had complete business and technology responsibility for a major account.  I then spent some time managing the installation of the first digital trading floor in Argentina.

The company was sold to a Japanese conglomerate (CSK) which asked me to help them develop their financial markets business in Asia/Pacific. I spent a year living out of hotels in Tokyo, Hong Kong and Singapore before getting tired of that lifestyle and moving back to the US to become a product manager.

I joined Morgan Stanley in New York in 1995, helping to establish product management processes for their IT department.  After a couple of years, I became an E-Business strategist. I moved to London in 1999 to get the European E-business initiatives into a higher gear.  While there, the big achievement was putting together a €100MM joint venture with OMX from Stockholm to launch a new pan-European stock exchange (Jiway) that would lower the costs for cross-border trading by retail investors.

I helped create and launch Jiway from scratch in just 9 months.  Morgan Stanley asked me to join Jiway after it was founded, to help them safeguard their interest in the JV.  Spent most of my time establishing strategic partnerships with the leading banks and brokers in Europe and US to support the new exchange and did a lot of PR (press, radio, TV, conferences, etc. across Western and Eastern Europe).

I decided to move back to the US in 2002 to live in the Seattle area and pursue my own ideas away, from financial services and back in technology.

First attempt to create the Kerika business was 2002-2006.  After failing to gain enough traction, I put the company in hibernation and spent a year as a contractor at Microsoft while deciding what to do next.  I joined Onvia in Seattle as head of their program management in 2007, eventually ended up managing all their IT and setting up offshore teams, but left in 2010 and decided to restart Kerika, re-imagining and rebuilding the original vision as a Web App.

That’s about it.  Side-note: while I was in London, I was asked to join the board of a Swedish company (Polopoly).  I remained on the board after moving back to the US, until I resigned in 2005 after concluding the relationship had become too long-distance.

You can see all this at

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

There was a moment of epiphany: when I was at Morgan Stanley in the late 90s, I reserved a conference room (at random) for a meeting.  Walking into the room I found  a large, complex diagram and set of notes on the whiteboard.  In one corner, was a reference to one of the products that I was responsible for.  I was astonished, because this room was in a part of the company that I had never visited before, and I couldn’t work out the reference to my product.  That got me thinking: “what if I could see the world through the eyes of the people who had been in that room before?”

I spent time thinking about this problem, but didn’t do very much.  When I moved to London to build Jiway, the question of effective collaboration within distributed teams became an acute problem for me: I was trying to coordinate the efforts of people in New York, London and Stockholm; people working within Morgan Stanley, OMX and external organizations; people from different departments and backgrounds.

The tools we had were from Microsoft: Project, SharePoint, and Outlook (the lowest-common-denominator way of collaborating).  I became convinced that there was a class of projects/work that was not supported by traditional approaches to collaboration, and this work was characterized by almost continuous changes in strategy and tactics, practically on a daily basis.

Traditional tools didn’t recognize the fluidity of knowledge-intensive work, where you learn about the project as you execute the project.  So, pretty soon you find that instead of MS Project and SharePoint supporting your work, you spend most of your time feeding the beast: trying to keep these “tools” up to date on the shifting reality of your project.

Not handling change gracefully is one flaw, the other is that task management is considered to be the key element of project management, when increasingly it is content management that drives success.  And increasingly, that content is sourced externally from the Web rather than generated internally by the team.

While I was working at Onvia, I realized this problem was getting worse because of some secular trends: teams were becoming increasingly distributed, with more work getting done offshore, and managing content, particularly the combination of Web and Office content, was becoming increasingly difficult.

At Onvia we used Project and SharePoint, again, and it was clear that their basic command-and-control model, which presumes that everything can be predetermined at the start of a project with relatively little discovery taking place during the project, were fundamentally unsuited for all sorts of knowledge-intensive work.

Q: How did you get started?

I started in 2002 doing a ton of market research on the problem: I build mockups and showed them to potential users in all sorts of companies and organizations — commercial, nonprofit, governmental — both in the US and Europe.  That helped me evolve the basic vision quite a bit.  (In retrospect, I did way too much market research and should have started building a usable product sooner).  I built a small team and decided to build Kerika as a p2p Java app that used the JXTA open-source networking technology.

We built several versions and got it in the hands of a broad range of users, with a surprising number of them overseas.

BTW, I used my savings to fund the company and never sought external investors.  Not sure that was the smartest move I made…

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

I restarted the company in August 2010.  I decided then that the old p2p model was made obsolete by the development of a broad range of Web services, so I decided to build a Web App the second time around.  I hooked up with Jon Cohen who acted as CTO and worked on the back-end; on the front-end we ended up cycling through a number of people locally in the Seattle area before finally hooking up with a very talented group of developers in India that are now the core part of the dev team.

We got a first beta version out in March 2011, and started showing it to a few friendly users that were local.  We got more people using by word-of-mouth, but we focused primarily on getting beta users in the Seattle area who would let us observe their use of the product and give us direct, extensive feedback.  This was enormously helpful: we learned a ton about usability of the product, and we also learned which parts of the product were more useful than others.  The product improved hugely in the April-Dec timeframe, to the point where we now view it as very much out of beta.  Along the way we picked up users from a broad range of backgrounds: students using it for group projects, other entrepreneurs using it for their startups, people using it for political and advocacy purposes, folks in enterprises…

The basic product is of generic use, but we think the value proposition is strongest when distributed teams have to collaborate, because then the greatest risk of project failure comes from team members not being on the same page, all the time — and not because team members are inherently incompetent or lazy.  We are now focusing our marketing focused around this single message: Kerika can eliminate (or at the very least mitigate) the substantial project risk that comes from people not being aligned on strategy, structure and content.

The company is self-funded again (i.e. “me-funded”), and will probably remain that way for a little while longer: I want to see more traction before I seek funding.

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?

Getting an offshore team working well has been a source of great satisfaction. That’s not easy, and it’s not accidental.  I have learned a lot over the years about making cross-border teams work, and getting an offshore team working well takes a mix of cultural, technical and management skills.  At this point now I feel I have one of the most productive teams I have ever had, and they are producing output of a higher quality than I could get from local talent.

I don’t know if Kerika is for everyone, but for some people it really does match their style of working.  I love the moments when I demo the product to someone who has been looking for a visual collaboration tool for years, without even knowing that they were looking for such a tool, and their face lights up as they immediately “get it”.

Finally, there is the professional joy of being in a startup, where you have to wear so many hats: you have to take on all these different disciplines and jobs that would normally be done by some other department, if you were in a bigger company.

Oh, and getting a patent issued was a pretty big high…

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

With the first version of Kerika (“K1”), the biggest blunder we made from a technology perspective was relying upon JXTA.  It seemed perfect when we first came across it: a beautiful architecture for p2p networking that had been designed by Bill Joy himself, which was now an open source project.  However, the project was never really “open” because Sun controlled it too much, and eventually smothered it.  JXTA had a number of critical flaws that we assumed would go away over time, because they were all right there on the product roadmap, but the flaws remained and Kerika 1 was inherently unstable as a result. It was really heartbreaking to see people come on board, get all excited about the product, and then walk away in frustration when they realized the communication and collaboration wasn’t reliable.

The big lesson learned there was: if you are going to use an open-source technology, make sure that (a) the technology already has everything that you think you might need, so that if it never improves in the future you are still in good shape, and (b) the product has a vibrant opensource community with a lot of active contributors.  Something that is open source may yet prove to be the most expensive decision you will ever make.

With K2, we may have made a strategic miscalculation in assuming the product will be used only by small professional services firms, because we are finding unexpected interest in larger organizations.  That’s going to require some changes to our product roadmap.

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 Kerika 2, we have a feature that we originally considered to be considered relatively minor: you can place arbitrary text on a project page.  The original purpose of this feature was to put labels on pages, but we happened to build it with a rich-text editor.  This little feature turned out to have much more appeal than we had every anticipated.

It took me a while to understand what this is all about, but now I realize that formatted blocks of text (containing lists, tables, pictures, etc.) are what I would call “glass-box” documents: you can see what’s inside without opening/launching that document.  There’s an 80/20 rule in effect that much of what people need can be better served with glass-box documents than with black-box documents.  In other words, our “little” feature is actually more important to most users, more of the time, than our “big” feature of offering seamless integration with Google Docs.

On the business front, we originally planned to market the product exclusively to small professional services firms. But we are getting unsolicited interest from enterprises, and supporting enterprises will require some significant changes in our product roadmap.  We are still grappling with this issue.

Q: Do you have some key lessons learned?

  • From Kerika 1: don’t spend too much time on market research.  After some point, you are not discovering anything new; you are just hearing the same points being rephrased in different ways.  Move faster into building your first couple of versions.
  • From Kerika 1: be very careful about what open-source products or libraries you incorporate into your own product.  If the feature is really important, it’s not free.
  • From Kerika 1 & 2: watch users where possible; don’t rely upon them to tell you what they are having difficulties with.  People often don’t articulate problems if they think they will look stupid in doing so, and sometimes people don’t even realize what problems they are having.  With face-to-face contact and conversation you can find out what people want to achieve, which is often different from what they are complaining about.
  • From Kerika 1 & 2: your users will use your product in ways you never considered.  That’s a good thing.  When you are trying to find your product-market fit, remember that you can’t push on a string: you need to find a use case where someone is pulling on the other end.  And if that particular use case wasn’t the one that you envisioned originally, that’s an opportunity not a problem.
  • From Kerika 1 & 2: stay true to your vision, which should transcend details of implementation, strategy or tactics.  Kerika’s vision is about getting people to understand their project’s current state, structure and trajectory.  In terms of path taken to realize the vision, be very flexible: desktop app, Web app, mobile app — these are all different embodiments of the vision, they aren’t necessarily the vision itself.
  • From Kerika 1 & 2: your family are fellow-entrepreneurs.  If they are not 100% behind your idea of being an entrepreneur, you need to exit before you damage your family.
  • From Kerika 2: build your value hypothesis, your discovery hypothesis and your growth hypothesis carefully by identifying all your leap-of-faith assumptions.  Cross-check them for coherence.  You will be surprised at how the corollaries of your various leap-of-faith assumptions can end up clashing against each other.  Once you do that, you will be further surprised to learn that what your startup needs to succeed is not what you read about on TechCrunch, or what you think is “conventional wisdom”.
  • From Kerika 1 & 2: a programmer without an understanding of computer science will build you a prototype very quickly, and possibly cheaply, but will not be able to build you a scalable, robust product.  Algorithms, data structures, etc. are all still relevant topics, no matter how high-level your scripting language.
  • From Kerika 1 & 2: you will almost never fire someone too soon.
  • Overall : I have become much more aware of the need to get all the details right.  Concepts are great, but execution is what matters, and execution is just plain laborious most of the time. I have come to understand that there are no instant successes: every successful company has a revisionist history that makes its founders look unusually brilliant. I have realized that you can fail by misfortune, but are unlikely to succeed by chance.

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

I knew about marketing in general, but not enough about online marketing, or marketing Web Apps or SaaS.  And much of what I had learned about marketing tactics was irrelevant when it came to SaaS.  That said, a lot of the basic concepts about positioning and competitive analysis are still relevant.

I had a ton of business experience, but very little of that was in sales itself.  Where I had done sales before, it was at a business development level: e.g. building strategic partnerships.  I really wish I had more sales experience itself: the hard-core stuff about cold calls, follow-ups, etc.

Q:  You seem focused on global teams and multi-firm collaboration, what do you see coming?  

I think the key phrase is “incessant collaboration”.  That’s because any knowledge-intensive work (software, management, marketing, design…) is based more upon discovery during the execution phase of a project, and less on perfect planning at the start of the project.

Our project tools need to embrace change, because resisting change, or treating it always as a danger to your project model, is simply an unrealistic option.  Consider SharePoint for example: when you create a new SharePoint page, you have to decide what kind of page it is — a document library, a workspace, etc.  Once you decide, you are stuck with that decision.  If your project changes radically — and it surely will — e.g. the entire project gets subsumed by some larger project, or some hitherto small piece (sub-project) grows to swallow it’s parent project, you are pretty much screwed: there’s no easy way to reconfigure your SharePoint pages to reflect the new reality.  And the reality changes every day, because every day you discover something new: you learn more about a particular requirement, you learn more about your competitors, you learn more about your customer needs, something you thought would be easy turns out to be particularly hard or vice-versa.

But SharePoint doesn’t embrace change: rather, it actively resists it.  And it doesn’t support easy management of Web-sourced content, which is increasingly more important than internally-generated content.  These days, the smartest guys in the room are the best curators of Web content, not the best writers of original content.

MS Project’s even worse: it’s basic metaphor is for engineering projects, like building a bridge where the science is exact and you really cannot experiment in mid-stream, but it is used for knowledge-intensive work where your goal is not as precise as “build a bridge across this river at this precise location”, but something vaguer like “connect these two systems/organizations/communities in a way that would achieve this other goal, while discovering and dealing with constraints on the problem as you move along a path that you will have to map out on your own”.

Global teams are much harder to synch up because there are fewer overlapping timezones where you can even communicate on Skype (for example) on a regular basis, and sharing a mental model of the project’s structure, strategy and content gets much harder with cultural and linguistic barriers.

That’s our core focus: we actually believe that asynchronous collaboration is far more important than synchronous collaboration. In other words, being able to catch up on my India team’s work when I wake up in the morning is much more important than being able to chat with them in the evening on Skype, because, by definition, my Skype calls will be limited in duration in comparison to the total workday for me and my India teams.

So, if you are trying to synch up when the other person is not online, what are your options? You have (a) text: someone writes a long email, (b) linear organization tools, e.g. use Google Docs and share a document dump, (c) hierarchical organization tools, e.g. try to synch based upon a common taxonomy of collections/folders.  Text/email is the worse of all options because the thread is lost very rapidly when there is more than one person involved in the conversation.  I can have a very long email thread with you as long as it is just the two of us, but the moment a third person joins the conversation and hits “Reply All”, we are all screwed because there is no telling where that person’s ideas will veer.

Linear organization, which I call the document dump because that’s the basic view offered by, places all the cognitive burden back on the user: here are all the leaves, go ahead and assemble the tree on your own.

Hierarchical organization is better only when the taxonomy is enforced with an iron fist: precise naming conventions, very hard rules about where individual items may be placed, etc.  There’s a whole class of document management tools (e.g. Documentum) that are in that business, and a whole class of users, e.g. people working on a new plane at Boeing, for whom this taxonomy works very well.  But for a bunch of other people, it places a set of unreasonable constraints on the user community.  The hierarchies don’t work because people don’t follow the rules, and people don’t follow the rules because the rules are viewed as peripheral to their core jobs of creating ideas and content.

Kerika believes the visual metaphor offers the least cognitive load, because it is based upon human biology: as babies, we learn to recognize faces and things long before we know their names.  When you look at a Kerika page, you can very easily grasp its organization and flow.  Many users have shared their private projects with me, so I have seen a wide range of styles in operation.  Some people are very hierarchical, and treat Kerika as a way of creating visual folders, others put everything on one big page and rely upon clustering (i.e. spatial organization) to lay out their thoughts.  The interesting thing is that it doesn’t matter what style they use: when I see their page I can, in just seconds, understand what their various projects are about.  And the visual metaphor then becomes a way of accessing their content.  Which means that when I get their content, I get it in a specific, useful, visual context.

When you have multi-firm collaboration, you are dealing with people from different corporate cultures, even if they are all from the same social culture. So you need some very basic, biology-based metaphor that everyone can understand.  If plane designers from Boeing are going to collaborate with a PR agency when their plane is ready for launch, you are going to have a massive clash of styles that will be frustrating for all concerned.  That’s where visual collaboration helps.

Q: How has your perspective changed on the available of Internet connectivity and the possibility for pervasive connectivity?

When I built Kerika 1, one of the reasons I decided to use p2p networking was that I didn’t believe there would be pervasive Internet connectivity soon enough, and I wanted to support offline usage because I envisioned my core user as someone on the road (or a plane) with a laptop.

With Kerika 2, we are not even trying to implement offline usage, because I believe there will be relatively few instances when you truly will be without Internet connectivity, and when that does happen (e.g. you are trapped in a car in a blizzard in the mountains), getting access to your Kerika projects probably won’t be your biggest problem.  It’s like Apple dropping support for floppy disks before any other manufacturer, and then dropping support for CD drives: they are pretty good at skating to where the puck is going to be (although I think they misfired with Firewire).

(I think Google Gears is an example of a solution for a problem that is already disappearing.)

If you have vastly increased communication possibilities, are able to stay online more often (or, at least, whenever you want to), then the signal:noise ratio starts to become a bigger problem.  There’s a ton of content available, a ton of new content getting generated, how do you sort the wheat from the chaff?  I think new business models that address the signal:noise ratio will become very important in the future.  I don’t see enough of that today: every startup is creating its own version of signal and assuming that it isn’t adding to the noise.  (Someone could probably say that about Kerika, too ;-) )

Q: Thanks for your time

Founder Story: Luc Burgun, EVE

Written by Sean Murphy. Posted in EDA, Founder Story

This originally appeared in my “Entrepreneurial Engineer” column in EETimes as “No longer a startup, EVE aims for top tier of EDA players” on Mar-29-2011. I have added some additional hyperlinks in this version.

Dr. Luc Burgun is co-founder and CEO of EVE. He has more than sixteen years of experience in EDA in both engineering and executive management positions. Prior to co-founding EVE, he was R&D Director for Meta Systems, a French company acquired by Mentor Graphics in 1996 that specialized in hardware emulation systems. Dr. Burgun holds a Ph.D. degree in Logic Synthesis from the University of Pierre and Marie Curie in Paris and has been granted six patents. The following interview took place over E-Mail; hyperlinks have been added to offer some additional context.

Founder Story: Linc Jepson, 74ze

Written by Sean Murphy. Posted in Founder Story, skmurphy

This originally appeared in my “Entrepreneurial Engineer” column in EETimes as “Linc Jepson’s 74ze leverages Russian and American engineering talent to persevere” on Jan-18-2011. I have added some additional hyperlinks in this version.

Linc Jepson studied Electrical Engineering at Tufts and after he graduated with his BSEE he was drawn to Silicon Valley’s technology boom in 1997. He worked as an RTL design engineer at several startups including Auravision, Broadlogic, and Believe and in 2002 he travelled to Eastern Europe for two years where he worked for a startup microprocessor company). He returned to Silicon Valley in 2004 to co-found 74ze, a design services firm that leverages Eastern European engineering talent. I sat down with him after a recent Bootstrappers Breakfast to learn more about his entrepreneurial journey; what follows is an edited transcript of our conversation with hyperlinks added for context.

Q: You have a broad base of experience, what kind of work do you enjoy?

I enjoy the fast-pace of small companies, where there is not only the opportunity but the necessity to do all kinds of work. And that work has an immediate and significant impact. Early in my career I was doing clean-slate development, performance research, upgrading and debugging modules of long-gone developers, verification, 3rd-party IP integration, you name it. I didn’t realize it at the time but it was great training for consulting.

Q: Why did you pick Eastern Europe when you left the Valley?

During the 2001 downturn in Silicon Valley I decided to indulge my wanderlust a bit and to get a better feel for the foreign labor market. I had previously worked with a team of engineers in India. I had studied Russian for about four years in high school and college and had a seedling of an idea in mind about starting a services company that would have a portion of its team abroad.

In 2002 I moved over to Minsk and then Moscow for about two years. I brushed up on–OK I greatly improved on–my Russian and found a job doing RTL design in Zelenograd, Russia. Interestingly, the company had been founded by Chinese/Malay investors. I created a CompactFlash controller and a touchscreen interface. I was also making contacts and continuing to think about an outsourcing team.

I had confirmed that there is some exceptional talent there.

Q: How did you decide on outsource engineering as a business model?

We consider 74ze (pronounced 74 Zee) a services firm, first and foremost. We happen to use remote experts when it benefits a project. About a third of our projects never utilize our remote team. In school I studied International Relations as well, for a BA. Working with remote teams allows me to pursue another passion.

While I wasn’t keen on the mercenary perception that many folks have of contract engineers, I knew that there could be improvements made in the outsourcing model. Specifically, most engineers tend to shy-away from verbal or face-to-face communication. It seems easier to be non-confrontational and swap a few emails instead of picking the phone or Skype, but you can delude yourself into thinking that all will be okay. This can be particularly dangerous when you are an outsider of a company. These communication issues are often compounded by cultural issues. Merge a few factors such as a contractor being foreign and also more junior than the client’s counterpart, as is often the case with remote teams, and you often find someone who too often will dodge asking a short, potentially embarrassing question, and try to compensate by putting in more hours.

The fallout from labor globalization can be overcome with stronger communication and more global management experience. It’s not achievable in all stages of development, but someone who work effectively  not only with other engineers in the same building but also with engineers in Krakow or Kiev is growing in value.

Q: How did you get started?

In 2004 I moved back to the US. We incorporated 74ze in Delaware, and then in Russia a few years later, after we had traction. One of our first two jobs was a local one. We had 2-3 people, all US citizens, on site. We only did minor work abroad, such as some analog modeling. The other early job was for a company in Europe. The job was a referral from an existing relationship. That job was done completely remotely. We only met the technical people from the client at a trade show, a few months later, where they demonstrated with our product.

Q: If you are doing RTL design and verification what EDA tools do you use?

An immediate obstacle that we ran in to when we started was the high cost of EDA tools. Right off the bat, this started knocking us out of the running for various contracts. When I was living in Zelenograd, I had used Aldec’s HDL verification tools and had a very good experience with them. After not using them for a few years, because we were using customer tools in the US, one of the guys on our team proposed that we incorporate Aldec’s tools into our next bid.

Over the years, we’ve built up a relationship with Aldec and have grown to rely on their tools quite a bit. It’s unfortunate that we didn’t get much traction in conversations with the other EDA vendors, but I think that we have found a good solution with Aldec Riviera-PRO and a solid partner for moving forward.

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

We’ve shifted more towards verification in the last few years, both in terms of the jobs we’ve taken and also in terms of a conscious decision to solidify our roots in that space. While most of our early jobs were in or involved some design, and we continue to work in this field, we see that the continuing abstraction of testing is creating a very large opportunity. We’ve been honing our SystemVerilog skills in the last few years and have been doing more verification than anything else, lately.

While we are still a mix of full-time and contract-based engineers, we are a pure engineering team with next to no marketing or sales overhead. This means less overhead cost for the client, but also that we don’t have the sheen of the larger companies. When we meet with a prospective client, they meet the lead engineer in the first meeting.

The economy interfered with our plan to cycle a few younger engineers into our team. Our team has a minimum of 12 years of experience, but I expect that we’ll have an internal project running as a testing ground for some junior engineers later this year.

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 increased our role significantly with two clients over a 2-3 year relationship. With one of those companies, we joined to develop a few blocks from spec and ultimately took on a much larger amount of design work as well as key roles in integration and top-level verification. We helped carry them through full chip functional sign-off and final timing closure. The chip worked the first time. The CTO of one of those companies, Mark Indovina, became an advisor.

We nailed the deadline to get a prototype RTL processor core developed for another client, enabling them to meet the deadline for a multi-day meeting with one of their key clients in Japan. We had to make two flavors, optimizing for power and performance constraints.

I am happy that we have grown to the point where it made sense to incorporate in Russia; growing our team there was a significant milestone.

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

Sales. Selling is tough. I came back from Eastern Europe and a bit arrogantly thought that as a skilled group of engineers, we would break into the contractor market easily. I have learned that selling is a process. I am not a salesperson in the least. My father was and I didn’t have much respect for the field, until I tried 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?

I thought that I would be spending a lot more time in Eastern Europe than I have been. We have a senior team there that runs smoothly. The last time I was there I was trying to hire another engineer for a project and was unsuccessful. Salaries were skyrocketing.

We are more local and on-site and less offshore-centric today than I initially envisioned.

Q: What suggestions do you have for entrepreneurs?

Be willing to deviate from your plan; not necessarily from your objective. I think we can (I did) envision the future too much or too specifically, such that you have a hardened mold in your mind and of how something will turn out and then work like hell to fill that mold with your progress. Sometimes there is less resistance to your goal down a parallel path.

Q: Thanks for your time.

Linc Jepson is a long time attendee at Bootstrapper Breakfasts®, and has a brief video interview up at “Linc Jepson: the main reason I come to the Bootstrapper Breakfast

Founder Story Sam Wurzel, Octopart

Written by Sean Murphy. Posted in Founder Story, skmurphy

This originally appeared in my “Entrepreneurial Engineer” column in EETimes as “Octopart helps nearly a half a million people find the part they need every month” on Mar-3-2011. I have added some additional hyperlinks in this version.

I originally made a note to blog about Octopart in October of 2007 and again in April of 2008 as I used them to research part information for various client projects. The interface has evolved over the years but the site offers a very clean and information rich way to search for parts and part information, aggregating content from a number of sites into a single coherent view. The company was founded by Sam Wurzel, Andres Morey, and Harish Agarwal in 2006. All three had a common background in physics and they have brought a level of rigor along with a hacker perspective to part selection that has created a useful and innovative part selection site.

When they announced in January that DigiKey was allowing them to include their catalog in the Octopart parametric search results I realized I needed to do an interview with them. I was able to talk to Sam Wurzel, what follows is an edited transcript of our conversation with hyperlinks added for context. I have included more on the founders’ backgrounds after the main interview to give readers who are interested a window into their diverse backgrounds and low key humor.

Q: Can you talk a little bit about your background

All of us have a background in physics, and physics is what brought us together. Andres and I became friends while studying physics in college and Harish and Andres became friends while studying physics in grad school. Our areas of research were all different; I was working on plasma physics, Andres was working on experimental cosmology and Harish was working on biophysics.

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

In 2005 I read Paul Graham’s essay “How to Start a Startup” and it really changed my perspective that I could start a technology company. I was in graduate school in Boulder but it was becoming clear that the academic path was not the right one for me and I had been looking for alternatives.

Soon after that I sent Andres the link, and we started throwing around ideas for startup companies. In the spring of 2006 I got a phone call from Andres. He was having trouble finding a low temperature capacitor for his experiment and suggested that we build a database of electronic parts and make it easily searchable on the web.

Q: Are there any entrepreneurs in your family or who you interacted with when you were growing up?

Both of my grandfathers were entrepreneurs in their own way: one owned a pharmacy and the other owned a car dealership.

Q: So both ran businesses that had complex inventory management issues?

It’s funny, I hadn’t really thought about it before, but now that you ask I remember working in the parts department of my grandfather’s car dealership. Maybe that gave me some insight into the problems that Octopart solves for engineers and electronics hobbyists.

Q: How did you get started?

In mid 2006, we started writing code and learning about web technologies in the little spare time we had. After working in the lab all day, we would come home and write code on a Linux server that I bought at a yard sale for $50. We would often work until 3 or 4 in the morning. By that fall we had a working prototype and applied to Y Combinator. We got some seed funding from them and incorporated the company at the end of 2006. We launched the site in March of 2007.

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

Today we’ve grown to serve over 440,000 unique visitors per month who are searching for electronic parts. We list the inventories of over 50 distributors, including some of the largest distributors in the industry.

We also have a relationship with Cadence: our aggregated part information is published in the OrCad Component information system.

Q: Octopart is a powerful search tool: what’s the business model? Are you profitable?

Our business model is connecting part buyers with distributors, and the distributors pay for that traffic. We also do display advertising targeted to the electronics industry. We are profitable.

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?

From a technical standpoint, we’re very proud of the back-end system we’ve built to handle the incoming data feeds and the front end system to serve up fast responses to user queries. From a product standpoint, we’re proud that our users find Octopart useful. Getting emails from users who love the site is great.

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

When we started Octopart, we were sure that within 6 months, we would have all the major distributors signed up and we would be overwhelmed with users. In fact everything takes longer than we expect it to. That includes building technology, building relationships and getting users. On the surface, it seems like the problems involved in part search are straightforward: get the data, build a system to keep track of it, and build an intuitive frontend interface. But each of those problems have subproblems, and each subproblem needs to be iterated on quite a bit.

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, the business model and the design of the site today has not changed that much since we first conceived it. The biggest difference between the original vision and where we are today is the time it took us to get here. We still focus on two critical challenges: getting good data from many sources and correlating it into an integrated view of a part, and offering our users an intuitive and powerful interface for finding the parts that they are looking for. Both are hard problems and although we have made a lot of progress I wouldn’t consider either of them to be fully solved.

Q: You must be doing something right if almost half a million people visit every month looking for part information. Thanks for your time

I have included biographical information supplied by Octopart on the founders as I found it very interesting reading.

Sam Wurzel
Sam graduated from Brown University with a Bachelors degree in physics and engineering. He went to graduate school at the University of Colorado at Boulder where left the PhD program with a Masters degree to work on Octopart.

Sam likes to build things. While a student, he spent alternate summers working in experimental physics labs as research assistant and in bicycle shops as a mechanic. In grad school at CU Boulder Sam joined a newly formed lab testing the design of a fusion plasma confinement scheme which one day might be useful in a commercial fusion reactor.  Although Sam liked the lab work, he realized academia was not a good fit for him. So, he started working on Octopart, and eventually left his PhD program to move to Berkeley to pursue Octopart full time.

At Octopart Sam manages relationships with distributors, writes code to handle their data feeds, and works on techniques to normalize the data arriving from many different sources.

When Sam is not working on Octopart, he enjoys running and reading while on public transportation.

Andres Morey
Andres received his Bachelors degree in physics from Brown University in Providence, RI and attended UC Berkeley for graduate school, leaving the PhD program with a Masters degree in physics to work on Octopart. As a grad student, Andres worked on the IceCube Neutrino Observatory – an experiment that uses neutrino interactions in the ice at the South Pole to map cosmic neutrino sources.

While working on various hardware projects for his experiment, Andres spent a lot of time searching for electronic components. Frustrated with the online search options, he called up his friend and fellow grad student, Sam Wurzel, and suggested that they build an electronic parts search engine. After spending several months working on a prototype they decided to leave grad school to work on the project full time and in November 2006 they incorporated as Octopart, Inc.

Since leaving grad school, Andres has been working on Octopart full time. Andres is responsible for most of Octopart’s consumer-facing features including client-side code and all graphical and UI elements. In the course of working on Octopart Andres discovered that he loves working at a tech startup because it is a platform for solving a series of never ending problems from managing human relationships to squashing obscure Internet Explorer bugs. Andres discovered that he loves coding because of the feeling he gets when he finds an elegant solution to a coding puzzle.

Currently, Andres spends his free time thinking about Octopart.

Harish Agarwal
Harish received his undergrad degree from the University of Illinois at Urbana-Champaign in Engineering Physics and a Masters degree from Cambridge University in Semiconductor Physics. Harish left his physics PhD program at U.C. Berkeley with a Masters degree to join Octopart.

Harish enjoys understanding systems and developing projects that work on top of them. As a graduate student in Jan Liphardt’s biophysics lab at U.C. Berkeley, Harish was tasked with studying nuclear transport in eukaryotic cells. Having come from a physics undergraduate education, this involved hitting the books and pestering kind colleagues for advice and gems of wisdom. This crash course preceded many long days at the bench developing biological protocols and a microscopy system to track nanometer scale cargo transit through the nuclear pore on millisecond timescales.

Harish left academia in the spring of 2007 to join two friends in developing Octopart, a search engine for electronic parts. Having come from a biophysics lab to work on an already launched website without knowing exactly what MySQL stood for, this involved a lot of intense on the job learning. In the past three years, Harish has had the opportunity to work on many nooks and crannies of Octopart, from developing front end user features, to hacking search capabilities into open source search engines.

Octopart has been covered in the last year by

Follow Up: Octopart Acquired in Aug-2015 by Altium

I’m very happy to share big Octopart news today: We’ve signed a definitive agreement to join Altium, a leading provider of design software for the electronics industry. Octopart will become a wholly owned subsidiary of Altium and continue to grow and operate independently from our headquarters in New York City.

First things first: this deal is good for Octopart users. Octopart will be increasing the pace of what we’ve always done: opening up access to part data for design, sourcing, and manufacturing. Our search engine will stay free, fast, and open. Our API will remain available to existing and new users. We’ll continue to provide component data in a clean, straightforward way without any pop-up ads or unnecessary forced registration nonsense.

We’re joining forces with Altium because we think we can innovate and grow Octopart more quickly together than apart. We live in a time when electrical engineers, makers, and hackers have high expectations for their design tools and for component search. Octopart users expect rich content like CAD models and reference designs at their fingertips when doing component selection. Users of PCB design software expect supply chain intelligence at hand when they are designing new products. Bringing Octopart together with Altium will make this possible, and more. We envision a future where going from prototyping to production is a seamless experience and we’re going to work together to make that vision a reality.

From the beginning of Octopart we’ve been encouraged and spurred on by our investors, our families, and our friends, and we are deeply grateful for that. Today Altium joins that group which will only accelerate Octopart’s forward motion. 

Founder Story: Eric Deal, Cyclic Design

Written by Sean Murphy. Posted in Founder Story

This originally appeared in EETimes on-line as “Eric Deal bounces back from a startup shutdown to establish Cyclic Design” on Dec-20-2010.

I met Eric Deal, president of Cyclic Design, through the IEEE Consulting Network of Silicon Valley and was impressed by his energy and enthusiasm in bouncing back from one failed startup to begin a second one.

The ongoing recession is encouraging a number of engineers to be more entrepreneurial. I think entrepreneurial engineers will find Eric’s answers insightful. His approach to establishing Cyclic Design as a successful IP company had three key components:

  • He built on his two decades of design expertise.
  • He leveraged his knowledge of trends in the solid state drive (SSD) market.
  • He reframed the problems the recession was causing his prospects as an opportunity he could focus on.

What follows is an edited transcript of our interaction with links added for context.

Q: Can you talk a little bit about your background

I graduated from Texas A&M University in 1992 with a BS in Electrical Engineering. Over the past 18 years, I have worked in digital logic design and architecture on a variety of projects at IBM, Conexant, and Sigmatel.

In 2008 I left Sigmatel to found an enterprise SSD startup called Multixtor as the VP of Hardware Engineering. In this role I defined, designed, and verified the hardware architecture for a multi-channel SSD. Unfortunately, we began fundraising about the time the market crashed, so in June 2009 we decided to pursue other options.

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

In the middle of the recession, I didn’t see any interesting opportunities at local companies, so I took the opportunity to start my own business doing consulting. To differentiate myself (and keep myself busy since few companies were hiring contractors/consultants), I took my expertise with error correction and created BCH IP (the algorithm used for NAND flash) that I could license to companies in need of a solution.

When I left Sigmatel, they were left without an ECC expert. I wondered how many other companies would be in a similar position as layoffs and lack of investment in R&D during the recession; when designs started ramping up again as the economy recovered, they would be left with a deficiency in the ECC of their NAND flash controllers.

I also saw the transition in NAND flash correction block size as an opportunity. The companies I had worked for were designing large SOCs, where they typically had designed their NAND controllers as a highly-integrated portion of a larger IO controller. For these companies, buying a new NAND controller was not a good option since it would require discarding their legacy hardware design and software drivers. It seemed that these customers would benefit most from simply integrating ECC IP into their controllers, preserving this investment.

Q: How did you get started?

I started networking with companies in Austin to determine if I could address this disconnect in the NAND market with a service. My goal was to determine if firms would value ECC as a consulting service. If they did, my plan was to offer a faster time to solution by building on a flexible ECC IP platform. I found my first customer at NXP for their SOC applications. I also promoted Cyclic Design online and became a Design & Reuse partner to improve visibility outside of Austin.

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

There were a few bleak periods, but now Cyclic Design is to the point where we have a few customers and a few more on the way, and it’s getting easier to find and close new business. As a small company, we can provide a high level of service to customers and have the ability to customize the IP in order to better fit their needs. Cyclic Design has also expanded IP offerings to support higher ECC levels for MLC flash as well as providing a solution for SLC devices as customers transition from single-bit Hamming codes to BCH algorithms requiring 4-12 bit correction.

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?

As a designer, it is satisfying to see Cyclic Design’s IP used in a wide variety of applications across the market. It is also pretty incredible to think that with easy access to global communications, Cyclic Design is providing solutions for companies all over the world.

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

Probably the biggest surprise is how hard it is to get potential customers from first contact through licensing. Having a solution that meets an engineering need doesn’t necessarily turn into a successful business relationship.

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?

Over time we learned that our initial ideas about customer demand was a little off, but we were able to learn and adapt our offerings. Now we believe we’ve gotten a better understanding of what most of the customers need, and we have a pretty good handle on what product offerings to do next.

Q: Any other remarks or suggestions for entrepreneurs?

You have to find something you love doing; otherwise, it is really hard to make it through the down times with little to no income or when a client changes direction and decides not to use your product or services. Also, before starting a venture, you need to know how long you can afford (financially) to stick with it before moving to something else; in this respect, a good financial adviser is a great asset.

Q: Thank you for your time.

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.

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 was part of their Keep on Walking campaign. It stars Robert Carlyle in a six minute single take.  I am not a scotch drinker but I found Carlyle’s delivery of the 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: Behind Johnnie Walkers Walk

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.

Quick Links

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