Max Mednik
  • Home
  • About
  • Interests
    • Angel investing
    • Magic
    • Scuba Diving
  • Blog
  • Contact

Readings and musings

Reading completed in 2011

12/30/2011

2 Comments

 
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!
2 Comments

Notes on IMVU Method of Experimentation

12/21/2011

0 Comments

 
The New Science of Product Development
View more presentations from James Birchler
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
0 Comments

Daily and weekly time slices

12/14/2011

1 Comment

 
Picture
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?
1 Comment
<<Previous

    Archives

    June 2021
    May 2021
    March 2021
    February 2021
    January 2021
    December 2020
    November 2020
    October 2020
    September 2020
    August 2020
    July 2020
    April 2020
    January 2020
    December 2019
    November 2019
    October 2019
    September 2019
    August 2019
    July 2019
    May 2019
    March 2019
    January 2019
    December 2018
    November 2018
    October 2018
    September 2018
    August 2018
    July 2018
    June 2018
    May 2018
    April 2018
    February 2018
    January 2018
    November 2017
    October 2017
    September 2017
    May 2017
    April 2017
    November 2016
    October 2016
    September 2016
    August 2016
    July 2016
    June 2016
    May 2016
    December 2015
    November 2015
    October 2015
    September 2015
    August 2015
    July 2015
    June 2015
    May 2015
    April 2015
    March 2015
    February 2015
    January 2015
    December 2014
    November 2014
    October 2014
    September 2014
    August 2014
    July 2014
    June 2014
    May 2014
    April 2014
    March 2014
    February 2014
    January 2014
    December 2013
    November 2013
    October 2013
    September 2013
    August 2013
    July 2013
    June 2013
    May 2013
    April 2013
    March 2013
    February 2013
    January 2013
    December 2012
    November 2012
    October 2012
    September 2012
    August 2012
    July 2012
    June 2012
    May 2012
    April 2012
    March 2012
    February 2012
    January 2012
    December 2011
    November 2011
    October 2011
    September 2011
    August 2011
    July 2011
    June 2011
    May 2011
    April 2011
    March 2011
    February 2011
    January 2011
    December 2010
    November 2010
    October 2010
    September 2010
    August 2010
    July 2010
    June 2010
    May 2010
    April 2010
    March 2010
    February 2010

    Categories

    All
    Angel Investing
    Cacti
    Cars
    China
    Community Service
    Culture
    Design
    Djing
    Dogs
    Education
    Entertainment
    Entrepreneurship
    Family
    Finance
    Food
    Google
    Happiness
    Incentives
    Investment Banking
    Judaism
    Law
    Lighting
    Magic
    Marketing
    Medicine
    Networking
    Nolabound
    Philosophy
    Professionalism
    Psychology
    Reading
    Real Estate
    Religion
    Romance
    Sales
    Science
    Shangri-La
    Social Entrepreneurship
    Social Media
    Sports
    Teams
    Technology
    Travel
    Turtles
    Ucla
    Venture Capital
    Web Services
    Weddings
    Zen

    Subscribe

    RSS Feed

Picture
Picture
  • Home
  • About
  • Interests
    • Angel investing
    • Magic
    • Scuba Diving
  • Blog
  • Contact