Lessons from Ryan Singer

Lessons from Ryan Singer

Ryan Singer spent 16 years leading design and product at Basecamp. He created Shape Up, a method that replaces open-ended development cycles with fixed time boxes and strict problem boundaries. This profile documents his approach to software constraints, Jobs-to-be-Done, and the mechanics of shipping.

Part 1: The Shape Up Philosophy

1. On ideas: "It's easy to overvalue ideas. The truth is, ideas are cheap." — Source: Shape Up
2. On the language of risk: "A lot of people talk about planning or deciding what to do and, very often, this is too much expressed in the language of certainty. What we're doing here is expressing everything in the language of risk." — Source: Mind the Product
3. On trusting teams: "Here you go, dev team. This is what we want, and we'll leave you alone for six weeks to build it. Implement the details as you see fit." — Source: Shape Up
4. On software economics: "In software everything is possible but nothing is free." — Source: Ryan Singer Blog
5. On the shipping mandate: A project is not finished until it is deployed to customers; separating the building phase from the shipping phase fundamentally breaks the feedback loop. — Source: Signal v. Noise
6. On betting: Treat product decisions like bets at a table, committing a specific amount of time to a project and firmly capping the downside if it fails. — Source: Shape Up
7. On backlogs: A backlog is a heavy weight that drags a team down; instead of maintaining endless lists of things to do, let old ideas die and start fresh with each cycle. — Source: Lenny's Newsletter
8. On running in circles: Teams often run in circles when they start writing code before the problem is properly defined, shaped, and bounded. — Source: Shape Up
9. On the six-week cycle: Six weeks is long enough to build something meaningful from start to finish, but short enough to feel the looming deadline from day one. — Source: Shape Up
10. On circuit breakers: If a project does not finish within its allocated time budget, the circuit breaker trips and the project is canceled rather than automatically extended. — Source: Shape Up

Part 2: Scoping and Shaping Work

1. On shaping: Work must be rough, solved, and bounded before it is handed over to a team to actually build. — Source: Shape Up
2. On abstraction levels: Wireframes are too concrete and leave no room for engineering creativity, while words alone are too abstract and leave too much room for misunderstanding. — Source: Basecamp Blog
3. On rabbit holes: The goal of the shaping phase is to find and eliminate the technical rabbit holes before committing any development time to a project. — Source: Shape Up
4. On finding the core: Identify the absolute core of the problem that must be solved, and strip away everything else until the proposed solution fits the constraints. — Source: Lenny's Newsletter
5. On pitching: A pitch should be a complete presentation of a shaped idea, clearly outlining the problem, the appetite, the solution, and the known risks. — Source: Shape Up
6. On independent execution: Teams need complete autonomy to execute a shaped project, meaning no dependencies on other departments that could block their progress. — Source: Shape Up
7. On the definition of done: A project is finished when it is better than what the customer has right now, not when it reaches some theoretical state of perfection. — Source: Shape Up
8. On over-specification: Over-specifying a design early in the process creates false expectations and locks the team into suboptimal technical solutions. — Source: Intercom Blog
9. On the supply side: While understanding customer needs handles the demand side, shaping is the necessary supply-side discipline to actually deliver the right solutions. — Source: Res Extensa

Part 3: Time, Appetite, and Constraints

