Summarizing last week’s trip to ‘Future of Web Apps’ event

Deciding to get out of the office to attend an event like last week’s Future of Web Apps event in San Francisco is never easy for me. Going to something like FOWA means time spent flying both ways (which totals out to about one to one and a half working days for a round trip to San Francisco, when all is said and done) and being out of the office for a couple of days. And we’re a small company so there’s always a lot to be done and things I’m working on definitely do fall behind (though I also get certain types of work done while I’m traveling that aren’t as easy to get done while I’m in the office).

So anyways, if last week’s FOWA was any indication, it’s definitely worth it to get out to these industry events. Being in Houston, we simply don’t get the same level of knowledge-sharing and idea cross-pollination (at least not outside of the office) that I believe are commonplace for people working in technology in Silicon Valley. So getting out of Houston and getting immersed in that is definitely a good thing, if nothing else, for motivation. From the Seven Rules of Motivation, attending events like these nails both “increase knowledge of subjects that inspire” and “socialize with others of similar interest.”

Unlike the few other “social software” events that I’ve attended in the past (basically, Gnomedex this year and last year), I took _LOTS_ of notes and in a sort of experiment, I’ve taken the time to put them all online.
My favorite talks were from:

  • Tom Coates (he highlighted principals behind social software in a generally theoretical framework)
  • Ted Rheingold of Dogster (his presentation was, I thought, the practical yin to Tom Coates’ more theoretical yang)
  • Cal Henderson (presentation on lessons learn at flickr– a mix of operations and developer stuff)
  • Cal Sjogreen of Google Calendar (basically a walkthrough of the process, from vision to launch, that lead to Google Calendar being created).

But there wasn’t a single presentation that I didn’t learn something from including those from Evan Williams, Matt Mullenweg, Jeff Veen, Mike Arrington, Steve O (Feedburner), Kevin Rose, and Dick Hardt (SXIP). And I have to admit that there were a couple of presentations that I missed… unfortunately.

All in all, this was a great event — thanks to Ryan and his wife Gill and Lisa Price for putting together such a great event.

Evan Williams’ five best screwups at Odeo

There’s a good write-up over on Om Malik’s blog but here are my notes from part of Evan Williams’ talk at the Future of Web Apps event in San Francisco last week:
Evan Williams at Future of Web AppsMy five best odeo screw ups:

1) we were trying to build too much stuff from the get-go

2) building for people not like ourselves: should have focused on listeners more, it turned out that not a lot of people didn’t want to use our podcast building tool

3) not adjusting fast enough: should have been more honest; wasn’t a purple cow by the time we got it out into the market engineered more and more for on page listening, flash players you could embed in other pages

4) raising too much money, too early

  • $70k to build the first version (Noah and a couple of contract developers)
  • opportunity to announce at TED
  • Ev joined the company full-time and put in another $100k
  • Angel-fund raising went well (over $1M committed after a month)
  • went and talked to a couple of VCs, made the rounds at a few different firms, charles river ventures (George Zackary)– three times valuation that we were raising the angel money at–> what should we do? –> decided to do at VC valuation instead of angel valuation. Rolled angels into that round
  • why was this problematic: think of money like fuel, see how people apply that fuel… you need to have the engine to put that fuel into, you can pour it on the floor and light a fire and do nothing (ha). Odeo didn’t have a product or a proven market
  • Google has fuel
  • scaled down our team
  • best scenario is probably to have the fuel waiting around until you are ready to burn the fuel

5) Not listening to my gut

“When I came hom from work I sat down and I forced myself to code for a hour or two. The enemy was thinking, whenever I paused or started to think I would force myself to type something, its amazing how much you can get done when you just type.” –Markus Frind, plentyoffish.com

‘Don’t talk. Type.’ big poster…”

Matt Mullenweg, “The Story Behind WordPress”, my notes

IMG_2925 Matt, creator of the popular blogging software WordPress and the popular Akismet anti-comment-spam service (we use it at SnapStream and love it) gave a talk at the Future of Web Apps conference in San Francisco last week. Notes from his talk:

Here’s what downloads of WordPress have looked like:

version | downloads
1.2 – 822 a day
1.5 – 2506 a day
2.0 – 5115 a day
2.1 – ???

SourceForge –> no SourceForge, it slowed us down because it took 20 clicks to trigger a download

It’s good to install your app from scratch every so often, that’s how we discovered the terrible download process that was part of SourceForge

More eyes = better software

  • is this true? everyone wants their 15 pixels of fame, if there’s a disagreement, the easiest resolution is to satisfy everyone (“put it on the left and the right” or “implement both features”) –> not a good way to do design, openoffice’s horrendous configuration menu is an example of this

