Lessons Learned from Technorati to OffBeat Guides: A ZURBsoapbox Podcast with Dave Sifry

About Dave Sifry

We had an amazing event last Friday with a great turnout, delicious food, and an animated discussion with Dave Sifry. Dave spoke at ZURBsoapbox about the lessons he learned from founding Technorati and starting OffBeat Guides. He shared some truly great points about building great products and growing start-ups. You can find a copy of the full podcast below.

Use data, not your own ego

Technorati was an ego project for Dave. As both the product manager and customer for Technorati, he decided to build the site as something cool to satisfy his own needs. He would think of features to add and the team would run with the ideas he proposed.

There were no analytics or any data measurements of how these features were converting customers. Dave used a loose measurement of how many people were writing him emails about the new feature or how many people were talking about it on the internet.

Technorati lacked the discipline of evaluating if new feature ideas would help them achieve their conversion goals or simply satisfy the person who came up with the feature.

"It's not about what Dave thinks should be added to the product, it's about what the data says about the feature. "

Understand your business model

Technorati was founded by Dave in order to build something cool. It was a search engine so the natural way to monetize it was ad revenue. The team found that people using Technorati to search were looking for blog ranking, compared to people who searched on Google for information on a wide variety of topics and products. As a result ads did not work very well on Technorati.

The first step, Dave says, is to figure out your business model and sell your services around it. Then you set a conversion goal and test the conversions to see how well you're performing.

If you're planning beyond 6 months, you're just guessing

Investors love five year plans, Dave says, but the reality is that if you're planning feature functionality one year out you're wasting your time. Ideal time for planning features is 3-6 months. Going further that 6 months you become inflexible to changes in the marketplace.

A product is like a pregnancy; no matter how many people you throw at it, it still takes 9 months.

A smaller team, Dave says, is always better for a young product. It's easy to throw people and resources at issues which arise. The key to a successful product is to find as few people as possible to deliver the product. Adding more people to a project just slows down the product. A talent pool ratio of three designers/coders to one business person is the best makeup for a start -up team.

Be of service

After Technorati closed their funding Dave had one question facing him: If Technorati succeeds what would I be most happy to see from the business? The answer which he had was: Be of service. Dave mentioned that all of us want to be of service to something more than just ourselves. All of us want to change the world. The job of a business, he says, is to make money, but if you're making money and being of service to the world you know you're on the right track. Hence, before any new feature is added in Technorati or OffBeat Guides the same question is always asked: Are we being of service to our customers?

Measure your virality

Viral is a strategy you can understand if you can measure it. The key is to make your customers into product evangelists. To move your customers from sub critical mass to critical mass you need to measure your virality.

"If I put out a tweet, how many people will retweet this information? How many people will pass on the message you give them? If your coefficient of virality is 1.0 then you're growing fast. If it is 2.0 you're growing insanely fast."

There are tools to measure all these things, the trick is to make sure you have a good handle on these metrics.

More Info

Transcript

Dave: Giving people a large amount of time, money or people is almost always a mistake. It's like I built Technorati purely as an ego project for myself. Let's build something that's cool. Doing it all the wrong way taught me by hard experience how to do things a better way. In the web, if you're going beyond six months out, you're just guessing.

Moderator : At today's ZURBsoapbox we're thrilled to have Dave Sifry here, entrepreneur and founder of Technorati and Offbeat Guides. He'll be talking to us about his experiences founding and running web-based startups.

We've got a great audience here today, some excellent questions from everyone, and Dave is going to be doing his best to answer all of them. So, thanks for listening, and we hope you enjoy ZURBsoapbox.

Dave: First of all, thank you, Dmitry , and thanks everybody. It's nice to be here, to meet you guys and to chat a little bit and, maybe share a little bit of experience, strength and hope because God knows in a young company I think the latter is one of the most important things that you need.

Why don't I tell you just really quickly, for those of you who don't know who I am or my background, I'll give you a quick just two minute history of me. I grew up in Long Island, or Long Island, you've got a problem with that, as we like to say. I was a computer geek and studied computer science at university, but also started my first business when I was 16 doing dBase IV consulting. I see a couple of nodding heads. Yes, we're old, right.

Anyway, I lived overseas for a number of years in Japan, came back to the United States, and in 1996 I started my first company out here in the valley. It was called Secure Remote. We did Linux-based VPN's software back in 1996 which was a fantastic way to find out that nobody knew what Linux was, nobody knew what the Internet was. People had no idea how you actually made money off of it and what it's like to be five years too early to the market.

