About This Case

Closed

2 Jul 2007, 11:59PM PT

Bonus Detail

  • Top 3 Qualifying Insights Earn $100 Bonus

Posted

12 Jun 2007, 12:00AM PT

Industries

  • Advertising / Marketing / Sales
  • Consumer Services / Retail Industry
  • Internet / Online Services / Consumer Software
  • Media / Entertainment
  • Start-Ups / Small Businesses / Franchises

Is It Worth Joining The Facebook Fad?

 

Closed: 2 Jul 2007, 11:59PM PT

Earn up to $100 for Insights on this case.

With the launch of the Facebook platform, a number of startups are developing apps with the Facebook API, rather than on general websites. This can obviously make sense for some products, especially ones that want to leverage immediate network effects of a large social network. However, as a web 2.0 applications startup trying to determine a development path, what key points should we consider before jumping on the Facebook bandwagon? We have a recommendation-based service that will be initially ad-supported and then offer premium subscription services. (Think evite on steriods.)

21 Insights

 



Well, two things to consider: How long will the Facebook fad last? And is your audience on there? And a third: Will you gain PR from doing it?

As you see, I do not think there is an intrinsic value in adding yet another API to your platform. You have to consider what you get by doing it. Especially the second question: Is your audience there?

If you gain market by joining - absolutely. If your audience finds you anyway, there are better things to do with your time.

Hope that helps.

//Johan

I say go for it. I should mention that I approach this question primarily as a user rather than a developer. I've got a computer science background, but I haven't really looked into the details of the FaceBook API. So my comments reflect the perspective of an active Facebook user with an understanding of web programming in general.

The big advantage of joining the Facebook bandwagon is that you don't have to deal with the headache of creating and managing user accounts. The programming infrastructure (account creation page, sign-in page, cookie management, "lost password" process, security auditing, etc) required is one consideration, but an even more important considerations is that you'll lose a non-trivial number of potential users who simply won't be willing to go to the trouble of going through the sign-up process, no matter how simple you make it. Using the Facebook API allows you to piggy-back on the work Facebook has already done convincing tens of millions of people to sign up for Facebook accounts.

The big thing to be wary of is excessive lock-in. Obviously, piggy-backing on Facebook's authentication scheme means that initially, at least, your fortunes will be entirely tied to Facebook's. If Facebook goes down in flames, your application could go down with it. To deal with this risk, I suggest that in designing your application, always have an eye to keeping your data as exportable as possible and your code as portable as possible. A good way to ensure such portability would be to include both a Facebook-based and web-based option for using the service, with users on the web site being able to sign up without first obtaining a Facebook account. This is especially important for an evite-like site because there will always be a few invitees who are not Facebook users. This will allow them to be included in invitations.

In addition to enhancing the site's functionality, this feature will give you an exit strategy if you find Facebook isn't as hospitable an ecosystem as you expected. You should also include a feature that allows FaceBook users to migrate their accounts to the web-based interface and vice versa.

One other advantage of this approach is that at some point it could make it possible for you to make the software work cross-site. In other words, if there's a Facebook interface and a web-based interface to the site, why not a MySpace or LinkedIn interface? Right now, other sites may not have the appropriate APIs to make this possible, but if FaceBook's experiment is successful, others are almost certain to follow Facebook's lead. Users who have friends who use a variety of different social networking sites will doubtless appreciate the ability to include them all in one invitation without forcing them to register yet another username and password on yet another social networking site.

 

icon
Timothy Lee
Tue Jun 12 9:43pm
Having submitted my insight, it occurs to me that it's somewhat self-contradictory. If you're including a web-based interface, then the Facebook API isn't saving you the work of building your own authentication system. However, I think there's still some value there. What you should do is have the initial version of the software be Facebook-only, but designed in such a way that it's easy to add a vanilla web option in the second version. This allows you to get your application out much more quickly, so you can start building market share and getting user feedback. Once you've got the Facebook version working well, web-based interface can be a good selling point for a subsequent version.

Does your app have a social appeal and ability to benefit me once my friends join?

The applications that succeed on Facebook:

a) rely on users to spread them around

b) provide more benefit for the user if their friends add the app as well

c) do not try to overtake user's Facebook experience, but generally provide something addictive enough (like music game at iLike) that makes people come back

You certainly cannot go wrong with developing a Facebook app as well as your own site. With Facebook you're likely to gain distribution to a few thousand users right away, and test features and get user feedback right away.

I asked myself the same question. I'm a 52 year old white male so I have not been their target market. After they announced their platform strategy I went and opened a Facebook account and invited my gmail contacts (nice automated process for that). I was curious whether my circle of friends would respond, have Facebook accounts, send messages, etc. The results surprised me. Several people went and registered with Facebook and sent me messages. Several more already had pages. The response was stronger than if I had simply sent them an email requesting feedback.

