Jason Fried / 37 Signals on Lessons Learned: Web 2.0 Expo NYC

Jason Fried / 37 signals
Sept 17/08 - raw talk notes


1. Momentum
Graph of project - cone of uncertainty like diagram
People trend towards losing interest
Don't want anything longer than 2 weeks

2. Planning is vastly overrated
No roadmaps, no specifications, no projections
3 6 9 months: rough ideas, but forget it.

Don't write specs, don't write design docs
We don't do them
Don't push back enough
Spec doc: contain a thousand yeses - no push back
Lead to illusion of agreement
All read the same thing, interpret them differently
Can't come to authentic agreement
Don't do projections: big huge guesses
Especially financial projections


3. Get rid of abstractions
Work on the real thing, right now
Not what we might do in 2 months, but what's happening now

4. Decisions are temporary
Paralyzed by decisions, because think they're permanent
Do 4 day work weeks: recent announcement
Pay for hobbies
You guys are fucking crazy
Only 12 people
If 100 people, you can't do that
Not setting in stone (for now, this is what works)
Optimize for now

5. Red flag words
Need, can't easy, everyone, nobody
Lots of needs, but really few necessities
Watch out for red flag words

6. Interruption is the enemy of productivity
David & Jason: chicago/denmark story
Got a lot less stuff done when working together
Closer in proximity, less work you get done.
Invite interruption
Tap on the shoulder, required meetings, call someone's name, check this out, phones and blackberries
Avg work day = work moments
No span of uninterrupted time anymore
"solitary work = real work?" is that the subtext?
What is "actual work"
A fragmented day is not a productive day
Only see each other once a week
Personal interaction isn't valuable? Stay away from each other. Anti-collaboration?
Passive collaboration instead of active collaboration? Time shift collaboration.
Real-time interruptions vs. async interruptions?

7. Focus on what doesn't change
Tech & software: obsessed with change
Find out what matters today and what matters ten years from now

8. Worrying about things that don't matter yet
Reasons projects are late: sketch with a sharpie, not a pencil
Accuracy vs. precision (resolution of a pencil vs. a sharpie)
Can't create details: which is good, early on, it doesn't matter

The longer it takes to develop, the less likely it will be to launch it

9. Underdoing
Cold war going on in software world: out-do (feature war)
Keep doing more than everyone else
Hard to win the cold war
Not something a small business can compete in
Underdo: one-down, not one-up
Target non-consumption (Clayton Christiansen - innovators dilemma, solutions)
Non-consumers: existing products are too expensive or just not accessible
Solutions are already upmarket: want to be consumers, but no options (think road bikes)
So aim downmarket

10. Find the right size
2 things that grow forever: business and tumours
Find your right size. Doesn't have to be a billion company
Don't need to set the goal to be huge
Grow slow: 10 to 100 in right year, you might miss the size
Don't have to be in a hurry, find the right size
Ricardo Semler - Maverick (Brazillian business author)
Oxford U: why aren't there oxfords everywhere? The one that exists, is about the right size.
If there was 100, they wouldn't be Oxford.

11. Follow the chefs
Inspiration from famous chefs
Lagasse, Batali, Flay, Child, Oliver
Not the best, but they out-teach, out share, out contribute competitors
Watch me. Show you this isn't hard. Here's my secrets, buy the book.
Not afraid to put ideas out there. Not afraid that people next to them will put them out of business.
Out teach, out share, out contribute.
What's your cookbook? How can you share?
Getting Real: everything that they know. No secrets, not in the book

Company with customers, lucky, fans, even luckier, audience, very lucky.

12. Always be questioning

Why are we doing this
What problem are we solving
Is this actually useful
Are we adding value
Will this change behaviour
Is there an easier way

13. Give up on hard problems
Nothing wrong with being lazy
Lots of easy problems that need solving
To be good, take on hard problems
Abundance of easy problems
Not worth solving hard problems, leave them to your competitors
(Solve 10 little ones in 1 month)

14. Work less
Industry plagued with workaholics
32 vs 40 hrs
Work less, it's better
Work is just as good and people are happier


Question & Answer session: Let's talk - 20 minutes to talk

1. Planning is vastly overrated: how do you align that to a strategic goal: 10 years out
Can't run a 5 billion company where you have shareholders aligning things with strategy
Even if you change your tactics

