(copy for my powerpoint for TFL)
How to make big things happen with small teams. Jason Fried, 37signals.com, from chicago. 10s of thousands use basecamp.
now build products. new product code name honey. all with 3 people. sometimes 4.
> reducing mass
> making things manageable
> lowering cost of change
> staying out of debt
Small has big advantages.
> small better.
1. customer is closer // collective customer is employee.
2. less distortion // less middle/muddle/no telephone game/
3. everyone on the front line // all involved with all gigs.
4. easier to change //
The Right People
passionate and happy.
well rounded. not just experts.
quick learner. evolve.
good writer. express self.
trustworthy. empower people. pull weight.
I'll take happy and average rather than angry guru.
Act your size.
less formalities // complex process. be flexible.
less mass // change. flexible. act. > rent. hardware. contracts. staff. major investment.
less fear // not afraid to speak. more freedom.
Embrace Constraints
less people, give more power.
less money, more value, make hard to spend money.
less reseources, better use, optimize.
less time, better time.
Build half a product, not a helf-ass product. (hb phases)
Say no by default. change later if necessary, needed.
Listen to the product.
Ignore details early on.
Improve what you have.
Decisions are temporary.
Build Less Software
lower cost of change
less room for error
less support required
encourage human solutions
Give people just enough to solve own problems then get out of way. ex. Ta Da, people create their own standards.
Get Real, start with the UI
nothing functional about functional specs
start designing, prototyping, experiencing, changing.
change, tweak, etc.
ex. design wireframes, hand to programmer to program once he gets it.
with clients get in as early as possible. get clients to understand. get right clients.
(their programmer is based in Denmark)
Responds to questions >>
Fixed cost. fixed scope. fixed deliverable = can only have 2.
User Interaction System = Use Case // needs to connect to real experience = design UI for it as the Use Case.
Like Agile Modeling > get real fast, test.
Funtional Specs > illustration of agreement, blame doc, no real agreement or understanding. Don't know what have in mind till build it.
UI > artifact, shared experience with team and client.
Just enough is more.
Make most decisions Just In Time (JIT)
Scalability // grow as needed
Admin Interfaces // build fast, controls only as needed.
Basecamp Billing example // 30 days free trial > 30 days to build billing engine.
Make decisions when you have real information.
Always work on 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, etc.
Okay to make mistakes, you can fix it. Faster, cheaper, smarter.
Feel the Hurt
Builders support it
Chefs become the waiters
Shared Annoyance
Publicity Amplifyer
Feature food. ex. iCal app.
Promote through education. ex. yellow fade technique.
30-day major upgrade. hold back features.
transparency = trust
bloggle = get it out
man, I am really glad you are writing all of this. Thanks for the notes and keep em coming. I am going to dinner but I have some questions on some of your notes.. will post later tonight. Have fun and toast me up on one. Will be with y'all next year!
Posted by: ben | March 12, 2005 at 06:36 PM