I went from there though, and the same co-founders and myself in 1998 started another company called Linux Care which was up in San Francisco, and that one kind of took off. We did support and services for all things Linux and went through the crazy, horrendous first bubble story.

Then, we took $70 million from Kleiner-Perkins and all these big VC firms. We went from literally three people to 480 people in 18 months, building essentially what we were calling a Silicon-based services model, so trying to build out lots of ways to scale human beings by building software on top of it to be able to do services.

Anyway, I ran that as a CTO for about five years. In 2002, I left and started another company called Sputnik in the Wi- Fi space where what we did was managed Wi-Fi routers that were super, super cheap. Like if you'd go to a coffee shop or what have you, you could just plug one of these suckers in and be able to get off to the races and start making money from it. With that, we never took a penny in outside funding and instead the company just kind of made it to profitability very nicely, and it's still going on.

By the end of 2002, I had realized that formal programming is for a very, very special group of engineers and I wasn't one of them, so I started working in my spare time on a little side project called Technorati which was, frankly, I built purely for myself. I just wanted to know in the end. This blogging thing was super cool. I was all into it. I loved writing. I loved getting feedback from people.

In the end, all I really wanted to know was: what are people saying about me today? I admit that is somewhat narcissistic. By the way, this leads to one of the good lessons which is like, if you're going to start a business, picking one of the cardinal sins probably isn't a bad way to go. It focuses on people's needs.

Anyway, Technorati kind of took off, totally in spite of me. I made so many mistakes at that business it's not even funny, and I'll tell you some of them. I was there as the founder and CEO for about five years. I built the business from me in my garage with two old computers that I bought off of eBay, running off of my home via cell line to just around 15 million unique visitors a month and a million dollars or so a month in revenue and about 50 people, 50 employees at which point it was time to bring on a new CEO and help grow the company another 10X fold where we actually brought in a new guy who's been helping us to build a big blog ad network as well.

Then from there, just lastly, I took off a little time and started another company called Offbeat Guides. What we do is personal travel guides. So, for over 30,000 different destinations worldwide, we actually pull in all the events, the festivals, the things that are going on, the best things to do, see, buy, the places to go and then personalize it just for you, what you care about based on your preferences.

Then, we actually deliver them to people in whatever format they want, including gasp! Printed books. So, I'll pass this around and you guys can take a look at it.

You were asking: What are the five big lessons? There are so many. Let me just say this, too. I really feel best when I'm not just some guy standing up in front of all of you, and I'd much rather this be an interactive conversation. So, if you have any questions at any time or if you have a comment or you think I'm full of crap, get up there and say it. Chances are I am.

I guess some of the big things, I'm not sure I can just limit it to five. One of the big ones was not measuring everything. So, the first three years, because I built Technorati purely as an ego project for myself and it was a science project is how it got started, I didn't build any analytics into it. I didn't put any AB testing into it. I didn't sit down and ask myself: how are we doing?

I thought judging just by my server logs that that was kind of a neat way of doing things, or it was how many people are writing me or how many people are talking about the company itself. It took us about three years until we were able to get enough discipline inside of the company where it wasn't, oh my God, it's rushing from one fire drill to the next. It's actually how do we step back from this and understand what our growth is going to be, say, three to six months from now and work really hard to actually achieve the technology and the systems to be able to scale to that growth.

I think we got incredibly lucky because people were so excited and had such low expectations of this service that even though we would go down all the time, like I'd built the thing on MySQL to start. Who builds a search engine on a relational database? It's kind of, well, the naiveté of youth, right?

Having done that, I would say this. Doing it all the wrong way taught me by hard experience how to do things a better way, I won't say the right way. It also taught me a whole bunch of ways of thinking about problems that perhaps if I had started out doing the right way, we would never have gotten to. So, when I thought at first about what I was trying to do, the core goal was satisfy my personal needs, and even though you could say I was the Product Manager, I was also the customer.

So, the good news was I knew the customer quite well. The problem was the customer was a tricky best who was constantly changing his mind all the time, and because we built it at the beginning on things like a relational database, it meant that I could try an experiment on a gazillion ideas and applications.

I was able to very, very quickly throw stuff on the wall like it was spaghetti, see which ones worked and see which ones didn't. The problem was we didn't really have a discipline around it. And so, it kind of took me saying, "wow! We should have a top book section," and then going home and hacking it together over a weekend in order for a new feature to happen.

