Google's formula for product development

Carl Sjogreen, who led the development of Google Calendar, provided a deep look into how Google develops products during a presentation at The Future of Web Apps Summit.  What follows is a play-by-play of his presentation, which is self explanatory.

The project started with the typical small Google group--one product manager (Sjogreen) and three engineers. The project was driven by customer feedback and internal interest in having a calendar, since it's a close relative of email. Google also concluded that there wasn't much innovation going on around calendars and nothing existing was "right."

First things first...talk to real customers

• It's amazing how little it is done...talk to real customers, not Silicon Valley geek buddies
• Speak 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

Key themes emerged

• Calendars are necessary but a chore
• Calendars are really personal and emotional
• Calendar collaboration is just too hard
  

We set out to build call that works for you.

You need a vision, three or four things you have to get right, or it's just a bunch of features

The four things

•     Fast, visually appealing, and joyous to use
•     Drop-dead simple to get info into the calendar
•     More than boxes on a screen (reminders, invitations,  text messages on a phone, etc.)
•     Easy to share so you can see your whole life in one place, make it public, private or somewhere in between and see all their events in the context
  

Designed for a consumer world where not everyone has a calendar (or one on the same system)

• Open APIs (import and publish), allowing data to flow back and forth
• Invitations for everyone--it has to work no matter what calendar you have
  

Vision in hand start to build the product
Lots of prototyping   

•     Relatively easy to get a basic system up and running--the details are hard
•     Focused on getting interactions and the user model right before thinking about scale (a significant challenge for us)
  

Internal use: Pros and cons

•     Got a ton of great feedback form other Googleers
•     Got interaction basics right and generated a lot of feature ideas
•     However, keep in mind that your early users might not be your target users
•     Look at feature requests through the appropriate lens
  

 Once we felt we had it mostly right, work on making it real

•     Backend infrastructure designed to scale
•     Front end/UI rewrite to pixel perfect mocks and static HTML
•     Doing all the hard parts (recurrences, parsing ical, API testing, interoperability, etc.)
  

Find the right balance doing hard things that you don't know if can do and the must-haves that take time

Worked on our UI design in stages as well

• Get the interactions down and try them out
• Focus on the look and feel while engineers are making it real
• Save the pixel pushing for when you know you have it right
  

Launching
Private betas are a good thing--even with all our internal testing, we learned a ton from testing with a small group of real users

•     Quick add improvements (being smart isn't always best)
•     Underestimated the importance of import (such as calendar info from Yahoo and Outlook)
•     Fixed a bunch of issues with SMS alerts
•     Better support for small screens (screen density is the most important issue, and Google developers on 19-inch screens is the most common environment for calendar viewing)
  

Launch day 4.12.06
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

• Always keep a close eye on the minimum 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  (redesigned the event page at least three times)
  

Don't spend too much time on the less important areas, know where you will get the most bang for the buck

2. Know your real competition

• Know what your competition does well
• The real competition is paper calendars

• 6 billion people who all something going on in their lives
• 300 million use electronic desktop calendars,  mostly at work
• 10 million Web calendar users

How to beat paper

• Non-tech and low-tech mechanisms are the way most people communicate and interact

•     Email vs. Evite

•     Notepad vs. Tada lists

•     The kitchen calendar vs. Google Calendar

• Easy to carry with you
• Doesn't require boot time
• Doesn't require login

• Import, offline, mobile, etc
• Mimic the flexibility of paper

•     Collabororation

•     Access from anywhere
  

3. Visual design matters

• Great Design = Usability + Visual Joy
• Usabity is clearly essential, but visual design helps create the personal connections
• If you are spending hours a day living in the product, it needs to feel good to you

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

• Not everyone who can benefit forn your service actually wants to use it--changing behavior and workflows is difficult
• 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, such as integrate with email
• Make it painless for people to start using your product without fully switching into a new way of doing things
• Make calenar useful even for casual users

5. Timing the launch properly

• Launch early and often is the mantra of Web companies
• However, the old adage 'you can only launch once still applies'

• Leverage internal testing and private betas

• Make sure your product is worthwhile once it lands on Digg, TechCrunch, etc.

6. Driving usage

• We have a steady rate of new users signing up daily with very little marketing
  
• Think about how your product can generate touchpoints that extend beyond your applications, and make it easy to do so, such as adding stuff such as reminders and sending invites...
• Social reinforcement is key for validation--my friend telling me to use the product is 10x more valuable than hearing it from the company
• Relentlessly remove acocunt signup--it's obvious but was surprising to me how much of a barrier account signups can be