Plugins++ — “luckiest thing that I ever did”

“there are no more killer features, there aren’t any because there are now 10,000 killer plug-ins and they’re all developed by the community.”

APIs++ — breaking APIs is WORSE than never having any at all–> put a little bit of thought before you build

Plug-ins vs. core

  • should everything be a plugin? (like Drupal) –> Matt says “no”, something that does everything generally doesn’t do anything well.

Do your own support: viscerally feel the pain of your users, example: Easter massacre at WordPress where a lot of stuff got deleted, Matt answered every message himself like self imposed punishment.

Pages: to figure out what to create, watch what they do, not what they say (people wanted multiple blog functionality — but it turns out they were using multiple blog to do content management… so the “Pages” capability came from this)

Plugins for design (themes): people switch themes ***ALOT***

What sucks now?

  • no central aggregation of wordpress themes and plugins


Pingomatic

  • search engines like Technorati, etc need to know when a new blog posting is made or updated.
  • it’s really, really heavy… 30M pings
  • you will get spammed –> if there’s anything I know about the future of web apps
    • Yes, you
    • Social software is anything that gets spammed”
  • plan for success
    • have you ever seen a car chasing a car, what happens when the dog catches the car? “rawr” and that’s it?

WordPress.com

  • pageviews has been growing faster than visitors –> 2.2M pageviews per day
  • far larger scale
  • all hosting sucks — 100% SLAs are a fiction
  • redundant networks and power –> a fiction, don’t pay too much more for that
  • make backups constantly
  • get a bunch of sucky hosts and hope that no one hosts sucks at the same time
  • wordpress.com easter massacre: all files that had ever been uploaded
  • buy cheapest hardware possible –> IF you can stay up when it goes down
  • in the initial dell boxes that we used, they were vastly, vastly overpowered
  • there are three numbers in computing: 0, 1 and n+1, the more data that you have, the more important it is to distribute
  • make it easy to contact you — contact form tripled the contacts coming through to us
    • the guy doing support for us was a nurse for 19 years working with clinically insane people
    • if I turn off my computer, does my website go away
  • what sucks? (on wordpress.com)
    • there’s no feature list on wordpress.com
    • there’s no tutorial
    • documentation is pretty sparse
    • 2200 sign-ups every day: these people really trust us
    • our sign-up emails should be better, some parts of the application that you don’t interact with a lot when developing the product are often areas that need attention.

Akismet

  • anti-spam system
  • ham (legit comments), spam (growing far, far faster than legit users)
  • developer API from the very beginning– simple REST API (is this spam, hey you missed something that is spam)
  • 20+ implementations from Ruby to Lasso (wikis, bugtrackers)
  • scalable business (in all the ways that pingomatic isn’t)
    • the more data, the better the service performs
    • Akismet launched on a $80 / month server and it’s still running on that server (plus some others ?)
  • social software

Be a painkiller, not a vitamin
did some research into these industries
– $300-500M vitamin industry
– $800M painkiller industry

Future of web apps

  • global
  • personal: not interested in subscribing to 800 blogs anymore, care about the people I have real relationships with
  • useful
  • humble: don’t be self-important, frame things in terms of you, the user, not me the application

Speakers –> the speakers on stage here aren’t the important ones. Who is? Next slide…

You. Build for yourself first. Working for someone else, not always the most attractive thing.

Business model –> important.

Never forget how lucky you are –> Don’t waste it.

Notes from Jeff Veen’s talk

Jeff Veen, who moved to Google as a part of Adaptive Path’s sale of “Measure Map”, gave a talk titled “Designing better web app interfaces”.  I didn’t take as many notes in Jeff’s talk, but his entire presentation is available online at:

http://www.veen.com/nextgen.pdf

And the few notes that I took are here:

Bubbles:
1) 17th century in Holland: Tulipmania: technological revolution, trade ___ opening up with Turkey
2) Industrial revolution: cars
3) abstraction of wealth into information (stock exchanges)
4) Tokyo in the 80s
5) Pets.com (web 1.0 bubble)

booms and busts happened all the time

fold.com… folds (from the frontpage of techcrunch)

Web 2.0 –> what does this mean for design
— not just visual design (typography, color, layout)
— also interaction design: the way that the way an application works and how that communicates what the application does

1) Giving up control (especially true with visual design)
with print, the designer had full control of the design
huge shift: now control is in the hands of the user

use visual design competency to built trust with users, empowering them to control their data

– Caution this sign has sharp edges… fine print: also, the bridge is out ahead

iFilm — catch errors before they happen (let ’em know that their username is taken — ifilm.com)

Providing context to people

Feedback: how the system responds
— really imporatnt to respond to changes people are making