If you know anything about viral, you know that it is a double-edged sword. If people detect the slightest hint of bullshit they will crucify you and it can take place in a very public manner (blogosphere anyone?). We are constantly asked about viral marketing by clients who uniformly believe it is a low budget, 'guerilla' tactic. It is not, in fact it can be very costly and very risky. That's why Facebook intrigues me. It probably offers the ultimate viral opportunity right now if you get it right.

Let's look at what that might involve. First of all, forget the ads at the beginning. There is almost universal agreement that you build your base before monetizing these days. The logic is that if you offer a truly compelling product that people use and recommend they won't mind the addition of ads later on. Using advertising from day one will cause a lot of potential users to tune you out without trying the service.

Second, using Facebook for its huge audience is a good strategy but you have to execute flawlessly. This means understanding, at a deep level, how people use Facebook and why they recommend things to others. You have to get into the ecosystem and do your homework. Have everyone you know join Facebook and then look and see how many add widgets and which ones they use regularly, recommend, etc.

Design your widget based on that research, being merciless in paring features and delivering a very strong core service. Don't waste any time planning upgrades, 'premium' services, etc. Focus on delivering something great that works and is attractive enough for people to enthusiastically recommend to their friends. That is, IMHO, the key to taking advantage of a platform like this. Once you have your base, then you can think about monetizing.

I think any start-up should consider the power of the Facebook brand as one of the primary motivators. Facebook seems to have generated a brand that garners respect in a way that MySpace doesn't. The technical benefits of tapping into this network of networks can be taken for granted - it's obvious. What may not be obvious is the effect of the Facebbok brand.

Being, associated with a brand growing in power is sure to rub off in very positive and powerful way. Take a look at iLike 3,286,238 users and counting (it was around half a million few days ago) no matter how you slice it - that is an enormous take up in a very short time and this is likely why you are thinking about the Facebook API. But what iLike gets a big benefit from - is the fact that Facebook has a fairly high trust level from it user base and that trust is what will encourage those users to trust iLike enough to make a financial transaction through them (be it a click through to iTunes, Amazon or Ticketmaster). Surely MySpace can create a greater network effect and the open Web a higher potential market - but both of them will not enable you to build a brand for your business like Facebook will.

In the end all transactions depend on the trust level between the parties. Brand is what creates that trust. Having your brand attached to one that generates trust on the level of Facebook is very powerful incentive to jump on that bandwagon. Brand can overcome many issues such as price/value, technical prowess or any other "empirical" issue that we geeks tend to focus on. Establishing a brand will allow you to build out in many directions you may have not even imagined yourself going.

Cheers! And good luck!

I think the decision necessarily depends on the nature of the product. The key consideration should not be the size of the audience, but whether the product incorporates a social networking element. As suggested in the question, the most successful Facebook applications will be those that can build on and leverage the network effect that Facebook provides.

I think a recommendations service is particularly suited for this purpose. First of all, users are aligned on Facebook by a combination of friendship (or at least acquaintance), similar interests, and in many cases proximity (i.e., all on the same college campus). These factors are especially relevant in considering the value and relevancy of a recommendation. People will tend to trust and value recommendations from friends over those made anonymously, and shared interests will make the recommendations more targeted. After all, there's no point in me recommending a particular rock band to you if you don't listen to that kind of music - and those kinds of connections are inherently built into the Facebook experience. Finally, for someone on a college campus, their world is smaller - so a recommendation for a particular restaurant near the campus is more relevant than a restaurant that isn't accessible to them, even if the latter is better. In other words, the recommendations are enhanced by being more contextual and building on the inherent social networking elements in Facebook.

The key risk in this case is loss of control. Though their license is undoubtedly better than the precarious relationship many companies maintain with MySpace, there are still reasons concern especially for an ad-supported product. Facebook allows advertising in third-party applications, but they do not explicitly set forth the terms and there are certain limitations and restrictions (particularly in the privacy and data collection areas) that one would have to be aware of. (A premium service probably has fewer risks, but there are still privacy and data collection concerns).

Facebook also reserves the right "to charge a fee for using the Facebook Platform and/or any individual features thereof at any time in [their] sole discretion", which could obviously have a significant impact on the business model down the road - especially if a good percentage of the traffic ends up coming through FB users.

Furthermore, Facebook explicitly reserves the right to change any clause in the license at any time, and simply by updating the TOS page.

We may modify any of the terms and conditions contained in this Agreement, at any time and in our sole discretion, by posting a change notice or a new agreement on the Facebook Site. IF ANY MODIFICATION IS UNACCEPTABLE TO YOU, YOUR ONLY RECOURSE IS TO STOP USING THE FACEBOOK PLATFORM. YOUR CONTINUED USE OF THE FACEBOOK PLATFORM FOLLOWING OUR POSTING OF A CHANGE NOTICE OR NEW AGREEMENT ON OUR SITE WILL CONSTITUTE YOUR BINDING ACCEPTANCE OF THE CHANGE.