And so, I didn't really set things up, especially as we started growing and building employees to say, "It's not about what Dave thinks" because it was at that point, it's about what did the data say. Had we had more discipline, I would have been able to say at the start, "Go build cool stuff. I don't know the right answer" and put more empowerment in my employees instead of making it more - and it was unconscious. It wasn't something that I wanted to happen, but it turned into that because it was kind of an arbitrary decision process. Yeah?

Audience Member: My question is: What's different about you actually did and best practices in Agile product building?

Dave: Okay. And I can talk about a little bit about, for example, what we're doing at Offbeat Guides and how that's very different and some of the lessons learned from it and a lot of ways doing it the wrong way and banging my head a whole bunch of times.

One of the first things was understand your business model. When I started Technorati there was no business model. It was build something cool that's just for me, and then the second part of it was: Hey, it's a search engine, like we could use AdWords or AdSense or Yahoo's product, and we'll be able to monetize it. What we found out when we started doing that was people have a very, very, very intent when they come to search for conversations than when they come to a traditional search engine looking for products.

Our click-through rates were much, much lower. The amount of revenue that we thought we were going to be making, by just plugging advertising in, totally didn't work. The first step was figure out your business model and then design your product around that model. So, at Offbeat Guides we said we're going to sell books. This is what we do, and people understand how to buy books. They understand that books cost money. They understand there's real value in what they receive, and they understand the experience already.

We don't have to go far out and try everything and its sister. Let's try focusing on building something great but that has what they want plus. And then, the nice thing there was you could use all of the great tools like Google Analytics; you could use Website Optimizer; you could use all of that tools that, also, by the way, in 2002-2003 didn't exist.

Because they're built around things like a funnel, we could actually start, "huh! Okay, our goal is conversions." Let's actually sit down and say, "How do we test those conversions?" Let's actually be disciplined about it, red versus green, mascot versus no mascot, put the pricing on there, don't put the pricing on there.

So, we could immediately and literally within a week have enough statistical information in an AB test or in a multi variant test to actually be able to say this is going to generate higher conversions for us whereas with Technorati there was so much like "I don't know. Let's build something that's cool." I think we got involved too much in building something cool for ourselves and not enough thinking about what is it that we're trying to drive. Do you know what I'm saying?

Audience Member: It sounds like you didn't understand yourself as a customer because you were intuitively using yourself as the user. You just hope that it's a representative of something that's . . .

Dave: And I think it turned out reasonably well from that perspective, but when I look back and I go . . . for example, we tried building products for the PR industry and for marketing companies, for example, because when we started out we said, "Oh great, we'll make money off of ads" and the ads didn't really make a lot of money.

We then said, "Oh, well, but all these PR agencies keep calling us up. All of these marketing companies keep calling us up. They want to get access to the data. They want to be able to find out the sentiment and what people are saying about them right now and the companies that they represent."

So, we spent a good year focusing on building analytics products for these companies, but even there I don't think we had the discipline of doing enough testing with those early customers. Otherwise, we would have found out very early on they loved the idea and they didn't have any budget and that, in fact, it just wasn't the right way to go. What we ended up realizing in the end was, and again, this was coming back and talking to our actual customers and asking them what they wanted, was they kept saying, "We love Technorati. We're frustrated by it sometimes, but you know what, we come back to you all the time. You guys have the authority. You keep us informed. Help us make money. Help us to . . ."

"As a small blog or a small social network, we don't have enough clout to be able to get Madison Avenue to think about us, but if you can aggregate all of the traffic that we have, you have all of this information about us. Can you help us to make money?"

And that was actually the things that really lit upon the high growth of revenue. It wasn't so much the high growth in traffic anymore. Our traffic, in fact, remained relatively flat, but the revenue numbers just started taking off like crazy because all of a sudden you were going from just trying to deliver ads or just trying to deliver audience on one site and turning it into 10X or 100X of the amount of reach.

Moderator : So, Dave, we're really interested about your designing. How do you design a service? You were saying that there were tons of features requests and you were juggling all of them at once. We're really wondering how do you go from a feature request to actually coding something up. I know people have road maps. How do you choose which feature to implement?

Dave: Of course, we had a road map, especially as you start getting bigger, once you start getting more than 10-12 employees. You go beyond what I call little red schoolhouse where everybody can sit in the room, and you've got the second graders helping the first graders and the third graders helping the second graders. It all kind of works out, and you all have structured recess, and you all go have fun.

