Skip to content

ZeroBlockers vs Lean UX

A failed test should be able to stop the feature.

Agree the outcome, test cheaply, follow the evidence

Lean UX links business outcomes, user needs, assumptions, and experiments. The whole team learns together, and design documents come second.

Lean UX runs a continuous cycle around a business outcome: think, by turning assumptions into hypotheses; make, by building the smallest test; and check, by measuring what customers actually do. Then the cycle starts again.

Discovery is covered, and delivery and scale are left open

Lean UX covers discovery in depth and asks for empowered, cross-functional teams. It says much less about how those teams build, release, and run what they learn, and it leaves open how they are funded, who decides when a test goes against the plan, and how many teams stay aligned. So organizations use what they already have: a roadmap of committed features.

When a test shows one of those features is wrong, the team is often told to build it anyway.

The same learning loop, with the authority to act on it

Who carries the work from idea to satisfied customer

Lean UX

  • Strategy and fundingLeft to the organization
  • Discover the problem to Test solutionsCross-functional team
  • Build to Run and measureThe same team, though the book says much less about how

ZeroBlockers

“Lean UX already asks for all of this.”

Lean UX practitioners will say the book already asks the organization to change. They will add that a team practicing Lean UX well earns this kind of authority over time, as leaders see its evidence.

It does, and ZeroBlockers agrees with the direction. The difference is how specific it gets. Lean UX describes what the organization needs to become. ZeroBlockers says who funds what, who decides what, and what the Weekly Product Review covers. Without those specifics, a team with permission to fail still reports against a feature roadmap.

How the approaches differ

The differences explained

A failed test is wasted if the team must build the feature anyway

The Lean UX book says plainly that the method needs support from the organization. Its principles include teams that own problems, permission to fail, and outcomes over output, and it has a chapter on the changes an organization has to make. It describes the shifts an organization needs. It does not set out a funding model or say which decisions the team makes and which stay with leaders.

Jeff Gothelf, co-author of Lean UX, has made the same point about large frameworks that adopt it. SAFe, a framework for coordinating many teams, added Lean UX in its version 4.5. Asked how the two are supposed to work together, he wrote: “The short answer is, I have no idea.” His test is how easily an organization changes direction after a discovery. A team can learn that a feature is unnecessary and still be told to deliver it.

Three of the ZeroBlockers changes apply directly.

  • Funding. Fund a customer scope, such as onboarding, for the year. Leaders review the investment every quarter, while the solution can change any week.
  • Decision rights. A Stream Team is a small, persistent team that owns one part of the customer journey from research through live use. It decides whether to change course, keep going, or stop a solution. The Product Team, the leadership group for the product, owns strategy and investment and agrees outcome targets with the team.
  • Review. In the Weekly Product Review, a 30-minute meeting between the Product Team and its Stream Teams, each team reports one thing it learned, one decision it made, and one decision it needs, along with its outcome numbers. A team that stopped a feature explains why and says what it will test next.

Keep the hypotheses and the small experiments. What changes is the commitment around them: Finance funds a customer scope in place of a feature list, and Sales sells outcomes in place of dated features.

Sources and comparison scope

Reviewed September 2026. This page compares ZeroBlockers with Lean UX as documented, with attributed practitioner accounts where available. Descriptions of Lean UX follow its published guidance. Claims about common practice are attributed where they come from a named source. Other statements about what organizations typically do are our analysis. The worked example is our analysis and reports no measured results.