How to Make Big Things Happen With Small Teams

Think your small team prevents you from doing big things? Think again. 
A veteran of many successful projects accomplished with small teams shares 
his tips on thinking large and achieving giant results.

Speaker: Jason FriedÊÊ(Owner) Ê37signals


- Reducing mass
- making things manageable
- lowering cost of change
- staying out of debt

Example: If you create a text editor and need to change something or add, 
it's a lot easier to do instead of changing Microsoft Word.


Small has big advantage:

 - The customer is closer to you
 	# less distortion with a small team
 	# less middle/muddle
 	# Everyone on the front line
 	# Change is easier


 
It's about having the RIGHT PEOPLE
	- Passionate and happy
	- well rounded (not experts on one thing)
	- quick learner
	- good writer (people email, and need to communicate with you)
	- trustworthy


I'll take someone happy and average over a guru who is disgruntled and frustrated


- Act your size as a company
	 - there are advantages of being small
	 - Less formalities
	 - less mass (having less allows you to control it)
	 - less fear
	 - more flexability
	 - more change
	 - more freedom


- Embrace constrains

Less people, more power
	- don't get more people, give the people you have more power
	
Less money, more value
	- you don't need to spend more money - just offer more of a value to your staff

Less resources, better use
	- if you fire someone - wait 6 months if you can do without them
	- figure out how to use the resources you have
	
Less time, better time
	- you want to spend better time


- Build half a product not a half-ass product
	- say no by default
		# "key is to listen to what really needs to be added"
	- listen to the product
	- ignore details early on
		# you can get stuck in the details to much
		# worry about big picture at first
	- improve what you have
		# don't just make more features, make the features you have better
	- decisions are temporary
		# you can make a final dicision to allow youself to come back to it later
		
		
		


Build Less software
	- lowers the cost of change
	- less room for error
	- less support required
	- Encourage human solutions


Give people just enough to solve their own problems their own ways
Then get out of their way.


Get Real, start with the UI

There's nothing functional about a functional chart



JUST START:
---------------------
Start designing
start prototyping
start experiencing
start changing

Rinse and repeat

------------------------------------------------
"my thought" - what does this mean about IA and wireframes at TIG?
------------------------------------------------


getting to the "Common Experience" as soon as possible





Make most decisions JIT (Just in Time)
	- don't have a lot of parts laying around



- Scalability
	- just because you spent the money, doesn't mean you have to use it
	- spend a dollar and forget about it because you can't change it.
- Admin Interfaces
- Basecamp billing example
	- Make decisions when you have the real information


Next most important thing
	- is this it?
	- if not, what is?
	- Are we doing it?
	- If not, why not?


Celebrate small victories
	- iterate
	- celebrate
	- iterate
	- celebrate
	- iterate
	- celebrate

Start from the experience and working backwards




Feel the hurt (do you own tech support)
	- if something is annoying them it will annoy you
	- builders support it
	- Chefs become waiters
	- Shared annoyance




Publicity
	- feature food
		# little features that people want to eat up and talk about.
		# RSS, iCal, etc...
	- promote through education
		# don't just tell people how you did it, show them (yellow fade technique)
	- 30-day major upgrade
		# always hold features back.
	- Transparency = Trust
		# if there is ever a problem, be public about it
	- Bloggle