Once you get beyond 20 people or so in a company, you can't just gather everybody around in one room and have an all hands meeting of really any value. Certainly, we started breaking that apart and saying, "Okay. How can we go three months out? How can we go six months out?" By the way, if you're going beyond six months out, you're just guessing.

I could create terrific five year plans, and my investors would all be like, cool, and the reality was entirely variable, beyond about six months. Even six months was way long. So, part of this was stepping back and saying . . .

Audience Member: Do you think that's still true?

Dave: Yeah. Totally. I think if you're planning a year out, you're wasting your time.

Audience Member: Really?

Dave: Yeah. Let me put it this way. It's always good to plan. Of course, it all depends who you're planning for. If you're planning for your investors and so on, sure; you have to be able to say, "Is there a real market here? Is there money in this space? Are we charging enough? Are we building the right stuff?"

But if you're actually starting to think feature functionality a year out, forget it. I think you're just . . . since we're being recorded, I probably shouldn't say that word, but a certain amount of mental [owninism] is coming into play.

Audience Member: I've heard of that.

Dave: Yeah. All of you, all of you vocabulary data people.

Audience Member: The Guinness Book of PDFs.

Dave: Right. But three to six months feels like it works about right is what I've seen. Going too much further it's just very hard. You become inflexible to the changes in the marketplace.

Very often, here's the really interesting thing is I tried to find people who had as much as possible a combination of coding skills and design skills, and these are really, really hard people to find, by the way. I think they still remain elusive even in this recession, it's extraordinarily difficult to find people who actually have a combination of good design sense and the ability to actually code things up.

If you can't find those people, at least, find somebody who's really, really strong in design and somebody who's really, really strong in coding and make sure that they love each other. And then, naturally try to slide as many pizzas under the door as you can possibly find. If you keep that and then add a business person on a one to three ratio approximately, so three teams of these designer/coder/designer/coder/designer/business person, designer/coder/designer/coder/designer/business person, you're doing about right.

Business people, and as a business person myself, it's amazing to think about all of these really cool ideas about the things that we can do, and you run out and let me find these partners. And we've got all these customers and clients, if only the damn engineers would execute. You can't have too many business people compared to the actual implementers.

Audience Member: What did you learn between hiring the technology [inaudible 20:25]

Dave: It is. I think one of the things that I learned was the smaller the team the better. Big teams, and this is typical "Mythical Man Month" stuff". Have all you guys read "Mythical Man Month?" Have you read of this book? If you haven't read this book yet, and you're involved in any way with helping to drive and deliver products, I highly recommend that you go out and buy it. It was written in the mid-1960s, early 1970s, if I recall correctly. Maybe, it was later '70s.

Audience Member: Everyone's got to read it. It's required reading.

Dave: Good. It's a terrific book even if you just skim through it. A lot of the things that you'll hear are things that lots of other people have repeated, but it's only because it's true. It's kind of like, things of pregnancy as a product. You can throw more people at it, but it's still going to take nine months. There are going to be projects that just take a certain amount of time to deliver, and actually adding more people to the product in an attempt to get it done faster only slows down the product. It only slows down development.

In the world of the Web, I'm not one of these guys that are super scrum and everything is Agile, and we have to follow the latest buzz word. I think the core question is: can you keep a team of people as small as humanly possible? Can you keep them reasonably resource constrained?

That's another thing that most people don't think about. As a builder, you always want, if I could only get that cool designer to come in and work with us, or oh, if I could only get that new software tool, or: oh, if I only had ten more machines. There's something that's extraordinarily liberating about having really deep constraints towards what you can do that it forces you to be really creative and really focused in what you deliver.

Audience: The design constraints in terms of what's the final project, too.

Dave: Sure. Sure. Absolutely. Of course, the more that you can actually get some clarity of design from the client, but in my experience that almost never happens. Maybe, that's just me, but usually what happens is somebody comes to me, and they say, "Okay. I kind of want this". Maybe, they've even done the design where they'll come to me with wire frames and so on. You look at it and you go, "That's still crap. Let me redesign that the right way."

Giving people a large amount of time, money or people is almost always a mistake. And so, in fact, what I tend to find is if I'm trying to get a project done, I try to find as few people as possible to actually deliver the first iteration that's possible.