Information architecture: how information on our site is organized and communicated to our users

“Given enough eyeballs, all bugs are shallow.” The Linus Law

Cal Henderson’s talk at FOWA: lessons learned at flickr

Notes from Cal Henderson’s talk at the Future of Web Apps conference in San Francisco:

(note, a PDF of his slides can also be found here):

I’m not going to talk much about scaling, you can buy my book or this other book.

Flickr’s come a long way

Diagram: Things we already know, things we needed to know (there’s a small intersection point and it’s labeled as “HTML”)

What we learned, wasn’t unique (we weren’t unique and beautiful snowflakes)

Advance notice of outages (if we’re going to be down, we let people know 2 hours ahead of time and we put it across the entire site)

Disable stuff by component — put architecture in place so you can take one thing out of service and keep everything else running. Obviously, this can’t be done with everything.

Tell your users
– communicate what’s going wrong, be completely open
– if you are down for xyz reason, explain that xyz reason (obviously, if you have a crash, don’t go post your stack trace)

Clear escalation paths
– large applications are going break
– the most important thing you can is having escalation paths — what happens when things break?
– who are people supposed to call when there is something wrong, Stewart Butterfield is surfing at 3am and photos aren’t uploading correctly, who should he call. Cal? DBA? or our 24×7 team? (ha)

In-process alerts

Communication! Creative ways to handle this… put a coloring page up during an outage, clear communication is cheap!

Stats tracking is hard (and important!)
– if you want to know what’s going to happen in the future, have to look at the past
– More graphs, much more graphs, can fit huge dense sets of information on graphs
– tens of thousands of real-time graphs of things

Good tools for graphing stuff
– Cacti (ajax zoom stuff)
– Ganglia (massive stat tracking, friendster using)
— very good for tracking stats for network usage, memory, disk, etc.

Web stats
– usually bad, all of the free ones are awful
– measuremap is good for certain things (blogs)
– webtrends is pretty good, but it gets pretty expensive

Create dashboards!
– Konfabulator, sidebar-like stuff

Visual Complexity
http://www.visualcomplexity.com/vc/
how to visualize large amounts of data

APIs = cool
Who knew?

APIs force clean interfaces– UK power socket photograph
APIs allow for easy regression testing
Automated regression testing

Beware of abuse of APIs: not a whole lot harder to abuse than just web-based scraping, but…be weary of people that are bad at programming (I’m making 20 calls per second? I thought I was making one per hour… Ah decimal place (ha))

Track usage of APIs carefully

URLs

  • I heart (clean) URLs I heart (clean) URLs I heart (clean) URLs I heart (clean) URLs I heart (clean) URLs — I’m obsessive about them, understandable by humans (maybe not all humans) but at least all humans in this room
  • (under 60 characters means things will behave better in emails)
  • (put more improtant stuff on the left and less important stuff on the right so maybe if something gets cut-off, it still works)
  • Never break URLs: December 20th: amazon.com changed the format for wishlist URLs and broke all wishlists, don’t break things, don’t break things!
  • Careful of middle tiers: that is, what is I remove the 1234 from http://www.amazon.com/products/books/1234? What if I remove /books/. If your URLs make sense, what’s the bits that fit between one end and the other end?
  • Don’t navigate by URLs: when developing we’ve released features that aren’t linked to from anywhere because we refer to stuff by URLs– ack!
  • Don’t expose auto-incremented variables: makes scraping every page from the system super easy, maybe this isn’t so important
  • /noun/verb/ :URLs should go from least to specific to most specific from left to right, if you have an action as a part of your URL, that action (verb) should be at the far right.

Hiring people, developers, is really tough
– Good people have jobs
– maybe you can poach people away from something they are already doing…
– Read Joel’s recent article on thi
Giving notice/moving house

Older the product, longer the induction (induction: take a new employee and turn them into an awesome engineer)

Documents saved my life
– one way to reduce the time required for induction is to document!

Release early, release often
– new features and new work, not new products (so what Carl from Google Calendars said yesterday is logical and makes sense too)

Old days of the Internet– Under construction sign everywhere…–> it’s been replaced by an endless beta, “nothing is finished on the Internet” (Cal didn’t say this as a bad thing but as a new application/service software paradigm)

Small increments, visible progress: release in small bits, everytime you release, less moving parts

Lightweight QA, no safety net (we don’t test a whole lot of stuff, we don’t have a QA department… flickr doesn’t have one! we have a bit of an odd process, someone will build it, test it themselves and then be responsible for releasing it) no back and forth of building it and then to testing and then ot build it an then to testing and then to release manager…. too SLOW!!! Correct model for really large teams. If you have three developers, that’s not really large. Without QA, there’s no safety net… true but we’re safegaurded against this by releaseing early and relasing often