Again, while the agreement is certainly better than the situation that exists today, caution should still be taken at building something too reliant on Facebook.

Given the nature of the product, though, I would advise to pursue this as one delivery vehicle for recommendations - and just be cognizant that of the potential risks down the road.

Tim Marman

No. But it is worth extending the Facebook model into businesses with lots of employees and/or contractors, dealers or customers. The basic issue for the business is how do we increase the business tempo. How do we get new people up to speed faster. How do we make finding the right resources easier. How do we get new ideas propagated faster. Pick up on new trends or issues. Social networking technology can do this for business. 

Hunter Douglas, to give one obscure example, has thousands of independent dealers and installers worldwide. Right now those folks have only indirect ways of meeting up with each to share tips, leads and experience. Company employees have no easy way of finding out about the dealers and installers. Corporate has no easy way to inject new business growing ideas into the dealers. Most importantly, dealers have no way to gain recognition from their peers for their innovations. 

Applying social networking techniques to business communities is the next big growth area. A company that makes the software to do that and delivers it as a service to companies will do very well for many years. 

Is it worth putting your video content on YouTube?

Facebook is providing a platform for applications, much like YouTube provides a platform for video. Facebook is one of the first companies to provide this service and it's the best way to launch some applications with access to a large and dedicated user base

 

I said "some" applications.

 

Just as there are some videos which are perfect for the YouTube Platform and others better on other platforms, so are there web applications which are perfect for the Facebook application and others not.

 

So, as you plan your recommendation service, the major question should be "does the Facebook Platform allow me to do everything I wish to do?" If not, build an application which does all you want it to do, then ask if you want to integrate with Facebook.

 

When it's time to decide if you'll integrate with Facebook, ask yourself "why" you'd consider Facebook. What strengths are you going after? If it's for the massive userbase, and your product relies on a critial mass of users to work, then put a big check in the plus column for building into Facebook. If your app and business model will rely more on the quality of engagement, I may not target the distracted Facebook user community.

 

Anyway, thinking about Facebook as a YouTube of app platforms could help you decide. My guess is that a recommendation service would do really well on Facebook, but not bound by it. Integrating with other platforms, surely, will be important as well.

I think there are (as ever) good and bad reasons to jump or not:

 

the good:

 immediate access to a large social network, some people are fed up with signing up for so many services so having access from an already in use and trusted servcie is a good thing, I for one am starting to add more apps to my facebook profile but have yet to decide if it's a good thing or not, however having one place to go to see things/info is a benefit

you get the hype effect that everyone is rolling along on the same wagon, it's a high profile place to launch your service

the bad:

lack of differentiation, you're in with everyone else and competing for a space on someones homepage which can get cluttered/busy quite quickly (however if your service is valuable and useful to someone this wont matter)

more difficult to build up your own brand image as may be seen as a subset of Facebook (same problem for everyone of course) 

 

Conclusion:

If your service depends on viral/social/mass adoption which it seems like it might from the brief descrition, tight integration with Facebook and other existing social networks is a good thing I would say overall, make the path to use your service as troublefree, simple as possible

