About Me
Twitter Stream
People Inside
Search
Thursday
Jan292009

What telco history tells me about Facebook business model

Did I tell you that I spent about 10 years of my professional life building high bandwidth pipes for telcos and blue chips ? During those years, I watched the advent of telco domination, but also their struggle to reach for the high margins of content providers.

Being a telecom operator is really a profitable but ungrateful task. You spend billions of dollars building the network infrastructure, and you resell access to this infrastucture to customers. Those customers use it for lots of different interesting tasks, from IT back-ups to video delivery. Being Apple, SAP, Youtube or Skype is much more fun than being AT&T, T-Mobile or Orange. 

As always with profitable but gloomy businesses, the boss wants to be an artist. He wants to launch new ventures, do sexy things so that he can be proud of and be invited to hype parties. So telcos have tried to become content providers for years. At the beginning were the ISP portals, then there was triple play, now there is mobile DVB. Telcos want to be television channel providers, buy start-ups or develop web services. 

They are crazy about Google billions revenue and valuation, because Google is just using their pipes for free. They would prefer Net tolls to Net neutrality. But they just can't compete when it comes to end-user benefits.

Well, it takes time to go from digging the streets to providing content. It takes a change of culture and mindset too. It takes switching from capital-intensive deployments to talent-intensive initiatives.

I don't know how the story will end for telcos, if they will be commoditized and content providers will rule, or or if they will succeed in taking a bigger share in revenues and fame.

What I do know is that telcos' infrastructure was built on ATM switches and IP routers. My team installed quite a few. Network technology is the most standardized of many, because a Cisco router must talk to and understand a Juniper router, if the network is to work. There is no other choice for vendors than meet the standards.

But wait. Routers and switches interconnection compose the basic layer to allow for Internet communication to happen. They were the technological layer necessary for building Web 1.0. But with the advent of Web2.0 and social media, another layer is needed on that technological layer. And that layer is the social graph.

I used to say that Internet is a collection of routers, and Web2.0 a collection of people. For the social media initiatives to expand, we need a new layer of people interconnecting in a standard way. Do we have to call the IETF (Internet Engineering Task Force) so that they work on it ?

No, that layer is already there, taking shape everyday. That layer is the social graph, as build by social networking sites. That layer is Facebook, interconnecting 150 millions people. Facebook Connect could in fact become the de facto standard (in networking terms we would say "protocol") to allow people to interact.

Is Facebook the new Cisco ? No, because in social media, routers are now people. Facebook interconnects people and build the social graph. Facebook is the new At&T, Facebook is the new telco, Facebook is a social communication operator (socialco ?).  

If what I feel comes true, it means that Facebook will (like telcos) sell access to the people infrastructure that they have build. And because they are the only one with such a reach, they will be able to demand a high price for this. 

If Facebook is the new socialco, then they will have to get content providers to use their people infrastructure, and enrich it with great applications and content. That's what they are currently trying to do with Facebook Connect, uh ? 

Let's assume that Facebook succeed in drawing the best app developpers, the best content providers on its platform. They will become a media and businesses will pay to access the media. Of course competing social networking companies will try to get their share of the pie, and provide alternatives to app developers and content providers.

In the end, the social graph may become a commodity. Google support of Open protocols like OpenID, OAuth and OpenSocial may well be a way to commoditize access to the social graph before Facebook gets too big.

In the end, Facebook may have the same feeling that Telcos have : we're profitable but the real stars that users love are app developers and content providers. We're profitable but no-one talks about us anymore, because we're just the pipes for Web2.0 to flourish.

Somehow, it just feels good to be an app developer ;-)

What do you think ? 

Tuesday
Oct212008

Tool or Toolbox ? You'd better know



What's the difference between a tool and a toolbox ? This one is easy.

Well, it looks an easy answer, but how come many start-ups mess up with it ? I'm gonna try to answer this, because it really feels as a very important thing to consider.

At first, you decided to design a new product, let's say a blogging platform. So you've already asked yourself the question "Product or Feature ?", and you decided it was a real product, something that people can use to get things done. In fact, that's also the definition of a tool.

You develop your product as a tool, and it's working well. You have a blogging platform that does 80% of what people intended to use it for.

Great.

And then you have users/customers asking for more. They want yet another feature that they liked in a competing product. You ask your developers to add it.

And then your developers see an new great technology that could be used in your product, and they convince you to add the feature that would use it. So they add it.

And then your sales reps/ marketers saw a new market opportunity for your product. They say that your blogging platform could be sold as a CMS if you added a few more features, and they could sell it to much more users/customers. So you ask your developers to add the new bunch of features.

