Notes from Future of Web Apps (FOWA) Conference in London '07

I attended the FOWA conference for this week in London. I enjoyed the conference, and some of the talks were interesting. I'll post my notes from some of them in separate posts here.

The highlight of the conference turned out to be the filming of 'DiggNation', a podcast by the founders of Digg, Kevin Rose and Alex Albrecht. Though most of it was childishness and how should I put it... bullshit, they managed to get the crowd really motivated and engaged. It was a great demonstration of marketing. While all they were doing was marketing their website, they managed to get the peoples' attention off that fact. They got girls proposing to them, which got other girls in the audience engaged. Talking about beer and booze, and cursing a lot, got the guys' attention. And giving free beer before and after, didn't hurt... In all it was a great performance.

From the talks, the common themes of the conference were:

1. Growth is essential, and the new social apps are well set for this. It must be made easy for the users' to invite their friends. Things like importing contacts from address books, sharing items with friends, newsfeeds (as in Facebook and Twitter) go a long way. People want to keep relationships with their friends and this should be made as easy and fun as possible.
   
2. Scaling is an important problem that all startups face once they start growing. Many developers mentioned services like Amazon EC2 and S3, which allow developers to quickly add or subtract servers/machines as the demand grows.
   Many founders/developers also mentioned the use of Memcached to cache objects in memory, and save the database from excess traffic.
3. About communities, most speakers rightly suggested that the startup founders should actively participate in their communities. They should be open and honest with them about the features that they are going to implement, and the decisions that they are taking. Any mistakes should be quickly owned up to and apologized for.
   Instead of hard-and-fast rules, there should be guidelines on how to use the product/community. Different and un-intented uses of the site should be allowed and learnt from.
4. About hiring, there were different opinions from different speakers. Some speakers like Matt Mullenweg of Wordpress encouraged hiring only when there are no red flags, and we are assured of the quality of the new hire. Some on the other hand, enumerated not hiring fast enough, as one of the mistakes they made.

In all it was a good conference, with lots of good speakers. From a point of view of a founder, it was interesting to see how other startups are dealing with the same problems that you are faced with. It also helps one's confidence to see other people who are achieving success, are actually not that different from you...

Update: Slides from some of the presentations are uploaded here - http://www.slideshare.net/group/future-of-web-applications/slideshows

FOWA: Paul Graham - Future of web startups

This is part of a series of posts with my notes on various talks I attended at the FOWA conference in London. Here are my notes from Paul Graham's talk on the future of web startups. You can read the whole essay here.

Future of Web Startups - Paul Graham (YCombinator)

Paul Graham of YCombinator postulated that Web Startups will also follow the pattern of any other technology that we have seen many times before. Initially, someone invents an innovative product/technology which is expensive. But soon after, someone figures out a way to do that cheaply and ideas and number of ways of doing it, explode.

The cost of starting a web startup has also decreased dramatically in the new web age, and this will have implications on what will happen in the future. His predictions were:

1. There will be a lot of them. As the cost is decreasing, the only threshold left is that, do you have the balls to work in a startup.
2. Standardization of things that are produced en-masse. As there will be many startups, there will be a standardization of the way, the deals are done.
• Standardization of Terms of business agreements. At the moment, every VC/Angel can come up with his own terms and deals. But, when the competition will increase, the funding packages and agreements will become standardized with set deals.
3. New attitude towards Acquisitions. Companies like Google have solved the stigma of acquisition and they use acquisitions to recruit smart people and ideas. They know this from their own experience.
4. More competition. As there are more startups, people will have to take more risk and do more crazy stuff do differentiate themselves.
5. Younger Nerdier Founders. More technically minded people who are generally wary of the business side of things, will be able to build new products. They can release good products on the web and get users first, before going to any investor.
6. Technology hubs like Silicon Valley are still needed, as they enable face-to-face meetings and easier visibility.
7. Also needed are Judges who can pick winners. VC firms and Acquirers both need people who are knowledgeable of the industry and startups. There will be more need for people who can pick the winning companies. Paul also postulates that companies will need to have a Chief Acquisition Officer, whose job is to find who to buy and then buys it.
8. College will change.
• The meaning of 'After College' will change from 'When you Graduate' to 'When you leave'.
• It will matter less and less, where you went to college. Peope from smaller colleges will have similar chances.
• Greatest value of college is who you meet there.
• Instead of studying to get grades, students will study to learn because thats the only way they will learn.
9. More wealth created. More competitors to satisfy users' needs (which are assumed to be unlimited).
10. Faster advances in technology.

I agree with most of the points that Paul Graham makes. Here is my opinion on what he predicts:

