Starting Findory Series: The End

By Greg Linden

This is the end of my Starting Findory series.

Findory was my first startup and a nearly five year effort. Its goal of personalizing information was almost laughably ambitious, a joy to pursue, and I learned much.

I learned that a cheap is good, but too cheap is bad. It does little good to avoid burning too fast only to starve yourself of what you need.

I re-learned the importance of a team, one that balances the weaknesses of some with the strengths of another. As fun as learning new things might be, trying to do too much yourself costs the startup too much time in silly errors born of inexperience.

I learned the necessity of good advisors, especially angels andlawyers. A startup needs people who can provide expertise, credibility, and connections. You need advocates to help you.

And, I learned much more, some of which is detailed in the other posts in the Starting Findory series:

In the beginning
On the cheap
Legal goo
Launch early and often
Startups are hard
Talking to the press
Customer feedback
Marketing
The team
Infrastructure and scaling
Hardware go boom
Funding
Acquisition talks

I hope you enjoyed these posts about my experience trying to build a startup. If you did like this Starting Findory series, you might also be interested in my Early Amazon posts. They were quite popular a few years ago.

In The Beginning

The fundamental idea behind Findory is to apply personalization to information. Help people deal with information overload. Help cut through the noise and filter up the good stuff. Help people find what they need.

Personalization can do this using implicit information about your wants and needs, learning from your behavior. Personalization complements search. Search requires people to explicitly provide a query. Personalization surfaces useful information without any explicit query.

Personalization can also be used as a way to improve search. For example, if people are repeatedly refining a query (e.g. [greg linden findory], then [greg linden amazon]), they are not finding what they need. Paying attention to what they have done, especially what they have done recently, and showing different search results to different people can help surface information that otherwise might be buried deep. That is also personalization.

In addition, personalization can be used to improve advertising. Almost all advertising is useless, and annoying. Advertising does not have to be that way. Advertising can be useful information about products and services you might actually want. By paying closer attention to your interests and needs, advertising can be targeted instead of sprayed. It can be relevant and helpful, not irrelevant and wasteful. That is also personalization.

Back when I became really interested in this and wanted to work on it, I was just getting out of Stanford in 2003. Creating a company was not my first plan. I talked to Google, Yahoo, MSN, and Amazon first. The people I talked to expressed interest, but not urgency, and did not want to move as aggressively on personalization as I did.

I believed in the value of applying personalization to information. I wanted to see it happen. While I thought it was inevitable that everyone will be doing personalization of information over the next 5–10 years, I wanted to see it sooner. I started Findory to make it happen.

On The Cheap

When I started Findory, I was extremely sensitive to burn, probably too sensitive.

Maybe having witnessed all the dot com flameouts caused me to be overly cautious, but I wanted to be very careful about money flowing out the door. Many companies do fail early simply by running out of cash. I thought the best way to avoid this was to be careful about spending money.

Findory was built on the cheap. It is self-funded. There is no office space; the company is virtual. There is almost no marketing or advertising.

There are no salaries or benefits at Findory. For most tech startups, salaries dominate the burn rate. Even at 1/3 salary, each additional employee is about $4–6k/month (fully loaded, includes benefits, expenses, office space, etc.) At full salary, it is about $10–15k/month. Salary and benefits would have burnt through initial funding in less than a year.

By the way, it is worth noting that not drawing a salary is roughly equivalent to taking a salary but investing an equivalent amount immediately back in the startup. The latter is a lot more complicated, but both serve to fund the company using the money normally paid in salaries and benefits.

Findory uses free open source software (Apache, MySql, Linux, Perl, Berkeley DB). This allows the company to keep its costs low in its infancy. A quick note here, using Fedora Linux was a mistake. As it turns out, the upgrade path to get patches on major releases (e.g. Core 3 -> Core 4) is quite painful.

Findory uses cheap, leased, commodity servers. Findory currently runs on six servers. The cost per server is under $100/month. They are simple, low end, AMD boxes with a reasonable amount of memory and a cheap IDE disk.

