Startup Tips From the Father of Gmail and FriendFeed
mashable.com
mashable.com
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.
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.
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.
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.
Curious.. do you have the original (full-length) interview video? Would you mind posting it somewhere?
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.
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.
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.
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.
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.
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.)
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.
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.