"The only difference between a problem and a solution is that people understand the solution." | ||
| --Charles Kettering (American inventor) | ||
"Problems cannot be solved at the same level of awareness that created them." | ||
| --Albert Einstein (German-born American physicist) | ||
If any chapter in this book is more important than any other for creating a successful startup, this is it. Much of this book deals with getting your startup where you want to go; this chapter is about deciding what your software will do to get you there.
In this chapter we focus on what your startup is going to be about and on how to decide what value your startup delivers to your customers so that they will give you money, attention, and support.
Ask most people in this industry how to decide what your startup should build, and more than likely you'll get some variation on "Find a problem people will pay to have solved and solve it."
I asked one of the more intelligent, thoughtful, and experienced people Iknow in the business, Microsoft's Don Dodge (whom we met in Chapter 1), where to find a really great idea. He replied, "I like to say, is your product a vitamin or a painkiller? Vitamins are nice to have, but pain killers, you got to have it, right? So, the nice-to-haves in bad times, the nice-to-haves just don't cut it, because people aren't going to spend time or money on things that are nice to have. They are going to focus on real pain points and just spend time and money on things that solve a problem that they have."
"There is another set of ideas that don't really solve a problem at all, and they are not a vitamin or a pain killer—they are more like a happy pill."
Happy pills? What's that got to do with startups?
Don replied, "Happy pills are things like YouTube or Facebook—they don't solve any particular problem, they just make you feel good. Or games, online gaming, that kind of stuff—it doesn't solve a problem, it is just fun and entertaining. One of them is solve a pain point and bring a service that solves that pain. Another is bring services that save money, that can save time or money.
"A third way is what I broadly call entertainment—things that make you feel good, social networks, games, online gaming, dating; online dating is probably one of the biggest businesses on the Web that is legal, other than porn or gambling. So, there are huge opportunities in those areas. You just have to do something that's unique and different, easier, faster, cheaper, something."
Now, these are good answers—and they beat the answer to build a startup like the one you read about this morning in TechCrunch. But they are just the beginning of getting a clear view of this stuff. "Solve a problem" doesn't tell you how big or small that problem should be (AIDS in Africa vs. a code library that makes it easy to interface with PayPal from Rails). It doesn't tell you what kinds of problems make sense for you to tackle, and it doesn't give you a theory that let's you reasonably say, If I want to do this, I'll need to do this and this to succeed. And it does nothing to help you define the value that will be the core of your startup.
Value? Value is one of those words with multiple meanings. In this context, we're talking mostly an economic definition: the market worth of a commodity, service, asset, or work. Put another way, it's what makes an Apple iPod worth more than a Microsoft Zune, why you'll pay dearly to live in one location rather than another, and why investors will fund and people will buy what your startup is providing.
But before we get into how to how this value thing works, we need to take a slight detour to see how a theory might simplify the job of finding a startup idea. What we need is a highly concrete example, something as solid as a rock, of how a theory can make a huge difference in what results you and your startup will achieve. And for that we need to talk to Wally.
Wally Wallington is a retired carpenter in Lapeer, Michigan, with 35 years' experience building things. Wally is also a guy who, using nothing more than wooden tools, figured out how to move a 1-ton concrete block by himself, then a wooden barn, and then 2- and 10-ton concrete blocks into a replica of Stonehenge (Figure 2-1)—by himself, without wheels, rollers, ropes, hoist, or power equipment or anyone else's manual labor.
How the hell does a single man move a 10-ton concrete block? He starts by knowing a few laws of physics, and he thinks about it for a bit. "The simple laws of physics are most helpful in moving large objects, inertia creates stability, momentum keeps things working, and kinetic energy slows things down so they can be controlled. By creating conditions, using some engineering skills, and math for weight and balance," said Wally.
Note
There is nothing more practical than a good theory. Information is good; information that gives you a handle on some aspect of how the future is going to play out is much, much better. Regardless of what kind of startup you're building, knowing certain theories that have some empirical evidence going for them, such as Chris Anderson's The Long Tail, Alvin Toffler's Third Wave, and th cluetrain manifesto is a Good Thing.
In honor of Wally, over the next few pages we're going to talk about a way of thinking about what value your startup is going to bring to the table—not because Wally's a startup (he's not) or because building startups obeys the laws of physics at the macro level (it doesn't). But there's a set of rules that make sense at play here. What's more, understanding those rules and relationships is going to give you a big head start to applying them to your startup, instead of cargo-culting what others do.[16]
Let's start with the components of this Startup Law, the first one being the problem (Figure 2-2).
To state the obvious, here are a few things we know about problems.
They have attributes: these can be anywhere from simple to mind numbingly complex, as large as climate change to as small as getting the drop shadow right on an image in a blog.
They have duration: a problem can be as old as history (meeting a mate) to as new as last week (protecting Twitter accounts from being hacked).
For some people—maybe everybody, maybe Japanese teenagers, maybe one guy who happens to be in charge of a piece of machinery that makes a specific kind of auto upholstery that goes into the side door panels of Mini Coopers—this thing is a thorn in their side, a rock in their show, an itch that needs scratching.
Hang in there, this is where it starts to get interesting, mainly how your startup is going to make money.
How much your software can solve that problem, fix it, improve it, lessen it, or make it go away defines the value of your startup (Figure 2-3). Whether the problem is that personal financial record keeping is a pain (Mint.com) or that you can't manage time if you don't log it (RescueTime.com), to name a couple of examples from Chapter 7, to the degree these startups solve the problem, they create value, and that creates at least the opportunity to generate revenue.
All too often, developers will solve a technical problem so obscure that few people really care about it (see the later sidebar "Ten Startup Ideas Not to Do, and Why"). Those problems just don't have enough potential customers to make them significant as the basis for a startup.
It's all about moving that problem. Fine. But how do you solve that problem? That's where the next part of our theory comes in.
You solve a problem with resources (Figure 2-4). For startups, that means everything from you and your other founders' technical expertise, to the money people invest in your company, to your knowledge and understanding of the problem, to the marketing you do to find and connect to the people who care about this particular problem. These are the building blocks of your software solution to the problem, that thing you're going to build so that people want to pay you to make the problem go away or at least to get smaller.
Connecting your resources to the problem takes time—maybe a weekend coding marathon, maybe seven months building a prototype so that you can get enough resources to really tackle the problem, maybe years and years if you work on your startup in your nonjob time, an hour here, a half-day there.
But resources are only half of what it's going to take to move that problem and create something of value. Let's now introduce the last piece of this particular puzzle.
Just as with Wally's 10-ton concrete blocks, you need a fulcrum to make things happen for your startup (Figure 2-5). Joel Spolsky calls it the secret sauce. It's that surprising, remarkable, innovative "something" that differentiates your product from all of the other solutions to a given problem. Here are a few kinds of the components that build a good fulcrum.
Disruptive technology. The problem? Not enough servers—be it to run a growing online business or to host a thousand such businesses. Servers and their cost were a big problem for startups and others back during the dot-com era. Then along comes virtualization, the rules change, and the problem is, if not solved, then taken down a few notches.
Originality/creativity/innovation. Call it what you will, it's the spark of genius that makes the difference between a solution that solves the problem the same old, tired way and one that changes what people thought was the solution to the problem.
Deeper understanding of the problem. Just about every programmer can code a basic content management system (CMS). But do you understand your intended market—be it a vertical market such as car repair garages, solo-practice podiatrists, or sports-mad soccer fans—so well, so deeply that you know exactly what that market wants and yearns for?
Design. The world is full of ugly software. I know because I've written my share of it. Awkward workflows, unpleasant screens, and the like can be overlooked when there's no other choice for getting the job done; your app could be that choice. This goes deeper than attractive web design—it gets into building an app that works better to solve a given problem than its competitors.
Disruptive business model. Sometimes the innovation isn't in the software; it's in the infrastructure around the product. For Apple, the secret sauce wasn't the MP3 player; it was the free iTunes app and being able to browse and buy music easily online for a reasonable price, song by song. For
Mint.com(see Chapter 7), the secret sauce was the idea of getting credit card companies and the like to pay for your online personal finance program.Combining unlikely things. Take the accelerometer from your car's airbag system and add it to your game console, and you have the Nintendo Wii and a runaway success. Take the power of an online application and combine it with the brevity of a Short Message Service (SMS) message and you have Twitter. As the world gets more complicated, surprising, and sometimes wildly successful, solutions can be created by combining unlikely things.
A new platform. As we saw with the Apple iPhone and then Google Android, new platforms create leverage for relatively old ideas. We'll have a lot more to say about this in Chapter 3.
There's one more element of Wally's Startup Law: the lever. In the preceding figures, I labeled it time: the time it takes to build a product, to find and connect and build a market, the time before others come up with their own take on the problem.
It can also be thought of as how long you as the founder are prepared to make slow and steady progress, how long your angels/VCs are prepared to fund you before cutting off your oxygen, how long before the problem changes, becomes irrelevant, or dwindles in importance.
Wally's Startup Law is not a real law: don't look for a bevy of neat equations or well-designed algorithms here. What the last few pages do is give you a reasonable theory to explain and predict how this particular dynamic works and therefore some idea of how things work for actual startups.
Let's look at a few of the implications of this theory we've just slogged through, especially how those implications work in reality and constrain or liberate your startup.
Big problems need lots of resources; not so much small problems. If you're going to move a big problem, such as letting people talk to each other via the Internet (VoIP), you are going to need resources, and lots of them. Consider Skype: founded by Niklas Zennström and Janus Friis using the proceeds from selling the peer-to-peer file-sharing network KaZaA, it went through another $37.4 million of VC money as it grew from a few thousand users to a whopping 405 million user accounts as of Q4 2008.[17] Oh, and along the way (September 2005), Niklas and Janus sold Skype to eBay for $2.6 billion.
Niklas and Janus started with a very large resource base of money in the bank and the fulcrum of extremely deep knowledge of how to build a peer-to-peer Internet transmission network. Given this nearly unique starting point, they could tackle a huge problem experienced by hundreds of millions of people all over the world.
The bigger, smarter, and better your fulcrum of ideas, the fewer resources you will need to move the problem you are tackling. Take the case of RescueTime, which we look at in depth in Chapter 7. Tony Wright and his two cofounders created a large and powerful fulcrum for their time management startup by realizing, even before the software was built, that the information RescueTime collected for its users and aggregated anonymously provided jaw-dropping surprises, surprises that got RescueTime press (TechCrunch, New York Times, BBC, BusinessWeek, etc.) other companies would happily kill for. RescueTime started as a self-funded startup, soon got $20,000 as seed money from Y Combinator, and, in September 2008, got $900,000 in Series A funding.
You need a fulcrum. Without some sort of fulcrum advantage—a deep understanding of the problem you are trying to solve, a remarkable approach to the problem, a disruptive technical advantage, or all three—it's going to be hard to move the problem and create value, regardless of how much time, effort, and money is committed to the other end of the lever. This antipattern (see the later sidebar "Ten Startups Not to Do, and Why") has been repeated time and time again, most recently with online video, white-box social networks, and micro-blogging platforms. In each of these cases the first startup in that space (YouTube, Ning, or Twitter) had a huge fulcrum comprising new social needs and disruptive functionality relative to what existed up to that point. Their competitors, when compared to these "first movers," don't enjoy the same kind of leverage or customer base.
The more specific the problem, the fewer resources are needed to move it. Consider 37Signals. Begun as a Chicago-based web design shop, its first web app grew out of a need for just enough online project management to get the job done. That product—Basecamp—in turn became a giant fulcrum as the part-time contractor hired to work up Basecamp extracted as an Open Source project an elegant and robust framework (Ruby on Rails) that has become a major foundation for web application development.
One good use of a theory such as Wally's Startup Law is to see how what you want to do measures up. Here's a short checklist of questions to help you evaluate ideas around which to build your startup.
Is the problem too big for the resources you can apply to it? If so, how are you going to change the equation to be more in your favor? Reduce the scope of the problem? Improve your fulcrum of unique/disruptive/innovative ideas and insights into the problem? Get more resources—more time, more partners, more funding?
Is the problem too small, given the resources and insights you have? Sometimes you can overkill a small problem while leaving it's larger (and more profitable) relative in the wild.
Is your fulcrum large enough to move the problem and thereby create real value? This is another way of asking if your idea is remarkable enough to gain the attention you want. Or will bloggers, investors, and, ultimately, customers find it wanting? Better to have this heart-to-heart meeting with yourself or your partners than to face it after putting 5,000 hours of work into it.
What components do you have, what are you missing to make this proposition work, and how will you secure what you need? For some startups, it's nailing down just how you and your partners are going to commit to the time needed to build 1.0; for others it's where to find someone who can sell your enterprise software to Fortune 500–size companies. Given what the problem is, who has it? And how do they decide what to buy? Do you have what you need, or can you get it?
Is there going to be enough value in this startup to get the resources you'll need? If you're going to need equity funding to get this idea off the ground, is there enough value to enough customers to give your angel investors 3 to 10 times their money back in, say, three years, and return 10-to-the-sky's-the-limit return on investment for VCs? The money guys are going to want real evidence here. Do you have it?
Is the lever going to work? Here's a subtle gotcha: You're all fired up to build a startup to take advantages of and sell to the users of a brand new platform. So you find funding and spend 18 hours a day in hand-to-hand combat with that new platform, only to emerge with your beta to discover that the million-unit first-year estimate cheerfully predicted by the platform vendor is looking like 30,000, most of those returns. Oops! And before you say it could never happen to you, I must tell you that it happened to me when Apple brought out the incredibly cool, hip, sleek . . . Apple Newton.
Sometimes it pays to look before you leap onto the latest and greatest platform.
This is a starter list of questions. Use it to grill—like the popular BBC show The Dragon's Den[18]—your prospective ideas before they get your time and money, let alone anyone one else's.
For most developers interested in building a startup around solving a given problem, that problem is very near at hand. When I talked to Tony Wright, the founder of RescueTime, the problem came from his and his cofounder's frustration with how the time management problem had been solved up until then.
"It was born out of our personal inability to understand how we spend our time," Tony said. "Every day we had a scrum agile meeting. We're a bunch of software geeks. Everyone's job was to say what they'd accomplished in the last 24 hours and what they were going to do in the next 24. We found that people's ability to articulate what they'd done, literally, just in the last work day, was terrible. People would say, well, I felt busy but I can't really articulate what I did.
"We wanted to understand that, but we recognize that despite all these time management books that say keep a log of how you spend your time, that's incredibly impractical for a technology worker who's shifting between applications and web sites, sometimes in 10-, 20- second blocks. We want something that was totally passive that would answer those questions for us and for our business without actually requiring data entry, which is no fun."
For two of the four founders of Brisworks (a client of mine)—which makes and sells Admin Arsenal, a Windows system administration tool—the problem was the frustrations they were experiencing as system administrators: "After years of seeing the bleeding, we decided to make the bandage. Upshot: We know from firsthand experience what sysadmins need," said Shawn Anderson. "We knew how expensive and overly complex most systems management solutions were. We saw a market for a simple, yet powerful solution," added Shane Corellain.
"I'm more evidence that the best products come from simple need," said Corey Maass. "My main product, dubfiler.com, is still in development, but has received a lot of good attention from the right people. Meaning the people I made it for—other producers, DJs, and musicians. We all share files constantly, but were tired of file-sharing sites. I said, 'Why not make the perfect one?'."
Sometimes you can spot the problem just by looking at an existing situation from a different point of view. "I was outside having a smoke break, looked into the offices at the computer screens displaying the default Windows logo screensaver, and thought, 'You'd think they'd have their own logo on there,'" added Steve Grundell, whose Any Logo Screensaver Creator at http://www.anylogoscreensaver.com brings in a tidy profit each and every quarter.
Often, defining the problem comes from doing something for someone not so technically orientated and thinking there's got to be a better/easier/cheaper way for nonprogrammers to do this. "I got the idea last year [for his startup, http://www.artists-portfolio-creator.com—see Figure 2-6] after years of helping my mum (who is an artist) make presentation CDs for when she wanted to make gallery submissions," Stephen Fewer told me.
"I have been self-employed in an unrelated area of computers for nearly two years and have always wanted to run a microISV and hopefully get another revenue stream coming in, so I had a 'light bulb moment' one day that their was a gap in the market and I could write a great piece of software to do what I had been manually hacking together previously. I thought if I could make it easy to use with great features, every artist who exhibits could want it :).
The idea for your startup might walk up to you at your day job, as it did for Simon Shutter. "The idea originated when I was hired by an engineering consulting company to review commercial calendar/scheduling software. The basic requirement was to be able to see at a glance the calendars of several team members six weeks to two months into the future. They liked how they could view multiple calendars in Outlook but didn't like how information in Outlook disappeared into the calendar grid when more than a few calendars were displayed.
"At the end of the contract I gave them my opinions on a range of commercial products and also presented a concept that was more in line with their requirements. They liked the concept the most and so I turned it into a microISV app (Schemax Calendar, at http://calendar.schemax.com/default.aspx).
Or you might get your startup idea when you realize you're not the only person facing a problem. "That was four years ago, while filling out my state taxes online. Realized that even a pro couldn't make a web form right," said Cedric Savarese about his startup, FormAssembly (http://formassembly.com).
"I find that to have good ideas I need to be working on some problem," said Y Combinator founder Paul Graham in a 2005 blog post. "You can't start with randomness. You have to start with a problem, then let your mind wander just far enough for new ideas to form." Paul is a very smart guy who's put a great deal of thought, time, and energy into what it takes for a startup to succeed.
Ten Startups Not to Do, and Why
Just as there are trusted patterns of software design, such as Model-View-Controller, that have proven themselves to work over time, there are antipatterns of startup design that time after time disappointed would-be founders, angels, and investors. Now, if your startup fits into one of these antipatterns, maybe you're the exception that's going to break the rule; but you'd better know why you're the exception. Hope is not a plan.
The Me-Too! startup. Twitter client startups are being written up in TechCrunch and elsewhere as their founders get funding, go to great parties, and start eyeing expensive cars. Therefore, we will do a Twitter client. For Twitter client, substitute "social media web app," "crowd-sourced video site," "enterprise CMS," "semantic web," "iPhone ad network," and so forth. Nothing wrong with these kinds of apps, but code monkey-see, code monkey-do works for most primates and some VCs—it's a lousy way to pick a business to be in for the next three to five years at least, if you succeed.
The Designed-by-Committee startup. It's easy to spot this kind of startup: it's got the latest hot social media, crowd-sourced, Long Tail features for the early adopters and training wheel wizards for the late adopters. It's the triumph of configuration options because the designers didn't want to say no to anything or anyone. In short, it's an app—web, desktop, mobile—that tries too hard to be all things to all people.
The Port startup. This is most often seen among desktop startups, but it's also fashionable among iPhone startups. The formula is simple: pick a program on one platform that's successful (it may be your company's or another's) and port it to a different platform—Mac to Windows, Windows to Mac, whatever. Do the port in such a way as completely to ignore the sensibilities and expectations of the market you are porting to. This is how web apps that mimic, say, Microsoft PowerPoint (except they're slower) come into being.
The PR-First startup. Every so often a startup bursts on the scene, trumpeted by amazing claims that should have the giants in the industry quaking in their shoes. Well, no. Some startups are able to generate publicity in far greater amounts than their apps warrant. Sometimes it's the "Microsoft Outlook Killer" Chandler Project[19] (six years in the making, no big deal) (Figure 2-7) and the "Google Killer" Cuil[20] ("Anybody who thought [Cuil] was this Google killer can really see now that, no, that's not going to happen today—and the likelihood is that's not going to happen a year from now," says Danny Sullivan, Internet search guru and editor-in-chief of SearchEngineLand).
The Outsourced startup. This is a startup that outsources not just the functions secondary to its core product, such as accounting, PR, and tech support, but then outsources the core development and coding of their application because either that's what large corporations do or that's what Angel Investor X or VC guy Z says they'd better do if they want funding. First off, while developers and development shops in India, eastern Europe, and elsewhere can code every bit as well as programmers in the United States and Europe, they (except the ones busy launching startups) are set up to implement code, have not come up with the vision in your head. Second, if they can somehow turn your hand-waving mockup into a real application, why do the money guys need you?
The By-the-Bootstraps startup. Try this experiment: Put on a pair of boots and find a stairway heading up. At the foot of the stairs grab the back of each boot with a hand; then in that position, jump to the first step. If you make it, jump to the next step, still holding your bootstraps. It can be done, but it's very hard, awkward, and prone to failure. Bootstra pping —building a startup while working full time—can be done: that's how I built
StartupToDo.com[21] and how many others have built their startups. But it ranks on the Pain scale somewhere between getting a tooth pulled and getting your fingernails pulled off one by one.The Only-a-Genius-Could-Love-It startup. Take one incredibly smart computer science/Zen philosophy graduate who rattles off a dozen world-shaking ideas when asked if she wants milk in her coffee and go let her play. When you come back, your partner has created a software app of incredible complexity using algorithms and logic you need to study for three months just to understand how to print. One successful example of this is Stephen Wolfram's Mathematica computational software program, which is incredibly powerful and robust but appeals to a very, very small market.
The Only-a-Few-Programmers-Need-It startup. You're a programmer with an itch to scratch and a keen desire to make some serious money. So you code up a library, a component, a control, a framework. While there are successful companies doing just that (Infragistics comes to mind), you first have to compete with all the Open Source projects doing the same thing and then find enough developers to squeeze out a living better than a day job.
The Built-to-Flip startup. This is a variation of the Me-Too! startup, but with a twist. You see that startup X just got acquired by Big Company Y, so you reverse-engineer their app and, more importantly, their marketing and come out with acquisition bait for Big Company Y's rivals. While there's nothing wrong with looking for an early exit (see Chapter 5 for a translation from VC-speak), building a company with that as its sole goal seldom works, for three reasons: There are too many startups trying to win that lottery. For example, Microsoft acquires about 20 companies a year. And that's it. Second, if your market of companies that might buy you out is exactly one, you're at their mercy—and they will know it. Finally, during recessions, M & A activity slows way down as big companies hunker down.
The We-Can-Do-it-Better-Than-Microsoft startup. Or Google or Adobe or whatever large software company you yearn to be better than. Specifically, in this antipattern you bring out a word processor, spreadsheet, or graphics editing program just as good as and maybe a bit better than the Big Guy on their native platform. Assuming you get funding (you won't), you're going to be locked in a cage with an enraged elephant who is going to outspend, outhire, outmarket, out-PR you to a very early death. That's not to say that Microsoft or any other company is anointed to always win, but that's the way to bet. This is not the same as finding a way to build a horizontal app tailored to a different platform that delivers things that Microsoft can't or won't (
Zoho.comcomes to mind) or as building an app that appeals to a sliver of the horizontal market, like, say, Scrivener on the Mac (http://www.literatureandlatte.com/scrivener.html).
The bottom line for these antipatterns is that they share one overwhelmingly bad commonality: they're unremarkable. And that's the kiss of death in the Online World.
There are as many different ideas behind startups as there are stars in the sky. But after looking at, reading about, and talking to several hundred startups, I see some commonalities emerging.
Most startups don't go looking for the idea that will (supposedly) make them the most money; they go looking for a solution to a problem they care passionately about.
A problem is a starting point, not an end-all. How you see the problem, what technical, business and human insights you bring to how to state the problem, and your solution make the difference between a ho-hum me-too startup and one that can gather attention, funding, and customers.
Resources cost; ideas multiply the effectiveness of resources. Programming takes time, funding costs equity, and marketing takes money. How effective these resources will be depend in large part on what I call the fulcrum: the approach you take to solving the problem. The bigger and more robust that fulcrum can be constructed using the sheer brain sweat of your startup's founders in order to understand the problem more fully, to see new ways of solving it, and to understand how the problem is affecting people today, not five or ten years ago, the better.
There's no shortage of problems or things people would want to do if they only could, and there's no magic or secret formula that will work for all startups everywhere. But there is a natural relationship between the size and shape of a problem you want to solve or an opportunity you want to seize, the resources you can ante up, and how you're going to see, solve, and connect to the problem that when done right can create exciting and profitable value no matter the size of the problem or the resources you have to start with.
Next we're going to turn to a major development that's changed dramatically how startups succeed from the days when commercial apps ran on either PCs or Macs: the rise of the platforms. Web apps, hybrids, Facebook apps, SaaS platforms, mobile, and more: Which platform is your startup going to call home?
[15] For more on Wally, see this YouTube video: http://www.youtube.com/watch?v=lRRDzFROMx0. And have a look at Wally's site (http://www.theforgottentechnology.com).
[16] In programmer circles, cargo-culting means using code libraries and projects when you haven't a clue as to how they actually work, although they do. "Famous examples of cargo-cult activity include the setting up of mock airstrips, airports, offices, and dining rooms as well as the fetishization and attempted construction of Western goods, such as radios made of coconuts and straw"—from Wikipedia.
[17] "Skype fast facts Q4 2008," Skype.
[18] http://www.bbc.co.uk/dragonsden/—In addition to the UK show, there are now versions of the show in Afghanistan, Australia, Canada, Finland, Israel, Japan, the Middle East, the Netherlands, New Zealand, Nigeria, and Russia and shows pending in Ireland, Sweden, and the United States (see http://en.wikipedia.org/wiki/Dragons%27_Den). I guess startups are getting pretty popular!
[19] "Chandler: What went wrong," by Bob Walsh, CNET Webware: http://news.cnet.com/8301-17939_109-10016837-2.html?tag=mncol and
[20] "Why Cuil Is No Threat to Google," Time.com, http://www.time.com/time/business/article/0,8599,1827331,00.html
[21] That's why I built StartupToDo.com too—traditional bootstrapping was too damn hard!