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
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.
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.
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.
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.
> 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.
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.
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..
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.
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.
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.
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.
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.)
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.
"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."
Then why not define "feature" as "the smallest useful unit of work such that there are no other features necessary to achieve its usefulness"? Sort of like a minimal connected set in a graph.
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.
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?
I made the app for myself. I wrote the first code a few days before flying to Startup School last year. I wanted to be able to tweet things when I was traveling. Initially, all it did was schedule tweets. That was the feature I wanted most. Over time, as I wanted it to do more, I wrote more code.
There are tons more features we will add - and a lot more that I'm sure we will add that we don't even know about yet. I am trying to constantly keep my ear to the ground and listen to my users and influential folks in the search marketing industry and trying to prioritize what needs to be done based on feedback and my own daily use of the app.
It's kind of the whole premise of what PG says to do - launch early, and listen to your users. Many startups change their whole model after they launch. We now offer many features I would have never guessed when we launched the app last year.