1. On estimates: Trying to estimate how long a feature will take is a losing battle; instead, decide up front how much time you are willing to spend on it. — Source: Shape Up
2. On the five-pound bag: "You can’t put 10 pounds of dirt in a five-pound bag," so you must reduce the scope to fit the time you actually have available. — Source: Business of Software
3. On appetite: Appetite is a strict budget of time and resources; it dictates how a problem will be solved rather than letting the problem dictate the timeline. — Source: Shape Up
4. On fixed time and variable scope: Fixing the time constraint forces the team to negotiate the scope and make hard, necessary decisions about what truly matters. — Source: Signal v. Noise
5. On the cool-down period: Teams need a cool-down period between cycles to fix bugs, explore new ideas, and breathe before the next structured bet begins. — Source: Shape Up
6. On outgrowing agile: Traditional agile methodologies often degrade into a feature factory mindset where the focus shifts to closing tickets rather than shipping outcomes. — Source: Lenny's Newsletter
7. On cutting scope: Cutting scope mid-cycle is not a failure; it is a necessary part of the design process to ensure the most critical pieces are shipped on time. — Source: Shape Up
8. On setting boundaries: Clearly defining what is out of bounds for a project is just as important for the team as defining what is included. — Source: Shape Up
9. On the value of constraints: Constraints do not limit creativity; they focus it by forcing designers and engineers to solve real problems within strict parameters. — Source: Intercom Blog

Part 4: Jobs-to-be-Done (JTBD)

1. On customer situations: "Situations cause purchases, not attributes. The same person wants pizza one night and a fancy Italian dinner another." — Source: JobsToBeDone.org
2. On feature lists: "Asking what customers want produces endless feature lists" because human desire is essentially bottomless. — Source: JobsToBeDone.org
3. On customer struggles: Meaningful innovation happens when you observe where customers are struggling in their current workflow and put energy into bridging that gap. — Source: Intercom Blog
4. On the domino metaphor: A customer's timeline is like a row of dominos; the final purchase only happens because earlier situational dominos tipped them forward. — Source: JobsToBeDone.org
5. On interviewing customers: Use customer interviews to interrogate their past behavior rather than asking them to predict their future preferences. — Source: Churn.fm
6. On personas: Fictional user personas are often distractions; teams should focus entirely on the concrete job the user is trying to accomplish. — Source: Intercom Blog
7. On making progress: People buy products to make progress in their lives, actively pulling themselves from a struggling state to a better one. — Source: JobsToBeDone.org
8. On competition: The real competition for a new feature is often not a direct rival product, but rather the customer's existing workaround or doing nothing at all. — Source: JobsToBeDone.org
9. On context and design: If you design software without understanding the situational context of the user, you are essentially just guessing at the solution. — Source: Ryan Singer Blog
10. On pushing and pulling: A purchase requires both a push from current dissatisfaction and a pull from the promise of a new, better solution. — Source: JobsToBeDone.org

Part 5: UI Design and Affordances

1. On capability over aesthetics: A user interface must first and foremost provide the capability to solve a problem; visual aesthetics are secondary to actual function. — Source: Ryan Singer Blog
2. On affordances: The design must make the software's capabilities obvious and accessible so the user knows exactly what they can do on a given screen. — Source: Ryan Singer Blog
3. On user flows: How a user moves through a sequence of actions is significantly more important than how any single, isolated screen looks. — Source: Signal v. Noise
4. On form and function: Do not make final decisions about form and layout until you have clearly communicated the required function of the interface. — Source: Hey.com Blog
5. On breaking down jobs: A well-designed interface maps directly to the beginning, middle, and end phases of the job the user is trying to get done. — Source: Ryan Singer Blog
6. On visual hierarchy: Use styling and layout primarily to draw attention to the most critical actions rather than relying on purely decorative elements. — Source: Ryan Singer Blog
7. On states and transitions: Designers must account for the empty states, the error states, and the transitions, because that is where users most often get stuck. — Source: Signal v. Noise
8. On the medium of software: Software design is not graphic design; it is the design of interactive, stateful systems that respond dynamically to user input. — Source: Intercom Blog
9. On validation rules: View constraints like account creation as a step in the user's larger job, rather than treating it as a strict database validation problem. — Source: Felt Presence

Part 6: Abstraction and Breadboarding

