Below are the 50 books I was able to complete in 2011 (next year I'm shooting for 52!). It's mostly non-fiction and entrepreneurship-related, but there is a sprinkle of fiction and humanities in there somewhere. Most of these books have separate blog posts written about them (you can also search).

Happy holidays everyone, and happy new year!

James is the VP of Engineering at IMBU, the very first Lean Startup founded by Eric Ries. IMVU experimented heavily on its way to tens of millions in annual revenue. In his talk, James describes how to build a culture and team of experimentation in your startup. You can watch the video and see the slides above.

Below are my notes on James Birchler's talk on experimentation at IMVU. I enjoyed his talk, particularly the segments that dealt with the specifics of IMVU's processes.

The Scientific Method is based on experimentation.

Core:

1. culture
   
2. technique
   
3. examples
   

Story of Copernicus

• heliocentrism
  
• experimental observation
  
• was met with violence; Church threatened him
  

Giordano Bruno (burned at stake)

Galileo

• scientific method
  
• put on house arrest
  

It was hard for these guys because the folks in charge didn't like hearing "bad news."

IMVU

• experiments
  
• share results freely, no matter who's pet project
  
• rapid iteration and learning
  

1. ask question
2. do research
3. form hypothesis
4. test (science?)
5. analyze data
6. conclusion
7. report results

And cycle back to beginning

Lean startup: build, measure, learn loop

1. talk to customers for use cases
   
2. form a hypothesis to test
   
3. write code, test on dev machine
   
4. test in production as QA/admin
   
5. roll out to a % of customers
   
6. analyze results, conclusion
   
7. share learning
   

Culture of experimentation:
Started out as simple as this:
if (setup_experiment(...) == "control") {
// do it the old way
} else {
// do it the new way
}

Then later built robust experiment management system

• Columns: experiment name, to which users (QA and admin only, 100%, 50%, etc.), status/close date
  

Also built tool to calculate statistical significance

• sample count: control and treatment
  
• mean: control and treatment
  
• variance: control and treatment
  
• p-value
  
• significance
  
• chance of occurring randomly
  
• table of user data with rows highlighted to show which validated or invalidated experiment
  

Embrace failure with exec team and whole company.

Embrace failure as an opportunity to learn.

Highest paid person's opinion (HiPPO) is not assumed to be correct.

Reference to paper "Practical guide to controlled experiments on the web."

Easy to screw up process at every stage

• use cases
  
• test hypotheses
  
• rinse, repeat
  

Don't ask customers what they want.

Instead, ask customers what they are trying to do.

Focus on use cases and not what they say they want.

What not to do: build what customers say they want.

Do this:

• start with use cases
  
• test hypotheses to learn best ways to fulfill them
  

It takes a lot of courage to balance experience, instinct, imagination, and experiment results.

"If you design a toaster oven and need to include directions for making toast, you have failed at designing a toaster oven." -Laura Klein

Don't just run a bunch of experiments without a strong point of view of what trying to learn.

Experiment design

• start with use cases
  
• have a specific hypothesis
  
• ask the right questions
  
• ask the right people
  
• ask enough people
  
• randomized control trial
  

experiment interpretation

• use the right p test
  
• don't rely only on p test
  
• don't confuse correlation with causation
• find psych or stats PhD's to help

Experiments are a great way to test hypotheses, not form them.

Product development

Build:

• 2-3 week sprints
  
• stop and adjust process each sprint
  
• agile and XP methods
  

Agile & XP methods:

• change, flexibility, iteration, continuous improvemnt
  
• Agile and XP support each other
• physical scrum board with post-its
• self-organizing teams, short sprints, daily stand-ups (15 min), no emails (just talk)
• clear roles and responsibilities: product owner, tech lead, visual designer, UED, QA
• stay flexible, don't be dogmatic
  

Measure:

• projects/stories completed
  
• time spent on tasks
  
• story points delivered
  
• unplanned vs. planned work completed
  
• how productive and happy do we feel
  

Learn:

• project postmortens
  
• sprint retrospectives
  
• 5 why's root cause analysis
  
• support open communication
  

Open communication:

• engineering project managers (just to assure engineering communicates ok)
  
• matrix management (managers manage people across teams to get slice across company)
  
• scrum of scrums (weekly uber-scrum mtg)
  
• team swaps (individuals switch teams liberally)
  
• open floor plan
  

Postmortems and retrospectives:

• meeting roles
  
• metrics
  
• action items
  
• all levels of organization must be in it
  

Meeting success:

• appoint a skilled facilitator
  
• foster communication and engagement (talk about elephant in room)
  
• table: days, project, story points
  
• whiteboard columns: misc., keep, stop (action item), start (action item)
  

5 Why's: fix root cause

Make the size of the fix commensurate with the size of the problem.

Handling interrupts

• Share interrupts among teams
  
• Create "interrupts" team; establish home team and rotate others through it
  
• Whenever someone commits code that fails battery of tests, interrupts team needs to fix the tests or the code.
  

Time tracking (used to do it more but now do it less):

• Focus on features and value to customers, not time
  
• Short planning meetings
  
• Caution: reduced ability to predict progress
  

Scrum 2.0: continuous planning

• based on successful process experiment
  
• just-in-time planning: kanban
  
• are we working on the right stuff?
  

User testing:

• pay $50 for 30 min of someone's time
  
• ask them to play your game, watch their reaction
  
• stop them after 15 min. and say they can go
  
• if they want to keep playing, then you're doing well
  

Keep your team together: embed designers, QA, data analyst, engineering and product in same location

Have a fixer: remove blocks, remain objective, team happiness = team productivity

Technical project reviews:

• organized by team tech lead: tech review of code, improve quality, reduce tech debt
  
• in-depth reviews of code
  
• all engineers welcome
  
• note follow-up action items
  
• prioritize actions and do them
  

Experiment they ran: small teams in a bare garage + no rules = big win

• break out of routine
  
• minimize process overhead
  
• focus on value to customers
  

Self-selecting teams: let people self-select to the teams they want to work on

Shake things up

• Switch to continuous planning
  
• Story points vs. Ideal Days
  

I wanted to write a short post on the topic of time management, mainly asking a question as opposed to providing an answer. I'm curious to learn how readers manage their busy schedules and what time slicing method works for them.

By "time slicing," I'm referring to two opposing methods that I've considered for time management:

1. Intra-day/small slices: Each day is filled with many types of activities that you need to be involved in. This means everyday you exercise, meet with customers, network with colleagues, do informational interviews, recruit, write code, do online marketing, eat, have fun, and sleep. That's a ton to fit in to one day, and each slice is necessarily small (or non-existent on certain days).
2. Intra-week/large slices: Separate days are devoted to separate activities. Huge swaths of time are devoted for intense focus on 1-2 important activities. For example, all coffee meetings, interviews, phone calls, etc. are on Fridays. All marketing work is on Wednesdays. Workouts are 2-3 days a week. And the rest of the days are all for intense work on ____ (fill in the blank for your most important function, like coding, recruiting, designing, etc.).

There are clearly pros and cons to each method. Large slices allow more intense focus and less switching costs. Small slices allow more "balance" in each day and quicker responses to opportunities that come up (like for phone calls, meetings, etc.). And sometimes you don't have a choice: if you really need to meet with someone who can only meet on a day that's not your "meeting day," it will disrupt your rhythm.

This decision also gets into the need to say no to various requests for help or meeting (or at least delays if not no's), which can often be painful to do.

What do you do? What methods have you found useful in managing your time along this axis?