Step 1 any good product
Pick a killer cool name
Google...
...Docs...
...&...
...Spreadsheets
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
IOW
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 http://docs.google.com
Google APIS http://code.google.com
Spreadsheets API: http://code.google.com/apis/spreadsheets/overview.html