At Flickr: developers own processes and not the features: developers own stuff

Avoid branches

Shared development environment –> all three or four or five developers working on at the same time, find conflicts much quicker, you know you won’t have to spend a day after working for three having to merge your code in with the trunk.

No developer is an island: everyone works together

One touch deployment

Automating everything — army of robots, robots and scripts very important

Many tools –> componententize (army of robots!)

Always deployable –> agile, always keep the trunk deployable (being able to release once a month != agile, at least not for web apps)

Pragmatic –> make it work. if it’s maintainable, that’s good too.

Beautiful code –> not a priority, idealogical purity is not a priority, I’d rather get something that works
————————–

This stuff doesn’t work everywhere
Takes the right people and process

Like extreme programming doesn’t start working until you do it all… but then it pays off

Ted Rheingold, Dogster’s founder and “Top Dog” speaks at FOWA

Ted’s talk was one of the best at the Future of Web Apps conference last week. His talk was entitled “The State, Future & Business of Passion-centric Online Communities” and he spent half the presentation (or maybe less) talking about Dogster and Catster and general guiding principals for passion-centric online communities. And the last half or so of the presentation was dedicated to a review of 20-30 different such communities– the latter part was awesome, a lot of fun and a great survey of online communities.

Ted also touched on how he believed communities would exist wherever there members are and that accordingly, you’d see them everywhere from mobile phones, to DVRs, PDAs, mobile game devices, and so on. This is something that I’ve always believed (something that’s reflected in some of the newer things that we’re doing at SnapStream) and Ted’s the first I’ve heard reinforce this notion.

My notes…

Ted Rheingold – Founder / Top Dog
blogs: blog.dogster.com & spideysenses.com

Passion-centric Whats
– passion centric online communities are spaces dedicated to a single particular interest
– they usually include human profile sharing, posting of passion-specific items and offer member-to-member and member-to-group communication possibilities

Other likely feautres
– design, copy, and UI that only refelct the site user’s passion, they amplify it
– moderation is key: a community is a garden and that needs sincere consistent care
– clearly stated ground rules that are community initated and community approved
– precised and considerate safety policies with lots of opt-in/opt-out

Sincerity cannot be faked
– people’s passions do not fit into silos
– using topic agnostic community software will rarely captivate your commnity
– if you ignore your community at any time for any length they will feel it and look elsewhere

Dogster & Catster’s frontpages:

(single code base, every cat word is specific — cats naps, dogs do tricks)
(regular cat page, samoa… blue ribbons, only subscribers can give blue ribbons and they disappear after 30 days — came straight from the forums)
(like locker in high school)
(profile pages are completely customizable)
(meet her feline friends)

Forums
– custom coded, don’t have to register to other forums

Dogster
– diary central, 36,000 dogs keeping diaries, most all of them are writen from the standpoint of the pets
————————–
Aggregate data
20.5 million virtual treats given
7.6 million distrinct friendships
289,000 dog and cat profiles
252,000 human members
50,000 pets keep diaries
16k logins yesterday
————————–
Da’ Biz
Not too many revenue options

– advertising and sponsorships (3rd party ads, affiliate programs and bounties rarely pay more than your expenses)
– subscription programs: a good goal is that the commmunity should be able to support it’s own existence
– selling member-made or site specific items: even better way than memberships fees for community to support itself
————————–
How to make advertising work
– keep your ad sales inside no one will be able to voney your memeber’s passion better than yourself (bring it in and your numbers will increase 10 fold)
– advertisers need to have a direct connection to the communities passions
– CPM is almost dead, for an advertisers message to be heard deliver it in the site voice and in place swhere members are receptive to messaging
– require advertisers to offer something real to the community. something that requires them to participate and become trusted

(if you are doing well, $8 CPM, 3rd party services get down to $0.10 – $0.25 CPM)

————————–
Circle of Trust
Dogster -> Community -> Advertisers ->

(community should like the product, advertiser should be happy)

————————–
Future of passion-centric online communities

– for every passion there will be a dedicated’ster’ and there can easily be more than one popular ‘ster’ passion
– there will be tens of thousnads of pasion-centric online communitiesi in 10 years
– public APIs badges and mini-sites widgets will bring communities to where the mbmber already is
– public/open ID system will be used
– the web is just the launchign point, think cell phones, mms, pdas, console-gaming, hand-held games (PSP/DS), DVRs, car-based computers, communities will meet where their members are

————————–
DeviantArt — started in 2001
35 people
2+ million members
25 milliions pages serves / day
alexa: 177, google PR 7/10
18k online at one point in time
community mood
besides subscription, they sell prints that people make
revenues from subscriptions and orders of member art

