Lean UX is Jeff Gothelf and Josh Seiden’s guide to doing design work inside agile teams. The traditional UX process, where designers create detailed specifications before engineers build anything, doesn’t work well in an environment where requirements change every sprint. Gothelf and Seiden propose an alternative: treat design as a continuous, collaborative activity where the whole team participates, rather than a phase that happens before development begins.
The book introduces a three-part process. First, declare your assumptions about the user, the problem, and the solution. Second, design the smallest possible experiment that can test those assumptions. Third, run the experiment, learn from the results, and decide what to do next. The emphasis is on learning speed: the faster you can learn whether an assumption is correct, the less time you waste building the wrong thing.
The collaboration model is the book’s most distinctive contribution. Instead of designers creating pixel-perfect mockups that get handed to engineers, the whole team works together on low-fidelity sketches, discusses the intent behind design decisions, and iterates based on real user feedback. This requires designers to let go of ownership over the visual output and engineers to participate in design conversations, which is a cultural shift for many teams.
For founders building product teams, the book provides a practical model for how designers and engineers can work together without the friction that often arises when detailed specs arrive late or when engineers feel like they’re just executing someone else’s vision. The approach is especially relevant for small teams where everyone needs to wear multiple hats.
The writing is concise and organized around practical guidance rather than theory. Each chapter includes specific techniques, from design studios (collaborative sketching sessions) to hypothesis-driven design (framing design decisions as experiments). The third edition includes updated material on remote collaboration. Some readers will find the content too basic if they’re already practicing agile development, but for teams making the transition from waterfall or spec-driven design, it fills a real gap.