And then your designer is asking you where to put all these new features in the back office. It was a sleek, beautiful and simple back-office, now it looks like MS OfficeXP.  You ask the designer to find a way to switch on/off features, because some users/customers want some features and others not.

Great.

Now you've got a toolbox.

Think of it a swiss army knife. Think of it a Lego. Think of it as Excel Toolbar. Think of it as a box of tools that can help you do many things, but can't help you do a simple thing.

In real life, Toolboxes are made for plumbers or locksmiths.

This is the same on the Web. Toolboxes are great for people trying to do many different things using that the same set of tools every day. Within professional Services companies, web agencies, marcomm companies, employees try to satisfy many different customers by crafting specific solutions for them. Toolboxes are great for these employees, because they can design specific solutions, while learning how to mix and match tools within the toolbox, so the next time they have to build a solution, they have some prior knowledge.

Toolboxes are like infrastructures.

They enable many things to be done, but don't specify the right use for a specific task.

Like infrastructures, the more generic they are, the more they will be used. Like infrastructures, the generic part brings constraints, because there is always a limit to what you can do with it.

On Highway 101, every type of running vehicule can be driven, cars, trucks, buses, bikes. But if you want to get out of it just right there, you'll have to wait for the next exit. 

So if you want a specific job to be done, toolboxes may not be your friends, because they will impose generic constraints on what you can do (so that other uses are possible).

On the other hand, a single Tool must be as specific as can be, so it will resolve your specific needs with efficacy.

It must be dedicated to a simple task, and help you realize it as fast and smoothly as possible. The user interface must be elegant, simple, clean so that you don't ask yourself questions on how to use it. You don't want to read the fucking manual (RTFM) to be able to use it. You want to use it like a pair of scissors. Cut, cut, cut.

So what's in a choice ?

You sell Tools to people that want to get things done, and they usually are not technicians (the house owner). To build a tool, you need developers and designers that understand usage. A Tool is essentially a Product.

You sell Toolboxes to people that want to be able to do things, and they are usually technicians (the plumber). To build a toolbox, you need developers and designers that understand technologies. A Toolbox is essentially a set of Features.

What was your choice ? why ? Did you stick to it ? I'm all listening.

 

Sunday
Sep212008

Product or Feature ? You'd better know.

What will be the outcome of your stealth-mode, revolutionary project ? A product or a feature ? When you're the founder of a start-up, it's a very important question you've to ask yourself, but sometimes it is very difficult to answer.

I met quite a number of web entrepreneurs,  and  most of the time, they were thinking of what they did as a new product, trying to brand it, to make it visible, to grow trafic. I met few people saying that they're adding a feature to an existing product or market.

Why do we prefer to think that we make a product ? 

Well, the difference between a product and a feature is relative. A video commenting system can be a feature for a blog platform, but a blog platform can be a feature for a CMS, and a CMS can be a feature for a CRM and a CRM can be a feature for an ERP.

When we start a company, we usually have a dream in mind. We want to change some part of the world, because we think we can make that part a better place. We expect the outcome of our project to have a big impact when it is eventually rolled out. We think we have the mission to do it ourselves, that it is our endeavour, and our cross to bear.

Because we think we're the only ones who can make the dream come true, it is very instinctive to think that we're crafting a product. A product, that we can design, develop and sell by ourself. . A product that all users are waiting for. A product that will suffice itself, that users will use for itself, not because they need to get something done.

I see a lot of these entrepreneurs and (would-be) products. They are trying to make the whole world use their product, but they seem to avoid the question : what is the goal of the user when he is using my product, and how does my product helps him pursue that goal ? 

Whatever we do, the users must find value in our product. Value can range from business process efficiency to personal pleasure. But there must be value. Value lies in the fulfilment of a goal. Where does your product fit in that goal ?

A product is used to get things done.

Most of the time your product is not enough to satisfy that goal. It is doing a small thing somewhere along other things that users have to do to fulfil that goal. So basically you're part of a solution.

Most of the time your website does't say so. It says that your product is the solution to do that small thing, not even aware of the bigger thing to be done. Most of the time you're actually making a feature for an encompassing product that you don't know.

 

What are you trying to say ? That I'm not doing the right stuff ?  That a new technological feat is not enough to make people adopt their product ?  That  having an article on TechCrunch is not the ultimate goal ?

 

Well that may work actually...for some time. They may find users that don't pursue any goal, other that spending time on the web, testing everything and looking cool (well that's a goal in fact...). They may test your product, find it cool, and give the word. That may work if flocks of users think it's cool. Until the nu cool.

 

Are you implying that a feature is a lesser product ?

 