Rather than pay for a news feed, Findory runs its own crawl. That allows us to customize the crawl to our needs and quickly launch new products (e.g. video, podcasts), but does take a fair amount of time to maintain and extend.

In retrospect, I think I have been too cheap. The tradeoff here is between death by burn versus death by resource starvation. While Findory has lived a long time with very low burn, it has been starved of resources, slowing growth and making it difficult to pursue many paths for expanding the products.

Legal Goo

Startups have to do a fair amount of legal goo. Finding a good lawyer is important not just for legal advice, but also business advice and contacts.

It is hard to find good lawyers. If you can, try to find someone with substantial startup business experience in your sector (e.g. internet startups). Talking with someone who understands your business, is excited about it, and can offer parallels to others is extremely valuable.

Unfortunately, legal work is extremely expensive. $400+/hour is not uncommon. While many law firms will delay billing for small startups and may even write off some of the work, lawyers can do major damage to the burn rate.

Even simple things like assisting with negotiating an NDA can cost a few thousand dollars. That can be annoying. Folks at large companies you might be talking to think of legal work as costless or, at least, cost is unimportant. So, biz dev people at big companies are happy to play games all day long with you with legal agreements.

But, in these discussions, each time your little startup needs to turn to your legal team, you rip through the nest egg. More substantial legal issues may cost enough to even threaten the life of a startup.

On the issue of intellectual property protection, Findory did seek patents, but I am not sure I would recommend this path to others. Filing was expensive ($10k+) and extremely time consuming, stealing time and money away from building products, helping customers, and innovating on the core engine. Even worse, I now fear that patents provide little protection for a small startup. Not only do they take years to issue, but also they cost at least $1M and several years to attempt to enforce; clearly that amount of time and money is impossible for a small startup.

There are a few other pieces of legal goo I will comment on briefly. Watch out for conflicts of interest with bigger clients of the firm; Findory lost its first two law firms suddenly and inconveniently when they bailed due to conflicts of interest. Choose your incorporation carefully; LLC or S Corp provides tax advantages, but you need to be C Corp to take some types of funding, and converting can be a bit of a pain. Put reasonable terms of use and privacy policy pages up on your website. Grab related domain names; I neglected to get a common misspelling for findory.com — findery.com — which still causes headaches sometimes. Make sure your intellectual property and ownership agreements are in place for anyone who does work for your firm, including your contractors.

Overall, looking back at my experience, I think a mistake I made in the very early days of Findory was thinking too much of law firm as a mere source of legal advice. In fact, the most valuable interactions with our lawyers were the business advice and connections they provided. Despite the cost, it is worthwhile to find one that can advise you on all aspects of your business.

I want to end by emphasizing that it is important to understand that any business discussions with any large firm are going to be costly for a startup. Not only do you have the risk of disclosing information (regardless of NDAs) to a potential competitor, but also the cost of any legal frameworks necessary for the discussions can be risky for a tiny startup to bear. Be very careful with who you decide to talk to and make sure those discussions are worth the cost.

Launch Early And Often

When I was at Amazon, I was a strong believer in the idea of launching early and often. In our group, new features typically launched in weeks, then were modified repeatedly. Often, projects were completed in just days. Projects spanning multiple months were unusual.

I carried this philosophy over to Findory. Findory was built on rapid prototyping and early launches.

When Findory first started, the company was targeting personalized web search.

A quick prototype revealed the need for more data about user behavior. The recommendation engine reached out to ask, “What have other users done?” and always got the answer, “I don’t know.”

For a brief time, I looked at whether I could acquire the necessary information about user behavior. Were there old weblogs available from major search engines (without restrictions for commercial use)? Would Yahoo consider a deal to share an anonymized sample of their logs? Could I acquire logs from an ISP (as Snap.com later did)? No, no, no.