1. On breadboarding: Use breadboarding to map out places, actions, and connections without getting bogged down in visual layout or pixel placement. — Source: Shape Up
2. On fat marker sketches: Draw with a thick marker to deliberately prevent yourself from adding unnecessary detail too early in the exploration process. — Source: Shape Up
3. On the danger of mockups: High-fidelity mockups create a dangerous illusion of completeness that often hides fundamental structural flaws in the design. — Source: Shape Up
4. On architectural thinking: Approach software design like physical architecture, focusing heavily on the load-bearing structures before picking the paint colors. — Source: Felt Presence
5. On spatial relationships: Define how different functional elements relate to each other spatially before deciding exactly what those elements will look like. — Source: Shape Up
6. On language in design: The words used in an interface are highly functional elements that require as much careful design attention as the buttons and menus. — Source: Signal v. Noise
7. On the limits of sketching: A sketch is simply a tool for thought, meant to be entirely discarded once the structural problem has been solved. — Source: Shape Up
8. On identifying risks: Working at a low-fidelity level of abstraction helps you spot the unknowns and de-risk the project before any actual code is written. — Source: Shape Up
9. On collaborative shaping: Keep the shaping group small to maintain speed and focus, avoiding the trap of consensus-driven design by committee. — Source: Shape Up
10. On multiscale thinking: Good design requires thinking at multiple scales simultaneously, from the overall system architecture down to the individual UI interaction. — Source: Felt Presence

Part 7: The Reality of Shipping Teams

1. On the thrill of building: Teams lose their momentum and joy when projects drag on without a clear finish line; shipping restores that thrill. — Source: Ryan Singer Blog
2. On good enough: Striving for perfection prevents you from shipping; focus intensely on whether the proposed solution is simply better than the current baseline. — Source: Shape Up
3. On discovering tasks: The real tasks of a project are discovered while the team is building it, not predicted perfectly during a preliminary planning meeting. — Source: Shape Up
4. On hill charts: Use hill charts to visualize progress based on certainty, distinctly separating the phase of figuring things out from the phase of executing. — Source: Shape Up
5. On the unknown unknowns: The first third of any project should be spent eliminating the unknown unknowns so the remainder becomes predictable execution. — Source: Shape Up
6. On scope hammering: As the deadline approaches, the team must aggressively hammer the scope to fit the remaining time, willingly sacrificing nice-to-have features. — Source: Shape Up
7. On quality: Quality is not absolute; it is highly relative to the strict time budget you decided to allocate to the problem in the first place. — Source: Shape Up
8. On comparing against reality: Compare your project's progress against the actual problem you set out to solve, not against the ideal, perfect version in your head. — Source: Shape Up
9. On finishing: The last ten percent of a project takes the most discipline because the temptation to add just one more thing is strongest at the end. — Source: Shape Up

Part 8: Strategy and Felt Presence

1. On consciousness in design: Pay close attention to how the human mind perceives a situation; the underlying psychological forces dictate how the design will ultimately be received. — Source: Felt Presence
2. On seeing in the dark: Product strategy requires developing the capacity to make confident decisions when the path forward is ambiguous and hard data is scarce. — Source: Ryan Singer Blog
3. On process as a toolbox: Reject rigid, step-by-step methodologies; treat design processes as a dynamic toolbox to pull from based on the specific challenge at hand. — Source: Felt Presence
4. On the product manager role: The modern role of a product manager should be heavily weighted toward strict problem definition rather than daily project micromanagement. — Source: Lenny's Newsletter
5. On systemic issues: When teams consistently fail to ship, the root cause is usually a systemic failure in how work is shaped and bounded, not a lack of effort. — Source: Ryan Singer Blog
6. On taking a step back: Step back from the immediate UI components to thoroughly understand the larger context of why the user opened the application in the first place. — Source: Ryan Singer Blog
7. On false precision: Avoid using numerical estimates for tasks that have not yet been fully understood, as it creates a dangerous and false sense of precision. — Source: Shape Up
8. On writing over talking: Writing down a project pitch forces a level of clarity and intellectual rigor that is completely impossible to achieve in a casual conversation. — Source: Shape Up
9. On the core loop: Find the core loop of value delivery and ensure it functions perfectly before attempting to add any secondary features or flourishes. — Source: Bright & Early Podcast