The first question to ask is how you would do in the absence of Facebook. Does your service drive enough value to be self-sustainable. The other question you have to ask yourself is how you differentiate? Your business can get quickly diluted if a competing service comes up (and for that reason I don't like the idea of going the of route premium services unless you have a great value proposition and competitive strategy). these two considerations are critical.

The service itself should be built so as to rely minimally on Facebook profile data. Obviously if more data is exposed that is great and more value can be extracted but that's gravy and should not be a dependency. The most appealing aspect is that an evite can find itself instantly broadcasted across the network and there in lie the most interesting challenges. The widget itself is the principal driver for signups through Facebook and the information imparted through it should add value. There are three aspects to consider: viewing the eVite, responding to the eVite, forwarding the eVite. Next, the signup page for the eVite service is just as critical. If users don't see a value-proposition on that screen, they will be turned off. This is also to combat the problem of dilution. I have recieved a dozen or so requests in the past 2 weeks alone.

Churn will be another issue. Once an event is over, how do you retain users and what is the point of them keeping up the eVite? This is another problem that should be addressed, because the value-proposition simply drops after the event is over and the widget is just idly taking up screen real estate.

Being first to market will surely give you a lead but a competitive strategy should also be set in place by considering some what-if scenarios.

icon
Vinaya HS
Mon Jun 18 12:03pm
Analyzing your insight took me on a different train of thought.

A popular framework used to market a product or service is the AIDAS (Awareness, Interest, Desire, Action, and Satisfaction) framework. Probably, this company could use the Facebook platform as a tool to attack the A, I, and D components, i.e. to generate Awareness and to create a viral Interest and Desire for their recommendation-based service. The back end website could then serve the Action and Satisfaction part.

What do you think?

I would like to begin with a few thoughts on the concept behind Facebook’s application platform itself before moving on to your specific application.

The question itself says it all: the new Facebook platform is a fad – one that will continue to generate glowing press – and attract heaps of new traffic – for a few more months and then die a slow death. What do you think is the problem with MySpace and those pesky hey-why-don’t-you-add-me-too widgets? What’s the difference between a widget and an application – apart from the fancy name change? Cluttering your profile page and that of your friend with all kinds of nonsense won’t work in the long run.

I don’t buy the hype surrounding Facebook’s idea of everything being a “social graph.” To me, the recent high-profile launch of the F8 platform seems to be more a gimmick to switch people’s curiosity from MySpace to Facebook (more eyeballs; more revenues for Facebook) than it is about giving developers deep access to Facebook.

Having said that, I believe that you should consider the following aspects before diving into the Facebook bandwagon:

1. Is your service a generic one or a demography-specific one?

Quite obviously, a solid user base is what is required by your service and Facebook, on the surface, seems to be a readymade solution (if you believe the reported numbers that is). But what kind of a user base do you really need for your service? A generic worldwide audience or a demographically-categorized one? I don’t think Facebook is a good choice for the latter.

2. Have you really read the terms of service?

Facebook’s terms of service are frankly, frightening. In summary, Facebook can limit you or terminate you at any time at their sole discretion, reserves the right to impose fees at any time and in any manner, can copy and distribute your application, can analyze the content in order to target advertising, may create similar applications with no obligation to you, can change the terms and conditions at any time (with your only recourse if you don’t like this being to stop using the service).

But then they publicly claim that Facebook will impose no limitations on how you make money. To quote the founder: "You can sell sponsorships, you can have ads, you can sell things, you can link off to another site - we are just agnostic." How hypocritical is that? But, your idea of starting out with an ad-driven revenue model does fit in well here.

The all important question here is: Do you have a solid plan in place for that rainy day when Facebook decides to exercise its dictatorial rights?

3. Do you have adequate backend infrastructure?

Suppose you do manage to garner the attention of a sizeable user base. Do you have adequate infrastructure at your disposal to handle the [potential] surge in traffic? After all, you don’t want to have a repeat of the iLike experience.

4. What do you think is a decent time to launch?

Once submitted, it takes some time for an application to be approved by the Facebook team. As more and more applications try to hitch on, the wait time could turn into a critical factor.

5. Would you rather wait and watch or go for a first-mover advantage?

As a business, you need to take the call between adopting a wait and watch policy (where you sit it out for a few months to check if the F8 platform continues to maintain traction) and garnering the first-mover advantage. How difficult is it for someone to replicate what you are offering? The currently viral applications on Facebook (iLike, Last.fm, etc.) were well entrenched stand alone web applications before they integrated with Facebook. You might have to dig around to check if there are any just-out-of-the-box applications that have managed adequate adoption. What credibility do you bring as a new startup?

I believe that if you can answer the above questions, you will be in a better position to judge your integration into Facebook.

Personally, I don’t have a use for Facebook and I would rather use your application as a stand alone service. Apparently there are millions out there who think otherwise. So, my advice is that you go ahead and enable integration with Facebook.

All said and done, the only positive about Facebook integration that I see for your recommendation-service is that you get a free platform and user base to test if your application has got what it takes to scale up.

icon
Aleem Bawany
Mon Jun 18 9:50am
Regarding #1, why do you say Facebook is not good for demographic targeting? Social networks tend to generally span the same age group--most of my friends are within my age group. That's the good thing about social networks--the service will find itself flowing down the path of least resistance along the social network.

Regarding #1, service agreements are often defensive and to protect the best interest of the service provider. It is possible that a company turns around and blames Facebook for dropping their service and undermining their business or whatever. This should not have any impact on the strategy for building Facebook plugins.

Regarding #5, a first-move advantage would be very lucrative. I don't think it should even be a question. If another similar service finds itself sweeping the social network, it won't leave room for others due to "network effects" (the 101st person will join the same service his other 100 friends are using and for that reason the 102nd person will do the same and so on; the newer service with 0 users will find it very hard to gain traction).
icon
Vinaya HS
Mon Jun 18 12:22pm
Thanks for your insightful feedback aleem.

On #1: Age is definitely one demographic parameter. But for a recommendation-based service is it useful as a stand alone parameter? What other demographic parameters can Facebook reliably provide?

On #2: Facebook may or may not exercise the clauses present in its terms of service. But, as an application provider, I would always prefer to be safe rather than be sorry. I'll sleep better knowing that there's a Plan B.

On #5: Thought about this one a bit and I think you are correct. If you can establish a first-mover advantage, why not just go for it and hope for the network effect to kick in.

Would love to hear your thoughts on this.
icon
Vinaya HS
Mon Jul 2 3:41am
Update:

It looks like the honeymoon is over. You are now allowed to invite only ten friends per day to check out an application. Forget any viral growth expectations that you may still have. Facebook's got the increase in traffic it needed. No one cares for your application anymore.

There's one more absurdity I would like to point out. I couldn't sign-up for an individual account directly on the Box.net (registrations are closed, it said), but I could sign-up for one through the Box.net Facebook application. Dumb. Really dumb. Don't make this mistake.

The Facebook API is a wonderful idea and is rightly praised by all sorts of developers excited that the FaceBook team has opened up their platform for use by outside developers. But is it right for you?

The first problem with the Facebook API is that it's on Facebook. In putting time and development into an application that fits only one platform, you're restricting yourself to a single community, one that has already grown up around an idea, and one that you're competing for the attention of people who did not originally sign on to use your product.

Key Point # 1: Is the Facebook community your target audience?

The Facebook users are primarily college students who use the software to flirt, to organize, and to talk to their friends. An evite on steroids software sounds great, but is it a need college students have? They can already organize parties with their friends, and you have to wonder if they will be open to using a new application when they are already concerned about the outside world finding out what they are doing. Many schools are logging in to Facebook to crack down on underage drinking - is the ability to create an invitation list on Facebook going to compete with their desire for privacy off Facebook? Even if the application gives them privacy, will they perceive is as an intrusion, or simply use another social networking software?

Key Point #2: Building Software Inside Facebook

The technical difficulties of building inside Facebook are not hard, but if you have an external application, building a second application doesn't make a lot of sense. Facebook users have to be logged in to use your Facebook application, and if I understand the user agreement correctly, you won't be able to get them to leap from the Facebook platform to your site. Basically, you'll have to rebuild your evite on steroids inside Facebook.

If you have an ad-supported strategy, do you think Facebook will let you run your own ads inside their platform? I imagine they will not, which means any traffic you get to your application inside Facebook is purely a branding strategy until you get premium subscriptions, and college students probably are not your premium subscription target users. This is the major roadblock I see. While you might have access to the Facebook community, unless your sole audience is Facebook, and you don't need the money, I see a major problem with advertising dollars.

Key Point #3: Rising Above The Noise

The Typepad Widget Gallery is an good example of what happens when too many applications are available. There are scores of widgets available for Typepad blogs, but precisely because there are so many of them, most of them can't get any traction, and the people using them are more likely to already be readers or users of the company hosting the widget. I don't have access to the figures, but widget growth from outside of a known community has to be small, because who has time to try out and use every new widget available? You don't have an audience that already trusts you that can use the Facebook application - instead they will have to learn about you from that application. That's a very tough thing to do, and I'd be worried about enough traffic to make it worth while. You're not competing with eVite on Facebook. You're competing with everyone for their attention. And will college students really take time to recommend you?

 

Key Point #4: Advertising Strategy

If Facebook does allow you to make money off of ads on your application, there's one more problem with the strategy. College Students don't click on ads. The truth is most internet-savvy people don't pay much attention to advertising, and no clicking means no money. The best way to maximize ad potential is to find a community of people who are searching for content related to your product, and thus more likely to click on ads and generate money.

Personally, I'd be going after moms with my online strategy. In addition to having the purchasing power, they are more likely to need party related products (baby showers, house showers, children's parties), and are a better target for a start-up. They are social networking gurus, and a recommendation system fits with their general personality, unlike the college students, who chase coolness, not effectiveness. The mombloggers community is huge, and the cost of doing business is substantially less than competing with people trying to get GEN Y attention.

 