So, I had a VP of Engineering at Linux Care actually who told me a great definition of version 1.0. So version 1.0 of your product is the absolute barest set of features that will allow you to sell it, the absolute barest set. So, write down all of your features, and you can probably still take off a couple of them. The product's not going to be complete, but can you actually sell it. If the answer is yes, then you probably haven't reduced enough to get to 1.0.

There's a great quote that I've heard around from a bunch of different people, but shipping is a feature. I think a lot of people, and I know I do this myself, I'm a perfectionist. I want to have all of the cool features in there, and I want to have them all working just right, and I want to make sure that it's totally scalable to hundreds of thousands of users before I launch it. That's almost always a mistake. Duct tape is a good thing because what it lets you do is it lets you fail far more often.

I think one of the things that we did right at Technorati actually was taking this attitude of let's throw a whole bunch of spaghetti up on the wall, and let's see what sticks because for all of the cool features that you guys have seen, there are 30 more that we tried out and then decided, boy, that's crap, that doesn't work and either shelved them or put them way, way deep into the site so that they really didn't affect the experience one way or another.

By constraining your resources, the most important resource which is your time, it's the thing that you maximize.

Audience Member: I thought it was [inaudible @25:23]. We've got about five more minutes.

Dave: Okay.

Audience Member: So again, going to the Brian's question again in terms of hiring. Do you think . . . well, it's probably two questions. One, do you think culture is important, or is this an over hyped phrase in businesses when starting further companies? And two is what kind of qualities do you look for when you hire people, and how do you identify them?

Dave: Okay. Those are actually very important, deep questions. Here's what I found after starting five businesses. The first three . . . Let me tell you first. Culture happens in every business. Every business has a culture, whether you plan it or not. The best businesses have plan cultures because, at least, then you've got a chance to get it right. It doesn't always mean that you get it right, but at least, "How am I doing?"

At Linux Care we went from 3 to 480, and it was insane. It was a culture explosion. It was a culture of conflict, and we liked to say, "We put the fun in dysfunctional". I learned a lot from that. Now, okay, the next time I'm going to build a company, it doesn't necessarily mean I'm going to try to build it slowly, but what I am going to do . . .

When we took funding at Technorati, I actually took a week off, and I went and I tried to figure it out. I sat down with a piece of paper and I said, "Who do I want us to be? What is the culture that I want to build? What is the core motto and mantra?" I'm not talking about vision statements and mission statements and all that stuff. That's nice, but that can just be corporate BS. But there was something much, much deeper about it to me.

What I came back with and what I said to myself, what is it that I feel like after four, five, ten years? If I work at this company, that if we succeed in this one thing, no matter what else happens I'll feel good. What it came down to for me was the be of service. I think all of us somewhere deep inside of us want to be of service to something much bigger than ourselves and something that I hope changes the world.

Look, you're a business. You job is to make money, but if we can also help to be of service to others while we're doing that, then we know we're on the right track. And so, we would constantly be asking ourselves, "Is this of service? Is this something that is helping, or is this just more cruft?" It's so easy sometimes to just throw stuff on the page because you just want to try it out. So, we kept asking ourselves, "Are we of service?" And then, when we would talk to each other, the big question was, "How can I be of service to you today?"

And so, we would use that in our hiring decisions as well. Part of this is building it into the set of questions that you ask people, but even more importantly it's watching how people interact over the first two, three weeks of their employment. We were also very, very careful. We had anybody can blackball a candidate policy at Technorati, and we have it at Offbeat Guides as well which is, if you can start indoctrinating and bringing that culture, whatever it is for your organization and you can make it conscious and clear.

It doesn't have to be of service. It can be don't be evil. It can be make lots of money, whatever it is that you want that to be, but if you're not being clear about it and if everybody doesn't understand it, then guaranteed it'll be fractured in a thousand different pieces because without clear direction everybody is just going to talk away from it.

The nice thing was since everybody felt that way, we were kind of oozing it from the pores. So, our candidates would come in, and they'd also know, immediately. Do I want to take this job because there's so much of this like . . . Do I want to do more than a job? Do I really want to be of service? Some of them would be like, no, not interested. I'm just looking for a 9 to 5 gig. It was like, great. It was like the white blood cells would get rejected.

Maybe yours is, "Do we really want a great lifestyle balance?" That's cool, you know what I mean? But the more important thing is to just be really clear. It gets harder to do the bigger you are. The more people who are in the company at the time when you actually sit own and try to figure this out, the harder it is to make it something that really, really sticks and doesn't just feel like a whole bunch of corporate BS.