ettiquette policy: this is not about being a jerk
————————–
amateur illustrator (based in England, brand new)
————————–
CNet — alot of community in it, amazing job in bringing in advetrisers into the community
————————–
PopSugar — blogging site with interesting products for hip people, make a profile on there, blog, comments, bookmark all your favorite items
————————–
Model Mayhem
Alexa 3896, Google PR 3/10

Models and photographers only
amazing set of rules: no pornography, no GWC (guys with cameras)

————————–
major league gaming
– halo and microsof tgames
– they have a tv shows
– hour long visitor sessions in 2004
– president: michael sepster
– website is just to bring people in and make them happy
————————–
Yahoo Autos
– people add photos of their car
– deep integration, photos, features, modifications
————————–
Edmunds — Carspace
– old company, trying to make a stir
– try to find the word car — it’s not there very much, not good
– lagging behind on alexa
– forums: are boring, “talk about your car”, too much advertising

————————–
boompa— car site from cnet
– your garage online
– add your ride
– random ride, battles
– must better than the edmunds site
– ask the community

– browse guides by categories or model
————————–
faniq: all about sports people
– college or university, good job of replicating a sports fan environment
– every team that has to elect a commissioner
————————–
Feelingbullish.com
– one of the few that’s wokring on a reputation system (has been elusive to deploy, lot of ways to game it)
– stock fan site, get people to stick by their picks and earn your reputation accordingly

————————–
Social picks— putting a faec behind investments
————————–
MyBlogLog
– people who have read my blog recently
– messages below– two lines of javascript that I put on every page
– 30boxes
————————–
Famster
– sharing families online
– “safe, fun and free”
– the safest way to share on the Internet
– can’t get a good feel for them
– could be huge in China (?)
————————–
TheFamilyPost
————————–
Club Mom
Alexa: 11,105
GooglePR: 4/10
Funding to date: $50M
– they are killing with advertising, but they started during web1.0
————————–
Minti is a baby site
– frontpage is a mess which is fine
– I could see 30 baby sites being successful
————————–
Teachade
– share workplan, calendars
————————–
Craftster.org
————————–
VampireFreaks.org
– goth enthusiast sites
600,000 members
Alexa: 4,105
Google PR: 5/10
2-3k members online anytime
4+ million forum posts
backgorund color is black, links are purple
“fuck the mainstream”
page is probably not w3c compliant (ha)
————————–
YourClimbing
— made with Drupal
— person on the homepage
YourMTB.com
– first site for this
– upload photos, videos, etc.
– you register and we’ll give you a free bumper sticker
————————–
EveryTrail
————————–
CuteOverload
– new realm of community
– using blogging software
– ‘commenting is community’
– they won a webby
– they use ning– topic agnostic — for “caption me”
————————–
search on ‘cats’ in Google– two communites in the top 10 hits
AboutCom’s Cats
————————–
Cats in Sinks
————————–
Stuff on my cat
————————–
CatsThatLookLikeHitler.com

Kitlers– cats that look like hitler

(photograph above by Scott Beale and hosted on flickr)

Notes from Michael Arrington’s talk at Future of Web Apps

I arrived a few minutes late to Michael Arrington’s talk, but caught most of his presentation in my notes (see below). Mike’s the editor of TechCrunch, the hub for a lot of the enthusiasm and news coverage around Web 2.0, and he’s one of the self-appointed spokesman and evangelists for this new generation of web companies… which is a absolutely a good thing IMO. From my notes at Gnomedex, Mike’s measure of success for an internet company is 1) it makes money and 2) it makes the Internet a better place. My notes from his talk last week…


Pretty good bets

(missed this slide altogether)

Ones to watch

– 1-800-free-411

(missed most of this slide)
What were they thinking?

– inform
– gather
– pubsub
– browzar (wonderful coverage on techcrunch UK, bbc, nytimes)–> about a week later and people looked closer at it and realized that it was just a wrapper to internet explorer
– jigsaw: 7000 new people coming into the site every day, one of Michael Arrington’s best friends is on the board of austin ventures; companies like this shouldn’t exist, Mike believes that we should have regulation in place to prevent companies like this from coming into existence)
– squidoo

– Purple Cow: must read book
– broken revenue model from the beginning
– put ads up and then you get a revenue cut

(be careful with what you promise people when you launch)

Shared attributes of winners

– passion for what they are doing (opposite of this: don’t over business plan)
– do something extraordinary (purple cow)
– removing serious friction
– great founder dynamics
– never raised big money or raised it after they won
– perfect revenue model not required
– and… luanched their copmany with a post on techcrunch

Shared attributes of losers