-Jim Durbin

http://www.durbinmedia.com

 

 

 

icon
James Durbin
Mon Jun 18 12:40pm
I went to submit to early - I read through the rest of the Facebook stories in my browser, and came out on two extra thoughts.

1) First, my key point on #2 about making money with Facebook seems to be answered - Facebook allows you to run ads on your canvas pages, but I still wonder about the amount of money this can generate, primarily because of:

2) Explosive Growth:
If your application is picked up by Facebook users, the growth will overload your servers, and you'll have to spend significant money to buy news ones and upgrade. iLike has been wildly successful, but they have had to cope with 50,000 users joining in the first day launching to 3,000,000 and growing. Do you have the cash on hand to handle that kind of traffic from the get-go? They didn't. They had three servers, and now have 1000's. Can you afford success at Facebook?

It's quite the pickle - you need money from advertising to pay for the growth, but without growth, you won't have money from advertising. Seems like a long shot.

-Jim

I personally do not think the Facebook API will be all that beneficial to most startups. The network effect will not be immediately realized and there's a possibility that it will never be realized. Just because you build an application that taps into a service with a large, dedicated community does not mean that community will migrate or adapt to a new value-added or complementary service.

Some key points of consideration include whether or not the community will adopt your product and if they do will it spread.

Another point to think of is whether the integration of third party API's should wait until after the first version is released. If I were in your shoes I would not spend the time up front developing an integration platform - I would wait for feedback from my initial user base as to whether they think Facebook integration would be beneficial. No one knows feature requests better than users. Use the 80/20 rule - if 80% of the base request it or respond to a survey inviting the idea than it would be worth the development time to integrate.