With some amount of frustration, I abandoned this web search prototype and switched to news. With news, bootstrapping is a bigger issue. Old news is no news, as they say. The advantage some may have from massive amounts of log data is diminished by the need to a good job handling the cold start problem.

I spent some time prototyping a personalized news application. I iterated. Eventually, it looked good in my tests.

I decided to launch Findory.com as a personalized news website in Jan 2004. At that point, Findory did not have its own crawl. Findory did not even have a search engine. But the personalization worked. I iterated on it rapidly over the next few months, launching new versions nearly daily, including a Findory crawl and a custom news search engine.

In June of 2004, I launched a version of Findory for weblogs. The underlying personalization engine had to be adapted for blog articles, articles that are often short, almost always opinion, and frequently crappy. Several iterations on an internal prototype tuned a version of the engine to the characteristics of weblogs. A crawl had to be created to cover the most interesting and useful weblogs. Tools were needed to process new weblogs and filter out spam weblogs (splogs).

With Findory and weblogs, I made the mistake of launching as a separate site called Blogory. It was a foolish decision and one that later would need to be reversed. Blogory is now merged into Findory.

Over the next many months, we iterated, iterated, and iterated. There were several redesigns of the website, all looking to figure out what format worked best for readers.

In May of 2005, personalized advertising launched. Findory’s advertising (which is sourced from Google) is targeted by Findory not only to the content of the page, but also to the specific history of each Findory reader. Findory focuses the ads both based on what each reader is currently doing and on what that person has done in the past.

Now, in 2006, Findory has many products: news, blogs, video, podcasts, advertising, and (alpha) web search. Findory is personalizing information in many different areas.

Looking back, I think a few things are critical for a strategy of launching early and often.

First, you need developer websites, a full testing environment where programmers have a toy version of the website with which they can tinker. To iterate and test, you need to see everything working together in a sandbox environment.

Second, you need some objective test of the ideas, some measure of what is good or bad. You need some way of evaluating the prototypes even if it is not ideal.

One important point is that not all prototypes should be launched. Yes, I know, you worked hard on that thingie. But, many things should be throwaway, just experiments. At Findory, many things did not look good during testing and were abandoned. They were a path not followed. That work is still valuable, mind you. We learned what works and what does not work. That information is valuable even if the feature was discarded.

Finally, I want to point out that the strategy of launch early and often is not without cost. It is true that some people and press looked at early versions of Findory.com and saw things that were still really prototypes. Sometimes, they judged it harshly and never returned. That has real cost. The damage to the brand is not insignificant.

I remain a strong believer in launching early and often for web development. Findory is learning constantly. We get immediate feedback. We get rapid gratification. The benefits far outweigh the costs.

Startups Are Hard

There is no doubt about it. Startups are hard. You have to do everything — and I mean everything — yourself.

You have to do all the technical work, including prototyping, research, coding, web development, design, data analysis, metrics, system administration, networking, hardware procurement, and database administration.

There is marketing, including advertising, press relations, viral campaigns, framing the product, and pitching to influencers.

There is business development, including handing requests for technology licensing, talking about cross marketing deals, exploring feed licensing, and investigating partnerships.

There is management, including project management, building a culture, choosing founders and advisors, hiring, mentoring, setting expectations, and building teams.

There is legal, including creation of and modifications to the corporate structure, non-disclosure agreements, licensing agreements, employee incentive packages, patents, intellectual property assignments, and frameworks for partnerships.

There is finance, including accounting, taxes, licensing, managing cash flow, business planning, and pitching potential investors.

There is customer service, including building help pages, creating customer self-service features, and handling incoming contacts with suggestions, complaints, requests for information, and requests for help.

All this for incredible risk. Often, it is your own money being poured into the company. There typically are no or limited salaries and no benefits.

That incredible risk comes with many rewards. Though unlikely, there is a large potential payoff dangling off at the horizon. Startups are building something new, the exciting tip of the cycle of creative destruction. And, running a startup, you have much freedom in what you decide to pursue.