1. Location: Even though Tech hubs like SV are still needed, it has become much easier to start/seed new ones. All that is needed is a couple of big successes in an area, and that place will start teeming with entrepreneurs/investors/lawyers/etc. This is what Microsoft did in Seattle, and what is happening in cities like Bangalore and Hyderbad in India. But those first few companies will have a hell of a hard time, when they start...
2. Competition: I think as the number of startups in any space will increase, the key factors deciding success will be growth and responsiveness. Startups that can move fast, add new features quickly, and have shorter cycles will gain traction quicker. Also, startups will have to be more risk-taking, as PG pointed out.
   
3. Measures of Success: As the cost of starting companies decreases, the pressure to generate revenues will also decrease. So, the startups will focus less and less on making money, and more and more on growing the number of users. The measure of success now will change to popularity, growth and brand, rather than revenue.
   It is noteworthy that this is not the same as the Bubble in 2000, as the startups are not spending money as they did then (on huge marketing campaigns and hiring). The startups on the web will become more like charity businesses...
   

FOWA: Kevin Rose - What I learnt about startups

This is part of a series of posts with my notes on various talks I attended at the FOWA conference in London. Here are my notes from Kevin Rose's talk on what he learnt while starting Digg and Pownce:

What I learnt about Startups - Kevin Rose (Digg/Pownce)

Kevin Rose advised that if you can bootstrap then you should. In the beginning, he invested some of his money into Digg and acted as if he was an investor in the company. So, he looked for metrics to decide if the progress was good.

He then went to elance.com and got a coder. And it took them one and half months to get to a Beta version for Digg. One mistake that he admited making, is that he didn't prepare for scaling and for the long run, and which was a lesson he learnt.

Kevin Rose also suggested that it is better go for rented machines or clusters rather than build them in-house. This way you don't have to worry about the hardware and networking problems. For Digg they tried Calpop (which he liked), Ev1 server and Media temple. He also mentioned that Amazon S3 was a pretty good service.

About design, he pointed out that if you find yourself using Photoshop filters, it is time to hire a professional design person. Digg was originally built with a geek design (like Del.icio.us), and later Daniel Burka came in to improve the design.

Features that worked for Digg and Pownce:

• Import contacts from address books all over the web (outlook, gmail, etc). There are code widgets that do that for you.
• An 'Add Friends' button wherever you are on the site and the page. (Single click done deal)
• A 'Share this' or 'Shout it!' underneath each story.
• Emailing a story. (Add icons for email clients, etc to make it easy to understand how this works)
• Have an 'Add friends' directly after registration, and connect them there first hand. Don't force them to do it though.
• On Pownce, the Recommending Friends to each other feature is popular.
• News links on Digg got indexed by search engines, and so many times the first link from a search result for a topic would be the Digg story. This lead to a lot of traffic for Digg.

Scaling recommendations:

• Use Memcached to cache data.
• Hire a DBA to review your db schema.
• Hire an Admin to review your Apache config.
• Visibility: Use Google Analytics and build a custom admin page to review all your stats. Use utilities like Nagios for downtime reporting/messaging.

FOWA: Matthew Haughey - Creating communities

This is part of a series of posts with my notes on various talks I attended at the FOWA conference in London. Here are my notes from Matthew Haughey's talk on Creating and managing communities:

Creating communities - Matthew Haughey (Metafilter)


Matthew Haughey talked about the lifespan of communities, and mentioned that they follow a graph like this one:

He mentioned that a community site has to become a third place for the user, after home and office. If has to compete with pubs, sports teams, TV and other such attention keeping things. The internet, Facebook and World of Warcraft are examples of this.
To do this we need to have a compelling idea.

He suggested that online community developers should have a basic model of a social toolkit in mind, and websites like Flickr is a good example of this.

He also emphasized that one must use their app themselves, and force oneself to use it even if it is bad.

In the beginning (and even later), Highlighting the best (features and content) in the app is very important, and we should make it easy for users to find this. One should also elevate the power users. Not just the content writers/submitters, one should highlight/award the readers too. The best contributors can be made moderators.

Once the community starts growing, one should get out of the way and let the users carry it the way they want. One should build in flexibility and allow for unintended uses of the your site.
It is very important to find and build out of the edge cases, or the weird ways in which your users are using your site. This will give us new ideas and maybe new directions.

Instead of rules, there should be guidelines from the beginning that define how to be a proper member of the community. While making decisions, emotions should be kept out of the decision process.

Happiness for users is ephemeral and one downtime can kill lots of goodwill. Every community suffers a revolt.

You'll spend more time on customer support than on coding.