If you don't plan, how do you align with big picture ideas
Don't care, not what we are: big rich huge companies: planning preventing things from going wrong

Basecamp: big idea per product: communications is all about PM
Is this feature still relevant to the idea
Keep stuff out of our products

Big picture idea: keep referring back to it

2. Advice in an in-house situation: half the org is tied to an older idea of software development.
How do you convince this behaviour that there's another way?

Suggestion: people pay attn to results
Find a small project, show you can do it in 2 weeks
Skunkworks - don't swear at your company
Should swear more.
People work better: fuck you!
Heckle!

Find a smaller project, slowly change things. Start at the edges

3. 2 weeks, momentum: 6/7 months until you see results?
Small projects out of big projects?
Don't do stuff that takes 6 or 7 months
Release half in 3 months, best in 3 months
Second half might have been the wrong half anyhow
Cut your projects in half, cut it way back
First version should be barely releasable.
Chunk into smaller and smaller bits

Basecamp: new feature (comments on everything)
A month worth of work

4. How do you sell your customers: cut scope?
20 pages to 10 pages? Not in the client services business anymore
Used to do long proposals
No-one reads them
Price, how long
Long proposals: think you have to do them
Cut proposals down
Client work: proposals were one or 2 pages
Doesn't work for everybody - how the client reacts
Getting out of client work: short answer: what was so bad about it?

5. What's so bad about client work?
Depressing
Not that satisfying
Lucky if you get 3 good clients
Won't let you do work. Just what happens
Build our own stuff, build our own client
Do things you think is right. Project make yourself your own client
Shifted from client to product

6. How to be a great client for a vendor?
Rail on clients: but then when I became it. Pain in the ass.
Why are you hiring them in the first place, trust them, stop trying to do
The project yourself
Spend less money on something… ? Stupid: answers are temporary
Respect them more. Disconnect between client and firm.
Listen to them. Client services: weird: plumber tells you something, you do it.
Designer, you second guess them.

7. How do you know when to hire if you don't plan?
We hire when it hurts
Not hiring in anticipation, we hire for stuff people need to do right now
And hire for stuff we're doing right now
Time to hire an accountant…. Not hiring an HR person yet.
Not in anticipation, hire people we need, replace jobs we're already doing

8. Unique culture: how do you find people that fit in?
How do you brainwash people?
How do you immerse them in culture.
Drop people in, let them figure it out
Don't have a training process.
Campfire: real time chat tool, most important to them.
Jump in, they're in. See how people work together.
Tend to hire people we've worked with before (open source world)
Try people out: 1 month at a time, weren't the right fit, temporary decision

9. As a company, working at one thing at a time?
6 products, Ruby on Rails, lot of stuff going on at once.
Multitasking is overated and costly
Stick to a product at a time
Switch off to something else, basecamp to highrise or backpack
Tried everyone working on same thing for 1 month: in theory worked okay, doesn't work well
Broke off into project teams, then move off to something else
Do all the same thing? No. Different roles. Programmers, Sys Admin, Design, etc.
Design screens first, then code.


10. Best way to motivate users to give feedback?
Make mistakes: they give you a lot of feedback. Give them great products. No shortage. Do a survey every now and again, but most part, just get customer feedback, sit there, get 150 emails / day.
Handful of feedback, customer forums, scour the web. Monitor that. Go out and find it if its not in your sphere.
No worries, they'll give it to you. Most will be negative, but not a bad thing. Not pure praise. That's not honest, nor is it useful.


11. How do you allow feedback to focus on featureset or development
Take it all in, make decisions on behalf of customers
Do what they're telling you, but a few of those things
Customers tell you what's right for them, but maybe not the product.
Museum curator role. Does this collection of features need this? Editor, curator, what's right.

Technique: read feedback, throw it out
Don't keep a list of all requests
Huge ass lists don't get looked at
Listen, then forget about it, things important, keep coming up
Customer base will remind you, due to frequency of request, what's important

12. Sharpie: stay away from details - visual mockups: paper and sharpies? Or other methods.
Ryan, Jason, Jamie: no set "you gotta do it"
Sketch on paper first
Then Jason goes straight into HTML
Paper to HTML, make it real. Share it with someone else

13. How do you avoid unforseen issues (miniscule detail): comes back to bite me
Jason: just don't know. Only know when something is being used and real. Can't anticipate it.
You adapt. Otherwise you're just guessing.