However, that freedom can be a curse. There are so many degrees of freedom, it can be overwhelming.

What should the company do? Even more important, what should it not do? Does it have enough money to pursue X? Can a competitor better implement feature Y? What really matters to the company?

There are so many options, but so little time. You must keep moving, keep making decisions, but always be willing to stop or reverse if something looks wrong.

You learn a lot, but it is incredibly difficult. It is a remarkable challenge, an incredible experience.

Talking To The Press

I wanted to do a piece on talking to the press. I am a tech geek, not a marketing dweeb, so talking to the press is not my strong point. But, having been forced to do it, I think I have learned a few things.

The biggest thing I have learned is to focus on what reporters want. It seems to me that reporters are looking to write a solid, interesting story, supported by good sourcing and strong quotes. A typical story seems to consist a few paragraphs of explanation followed by some quotes from someone that express an opinion on the reporter’s explanation.

My strategy is to only try to make a few key points. I try to say a few things that describe my impression of the overall situation, intending that piece to help with the explanation that is in the reporter’s own words.

Then, I try to give just two or three pieces of opinion, my view on the situation. At this point, I try to talk slowly and carefully, keeping in mind that the report probably is trying to transcribe an exact quote. Sometimes, I repeat the quote or something fairly similar to the quote.

One other thing that I have found important is that reporters do not always ask the questions you think you they should. That is okay. You can usually take a question that you may feel is poorly chosen or misdirected and simply answer a variant on it that is the question you thought should have been asked. That variant is just as likely to make it into a quote as a more directed answer and may be more appropriate and more useful to the reporter.

Finally, I have found that most press coverage of tiny, little startups like Findory will be positive. After all, if they were going to write something negative, they would not bother writing about Findory at all. Yes, being ignored is an issue, but it is good to know that, when you are talking to the press, if you get any coverage, you are likely to get fairly positive coverage.

Maybe it is working on a news site, but I tend to have a lot of sympathy for the press. I think reporters are struggling with a difficult job and try to help them as much as I can. However, helping reporters is not a selfless act. The more helpful I am, the more likely it is that I get in the story, and any mention of Findory may benefit the company.

Customer Feedback

Findory customer service is light, averaging a couple e-mails per day. They are mostly suggestions, a few requests for help, and a few complaints.

Of the few complaints, the most common are various forms of rantsabout either liberal bias or conservative bias. Partially this is due to our political climate right now where any site at all related to news is bombarded by absurdity from the extreme fringes.

However, accusations of bias also may be due to Findory explicitly trying to not pigeonhole people. The idea of personalized news has been around for a decade or so. One common criticism of the idea is that personalization may pigeonhole people, showing them only what they want to see. On Findory, opinion articles are not selected based on a particular view, with the result that people are exposed to viewpoints they might prefer to ignore.

It is an interesting question whether Findory should have given people what they wanted — let people put on their blinders and pigeonhole themselves — or if it is doing the right thing for the long-term by helping people discover a breadth of information and viewpoints.

On the requests for help, the most common is somewhat amusing. People often expect Findory to be harder to use than it is. It surprises me, but some write in and ask, “How do I set it up? What do I do?”

Perhaps Findory is too simple. “Just read articles! That’s it,” I often say. “Findory learns from what you do.” Everyone has been trained to expect sites to be more difficult — lengthy registration and configuration, for example — and it appears it can be confusing when all those barriers are removed.

On the suggestions, the most common are requests for a feed reader (which we did as Findory Favorites), interest in rating articles and sources (which we have prototypes a few times but never launched because it seems to change the focus away from reading), a desire to see news photos inline on the page (potentially costly, but something we are exploring), extending the crawl (always working on it), and support for non-English languages (prohibitively expensive due to the changes required in the recommendation engine).

Customer feedback is useful. Many Findory features have been implemented as a direct result of suggestions from Findory readers.

