Carl Sjogreen — How we built Google Calendar

Some quick take-aways:

  • The road to Google Calendar: In the beginning, a largely “classic” google product team (1 product manager and 3 engineers), origin from both customer feedback & internal interest, seemed like a space with little innovation, nothing out there was “right”. Vague idea: “Google should do something in the calendar space”
  • First things first — go talk to “real” customers: Sounds cliche, but it’s amazing how little it’s really done (btw, “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. Kept probing: busy is not the same as “needs a calendar” (e.g. students may be extremely busy but may stick to a pretty regular calendar. Maybe “busy + irregular calendar” is more of a sweet spot)
  • Key themes emerged quickly: Calendars are necessary but just a chore, calendars are really personal and emotional, calendar “collaboration” is just too hard
  • Vision — it’s important to have one: You have to have a vision, a larger idea (otherwise, you might be building a feature list, not a product). Vision for Google Calendar:
    1. Fast, visually appealing, and joyous to use
    2. Drop-dead simple to get information into the calendar
    3. More than boxes on a screen (reminders, invitations, etc.)
    4. Easy to share so you can see your whole life in one place
  • Development: Lots and lots of prototyping, focused on getting interactions and user model right before thinking about scale (scaling is a significant challenge for Google).
  • Keep in mind that your early users might not be your target users, make sure you talk to actual, real users!
  • Once they felt they had it mostly right, worked on making it real: Backend infrastructure designed for scale, frontend UI rewrite to pixel perfect mockups + static HTML, doing all the hard parts (recurrences, parsing iCals, API testing, interop, etc.).
  • Worked on 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 for when you know you have it right.
  • Private betas are a good thing: Even with all the internal testing, learned a ton from testing with a small group of “real users”
  • 6 key insights that might be useful for your next product or company:
    1. Easy is the most important feature: Always have an eye on the minimum useful feature set that most people will use. Product usage tracks directly to how easy a feature is to find and use. Figure out what you absolutely have to get right and relentlessly refine it (keep redesigning if necessary). Don’t spend too much time on the less important areas (i.e. know where you’ll get the most bang for the buck).
    2. Know your real competition: Know what your competitors do well. Google spent a lot of time looking at the market (online and desktop), but the real competition may be paper (non-tech and low-tech mechanisms are the way that most people communicate and interact, and paper has a bunch of great advantages that you need to beat, e.g. easy to carry with you, doesn’t require boot time, doesn’t require a login etc.). Focus on removing the hurdles to adoption. Focus on what the web can do that paper can’t (e.g. collaboration, access from anywhere)
    3. Visual design matters: Usability is important, but visual joy is key (helps to creat personal connection).
    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, changing behavior and workflows are very, very hard. You 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: Can you integrate with email in a meaningful way? Can your install something on the desktop (links count)? Can you integrate with Google’s applications (home page, toolbar, desktop)? And then make it painless for people to start using your product without fully switching into a new way of doing things.
    5. Timing launch properly: Launch early and often, but not too early (the first time around). Launch early and often is the mantra of web companies, it is a fundamental structural difference that sets web companies apart from packed 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): Ask yourself if you could really see your target user using what you have at day 1, or switching from something else.
    6. Driving usage: Think about how your product can generate touchpoints that extend beyond your app (and make it easy to do so): “Add stuff from my site” (remind me with Google Calendar), “publish stuff” to my site (embeddable calendars), “tell a friend” (invitations & sharing). Social reinforcement is key for validation: My friend telling me to use a product is ten times more valuable than hearing it from the company. Make social reinforcements easy. Relentlessly remove account signups: This is pretty obvious, but it was surprising to me how much of a barrier accounts can be.

Stumbled upon at The Future of Web Apps Summit, San Francisco, CA, September 13, 2006 (wiki).

2 Responses to “Carl Sjogreen — How we built Google Calendar”

  1. Naik’s News » Building Web Native Apps: Google Calendar and Web Office Says:

    [...] ence about how they built Google Calendar. Rakesh Agrawal took extensive notes, as did Tim Bonnemann. What I love about Google is they consistently think ‘Web Native’ when developing [...]

  2. Next Generation Internet » Blog Archive » Nyckelfaktorer för framgÃ¥ng pÃ¥ webben Says:

    [...] lfaktorer som de jobbar efter för att lyckas med en webbtjänst a´la Google Calendar Via Planblog där det finns en bet [...]

Leave a Reply