– poor founder / team choices
– lifestyle / ego entrepreneurs
– raised too much money (may or may not be sign of a bubble)
– spent too much money
– over business-planned
– forgot about scaling (friendster)
– didn’t launch their company on techcrunch (ha)

What server platform?

– PHP (most popular)
– Ruby on Rails (upcoming)
– Java (serious applications)
– .NET

What client platform?

– .Net ActiveX (no firefox)
– AJAX (monster)
– Flash (growing)
– XUL/XAML (interesting)
– Adobe Apollo (flash applications that aren’t running in a browser)

– with an apollo application there would be no break between a local application or an online application

– Desktop hybrid

Market saturation
AVOID:
– social networking (socialzr)
– social bookmarks (switched away from delicious… but after reviewing 20 of them)
– video (250 video sites now… many of them are funded)
– photos
– blogging/podcasting platforms
– portals / homepages
– feed reeders

BIG POTENTIAL
– Platforms
– Desktop apps
– Office efficiency
– Cloud storage (microsoft and google launching next year, omnidrive, box.net)
– Identity (rapleaf is a company I love)
– Developer tools
– Market destruction
– ENTERPRISE

– typically enterprise innovations happened and then it came to consumers
– hasn’t happened recently– blogs, voip, instant messaging, online storage
– new enterprise blog from techcrunch– dan farber is writing

Note: The best entrepreneur’s avoid this type of advice. Invent a new market.

(photograph above by Thomas Hawk, hosted here on flickr)

The road to Google Calendar (talk by Carl Sjogreen of Google)

Carl Sjogreen delivered an extremely informative talk about how they built Google Calendar. He covers everything from the initial customer interviews and research, to the vision they established for the product, the development iterations they went through, the launch and post-launch reflection. I had a couple of questions that there weren’t time for and I’ve thrown those in the end in case Carl comes across this and can answer then.

Here are my detailed notes…

——————–

How did we build Google Calendar?

Quick Demo

Manage your own personal schedule and share it with other people

  1. Moved a lot of desktop metaphors and moved them to the web. Invested a lot in this.
  2. Also invested a lot in natural language (quickadd)
  3. Also focused a lot on sharing

In the beginning…

– a largely classic Google product team
– 1 product manager and 3 engineers
– Origin was from both customer feedback and internal interest
– Seemed like a space with little innovation — nothing out there was “right” –> exactly the kind of opportunity Google looks for

Okay now I’ve got a team and a vague idea: “Google should do something in the Calendar space” What next?

———-

The Road to Google Calendar: Talking to Customers

– First thing’s first — go talk to “real” customers
– sounds cliche but it’s amazing how little it’s really done
– real customers, not your silicon valley geek buddies
– Spoke to many people, sometimes even in their homes
– students, families, schools, working couples, PTA organizers
– tried to find a whole spectrum of different technical backgrounds
– keep probing: busy is not the same as “needs a calendar”
– Key themes emerged quickly:
– Calendars are necessary but just a chore
– calendars are personal and emotional
– calendar “collaboration” is just too hard

I interview a lot of product managers and one of my favorite interview questions is: How do you go from an idea to a product? One of the things that a lot of people miss is establishing a vision. This is the thing that says that if we don’t get anything else right, this is what we’re going to do well.

Our Vision

– Set out to build a calendar that works for you
– fast, visually appealing and joyous to use
– drop dead simple to get information into the calendar
– more than boxes on a screen (reminders, invitations, etc.)
– easy to share so you can see your whole life in one place

– Designed for a consumer world where not everyone has a calendar (or one on the same system)
– open APIs (import and publish)
– invitations for everyone

————————–
The Road to Google Calendar: Development

– Vision in hand, we set off to turn an idea into reality

– Lots and lots of prototyping
– PHP, MySQL, no Google infrastructure
– relatively easy to get basic system up and running: details are hard
– focused on getting interactions and user model right before thinking about scale (a significant challenge for us)

– Internal Use: Pros & Cons
– Got a ton of great feedback from other Googlers
– Got the interaction basics right & generated a lot of feature ideas
– However, keep in mind that your early user might be not your target users

————————–
Once we felt we had it mostly right, worked on making it real
– backend infrastructure designed for scale (ie “Google Infrastructure”)
– front-end / UI rewrite to pixel perfect mocks + static HTML
– doing all the hard parts (recurrences, parsing icals, API testing, interop, etc.)

Worked on our UI design in stages as well
– Get the interactions down and try them out
– Focus on the look & feel while engineers are making it real
– Save the pixel pushing (fine alignment on the user interface) for when you know you have it right