Absolutely not. 

In fact developing a feature is a great thing, and you should be proud of it. 

First, it is real innovation, it doesn't have to deal with messy integrations, aggregating lot of stuff, supporting end users that are necessary for product developers. So it can be dead pure and simple. If you're a bunch of great engineers but don't know how to manage or sell, developing a feature is a great way to match skills and market needs.

Second, most product vendors are dying for innovation, and they just dream of new features that they can quickly integrate in their product without the hassle of managing developpers, roadmaps, planning, and the like. NB : of course you need an API.

Third, the market needs consolidation, and consolidation appears at the product level, not at the feature level. So being part of an eco-system can be quite confortable.  IPod accessory vendors know that ((First movers at least).

 

My point is : if you're making a feature, you'd better know. Because knowing will :

 

  1. Save you a lot of money otherwise spent in trying to appear as a product
  2. Make you understand the right moves so your feature becomes a must-have for surrounding products 
  3. Make you understand your exit options (who you can sell to) 

 

If you're making a new feature, your goal is to understand how it will improve users life, and in what circumstances will that happen. When you find the environment, you can find the main actors of that domain and make them understand that your feature will improve THEIR USERS' life. Make them understand that you bring VALUE to their product.

If they believe you, they will soon integrate your feature in their product, you'll share revenues, you'll have access to their end users, and your feature will spread rapidly. Competitors will want it too, and you can grab the market. If all goes well, you may grow without VC money, and if ever you need it, you'll be able to articulate exit opportunities.

Of course, in order to drive interest, you must have a demo, so you'll have to integrate your feature within the user process. You'll need a website so that people you talk to, and others, can find information materials. But don't try to pretend you're a product and try to make your website a destination site - BTW you're not a media, so don't be afraid of your trafic is less than Yahoo or CNN.

Don't go to big conferences trying to appear as the next big thing, unless the people you're targeting (the product vendors) are in the audience. Better call the vendors and do one-to-one meetings.

If surrounding vendors don't hear you, you may have to go your way without them, try to be visible and patient. . If one vendor ask for exclusivity, don't give it to him unless he is the leader in his field.

 

So what do you do ? A product or a feature ?

 

PS : For my part, I have gone through the question, I believe we make a product and we are seeking great features !

 

Upcoming : "Tool or Toolbox ? You'd better know."

 

Thursday
Sep112008

What if Streams go mainstream ?

It just came as a flash : Google doesn't index the content produced within Facebook and Twitter.

Looks obvious when you think of it, but nevertheless shocking. 

That robots don't reference Facebook is easy to explain : Facebook is a password-protected social network. Still, a lot of content is produced on Facebook, and you can only search it within Facebook.

That robots don't reference Twitter is a bit counterintuitive, because Twitter pages are public. After a while, I understood that mini-feeds were quite difficult, as well as not very productive, for search engines to reference.

Why would Google index my tweets ? They are short lived, and even Twitter doesn't allow me to see my older tweets (maybe they archive them for future evil use, but that's another story). 

The context if tweets is also very difficult to grasp if you are not following the ongoing conversation flow. I may tweet something in reaction to someone else tweet, and if you don't follow both of us, you just can't understand what's going on there. So if Google ever indexed tweets, a user searching for me would find links to pages with poor content and no context.

If we go one step further, mini-feeds or activity streams can't be inserted into usual web pages, because they are real -time, short-lived, event-driven pieces of  information that don't match with editorial style static pages. You can only insert a feed into another feed. Once again, it is obvious when you say it, but it must be said.

That's why tweets can be indexed by RSS driven search engines like Google News Alert or Technorati. 

But, wait !

Every new web app is mimicking Facebook mini-feeds or Twitter activity stream. The Feedization of the web is going at a fast pace, and a lot of content is now consumed through these short news messages. Is mobile SMS taking on the Web ?

Among other things, I use Twitter as a substitute for Google or Delicious to discover interesting links, filtered by the network of the twitterers that I follow / trust. I also use it as a substitute for emails to communicate to my staff in my company. I also use it as a substitute for chat when it comes to have a short answer from a brand customer service. WOW !

I tried Snackr a few weeks ago, and I think tickers may be the future of feeds visualization. We're so used to tickers on news TV (CNN and the like), that tickers could go mainstream in a flash.


So Mini-feeds/ Activity Streams / Tickers are on the way up, and nothing seems to be able to stop that wave...

What about Google then ?

Google main search engine indexes pages of information that are there to stay, and add ads over it. What is the crowd rallies the feeds ? Less search, less ads impressions, less trafic...

