Startup Tips From the Father of Gmail and FriendFeed

http://mashable.com/2009/02/24/paul-buchheit-startup-tips/

by peter123 • 17 years ago

50 29 17 years ago

brlewis• 17 years ago

Paul surely is responsible for a large part of what FriendFeed is today, but the parents who were there at birth are Bret and Jim: http://friendfeed.com/about/team

adamhowell• 17 years ago

Weird to see a "Top 5" list from the same guy who said "Limited Life Experiences + Overgeneralization = Advice"

AndrewWarner9• 17 years ago

To be fair to Paul, I should say that the list of 5 isn't his top ideas. It's just 5 ideas that he told me in when we talked.

colins_pride• 17 years ago

That's fair, but numbers 2 & 3 are good points that you don't hear from everybody and their mother. And besides, I wouldn't want to bet against Paul.

mikeryan2• 17 years ago

Not really very insightful. And the don't need virality if your product is good bit really hasn't been proven out.

There are many superior products out there that have lost to the competition (especially in the social network space) because they never gained enough early traction.

AndrewWarner9• 17 years ago

Mike, I agree that virality can't be dismissed so quickly. Seems if you don't have that, the rest of your marketing has to work much harder.

smwhreyebelong• 17 years ago

I agree with Paul's point. Google's early growth was due to the product being superior and not because it had any sort of virality. I don't recall seeing any Google ads on TV/print/billboards yet soon everyone was talking about googling instead of searching the web.

paul• 17 years ago

I didn't really say that you "don't need" virality, but that the best kind is a product that people love so much that they want to tell everyone about it (which is a kind of virality).

Obviously, the need for virality also differs based on what you are building. For social networks, having your friends there is a big part of what makes it a "good product". For a search engine, that's less important.

What bothers me is the focus on virality over actual value creation. The best examples are some of the "zombie" type facebook apps that are pretty much just pure virality.

unalone2• 17 years ago

That's an important distinction to make re: virality. There're two kinds: the sort that forces you to spread it to gain functionality, and the sort that spreads because people like talking about it. It's easy to force the one, but very, very difficult to fake the other.

mikeryan2• 17 years ago

I agree w/r/t to the facebook apps - I don't think they have any lasting value.

And I think any product that completely revolutionizes a domain doesn't need to "go viral" to succeed - ultimately the excellence or game changing experience will cause these apps to succeed, Amazon, and the iPod are two great examples. Google was a success because they created a game changing search product - it was (and still is) vastly better then anything else out there.

I think however that while everyone tries to create a game changing product, the vast majority of products are really incremental improvements and in these cases going viral helps. Twitter being a great case in point - really just an iteration somewhere between IM/Email/Blogging - but went viral enough to be important, over some better platforms such as Jaiku.

teej• 17 years ago

> And the don't need virality if your product is good bit really hasn't been proven out.

Great point. He really skipped over Gmail's marketing strategy, which wasn't just being good. Gmail didn't get a lot of attention soley because of something as abstract as "it was good". Gmail combined artificial scarcity (invite only) and an outlandish offering (1 GB space) to spark demand. That is the core of the hype machine that drove the word of mouth. Being good was only a multiplier on that, not the base.

sam_in_nyc2• 17 years ago

The hardest part about his first point, "launch a scaled back version first" is determining what, exactly, that means to your product. For me, it's not at all a challenge to think of 20 incredible features that would completely blow away the competition. Does that mean I should only pick 10? What if I'd though of 50... should I now only pick 25?

I wish he'd talked more about the purpose of scaling back. I'd presume that it's to save time, and to have something working with which you can improve. If that's the case, I'd much rather heed the advice of "launch early, launch often" then "scale back." The most difficult decisions to make, for me at least, are what features to spend time on. I consider every version of what I make scaled back, because to me, it's never done.

About his argument for scaling back: "there are people in their garages building an electric car." What does this prove? It doesn't convince me that these people in garages are on a better track than Tesla. If, however, one of these people manages to build a better company than Tesla, based on their garage-built prototype, then maybe I'd take his point more to heart.

goodkarma4• 17 years ago

Really?

I think the whole point is to launch as early as possible. "Release early, release often"

Plus you want to get up and running, get some users, and start building momentum (which comes from people using it, talking about it, giving you feedback, etc.)

I recommend building the app for yourself. You will know what features need to be done first.

AndrewWarner9• 17 years ago

Alex, I'd love to hear how you did that for easytweets.com. Looks like you have a broad collection of features. How'd you decide which were core and needed to be put in before launching and which could wait?

AndrewWarner9• 17 years ago

