FOWA Notes: How and Why We Built Google Docs and Spreadsheets - Jonathan Rochelle

Step 1 any good product
Pick a killer cool name


People said it sucks. But At least no-one will be confused.

Who Cares? It's actually a start-up acquistion story

20052Web Technologies / XL2Web joins Google.

Mar 2006 - Upstartle / writely joins google

Jun 2006 Google spreadhsheets launched in labs
Aug 2006 Writely re-opens
Oct 06 Google docs launched.
Took it global

It actually fits well with our mission
Orgnaise my info Make it accessible with whomever I choose and nobody else

DIY content creation Accepted/familiar interface. Accessibility from anywhere. Easy to use collaboration. DIY community creation

It's not on the web it is the web.

Key target features
Realtime editing online storage Publishing APis

One overriding product goal:
Be easy to use.

General Architecture

Server-side calculation engine. lighten the load Ajax client Collaboration engine. Storage Layer infrastructure and shared services

Google infrastructurep provides cheap scale - just add water. The team focuses on integration and features.

Ajax Client
Well defined communication layer Push calculation logic to the server side Browser challenges - no safari or opera support Perceived speed

Ajax is graeat,
nice browser based UI No plugins Multi-platform

Ajax stinks
300k pages X browser issues

Decisions Decisions
Who is our initial user What are the must-have V1 features? Launched in June, updated based on feedback in July and August. Collaboration features - rich conflict resolution or simple "trust me" collaboration

Integration Choices - which google products when?

Technical decisions Storage services.. which fits best? Stateful vs stateless homing how to split the load.

Feedback from the users
Give us more specific features.

Give us improvements to current features More sorting options etc.

Give us more integration with more Google and non-google services.

".. but we're not whining.. We love this product!"

Lessons learned (pt 1)
Get UI help and get it early UI innovation can make a stellar success or failure

  Front-end code is very dependent of the desired ui behaviours.

  Users don't like guessing what icons do.
  PM's don't make good icons.

Lessons learned (pt 2)

Test new ideas with users early.
  Nobody cared to "Pan" their spreadsheet like a map.

Use Test harnesses, Automation and benchmarks - early
  Client and server side
  Key for ajax experimentation

Speed is critical
  Performance improvements can Always be made.
    Get someone important to say it's too slow
  Compromise, kill the cool but un-used features...

Lessons learned (pt 3)

The needs of many outweigh the needs of the few Even if that "one" is paying the bills Get user feedback and use it as a key input to feature plans

Sometimes insight does NOT come from the user Our biggest was realtime collaboration. - This was a critical change to the proposition.

User data is sacred Don't ever give users a reason not to trust your product. Even internal users. Treat data like it's your bank account details.

Lessons learned (pt 4)

Provide a very specific value that users can describe

If users are saying they need somewher to use this product 
  is not as good as
users saying that your product will improve productivity 80%  

Focus on features which align with your product's value.
for example collaboration features are critical. It's not about which features most people want or which features will get us more users.

Talk to users Gather plenty from early users - if they represent your target.

Final lesson learned
The team is the most important thing. have partners Pick the right partners Complimentary skills
I'm not a good administrator so I picked a partner that was a great admin Same with engineering.

Build a great Team
  Don't compromise

Don't hire for everything. Buy services  

Docs and spreadsheets
Google APIS
Spreadsheets API:

comments powered by Disqus