————————–
Private betas are a good thing
– Even with all of our internal testing we learned a ton from testing with a small group of “real users”
– Quickadd improvements (being smart isn’t always the best)
– Underestimated the importance of import
– Fixed a bunch of issues with SMS alerts (tough to test because of all the carriers)
– Better support for small screens (screen density was really important)

Launch day: 4/12/2006
– Flipped the switch, and didn’t sleep for the next 36 hours!

6 key insights that might be useful for your next product or company

1. Easy is the most important feature
– “simple things should be simple and complex things should be possible” ALan Kay, Disney
– Always have an eye on the minimum useful feature set that most people will use
– talk to grandma in NYC
– a mother loved quickadd (& then prints out the calendar for the fridge)
– Product usage tracks directly to how easy a feature is to find & use
– creating calendars = easy
– finding calendars = not easy enough
– Figure out what you absolutely have to get right and relentlessly refine it
– Redesigned the “event page” at least 3 times
– Kept adding new ways to get events into the system up until days before we launched
– Don’t spend too much time on less importnat area
– Know where you’ll get the most bang for the buck

2. Know your real competition
– know what your real competition does well
– we spent a lot of time looking at the market — online and desktop
– but the competition that keeps me up at night is paper
– ~6 billion people in the world, all who have things going on in their lives
– ~300 billion desktop calendars

– Non-tech and low-tech mechanisms are the way that most people communicate and interact
– email vs. evite
– notepad vs. tada lists
– the ktichen calendar vs. google calendar

– paper has a bunch of great advantages that you need to beat
– easy to carry with you
– doesn’t require boot time
– doesn’t require a login

– focus on removing the hurdles to adoption
– import, offline, mobile, etc.
– mimic the flexibility of paper

– focus on what the web can do that paper can’t
– collaboration
– access from anywhere

3. Visual design matters
“Great Design” it’s that ineffeable quality that certain incredibly successful product have that makes people fall in love with them desptie their flaws.” –Joel Spolsky
– great design = usability + visual joy
– ipod vs. everyone else

4. Build products for people who don’t want to use them

– Not everyone who can benefit from your service actually wants to use it
– change behaviour and workflows are very hard
– Need to make it as easy as possible for people to use your product with as little work as possible
– Get your product in front of the applications people use every day
– And then make it painless for peopel to start using your product without fully switching into a new way of doing things
– Google Personalized Module is a great way to get traffic, by the way… they get a ton of traffic from there.

5. Timing launch properly

– launch early and often is the mantra of web companies
– it IS a fundamental structural differences that sets web companies apart from packaged software
– However the old adage of “you can only launch once” still applies
– leverage internal testing and private betas to get feedback early, but…
– make sure that you have something worthwhile once you land on digg / techcrunch / etc.
– launching is hard to do (it’s never an easy call)
– in our case, expectations were very high
– should we have waited for sync for example
– ask yourself if you could really …

6. Driving usage
– We have a steady rate of new users signing up daily with very little marketing
– How? Made it easy for there to be touchpoints everywhere. (buttons on 3rd party sites, send invites, etc. : many touchpoints))
– Think about how your product can generate touchpoints that eten beyond your app[ (and make iteasy to do so)
– social reinforcement is key for validation
– relentlessly remove account sign-ups
– this is pretty obvious but it was surprising to me how much of a barrier accounts can be

———————

My questions

— WHAT PERIOD OF TIME DID THIS SPAN?
— HOW MANY PEOPLE OVER THE SPAN OF THE PROJECT?
— HOW WERE DECISIONS MADE ON UI?
—WERE THERE OTHER PRODUCT MANAGERS LIKE YOU THAT WERE RESPONSIBLE FOR PORTIONS OF THE EXPERIENCE?

Steve Olechowski of FeedBurner talks RSS

My notes from the Feedburner talk (given by Steve Olechowski) aren’t exhaustive like some of my other notes, they are limited to the things that I found interesting:

IMG_2852

10-15% of videocast/podcast are video

interesting things going on with feeds, lots of growth… 20M subscribers, 500k feeds under management by Feedburner

consumer device can really drive things — iTunes with podcasting set off feedburner managed podcast and videocast managed feeds

more text in my feed = more total traffic

feeds are a place unto themselves

there are over 3000 RSS clients out there (!)

IMG_2850

My Yahoo leads by a large margin as far as number of subscribers (more than 50%) –> Yahoo has done a fantastic job of making RSS a behind the scenes thing. But the tracking here isn’t completely reliable (Google and ____ don’t do things in a way that they can reliably tracked)

IMG_2853

RSS is being read on mobile
– 2900 distinct user agents from Nokia, SE and Motorola
– Top 10
– Nokia podcasting client
– Sony Ericsson
– ” ”
– ” ”
– ” ”
– Nokia Onskreen Fusion
– Sony Ericsson
– Nokia 6630
– Nokia N70
– Nokia 6682

Publishers ARE making money with RSS (there were some interesting slides here like how many ad impressions they are generated, I believe they were in the triple sigit millions per month — like maybe last month was something like 146,000,000 impressions)

Notes: Tom Coates talks social software

Tom Coates, Yahoo (also worth listening to is the podcast of Tom’s talk from the London event)

  • Working for Yahoo in a rapid prototyping unit in London
  • How people can interact to make something that’s greater than the sum of its parts
  • MySpace– impressive site, eaten a whole generation of people, easy to take potshots at it but it’s pretty amazing…
  • Looking up too close at web statistics and at websites is a mistake, have to look at the big picture to see the utility of the whole thing
  • social software: latest in a long line of cooperative things, goes back to things like the alphabet and writing, justice and government, the invention of money.
  • (he was a classicist, studied things related to rome and greece)
  • What is it? It helps us do more together than we could apart.
  • stated another way: Using software to enhance our social and collaborate abilites through structured mediation
  • Characteristics, in a nutshell:
  1. When an individual conttributes, they get value
  2. these contributions should provide value to their peers as well
  3. the organization that hosts the service should derive value and be able to expose this back to the user
  • two models:
  • 1) Consensus: many contributions make one voice (example: wikipedia): Generates canonical or definitive representations in data