Of course this is very dependent on the nature of the application you are building. From what it sounds like from the brief description provided Facebook integration may be helpful allowing users to send recommendations to their Facebook friends. Even if that's the case I think it would be a great feature for a second version giving your users increased value.

There can be a slippery slope though as users may request integration with hundreds of other services (myspace, gaia, etc) once Facebook integration is added. Again, if you waited you could release a suite of integration additions in a second version.

Another great reason for waiting is that you can focus on the core functionality of your application for your initial release. 

The issue of to Facebook or not, is an important one. For a recommendation-based/"evite on steriods business", it would be highly advantageous to make a Facebook widget. Taking it a step further, it would be useful to provide a widget for iGoogle, myYahoo, PageFlakes, MySpace, etc. as well.

However, it does not have to be a widget or web decision. In fact, it probably makes sense NOT to make it a either or situation.

Widgets are great ways to reach a huge audience, such as the Facebook community. According to Read/Write web - December 18, 2006 (http://www.readwriteweb.com/archives/long_tail_shrinking.php), the top 10 websites % of total web-page pageviews went up from 31% in November 2001 to 40% in November 2006. The popularity of RSS feeds and widgets has accelerated to the point where this trend is likely to continue in this direction. Therefore, using the popularity of Facebook, Myspace, iGoogle and My Yahoo! to gain traction will become commonplace for consumer Internet companies. A few good example of companies that successfully used plug-ins and widgets to gain widespread adoption include Flickr, YouTube, and Photobucket. Especially Photobucket.

Keep in mind that widgets have inherent limitations. Widgets are designed to be compact is size, and the transactions on the widgets are expected to be short.  For complex and graphic intensive transactions, a company's own web-site is likely better vehicle for these consumer interactions. 

Ideally if the widget becomes popular, the consumer will come to the corresponding web-site and use advanced features that would enhance the user experience.  For a recommendations engine, you may need the consumer to provide some user profile information to better improve their results from your engine. 

You have to start with one question: Would you app fit in with the current facebook experience and expand a particular piece of it.  If yes, keep reading, if no, you're wasting your time playing with the API.

 Look at the current top applications on facebook, the ones that spread.  They all expand what users were already doing on facebook. Users were already talking about bands, and iLike expanded it.  Users already added and wrote on the walls of their friends, with top friends they could display their best ones (especially popular with the younger facebookers who started on MySpace).  X Me and Superpoke expand the poking feature, one of facebooks originals.  I could go on about nearly all of the top facebook apps.

So...questions to ask.

1. Would my app expand the current facebook user experience?

If Yes....

2.  What do I want to get out of the facebook app?  Most users aren't going to start using your app outside of facebook, so you'll have to discover a way to monetize it within the site if that's what you're trying to do.  If you're trying to generate buzz about a site/service (I think you are) OUTSIDE of facebook then think hard about how you're going to do that...it wouldn't be easy.  

3. Will users continue to use my app?  The political compass was really popular at first...but you only need to use it once then you're done.  iLike climbed because people continually use it.

 

The answer to 1 has to be yes.  The answer to 3 should be yes if you put more than 3 hours worth of work into it.  The answer to 2 is the most important, if it doesn't fit your business it's not worth the time.

 

Guess what...you SHOULD use facebook.  Invitations (along with picture sharing), is the MOST POPULAR THING ON FACEBOOK FOR UPPER CLASSMEN.  I've been using facebook since it was thefacebook.com.  I don't edit facebook much any more, don't really look through my friends profiles, but I use the Invite/party pages service ALL THE TIME.  If you're evite on steriods can expand that process (talk to some college kids about how they use the party page invite thing...if you can't find any ask me)...then you'll have a winner, because no current facebook app is doing it well.

 But remember, school's out.  Your traction, especially for party invites, sucks when everybody's at home for their parents.  Build the app, launch it slowly, then push it hard in late august when all the back to school parties start.

 

 

There are many disadvantages to developing for Facebook, beyond the obvious risks of it's "fad"status.  Creating an application within a closed platform means giving up a lot of control over your creation, as well as making it far more difficult to innovate.  Facebook owns your customers, not you, and your application is basically an advertisement with a very poor conversion rate for your main service.  Meanwhile, you are paying for this advertisement with servers and bandwidth, and getting little in return.

Also, Valleywag reports that a change in how applications spread virally on Facebook limits the ability of new applications to catch on with the community.  With thousands of applications, and some having a multi-million user lead, getting noticed by the community is going to be difficult, and it will only get worse with every day.

Still, a Facebook app can be a good add-on for an already well-established platform.  You can create a Facebook app as a value-add for your current users, not as a means of trying to recruit from the Facebook community.  The trick is to require users of the Facebook app to be logged in users of your own service.  This ensures that everyone using your application is a member of your service and has received a full pitch, not just clicked an install button.  It creates a barrier that will save you from being added to too many users that will not take advantage of your service, while creating greater& nbsp;value for your actual users.

Alternatively, if you have deep VC pockets willing to go all-out on the bandwidth, create the application, with extra features for logged-in users, and go all out on Facebook.  You'll burn a lot of money, but the potential upside is there.

The thing about facebook is that it's different to other social networks - the networks on facebook are not "online" networks, they are just an online manifestation of a real world network. The apps taht have been most successful (in my network at least,) have been the ones that help people to do real world things wether that's as simple as a bit of banter - through the wall and the poke pro apps or finding out who wants to see a film I'm interested in.

If your program has a real world application, get it on facebook, if not don't bother - it's already crowded with cool stuff for cool stuff's sake.

Also - judging from my network, facebook users are not tech savvy in the same way that people in my myspace or bebo networks are, again, I think that's down to the nature of facebook and its pre-networked users. If your app is hard to use, facebook might not be the best place for it.

Hope that is helpful.

Sam 

Without knowing the specifics of your recommendation-based service, my first general reaction is:  why not join the Facebook fad?  With the open API, it seems to me the only costs are development time, much of which you would already have to spend anyway.  Extending the service for Facebook, or creating a specialized app for Facebook, would entail modifying what you are already putting into place anyway, unless somehow the time and costs were extensive.

Moreover, it's not a question of either/or when it comes to developing a Facebook app or a Web 2.0 app, is it?  My sense is the target market for a service like evite on steroids would be early adopters or younger Internet users and Facebook delivers the ideal demographic. 

So, some of the key points worth considering:

1.  How much more time and effort would it entail to develop a Facebook app? 

2.  Is your primary target early adopters or younger Internet users?  This is particularly important given that you plan to extend the model to premium subscription services.  Although not much data exists on this issue, Facebook users don't spend a lot of money -- yet -- on add-on services.

3.  There has a been a lot of discussion over the past few weeks around the idea that Facebook, and to a lesser extent, MySpace, are serving to resurrect the idea of a "walled garden," much the way AOL did in the earliest days of mass market Internet adoption.  I believe this is true for the younger demographic, who rarely stray beyond IM and their Facebook profiles.  The wide-open Internet is, for this segment of the Internet population, almost non-existent. 

It's impossible to predict how long this "enclosed" Internet will exist for this youth-oriented Internet population, but I think it will continue for some period of time and, indeed, continue to increase.  Any start-up that is targeting the Facebook population has, to some limited extent, a "captive" population that won't stray very far and you can probably expect that market to grow.

Yes.

It is almost certainly going to be worth working with the new Facebook APIs to integrate your project with that network as much as possible.
I think your introduction to this question has a key part of the answer:

... leverage immediate network effects of a large social network ..

Facebook integration offers the potential for extensive free publicity and increased functionality with Facebook's enormous social network.  Web 2.0 branding has become extremely problematic and potentially very expensive as the number of companies in the space explodes and the capital cost to enter the space with new applications has dropped.

Facebook offers the potential *right out of the chute* for robust social networking, promotion, and testing of your application. You effectively get  "co-branding" with a major 2.0 name for the small cost of some additional development. Also, Facebook's open API approach is very forward thinking. You are not "putting your eggs all in one basket" as you will be if you simply create an isolated new website or concentrate on integration and marketing via, e.g., Myspace's more closed environment.    There also will likely be search optimization advantages depending on the nature of the integration as Google tends to favor fresh and fast growing user generated content over simply a "new website".  Sites alone have become increasingly difficult to promote at search engines using old-style organic search optimization.

Thanks to the open nature of Facebook's approach you are not constrained to that environment - ie you can maintain Facebook functions within your own site as well as incorperate some of your own site features into the Facebook environment. This is not just a desirable thing for almost all new Web 2.0 efforts, it is arguably an essential component of a successful 2.0 promotion strategy.

Although your promotion efforts should also include Myspace and Twitter, Facebook is the most important social network for your project for several reasons. Facebook is growing faster than any other social network, Facebooks demographic is more likely to match up to your subscription services than Myspace's, and your service is more likely to be adopted by an older, more sophisticated crowd that tends to use, and be migrating to, Facebook. (source: Dana Boyd's recent Social Network research).

Summary Points:

Facebook is not a fad and the new open APIs represent a significant shift in social networking.   Use Facebook. 

 


Many developers are jumping on the Facebook bandwagon. The advantages are enticing: a stable platform that can potentially simplify product development and a large customer base to tap into. However, choosing to the well-defined Facebook route is often done in lieu of developing a well thought out business strategy. Let's look at it from a few angles...

Advantages:
  • Using existing platform can potentially save development time - the more time it will save, the more reason there is to go with platform
  • Easier to acquire customers - does not require users to change existing habits, and only requires a one-time action (adding widget) rather than returning to a new website

Disadvantages:

  • Potential limitations of Facebook API
  • "Faddish" nature of facebook means your business will be dependent upon facebook's continued success
  • Limited to facebook's market segment (shouldn't pose a problem for an evite-like service)
  • Competition intense with other Facebook apps

 Critical Issues:

  • Is it easier to start with a Facebook app and later tie it to a standalone website, or to build the standalone product first, then integrate into facebook later?
  • How do we intend to monetize?
  • What flexibility might we lose from choosing either option?

 

