Reducing mass
Making things manageable
Lowering cost of change
Staying out of debt
Small has big advantages
- customer is closer to you
Need the right people for a small team
- passionate & happy
- well-rounded, so can fill multiple roles
- quick learner
- good writer
- trustworthy
Act your size!
- there are advantages to being small so tout those and don't pretend to be big
→ less formality, mass, fear
→ more flexibility, change, freedom
Embrace constraints
- fewer people, more power
- less money, more value
- fewer resources, better use
- less time, better time
Build half a product, not a half-ass product
- you can always add to it later
- Say no by default (can change your mind later)
- Listen to the product
- Ignore details early on (look at the big picture)
- Improve what you have
- instead of adding more features - Decisions are temporary
- no decision must be final
- small teams can change things later
Build less software
- lower cost of change
- less room for error
- less support required
Encourage human solutions
- give people enough to solve their problems their own way, then get out of the way
- e.g. Ta-da to-do lists
Get real, start with the UI
- not the functional spec
- start designing
- start prototyping
- start experiencing
- start changing
- people don't know what they need 'til they see it
Fixed cost, fixed time, fixed scope → pick 2
Don't just write stuff, produce stuff then test it
- similar to extreme programming
Make most decisions "just in time"
- like car manufacturing
Examples:
Scalability - scale when you need to
Admin interfaces - build at the end
E.g. BaseCamp billing page not built until product was released, deadline was when free trials expired
"do what you need to do when you need to do it"
Make decisions when you have real information
Work on the next most important thing
- don't get too far into the future
Celebrate small victories
iterate ↔ celebrate
It's OK to be wrong
- it's expensive to be right the first time
- small teams can fix things quickly
Builders support it :: chefs become waiters
- do your own tech support
- shared annoyance
- makes you closer to your customers
Publicity amplifiers
- Feature food → features people will talk about
e.g. iCal integration + RSS in BaseCamp - Promote through education
- 30-day major upgrade → hide a few features back
- shows you're still supporting product - Transparency = Trust
- admit if something's wrong - Bloggle
- get blogs talking about product to raise Google ranks
Conclusion
- Reduce mass
- Make things manageable
- Lower cost of change
- don't write code you're afraid of - Stay out of debt
- spend time building, not fixing