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

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

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:

Show Comments