How to avoid disaster:

1. Be transparent. Be honest and responsive with the community and explain things to them.
2. Have a dedicated place to talk about the site and its issues. Otherwise the talk will be all over the web.
3. When you make a mistake, acknowledge it and be quick in the response (same thing said by Kevin Rose of Digg).

Legal issues: Find a lawyer/expert who knows the internet. You should have a Corporation LLC, TOS, Privacy Policy and DMCA(copyright) policies in place.

FOWA: Matt Mullenweg - Architecture of Wordpress

This is part of a series of posts with my notes on various talks I attended at the FOWA conference in London. Here are my notes from Matt Mullenweg's talk on the Architecture behind Wordpress:

Architecture of Wordpress - Matt Mullenweg (Founder)

Matt Mullenweg talked about scaling as the biggest technical issue facing Wordpress as the site grew in popularity. He talked about Scaling the Platform, your Community, the Business and scaling the people in the company.

Scaling the platform: Matt explained about a configuration that he calls "Matt's magic mini-cluster". It consists of 7 boxes and costs about $1500 per month.
It consists of:

• 2 Load Balancers. They can have any CPUs, 2GB RAM, and have Pound+Wackamole+Spread. I don't know these are?
• 2 Databases. Any CPUs, 4GB or more memory, Fastdisks and RAID.
• 3 Web servers. Fast CPUs, 2GB RAMs, Litespeed or a well configured Apache and any type of disks.

http://2007.wordcamp.org/schedule/hyperdb-and-performance/

Other tips:

• Put everything in Source Control (Subversion), including config files, etc.
• Be Stateless - keep nothing to share between calls. This makes load balancing easy. Username/Password, etc and other session tracking stuff can be put in cookies and read from the request.
• Use Memcached - which is an in-memory cache table.

Scaling the community: http://photomatt.net/about

Scaling the business: Matt talked about how WordPress changed its business model from that of paid upgrades to that of advertising. He also pointed out that people coming to the blogs from a search engine, generate the highest ad revenue. They have an intent to search, and thus click around more. Other users were not shown ads. Matt does not like ads and prefers to show as little ads as possible.

Scaling people: Hiring is most important for startup. Each new hire should be smarter than you, otherwise the average 'smartness' goes down. Matt said that hiring should be done very carefully, and if there is even a single reason to say no, then we should say no.
Great people = Rich environment + Worthwhile problems

Things to look for in new recruits (in dec. order of importance):

1. Personality fit.
2. Ability to learn and gain new knowledge quickly.
3. Taste
4. Passion for the space they are in.
5. Familiarity with the technology. This is less important as smart people can learn new tech, but if deadlines are close, a familiar/experienced person is needed.

FOWA: Daniel Burka - Interpreting user feedback

This is part of a series of posts with my notes on various talks, I attended at the FOWA conference in London. Here are my notes from Daniel Burka's talk on Interpreting Feedback from users:

Intepreting Feedback - Daniel Burka (Creative Director, Digg.com)

Daniel Burka identified three stages during the development of a product/feature which can be different from each other.

1. Before starting to design/develop the product, decide if the feature is worth it? Do decide, rely on previous feedback from users and participate in the community. Try to anticipate areas of friction beforehand, and attempt to handle them. Focus groups and usability studies are worth it, and can help to identify these areas of friction. Also decide beforehand, what success means and how it will be measured.
2. Gathering feedback during development and alpha testing: Based on the type of feedback, there can be different strategies of gathering and intepreting it. Types of feedback:
   • Positive feedback
   • Bug reports.
   • Negative feedback. Interpretation is different depending on when you get it. If just after launch, this could be because of changes in the set patterns of users. If you keep getting -ve feedback after 2-3 weeks then there is an underlying problem that needs to be fixed.
   • Expert feedback.
   • Implicit feedback. This consists of observing user behavior and metrics. It tells what is actually happening, and speaks for silent users.
3. After product launch you have to react to user feedback. The procedure to reacting to feedback should be:
   Step 1. Dont do anything. Watch and listen for a few days (except for bugs).
   Step 2. Identify themes and strong ideas. Look for a bigger problem underneath smaller issues and also patterns in user needs.
   Step 3. Engage your community and talk to them. Participate and be near your users.
   Step 4. Iterate.

Lessons learned:

1. Plan for a ton of feedback. If possible hire someone to handle it, otherwise you'll spend large amount of time responding to feedback.
2. Anticipate negative feedback.
3. Listen to your community.
4. Usability testing and focus groups are useful.
5. Don't panic! Take your time and analyze the situation.
6. You can't please everyone and don't try to.