Developing an app within Facebook should never become the sole product, however depending on the advantages/disadvantages outlined above, it may well make sense to develop the facebook app first in order to bootstrap the company.

One additional consideration would be the effect this may have on raising venture capital. VCs are likely to be suspect of such a business model until they have examples of valuations to measure against.

 

icon
Daniel B
Mon Jul 2 12:13pm
Another thought:

In terms of generating mass market adoption, how does just having a facebook app (without a standalone alternative) limit the ability to market?

Imagine a Superbowl ad for a facebook widget: only 1/100 viewers would be in the target audience and 99% of the cost would go down the drain, simply because most people aren't on the platform.

 

I want to talk about this from a couple of perspectives.  

This type of value-chain is just beginning to emerge in consumer software, but has been common in other industries such as consumer electronics, household commodity goods and more, so we can take some lessons from them.

Essentially all new product developers are faced with two keys to making their venture successful (1) Speed (2) Scale.

For small consumer electronics manufacturers, the added challenge is the massive investment required to put the product out into the marketplace to begin with. In the CE industry, then, this resulted in ODMs (Original Device Manfacturers) working with Brand Names to bring a product to the market. Two famous examples of this is the HTC/Imate partnership and Motorola Razr, which was not designed by Motorola.

The benefit from having such an arrangement is clear - you get speed-to-market because each party juts focuses on what they do best (product dev ; distribution ; marketing etc.), and you also get instant scale because of piggybacking on a bigger brand. 

