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?