Category Archives: Startups

Time Scales

This post is not about starting and financing small businesses or what some call “lifestyle businesses”. It is about starting and growing venture-funded companies that must never become lifestyle businesses. I’ll ignore the issue of “doing what you love” as you’ll need that in either case.

Your time is “scalable”.

While you can’t be in two places at the same time, you can decide where to focus time and energy. Where you focus your effort can have a large (or small) impact, and so these choices are important. I’m not suggesting wringing your hands over how to structure every moment of your day. I’m sometimes guilty of this sort of obsessive optimization, but it misses the larger opportunity to stop and think about the trajectory of your current and future efforts.

When starting a company, solving a small problem often takes as much time and energy (often more) as solving a big problem. The only difference is your impact. It’s an important realization. Recently, I’ve met a number of entrepreneurs looking for venture financing to solve small problems. With great time and effort, luck, and perfect execution, their impact will still be small.

Having raised capital to solve both big and small problems, I believe that whatever one chooses to work on, it should be a big problem that is inspiring to attempt to solve. Most investors distill this “big idea” principle into the question, “how big is the market for X?”. While this is a fair question, it doesn’t motivate the right answer. Since in many cases a market doesn’t yet exist, the better question is, “what are the implications of X solving this problem?”. Market size and disruption are a big part of the answer, but there are many reasons why choosing a big problem in a big market is better than solving a small problem in a niche market.

1. Impact. Again, your time is scalable. Build things that have a meaningful and positive impact on the greatest number of people. In doing so you will undoubtedly focus on big problems in big markets.

2. Market size. Perhaps most important, targeting a large multi-faceted market allows you to approach the problem from a number of angles and pivot if necessary. While better explained in a different post, it is critical to understand how value is really created in your market (if it is an existing market), the magnitude of that value, and how to disrupt the creation of that value. Also, don’t rely on second-hand data when sizing your market.

3. Motivation. I’ve written about Larry Cheng’s concept of missionary and mercenary leaders, but to attract missionaries, you need inspiring problems that motivate great people to work through intractable challenges. Does the problem remain an inspiration through the emotional highs and lows of building a company?

4. Financial Return. By definition, solving big problems creates more value than solving small ones.

Even if you fail to fully realize the vision of your big idea, it will have been worth trying since the effort and luck needed to build a niche business would have been nearly identical. In other words, given identical time inputs, you have massively different outcomes. In expectation, your impact is greater by attempting to solve the intractable, by attempting big things. Time scales, so make it count.

The Next Big Thingd?

Thingd (Thing Daemon) is building a structured database of every object in the world and then mapping those objects (and associated metadata) to people and to other objects.  The concept is still in its early stages of being realized, but it is a big ambitious idea and one worth thinking more about.

The easy (and slightly inaccurate) way to put Thingd in context is: Facebook organizes people, Google organizes information, and Thingd organizes things.  The lines get blurry though and I’ve written before about how Facebook and Hunch are creating massive collaborative filters that can improve recommendations for ecommerce and deliver more targeted content and ads across the web.

Thingd approaches the problem differently by focusing on the database itself.  It’s basically a utility in the way that twitter has been described as a utility.  It is a product whose core function is so basic that it can power a multitude of applications.  That is the promise and the reason for the excitement.

For example, Plastastic is a game for toy collectors that is built on the Thingd database (by Thingd).  Because it pulls structured data from Thingd, the site enables extremely granular browsing.  For example, you can browse for toys that are only 5.5″ tall.  More importantly, you signal your purchase interest by clicking “Have it” or “Want it” (similar to Like).  By “Wanting” lots of Handpainted Resin toys, Plastastic could show you other toys that people with similar tastes Like.  So, what’s exciting is not necessarily the collaborative filtering, but Thingd’s structured data (as long as it is of high quality).  Assuming an API is released, anyone could leverage Thingd’s structured data to build completely new kinds of web services.

Since Thingd’s database will theoretically include every object, it could empower anyone to very easily become a buyer and (passive) seller via its marketplace.  One could also imagine extending Thingd to other services: consider how Thingd could be integrated with Facebook profiles.  It would be far more useful than Facebook Marketplace.  Using image recognition, the database could also be used to power affiliate services on sites like Pinterest and Aprizi (similar to how Pixazza works).  While an affiliate business model is a first thought, other more interesting models could emerge.

