Strumming waveform -- short projects

* Planning is overrated

* Get rid of abstractions

  - Functional specs are an illusion of agreement

  - no wireframes

  - closer you are to real thing, the more you can reach agreement

* Decisions are temporary

  - credit card thing

  - optimize for now

* Red flag words

 - Need, can't, easy, everyone, nobody

 - These words most often cause a project to be late

 - replace "Need" with "want" or "could use"

 - Momentum is important so the more "cants" you have

 - Easy is a word to describe other people's jobs

   - imaginary work is a lot easier than real work

   - calling someone's job easy sets them up for failure

 - Everybody and nobody aren't true.

 - Words that fuel animosity, office politics

* Interruption is the enemy of productivity

  - Taps on shoulder

  - required meeting

  - "hey check this out"

  - phones & blackberries

  - This FRAGMENTS people's day

    - a fragmented day is not a productive day

  - Look for ways to stay away from one another

  - Focus more on passive collaboration

* Focus on what doesn't change

  - What is important today and ten years from now?

  - speed

  - simplicity

  - clarity

  - ease of use

  - uptime

* Underdoing

  - "features" or "spending" or "funding" cold wars

  - don't play in the cold war

  - target non-consumption

    - big guys don't care about that market

    - small companies should focus here

    - find markets where you can enter on the low end and deliver the

      SIMPLEST POSSIBLE SOLUTION

    - don't think you don't have to charge money

* Find the right size

  - 2 things strive for eternal growth: business and tumors

  - this shouldn't be true for business

  - imagine if your software was physical

    - imagine every feature has to be a physical button

    - helps you constraint to something that makes sense

* Follow the chefs

  - Lagasse (Emiril)

  - Batali

  - Flay

  - Child

  - Oliver

  - These guys:

    - Out Teach,

    - Out Share,

    - Out Contribute

  - What's your cookbook??

  - Kathy Sierra: "You can either out-spend or out-teach your competition"

* Always be questioning your work

  - Why are we doing this?

  - What problems are we solving?

  - Is this actually useful?

  - Are we adding value?

  - Will this change behavior?

  - Is tehre an easier way?

* Give up on hard problems

  - nothing wrong with hard problems SOMETIMES

  - abundance of easy problems

  - you CAN make money solving simple problems

* You're an editor

  - (Seth mentioned "you're a storyteller")

  - Curate yoru product (its a museum)

  - You have to decide whats going on the wall

  - Don't be afraid to say no

* Work less

  - don't work on fridays

  - work 32 hour weeks

  - more time you have, the more time you work on stuff that doesn't matter

  - less time to get stuff done, make smart decisions about what really matters

  - no one has productive fridays

  - most people don't work 8 hour days

---

Q & A

Q: How do you chunk a big project into smaller projects?

A: Decided to focus on 3 things.  Once those were solved, version 1 was done. 

  - Pretty quickly they were solved.

  - Basecamp couldn't do a lot of stuff at first

  - What can you do in 3 hours or 3 days

  - Take a problem thats a molecule and break down to atoms

Q: How do you deal with size, how do you know the right size? How do you constrain to a given size?

A: Problem is a fallacy: that success = size

   - At a certain point (cites Seth Godin) to support MORE people the product has to be mediocre

   - Equating success to size and growth is a problemx

   - Small Giants address that

Q: Wants to defend personas b/c his developers can't be users?

A: If the persona isn't a real person, its BS

   - what J.F. means by personas is a profile (ie, 3 kids, dog, 37 yrs old, etc)

   - talk to the people who will use the product

   - those aren't personas -- those are people.

Q: Wants to defend Functional specs - do software for enterprise.  Functional spec is seed for tech writers to get past steps to get into the 'bidding' process. How do you reconcile those two

A: Want to clarify: What i say doesn't work for everyone.

   - the premise of the question is flawed

   - idea that you need to go back to a document is flawed

   - first we design the interface, and that becomes the 'real thing'

     to discuss the real product, real customer experience

   - people refer back to a screen, a flow, a series of buttons

   - sometimes support with a brief story (couple of paragraphs) AFTER we

     build the UI

   - spec is the way the product looks

Q: How do you manage customer support & tech support on fridays?

A: Looking for another CS person to stagger it.  J.F. says he works on fridays.

   - Still believe in 4 day work weeks, but would stagger

   - Currently don't do support very well anyway

Q: Elaborate on scalability reliability

A: We feel these are things you should worry about later.

  - originally basecamp ran on one server

    - reckless maybe, but right

    - didn't know if basecamp would work

    - ok to be slow for a little bit as long as you solve the right problem

  - if you charge for your products, when you need to scale, you are

    making more money

Q: Examples of investing in things taht don't chagne

A: Investing in the people, for example

     - 4 day work week

     - investing in hobbies

     - etc.

   Investing in user experience

     - saying no to things we "could" do

  

Q: How do you handle the dumb ideas that come in?

A: You need to just be happy with what you're building...

   - certain things will never make it into basecamp

   - gant charts example:

   - J.F. believes that cash flow will follow integrity

Q: Philosophy about throwing out requests?

A: no one looks at long lists, etc.

Q: When did you decide to throw out v1 of highrise?

A: When we realized we didn't want to use it.

Q: How do you track bugs?

A: Don't "really" track bugs - fix root causes, then fix bugs along the way.

...