Sam, I think whether you want to launch 20 or 50 or 20,050 features, ideally, you should launch with just 1.

The questions I have are: how practical is that? and how can you decide with 1 feature to launch first?

I tried asking Paul that in the interview, but it's a tough concept to teach in an impromptu interview like the one I did.

If anyone has any suggestions for people I can interview about this concept, I'd love the help.

unalone2• 17 years ago

Very cool to see somebody from Mashable writing here - I like when a writer follows their discussion places.

In writing you get told to focus on a single core idea: a central theme that you revolve everything else around. It works similarly for web design (or at least that's the model my cofounder and I are using): you find out what lies at the heart of your system, what everything else revolves around. Every idea has one, even complex ideas. You figure out how to create that idea, and in theory every feature you add should revolve around that central concept.

Sam: your idea is based around commenting, right? What you need to do is figure out exactly what your big idea is. It's never something vacuous: it's one specific thing that you think places you above the people who are out there now. Everything else you do revolves around that core.

(As for people to interview: you could always try the 37signals people, and I'd also recommend the contrast.ie team: They have a very good sense of how to focus a concept.)

sam_in_nyc2• 17 years ago

What makes a "feature" a "feature"? Due to the nature of software, it's nearly impossible to adjust your "scope zoom" to be set on "feature." Example: If my one feature were: "allow users to send e-mail," or let's make it easier... "allow users to write a comment." I'm already at a loss as to what exactly that means. It may or may not be a feature (and may or may not be work to implement) any detail of that, such as allowing comments to be multiple lines, allowing other characters besides a-zA-Z0-9, formatting, storing the date the comment was written, etc.

Give me any 1 feature, and I can zoom into it and force you to accept other features that need to go along with it, otherwise rendering it near useless. Likewise, you can zoom out from any aspect of software and see that the "feature" really only works because it's part of a greater whole. That's where my confusion over "launching 1 feature" arises. There's really no such thing as a "feature" per se, but a some Platonic-esque form of your software that you strive to achieve.

I think it's precisely this kind of mysterious trickery behind software that makes it so hard to make specifications, test, debug, etc... and why something like 80% of all software projects go either over budget or miss their deadline.

This intangibility of software is also why I take advice about it with a grain of salt. It's easy, after the fact, to look at what you've made and point out the "one thing" that made it work.

I like unalone's concept of the "core goal" behind your project. PG and others talks about this as well. Focus on the one core thing your software does, and do that the best. This has problems also... because there's nobody to tell you that your "zoom level" of the goal is just right. What if my software's goal is to "make users happy?" I could encompass nearly anything with that. Conversely, I could set my goal to be: "to allow users to post a 140 character message", which is way too specific in and of itself to create a useful product.

I guess my point is that software, and nearly all other feats of engineering, are extremely organic. I'm skeptic about advice on the topic by "proven successes" for two reasons: hindsight is always 20/20, and selection bias. I think what it really comes down to is using your best judgment.

AndrewWarner, I'd love for you to investigate: "What do you start with?" I think it's one of the biggest blockers for would-be entrepreneurs, and puts off so many people from even starting.

goodkarma4• 17 years ago

Oh my gosh, how annoying is the video at the bottom? I was hoping to just see the interview with Paul, not a sliced and diced version that screetches like he's pulling a needle over a record..

AndrewWarner9• 17 years ago

Yikes! Alex, I'm still trying to figure out how to sum up long interviews in short videos. I'll keep at it.

toodlestech• 17 years ago

I actually quite enjoyed that style of video interview. It broke it up for me and clearly separated each chunk of information, letting a few seconds for it to set in and moved on to the next question.

goodkarma4• 17 years ago

Sorry I was a bit harsh there. I had really hoped to see the full interview and got a little frustrated.

Curious.. do you have the original (full-length) interview video? Would you mind posting it somewhere?

sheriff• 17 years ago

As a video on it's own merits, I liked it.

But I watched it after reading the post, which was already an abbreviated form of the interview. I only watched the video because the post had already interested me, but watching the video after reading the post didn't really add anything. Given this presentation, I think it would have made sense to embed the full video instead.

andreyf• 17 years ago

Suggestion: keep (the time you're on the screen)/(the time Paul is on the screen) ratio as low as possible. There's no need to repeat what he just said, or spend a long time introducing him. Sorry if it's blunt, but I'd be interested in what he says even if he goes on for an hour, and not interested in your summaries of his opinions in the least.

AndrewWarner9• 17 years ago

Here's the whole (unedited) interview: http://www.vimeo.com/3368761

Startup Tips From the Father of Gmail and FriendFeed

Related Stories