Thingd also launched a platform for mobile developers called productids.org which provides access to >100 million UPC barcodes tied to Thingd’s database.  So, if you’re shopping for a bike at a store, imagine an app that could scan a bike’s barcode with your smartphone and then browse for similar bikes based on the specific attributes you care about (style, number of speeds, material, color, etc.).  You could check prices and availability online and at physical stores (via Milo).  An integration with Google Goggles would be even cooler: take a picture instead of scanning the barcode.

In addition to ecommerce business models, advertisers and publishers might also be interested in connecting to people based on users’ prospective (Want It) and historical (Have It) purchase habits.  As long as the structured data is consistent and clean (very difficult to achieve if attributes are crowdsourced), there is a lot a developer could do with a Thingd API.

The immediate challenge for Thingd is to continue improving the user experience while building and refining its database.  While the experience on Thingd.com isn’t seamless yet, the company recently launched Fancy, which is a lot more user-friendly than Thingd.com in allowing you to tag images and discover new stuff.  Fancy will make it easier for Thingd to collect data on more objects and there’s no doubt the company will be adding features as it rolls out (would be nice to have a bookmarklet for easier off-site tagging; small design tweaks like tiled images and infinite scrolling).

It’s clear that there is no shortage of options for Thingd, so the question will be product focus and execution.  I’m really excited to see how Thingd develops.  It’s working on a truly massive idea.

Coke’s API and the Outsourcing of Innovation

While he may not have realized it at the time, Asa Griggs Candler helped pioneer the “platform” business model used by thousands of web companies today.  But Chandler wasn’t a tech startup guy, he was the founder of The Coca-Cola Company.

Coke became a platform company almost by accident.  Beginning in 1886, Coke was principally sold to soda fountains and Candler saw little demand for bottled Coke.  Couldn’t you just get a Coke at your local drugstore?  Besides, creating a bottling and distribution operation was expensive, and lower-margin.  The Coca-Cola Company had great margins.  They didn’t even make the Coke that people drank.  They manufactured concentrated Coke syrup and marketed the final product.  It was the pharmacy soda fountains that added carbonated water to Coke’s concentrate to make the drink.

In the late 1890’s, Candler was approached by two Chattanooga businessmen who proposed creating a Coke bottling operation.  Candler signed a contract with the two men, giving them control of Coke bottling for one dollar (Candler never actually collected the dollar).  Whether Candler didn’t see the potential for bottled Coke or was nervous about the risks and costs associated with building a bottling operation in-house, the decision was incredibly beneficial to Coke over the long-term.  Coke was able to focus on its two core competencies while the technology and manufacturing processes required to bottle mass quantities of soda developed in parallel.  Coke benefited massively from the greater volume and distribution that bottlers enabled.

APIs provide a similar function in the programming world.  Platform companies such as Twitter have stuck to developing their core capabilities (their syrup and marketing) while enabling others to innovate around the Twitter APIs.  Basically, it’s a licensing strategy.  As of the Spring, Twitter was generating about 75% of its traffic through third-party clients (its bottlers) utilizing the Twitter APIs.

Apple’s app strategy for iOS is another example.  Apple developed a few core applications (iCal, Safari, Mail, etc.) for the iPhone platform and then enabled the creation of hundreds of thousands of applications via the iOS SDK.  This has enabled Apple to create enormous value for its platform without shouldering the costs of building thousands of applications in-house (which it couldn’t do with the same efficiency and creativity of its developer community anyway).

There are of course benefits and dangers to innovating on top of another company’s platform.  Primarily, there is a hold-up problem with this type of innovation.  For example, Coke could hold its bottlers hostage and force the bottlers to pay higher fees for concentrate.  On the other hand, bottlers could threaten to choke off Coke’s distribution.  The way to solve these hold-up problems and to improve manufacturer-supplier coordination is through vertical integration, and that’s exactly what we have seen from both Coke and Twitter.