NB : Suddenly blogs seem a good compromise between static pages and streams. Blog posts are up to date and archived by Google.

So what happens for ads if streams go mainstream ? Ads will have to be in the Streams (cf Twitter Testing Advertising), but then we go back to the old media model. TV and radio channels are Streams, and advertisers chooses time slots to broadcast their ads. As of today, everyone of us is a channel, so will there be channel aggregators that will merge our streams ? Will we see web Tivos ?

Lots of questions, lots of innovation space, great times.



PS : This post was first inspired by Fred Wilson's  The "Feedization" Of The Web (continued)


 

Thursday
Sep042008

Groups : forgotten children of social media ?

"Technology changes, humans don't." says Deborah Schultz

I always have this motto in mind when I give a rapid look at a new web service. Like my friend Eric says, "if it didn't work in the Middle Age then it won't now". 

I won't tell about the weird services that I see popping up everyday, focusing on technology, not on people usual behaviour. Better talk about something that is working in real life, but seems to be vastly overlooked by web initiatives.

I want to point at Groups as the forgotten children of Web2.0 services (they say Social Media now).


GROUP : A number of people or things that are located close together or are considered or classed together.

 

Call them clusters, tribes, communities, clubs, lists, parties, etc., Groups are a very common result of human behaviour. We group with other people more often than we think. 

Family is the first group that we're part of. We share with our family lots of things, that we wouldn't share publicly with strangers. Then there is the Friends Group, with college students and first dating partners. Then there is the professional Groups with colleagues around a company endeavour. Then there is the social networking Groups, with people you  met and appreciate.

Groups are there so you can share with members many informations or feelings or actions. In prehistoric age, I believe groups were the founding brick of Society, motivated by higher security and hunt efficiency. Groups are a way to feel stronger, to make projects possible. Groups are also an organizational entity used by start-ups and corporations.

So it feels strange that groups are so absent of popular web services, that mostly shoot at the individual level and seldom at the group level. 

Want examples ?

Well, let's take Delicious and Twitter. These are two of the most popular web services, yet they don't sport groups. 

Delicious enable users to bookmark their favorite web pages. That's a great service, because you can see what each other is bookmarking (if it is a public mark), or save links for your own future use (if it is a private mark). 

What would you do with groups ? Well as a company CEO, I'd like my staff to privately share links (of roadmap ideas, future partners, competitions, potential customers,...) with the internal company GROUP. Members of the group could choose to share links publicly (as a communication mean) if a moderator allow it.  

Would be the same for a magazine editor, a technology geek team, or a non profit-organization.

With groups, we could take bookmarking to the next level : a collective intelligence system for knowledge-sharing. Without groups, it stays a personal tool, with limited reach.

Twitter is another great service for micro-blogging that the other half of the web is using (almost). You can write a few words about what you do, think or see, and share it with your followers. It gives a realtime overview on what your friends or contacts are interested in. 

What would you do with it if Twitter had groups ? Well you could share information about what you do or find interesting with your workmates, sport team or tour planners. I really wanted to do that with the company, because it is really easy to lose contact about the company activity stream even for small teams. Name of the latest customer, new feature availabilty, competitor actions, you really want your staff to stay connected. 

It was not possible within Twitter, so we had to find a workaround to do it, and it is now a pillar of our internal communication (more on that later).

Don't misunderstand me. I'm not saying that Groups don't exist in the Web20 realm. Some major apps understand the Power of Groups, in particular Social Networks : Facebook Groups and Fan Pages are basic Facebook apps, and LinkedIn Groups are useful. In their cases though, Groups are quite mandatory, they serve as categories or tags.

Within a social media app, I think groups should have access to (at least) the same level of features that individuals have, added with specific features like moderation to accept new members and manage public/private toggle. Groups members can be added by the account owner (à la Alltop), or added on demand (moderated or not). Features like adding content, scoring, analytics, should of course stay available with with the added scope of Groups. How does one Group compare to the other ? What is the most active Group ? are some questions that the app should help answer.

Of course, Groups interest Brands. 

Marketing focus groups are there to stay, and wise web apps should be aware of that. The white label monetization strategy is of course a clear candidature for adding Group features. Associated with good CRM targeting, they can give real insights on Group feelings and behaviours that Corporate Marketing Depts love. HR and internal communication officers could also be very interested by Group targeting.

To make a long story short, Groups are in our Genes. "Technology changes, humans don't." So whether you're a web app editor or user, you should add Group features as a request on your roadmap.

Please, WWW, give us Groups, and we will group together faster than the speed of a page download.

 

Comments welcome !

 

PS : Feel free to list Web Apps that have a Group strategy or new Group features.