well-shaped work = thin-tailed probability distribution of risk
betting: choose among pitched projects (only those brought forward)
good questions to ask: "Does the problem matter?", "Is the appetite right?", "Is the solution attractive?", "Is this the right time?", "Are the right people available?"
building
important: sth demoable in ~1 week (core, small, novel)
mark nice-to-have tasks with ~
uphill (figuring out what to do) and downhill phase (executing)
circuit breaker: by default no extension for unfinished projects
2 week cool down after cycle (don't mix deadline & planning pressure)
ideal reply to ideas: "maybe some day" --> soft no with optionality
fat marker sketch: rough early stage of project
avoid: "I know I drew it like this but ignore that ..."
breadboarding: electrical eng prototype with full components but no design
places (what you navigate to), affordances (buttons/fields), connections
a) start with place and underline it, b) add affordances underneath place, c) connect affordance with new place
Basecamp's structure at time of book: Core (shaper & cycle teams), SIP (Security, Infrastructure, Performance), Ops, Support
recommendations:
don't keep backlogs (let people instead raise topics again)
fix shipping before you fix research & discovery
once per year one cycle (before holiday season) for bugs ("bug smash")
don't do "redesigns" or "refactorings" without clear problem
create to do lists by structure (what can be worked on independently), not by persons
chowder list: loose tasks that don't fit anywhere
quicker decisions: don't compare up to ideal, compare down to baseline