openstreetmap.org: response from the bubble community
musicbrainz: about getting new sources of data about music
clear honorable mission is a necessary thing

  • 2) Polyphony: many voices with emergent order (example: flickr): generating a whole lot of material and then manifesting the order in that data, make it comprehensible
    • works a lot better than the consensus model
  • – youtube
  • – delicious
  • – plazes
  • – hollywood stock exchange
  • – last.fm
  • – amazon.com
  • Infinite communities, supports a lot of communities not just one: that’s why it works better
  • MOTIVES: why do people contribute to these sites at all?

friend said there are only two motivations (ha):
– to get laid
– please jesus

  • Why do people contribute
  • (Peter Kollack, Economies of Online Collaboration)
  • anticipated reciprocity
  • reputation
  • ‘sense of efficacy’
  • identification with a group, community
  • Open Source Motives
  • “Success of Open Source”
  • Learning to code
  • Gaining reputation
  • Scratching an itch
  • Contributing to the commons
  • Sticking it to Microsoft
  • Who and in what context are they contributing…
  • You can share without really knowing it (example: search engine) (purely utilitarian motive)*
  • Saving for personal use, but you save in public (example: delicious) (personal utility motive)
  • Sharing with friends*
  • Sharing with community interests*
  • Self expression / showing off**
  • Altruism / good of the world**
  • (spectrum: more individual* —- more social/public**)
  • be wary of clumsy incentives like money, points & competition –> don’t reward the wrong thing, creates gameable and screwed up systems
  • (points: players who suit MUDs… Richard Bartle, four types of users you have to have to have a MUD. Diamond– achievement, Spades, Hearts:____ ; Clubs: interested in imposition on others, combat with others)
  • – people might move between these motivations during the life of their existence in a game
  • – if one of those types of users isn’t rewarded, then the thing comes unraveled –> need a variety of different types of users to create a culture that will last
  • – example: Digg requires two types of users, one who explores the site and diggs stuff and people who just read pages (and click on ads). If you reward one group but not the other, the sight would come apart.

Building something of collaborative value:
helping people feed back on their own data to build something of lasting value

Last.fm
————————–
Why hasn’t Apple purchased last.fm??

Flickr
————————–
250M photos
all with clear permissions for use
5M of those photos have been geocoded
a vast number of those photos have been tagged
knowledge of which photos are interesting

Open up social value
————————–
expose every axis of data you can
give people place to represent themselves
allow them to associate, connect and form relationships with one another
help them annotate, rate and comment
look for ways to expose this data back onto the site

APIs are cool

Be VERY careful of user expectations around how private or public their contribution is
— Facebook is an example of where someone failed to do this

Be wary of creating monocultures or echo chambers
— digg homepage, don’t make it so that only the same kind of person can use it

Remember: not all of you users ned to participate to generate social value

Business value
————————–
openstreetmap.org (could challenge navteq, mapquest, etc)
flickr.com (making money not by owning data, by 3rd party services)

  • Attention and advertising
  • Premium accounts
  • Building services around the data
  • Using user-generated annotations and contributions to improve your other services

Rise of aggregate data?
————————–

This is an idea, I need your feedback…

  • proprietary data own a space
  • they license their data selectively
  • increasingly fluid and commoditized services emerge with flat rate-card data provisions
  • until finally data services generated by distributed commmunities emerge and take over?