Vertical integration allows a company to remove coordination problems and reduce costs by bringing the relevant supplier(s) or partner(s) in-house.  Coke did this by acquiring its North American bottling partner in February 2010.  Twitter did this by acquiring complementary functions such as search (Summize) and mobile (Tweetie).  These acquisitions reduced coordination problems for Twitter, enabling them to accelerate development of their roadmap.   Most importantly, both companies were able to maintain focus while enabling the ancillary innovation that would become critical to their long-term growth.

On a much broader level, the trend of outsourcing corporate R&D to venture-funded companies seems to be accelerating.  Steven Kaplan and Josh Lerner wrote a great paper explaining this trend, noting that venture-backed firms are three times as efficient in generating innovations as corporate research.  Incumbent (and upstart) technology companies can take advantage of this trend by providing entrepreneurs with the tools that accelerate innovation: API’s, open source software, and greater access to data/information.

“Should I Get an MBA?” and Why It’s Not about the (any) Degree

There has been a lot of discussion about the best educational background for founders and for those who want to join startups.  Earlier this month, TechCrunch ran an article from Vivek Wadhwa which argued in favor of an MBA education.  Similarly, Vinicius Vacanti (a former banker) wrote a great post, “5 Reasons Why I-Bankers Make Bad Tech Entrepreneurs“.  Steve Blank wrote a very practical and balanced post about whether folks should get an MBA or an Engineering Management degree.  Guy Kawasaki has pegged the value of an MBA to a post-college entrepreneur at negative $250k.

There’s clearly a lot of conflicting wisdom out there.  After reading some of these articles, my initial concern was that some of these perspectives could lead would-be entrepreneurs to question their ability to start a company based on whether they had the right background.  But the concern is misplaced because anyone who could be dissuaded from starting a company based on one person’s opinion probably isn’t ready anyway.

The bottom line is that if you are looking to start a company, formal education matters little: it is about what you can do.  And what you can do – if you’re talking about founding a tech startup – is all about your vision and passion for the product and your ability to execute.  For this reason, if you are deciding where to focus your formal education, I strongly suggest engineering.  As my dad told me, it’s difficult to learn “hard sciences” once you’re out of an undergraduate program (unless you’re building on a background in hard sciences).  While you might pick up a history book for leisure after graduating, you’re probably not going to relax by doing calculus or learning Cocoa.  This is not to say it’s impossible to gain these hard skills once you’re out of college (I’ve had to do a bit of this), it’s just easier to learn these things in an academic setting when you probably have more time and fewer real-life distractions.

I wouldn’t be overly concerned about gaining accounting and finance skills at first – these are very valuable, but again, the core value of a startup is not finance and accounting, it’s the product.  You’ll acquire business skills with experience and if your startup gains traction, you will be in a good position to raise money and attract the talented sales, BD, and finance folks needed to build the product into a moneymaking enterprise.

Assuming you have the knowledge, passion and ability required to start a company, get started on it.  You don’t need to get an expensive graduate degree.  And, if you have an expensive graduate degree, that doesn’t make you any less “able” as a founder or startup exec.  Everyone has innate abilities regardless of educational background and, if you’re building a founding team, it’s your job to find people who complement your abilities.  And if you’re a startup looking for exceptional people, it’s your job to recognize talent independent of a candidate’s pedigree or formal training.  Finding the right people is complicated: use too coarse a filter (Ivy-only, college-grad only, no MBAs, MBA-only) at your own risk.

Open Graph is Facebook’s Beacon Pivot

Facebook Beacon was the company’s much-maligned initiative that captured and broadcast off-Facebook browsing activities to one’s Facebook friends.  Signing up for a service, purchasing a product, adding an item to a wish list – all of these actions were automatically shared.  The way it worked was that the affiliate would call a JavaScript snippet from Facebook that captured and sent the user’s IP address, addresses of the pages the user browsed, and any actions taken on the partner site to Facebook (deleting FB cookies wouldn’t stop their ability to track this info).  This bit of code even tracked those without a Facebook account, assigning them a unique identifier.

Beacon was pulled due to privacy concerns.  The goal for Beacon was to create an ad/affiliate network that would allow Facebook to make specific recommendations based on users’ actions off-Facebook. Beacon was a way to capture users’ off-Facebook actions and broadcast those preferences (implicit recommendations) to users’ friends. The problem Beacon hoped to solve was one of “intent”: people go to Facebook to see what their friends are doing, not to research with the “intent” to make purchases (as when searching on Google).  Without “intent”, Facebook users don’t click on many ads and CPCs are low.  Alas, Beacon’s attempt to remedy the intent problem failed, but that may have been the best thing to have happened to Facebook.

