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: 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.