Skip to content

Change 1 of 6

Process

Teams decide what to build.

One team researches, designs, builds, and improves in a continuous loop.

The change

One team. A continuous learning loop.

A team can deliver exactly what was requested and still have no impact on product and business metrics. The risk begins when an idea is treated as a commitment before the team has learned whether it solves a worthwhile problem.

ZeroBlockers gives the team a customer outcome and a value stream to own. Research, design, and development become ongoing activities shared by the team. New evidence can change the solution while there is still time to act on it.

As AI speeds up research synthesis, prototyping, and coding, the team still has to judge which problem is worth solving and check its assumptions with customers.

What changes in practice

  1. Start with an outcome.

    Agree what should change for customers and how the team will recognize progress. Leave room for the team to choose and revise the solution.

  2. Learn as a whole team.

    Bring the people doing research, design, and engineering into the same problem. Work on a small amount at a time so context stays shared.

  3. Change direction on evidence.

    Use customer research, prototypes, and working software to test the important assumptions. Stop or adapt an idea when the evidence does not support it.

A practical example

Is a checklist what onboarding needs?

An onboarding team is asked to add a checklist. Instead of treating the checklist as the goal, it investigates why customers abandon setup. The problem might be unclear instructions, an unavailable integration, or a task that is not valuable enough.

The team tests the most important uncertainty first. It may still build a checklist, but the choice follows from learning about the problem. It defines success as more new customers completing setup and reaching their first useful result. Shipping the checklist is one possible step toward that outcome.

Three interwoven UXDX loops connect research, design, and development within one team.

Process in practice

Real case studies from UXDX conferences and other sources.

Browse 12 process case studies ↗

Common objections

Quality drops when you take away the handover gates
There are two ways of ensuring quality: checking at the end or continuously checking. But checking at the end is much slower and more expensive. Build quality into the work through peer review, automated tests, small changes, monitoring and rollback. Risk-based release guardrails distinguish routine changes from those requiring specialist judgment. And it works in practice, Hunter Industries reported an 18-month period with no new bug reports while practicing mob programming and continuous improvement. Read Chris Lucian’s account.
You will still have handovers between the different specialists in the Stream Team so it isn't really ZeroBlockers
Teaming is the default way of working in ZeroBlockers. The whole Stream Team works on the same item across research, design, and development with very low work in progress. So developers sit in on customer interviews, and designers are there while a developer prompts the agents. Specialists contribute their craft while everyone shares the context, decisions and feedback. Working together means higher quality decisions made much faster.
Having everyone work together is a waste of time. It is much more efficient to work separately
Individual utilization is not the same as team effectiveness. ZeroBlockers uses teaming by default because it lets teams finish one item together rather than maximize how many items are started separately. Shared context reduces handovers, exposes assumptions and brings review into the work. Once you factor in the rework normally required with separate working, teaming works out as the same amount of effort (assuming the team size is less than five). And it has the added benefit that the team learns and raises the quality bar continuously.
Does every specialist have to do every activity?
No. Specialists still bring their own craft, so a developer might sit in on customer interviews without running them, and a designer can follow the build without writing the code. What the whole team shares is the problem and the decisions. That keeps the context in the team and leads to better decisions, because ownership isn't passed from one function to the next.
All common objections ↗