This has been successful for many smaller vendors, especially HTC who used their success with the iMate to build their own brand to the extent that they could then become an OEM.

For software companies, they dont even face massive investments in production and can similar enjoy savings of marketing expense.

However, there are a number of risks involved as well:

1- Typically, you do not scale the brand value as fast as the product. There are success stories like HTC and iLike in the world, but they are very few. Even software apps on Facebook -- even if they become popular -- will not be able to create enough of a brand to venture into a solo product line. 

2- The Big Brother Partnership. Big Brother partnerships are risky because the big brother can choose to shut you out instantly, thus pretty much killing your entire business model. 

In the case of Facebook specifically, while their initial application support model was very viral, they have recently put measures into place to actually hinder the viral spread of your products, such as a limit on the total number of friends you can invite to a particular application. This has a lot of software developers frustrated because they are now unable to get scale advantages that they had hoped for. 

In some cases, such as Revver, big brothers can choose to simply ban the application outright (although this is less likely to happen with an application created specifically for Facebook). However, there is still always a chance that a big brother can choose to stop the business relationship with you, leaving you without a brand to survive on and without the network you hoped to create.

 

I think your strategy should be three-fold:

1- In the very-short-term, use the Facebook Platform. There can be short-term advantages for an "Evite on Steroids" recommedation service to be on Facebook. However do not architect your application in this way.

2- Architect the application to be platform-independent. Build one app that you can use on Facebook, MySpace, Dashboard, Google Gadgets and more.  This will give you a much larger scale than with just relying on Facebook.

3- Focus on building a network effect that is proprietary. For long-term success, you should focus on building your own brand and community as a self-standing service that does not piggyback on platforms. Achieving critical-mass to build such networks is getting more and more difficult but you could use some of your short-term gains to your advantage.