However, just listening to customers is not enough. Customers will tend to suggest iterative improvements and request more features. Customers will not offer ideas for big jumps, big ideas, or major new products. Customers will not balance requests for new features against simplicity and usability.

When looking at customer feedback, I find it is important to look beyond the words to try to divine the intent. The best solution may be something completely different than what was suggested.

Marketing

Ah, marketing. Is there anything that techies like less?

It is obviously naively idealistic, but I think we geeks wish marketing was unnecessary. Wouldn’t it be nice if people could easily and freely get the information they need to make informed decisions?

Sadly, information is costly, and the time spent analyzing information even more so. People generally do use advertisements to discover new products and rely on shortcuts such as brand reputation as part of their decision-making.

As much as we might hate it, marketing is important.

Marketing also is absurdly expensive. It is mostly out of reach for a self-funded startup. Though I recognized the need, Findory.com did almost no traditional marketing.

There were limited experiments with some advertising. For the most part, these tests showed the advertising spend to be relatively ineffective. The customer acquisition costs came out to a few dollars, cheap compared to what many are willing to pay, but more than a self-funded startup reasonably could afford.

Even without substantial advertising, for the first two years, Findory grew at about 100% per quarter. Most of this was from word of mouth and viral marketing features.

Findory tried to accelerate word of mouth by focusing marketing time and effort on PR with reporters and bloggers, sharing data throughRSS feeds and APIs, and providing Findory content to websites and weblogs with Findory Inline.

Findory’s growth has stalled lately, casting some doubt on the strategy of pursuing word of mouth and viral marketing alone. Again, the question comes up over whether to spend time and treasure on non-traditional or traditional marketing.

The Team

Building a strong team around a startup is important. No doubt about it, I was slow to build a team for Findory.

Findory was started with a very modest amount of capital, probably too small. The on the cheap strategy meant Findory could not pay salaries or benefits. That made hiring and building a team difficult.

I did not want to bring people on part-time who were not dedicated to success of company, but I could not offer what people need — at least a modest salary — to come on full time.

In retrospect, I should have increased the initial capital invested, paid small salaries, and brought more people on the team. I was too concerned about the burn rate and not concerned enough about getting the right people on board quickly.

I also should have brought on advisors and formed an advisory board. The assistance and connections would have been valuable. Worries about loss of independence and dilution of ownership should have taken a back seat to getting the advice I needed.

Finally, I should have brought an angel on the team. As I learned withour lawyers, the advice and network I would have gained from a dedicated angel would have been as valuable as the funding. A modest amount of additional funding also would have been sufficient to pay 1/3 salaries to a couple employees, easing the build out of the critical early team.

It is ironic. I started Findory because I was passionate about an ideaand loved the speed of execution I gained from my independence. In my excitement, I forgot the importance of sharing that passion with others and depending on their advice.

Infrastructure And Scaling

From the beginning of Findory, I was obsessed with performance and scaling.

The problem with personalization is that that it breaks the most common strategy for scaling, caching. When every visitor is seeing a different page, there are much fewer good opportunities to cache.

No longer can you just grab the page you served the last guy and serve it up again. With personalization, every time someone asks for a page, you have to serve it up fresh.

But you can’t just serve up any old content fresh. With personalization, when a visitor asks for a web page, first you need to ask, who is this person and what do they like? Then, you need to ask, what do I have that they might like?

So, when someone comes to your personalized site, you need to load everything you need to know about them, find all the content that that person might like, rank and layout that content, and serve up a pipin’ hot page. All while the customer is waiting.

Findory works hard to do all that quickly, almost always in well under 100ms. Time is money, after all, both in terms of customer satisfaction and the number of servers Findory has to pay for.

The way Findory does this is that it pre-computes as much of the expensive personalization as it can. Much of the task of matching interests to content is moved to an offline batch process. The online task of personalization, the part while the user is waiting, is reduced to a few thousand data lookups.