Secondly, or it's the kind of thing that really has to come from the top and that it has to be lived. It can't just be said.

Audience Member: Another question here.

Dave: Does that answer your question, by the way or did I give you two?

Audience Member: One more question, too.

Dave: Yeah. Sure.

Audience Member: Lonely Planet has tons of apps now, and it's very successful. So, why are you going to Express?

Dave: It's not to say that we aren't going also towards mobile. First of all, let's be clear. We have seven people at the company. So, we have to pick and choose and be very, very careful about what are the things that we are going to be spending our time on, and what are the most important priorities, the second most priorities, and the third most priorities. What we realized was that right now there's this enormous hole in the market for people like my sister or my mom or my dad who are not going to be using their mobile phones. They're not big. They don't have the latest iPhone or Blackberry.

If I gave my iPhone to my wife and I said, "Honey, get us to blah, blah, whatever, she'd be like, huh?" That's not a diss again her. It's just she's not a technology person like that. But if I hand her a book and I say, "Honey, tell me the directions. She knows exactly what to do with a book." So, that was number one.

Number two is . . . so, I actually think there is something very interesting in the tangible. I think that there's an extraordinary opportunity. You can think about the web in a number of different ways, but one way that I like to think about is so, Web 1.0, the pre, that first bust, was about bricks and mortar companies coming online and taking the current business models that were out there, auctions, and turning them online, eBay; books, Amazon and so on.

The second generation of the web was all about frictionlessness. It was like, wow! We're all online, where we have all of these cool amazing things that no one has ever really thought of that we could do, like social networks? Yeah, sure. We have an analog for social networks in our real world, but there's so much friction here, the Dunbar number and all the rest of it. I know how many people I can know, but boy, Facebook and LinkedIn and all of this other cool stuff really started to take off; viral videos, all of that stuff.

I think that there's an extraordinary opportunity here in the third part of the web or this third generation, which is: how can we take all of this amazing stuff that's happening in frictionlessness and turn it into tangible products again? It's like Spreadshirt or Etsy or some of the different crowd sourcing startups that are out there, or it's things like what we're trying to do with Guides where we're taking the virtual and bringing it back into the physical.

I think there's going to be a really, really interesting opportunity to grow for the next five to ten years. And so, this is our first product. Number one, it's really differentiated, like when I show this to someone, I love watching people feel it and touch it and look through it. That's one way of really getting memorable.

The second thing though is look, it's just information. My take is if you bought the information, I want you to get it in any way that you can. I want you to be able to get it this way, see it in HTML, get it on your mobile phone. Right now, the interface might be a little bit different. So, maybe it's a map oriented interface when you're looking at it on the phone, and it's more of a narrative interface when you're looking at it in a book or you're on the web, but the core piece of information doesn't change. So, watch this space.

Moderator : Dave, I'm interested and I know everybody here is interested about a term called "viral". Everybody's talking about it. What does it mean to you, to our organization, to Technorati, to Offbeat Guides?

Dave: It's good. Actually, I was at a talk last night where this came up as well. I like to think of viral as a strategy that you can measure as opposed to something that you can guarantee. We like to think of coefficient of virality when we build stuff. How are we building things to enable people to share it? How do we measure when those people have shared it with others?

To me, virality is all about . . . it's like that chain reaction of saying, "How do I make my customers or my users into my evangelists so that other people find out about my product through them, and then they're incented to tell other people about the product and so on and so forth."

The only way that you can really go from sub-critical mass to critical mass is by tuning and testing and looking at it. If I put this out and say, "Retweet this," how many people actually retweet it? And compared to the total number of people who then see that retweet, how many of them actually come to the service, and then how many of those people actually come sign in and then take the next step, which is retweeting it again?

You can measure every single one of those steps, and when your coefficient of virality is under 1.0, you grow slowly. And when your coefficient of virality goes above 1.0, you start growing fast, and when it's above 2.0, you are growing at a geometric rate. But this is totally designable and measurable, and you can test it and you can track it in the exact same ways that you're tracking e-Commerce-type stuff today.

I don't think it's about: gee, let's go out and create a really cool video because, maybe it'll get so big, it'll be like the wedding dance. That to me is, I think, a complete waste of money. I think it's about sitting down and saying, "How do I design my application so that it is so useful, and it's designed so that people want to share it with others. And then, I can measure that."

Moderator : Cool.

Dave: Well, thank you.