Enter Open Graph
The failure of Beacon forced Facebook to rethink how to solve its “intent” problem and Open Graph is a brilliant if not worrisome solution.  Basically, Open Graph allows publishers to put “Like” buttons next to articles, products, blog posts, etc.  If you’re signed into Facebook, you can “Like” something on the publisher site and that gets posted on your Facebook page with a link back to the publisher.  Users will also see their friends’ actions on that publisher site.  Unlike the soon-to-be retired Facebook Connect, your Likes will not only be displayed in your Activity Stream, but also persistently stored against your Facebook profile.  Since Open Graph supports semantic markup of objects using RDF, Facebook will know that what you like is a book, song, band, etc. and not just a web page (as of today, the API doesn’t support multiple objects per page).  So, the idea is that Facebook learns and stores what you and your friends Like across the entire web.  The Open Graph API not only writes this information to your Facebook profile, but also allows a publisher to read your profile’s Likes in order to customize your experience on the publisher’s site.  As CEO Mark Zuckerberg explains, this would be pretty useful to a concert site looking to tap into the data FB stores against its users:

“…if you like a band on Pandora, that information can become part of the graph so that later if you visit a concert site, the site can tell you when the band you like is coming to your area. The power of the open graph is that it helps to create a smarter, personalized web that gets better with every action taken.”

Why Open Graph will Succeed Where Beacon Failed
The implications of Open Graph are extremely important.  Through user-generated “Likes”, Facebook will become the central repository for your and your friends’ preferences and that information will be used by FB and its partners to make recommendations (sell things) to you on- and, more importantly, off-Facebook.  Like Beacon, Open Graph attempts to leverage users’ off-Facebook actions so that FB can be there when the user has the “intent” to buy that concert ticket.  But Facebook learned its lessons from Beacon’s failed attempt to (some might say) surreptitiously track and broadcast users’ actions.  Unlike Beacon, Open Graph will succeed by giving “control” to users.  Namely, the Like button will get users to voluntarily share their Likes with friends.  Facebook will then use this information off-Facebook at the concert site when the user’s intent is to purchase tickets.  There is no lack of cunning in this Beacon pivot.

It seems Open Graph has all the ingredients for success.  Publishers will implement it to generate more traffic and improve monetization.  Users will enjoy seeing what their friends Like and will generally appreciate a more customized browsing experience.  Furthermore, it’s easy.  Users have been trained to click Like buttons all over the web and since these buttons are the lowest-common-denominator contribution (vs. rating, tweet, comment, review, picture, video, blog post, etc.), the barriers to participating are low.

Implications for the Taste Graph
Open Graph may also have implications for sites such as Hunch that provide recommendations (on- and off-Hunch) based on what other people like you enjoy (what Hunch calls the “taste graph“).  While less sophisticated (and less fun), Facebook’s Like button is similar to the “Teach Hunch About You” questions that give Hunch the data it requires to make recommendations.  Facebook’s clear advantage over Hunch is Facebook’s massive installed base of 500 million users that will attract publishers to implement Open Graph.  Nonetheless, publishers should consider the long-term implications of implementing Open Graph for a couple reasons.  First, by supporting alternatives to Open Graph, it preserves competition and will help drive continued innovation.  Second, Facebook doesn’t have much experience building collaborative filtering systems and it’s not clear whether a simple “Like” system can generate the type of data necessary to deliver effective recommendations (that drive conversions, etc.).

Regardless, Facebook is positioned extremely well.  They provide an increasingly compelling product to a huge and rapidly growing user base.  While it’s not clear whether Open Graph will be widely adopted, more thought and resources should be directed towards initiatives such as OpenLike and XAuth that could counter-balance Facebook’s awesome success.

One Way to Join a Startup and “Try Before You Buy” Hiring Practices