Even a few thousand database accesses could be prohibitive given the time constraints. However, much of the content and pre-computed data is effectively read-only data. Findory replicates the read-only data out to its webservers, making these thousands of lookups lightning fast local accesses.

Read-write data, such as each reader’s history on Findory, is in MySQL. MyISAM works well for this task since the data is not critical and speed is more important than transaction support.

The read-write user data in MySQL can be partitioned by user id, making the database trivially scalable. The online personalization task scales independently of the number of Findory users. Only the offline batch process faced any issue of scaling as Findory grew, but that batch process can be done in parallel.

In the end, it is blazingly fast. Readers receive fully personalized pages in under 100ms. As they read new articles, the page changes immediately, no delay. It all just works.

Even so, I wonder if I have been too focused on scaling and performance. For example, there have been some features in the crawl, search engine, history, API, and Findory Favorites that were not implemented because of the concern about how they might scale. That may have been foolish.

The architecture, the software, the hardware cluster, these are just tools. They serve a purpose, to help users, and have little value on their own. A company should focus on users first and infrastructure second. Despite the success in the design of the core personalization engine, perhaps I was too focused on keeping performance high and avoiding scaling traps when I should have been giving readers new features they wanted.

Please see also a post on O’Reilly Rader, “Database War Stories #8: Findory and Amazon”.

Hardware Go Boom

Computers go down, a lot more often than we might like.

For most of Findory’s four years, it ran on six servers. In that time, those servers had one drive failure, one bad memory chip, and four power supplies fail.

Of these, only the two power supply failures caused outages on the site, one of one hour and one a painful eight hour outage. There were a few other short outages due to network problems in the data center, typically problems that took the entire data center offline temporarily.

Findory’s six servers were all cheap commodity Linux boxes, typically a single core low-end AMD processors, 1G of RAM, and a single IDE disk. Findory was cheap, cheap, cheap.

The reliability of Findory over its lifetime was perfectly acceptable, even quite good compared to other little startups with similar levels of traffic, but I think it is interesting to think about what may have been able to prevent the outages without considerable expense.

Surprisingly, RAID disks would not have helped much, though they would have made it easier to recover from the one drive failure that did occur on a backend machine. Better redundancy on the network may have helped, but would have been expensive. Splitting servers and replicating across data centers may have helped, but would have been both expensive and complicated for a site of Findory’s size and resources.

Probably the biggest issue was that Findory did not have a hot standby running on its small database. A hot standby database would have avoided both the one hour outage and the eight hour outage. Those outages were caused by losing the first, then a second power supply on the database machine.

Looking back at all of these, I think it was particularly silly not to have the database hot standby. The cost of that would have been minimal and, not only would it have avoided the outage, but it would have reduced the risk of data loss by having a constant database backup. I almost added the hot standby many times, but kept holding off on it. While I may have mostly gotten away with it, it clearly was a mistake.

Other thoughts? Anyone think it was foolish not to run in RAID and not to be split across data centers? Or, maybe you have the opposite opinion, that small startups should not worry much about uptime and small outages are just fine? How about the hardware failure rates, are they typical in your experience?

Funding

I had the wrong strategy with trying to get funding for Findory. I pursued VCs instead of angels.

I should have realized, VCs would never fund Findory. From their point of view, there was just too much risk.

Findory was lead by a first time entrepreneur and was missing critical expertise in building a company. Findory lacked a full team; in particular, there was no finance, marketing, or business development talent. And, Findory had an unproven technology — a specific technique for personalizing news, search, and advertising — that is difficult for a VC firm to evaluate.

Had any one of these three been different, there might have been a better chance. A proven founder may be able to get funding with nothing more than an idea on a napkin. A strong team ready to go is an attractive investment for a VC. A proven technology that just needs the wind of capital behind it is an easy bet. But, with all three missing, there was never much of a chance.

Perhaps in the frothier SF Bay Area, this might have been different. Perhaps someone might have taken a gamble. In Seattle, there are only a half a dozen VCs doing substantial internet investing; most firms out of Seattle will not fund without a local firm joining in the round.

I did pitch dozens of venture capitalists in and outside of Seattle on Findory. It was a fascinating experience, educational, exciting, and often humbling. But, ultimately, I have to say it was a wasteful distraction from building things to help Findory readers.

I should have focused on angels. Not only would angels have brought the right amount of cash for short-term needs, but also the addition of experienced angels to the board would have provided valuable advice and connections. It would have been just what Findory needed.

I had thought that, with how far I had bootstrapped Findory, that I could skip a step and jump directly to VCs. That was foolish. Findory remained a long way from the point where the momentum would be so obvious that it would overwhelm the other concerns.

Instead of looking to VCs, I should have looked for an experienced angel, someone passionate about personalizing information, who would have given the startup the advice it needed while enjoying the experience of joining with us to grow the company.

Please see also Paul Graham’s article, “A Hacker’s Guide to Investors”.

Please see also Paul Graham’s article, “Why There Aren’t More Googles”, especially his discussion of VCs as tending to be surprisingly “conservative” and “driven by consensus”.

Acquisition Talks

At various points when I was running Findory, I approached or was approached by other firms about acquisition. For the most part, these talks went well, but, as with many experiences at Findory, my initial expectations proved naive. It gave me much to contemplate, both for what startups should think about when entering these talks and changes bigger companies might consider in how they do acquisitions.

For a startup, acquisition talks can be a major distraction. It is time away from building features for customers. It creates legal bills that increase burn rate. It distracts the startup with nervous flutters over uncertainty over the future, potential distant payouts, and the complexity of a move.

Acquisition talks also can be dangerous for a startup. Some companies might start due diligence, extract all the information they can, then decided to try to build themselves.

There is some disagreement on this last point. For example, Y-Combinator’s Paul Graham wrote, “What protects little companies from being copied by bigger competitors is … the thousand little things the big company will get wrong if they try.” Paul is claiming that big companies have such poor ability to execute that the danger of telling them everything is low.

However, big companies systematically underestimate the risk of failure and cost of increased time to market. For internal teams, which often already are jealous of the supposedly greener grass of the startup life, the perceived fun of trying to build it themselves means they are unreasonably likely to try to do so. Paul is right that a big company likely will get it wrong when they try, but they also are likely to try, which means the startup got nothing from their talks but a distraction.

There are other things to watch out for in acquisition talks. At big companies, acquisitions of small startups often are channeled into the same slow, bureaucratic process as an acquisition of a 300-person company. Individual incentives at large firms often reward lack of failure more than success, creating a bias toward doing nothing over doing something. In fact, acquiring companies usually feel little sense of urgency until an executive is spooked by an immediate competitive threat, at which point they panic like a wounded beast, suddenly motivated by fear.

Looking back, my biggest surprise was that companies show much less interest than I expected in seeking out very small, early-stage companies to acquire.

As Paul Graham argued in his essay, “Hiring is obsolete”, for the cost of what looks like a large starting bonus, the companies get experience, passion, and proven ability to deliver. By acquiring early, there is only talent and technology. There is no overhead, no markups for financiers, and no investment in building a brand.

Moreover, as the business literature shows, it is the small acquisitions that usually bring value to a company and the large acquisitions that destroy value. On average, companies should prefer doing 100 $2–5M acquisitions over one large $200–500M one, but business development groups at large companies are not set up that way.

There is a missed opportunity here. Bigger companies could treat startups like external R&D, letting those that fail fail at no cost, scooping up the talent that demonstrates ingenuity, passion, and ability to execute. It would be a different way of doing acquisitions, one that looks more like hiring than a merging of equals, but also one that is likely to yield much better results.

For more on that, see also Paul Graham’s essay, “The Future of Web Startups”, especially his third point under the header “New Attitudes to Acquisition”.