Earlier this week Bijan Sabet at Spark Capital wrote a post, “An inspiring way to join a startup“.  The post describes how a couple of companies in Spark’s portfolio had individuals offering to work for free in exchange for the possibility of a full-time position.  I don’t know what the exact circumstances were for each candidate, but if the candidates were switching industries and this was their first startup, I’m a little surprised that this path is considered unique.  Having lived this process as both a newbie and an employer, below is the story of how I got into the startup world and some thoughts on “try before you buy” hiring based on my experience.

In August 2001, after I had worked for a couple years at JPMorgan (my first job out of undergraduate), I finally decided to quit and join a startup.  I had known since before day one that I didn’t want to make a career out of banking.  To me banking was a two-year graduate school program that would provide much-needed skills in finance and accounting that I didn’t get while studying economics and Russian in college.  By the time I left, I thought I had the wind at my back.  I had been offered a promotion to Associate and naively figured it would be easy to get a startup job.  Wrong.

During my two years at JPMorgan I had been reading everything I could about the NY startup scene and keeping a spreadsheet of all the NYC-area startups.  I had even gone on a few interviews to test the waters.  About a month after I left, I was out in San Francisco visiting a friend and woke up early on September 11, 2001 to catch my flight back to New York.  I won’t recount that terrible day here, but needless to say I was in San Francisco for another week.  Returning to New York many days later, I arrived in a different city than I had left.

This was not a good time to be looking for a startup job.  New York was reeling from 9/11 and the internet bubble had burst.  Then I tore my ACL playing soccer at Chelsea Piers.  Awesome.  The day it happened, I had 24 hours left to send in my COBRA before it expired.  I had the surgery and then focused my efforts on getting a job at Colloquis (then called ActiveBuddy), a developer of natural language software systems.  I had already been following the company’s progress for some time.  To me, Colloquis’s technology was indistinguishable from magic.  I totally fell in love with it and decided I had to work there.  My initial application (through the company’s website) was rejected.  Then I had a stroke of luck and was introduced to the CEO, Steve Klein, through a mutual friend.  Finally, I got a meeting with him.  I remember it well.  Steve was firing questions at me, and at one point he asked, “how much did you make at JPMorgan?”.  I told him and he laughed.  “That’s ridiculous!”, he said.  “You’re two years out of school.  You have no real experience.  Nobody is going to pay you that outside of finance.”  I told him I knew that and that I wasn’t expecting a similar salary.  Of course, the other Colloquis-specific factor at play here was that the company was in major trouble.  Management had been recently replaced and the company was scrambling to close necessary financing.

Regardless, Steve was absolutely right.  Sidebar: there’s no chance in hell that a startup is going to pay someone with no operating experience a six-figure salary.  In fact, if you find a startup willing to pay you a six-figure salary when you have no experience, you should run in the other direction.  They’ll be toast in a year.

Despite my lack of experience, Steve saw how fired up I was and he gave me a shot.  I asked that we formalize the arrangement in a letter.  We worked out an offer letter outlining what my responsibilities would be, success metrics, etc.  While I agreed to work for free he offered to pay my expenses: cell, internet, etc.  It was April 2002 and the company was still trying to close its next financing round.  A few months after I began working, Steve unfortunately had to lay off 75% of the New York office.  It was terrible and those were the worst days, but the short story is that the remaining team turned the company around, built it back up, and we successfully sold Colloquis to Microsoft in 2006.  I started earning a salary around the time Steve pared down the company to five in NY (I was the only person left on the business side plus Steve), and by the time of the sale I was a member of the management team.  It was an amazing experience to have worked with such incredible people and to have lived through all the ups and downs with them.  If there is any lesson to be learned from this it is that sometimes you need to realize that you know nothing – you must take a few steps back before you can start climbing again.

Years later, and having the experience of hiring individuals as an employer, I am a big fan of “try before you buy” hiring practices, particularly for job seekers switching industries.  It’s very difficult to know how someone will perform until they’re actually working.  A period of purgatory gives a company the opportunity to get to know the individual, and likewise.  These trials can take many forms and don’t necessarily translate into working for free.  One path might be to give candidates a discrete paid (or unpaid) project to complete.  In any case, timing and objectives should be laid out in writing beforehand so that both parties go into the evaluation period with the same expectations.  While “try before you buy” is not possible (or even preferable) in many circumstances, it can be an effective tool to ensure that you get the right people on the bus.