Abstract
Teams argue about whether to ship fast or build it properly as if one answer fits every project. Brandon Chu's model says it depends on what you already know.
If you aren't sure the problem matters, polish is wasted, so move fast and learn. If you're confident in both the problem and the solution, take the time to build it well, because the work will last. If the problem is real but the solution is unproven, find a middle ground. Your confidence should come from evidence you can point to.
Method
- 01
List the initiatives
Write down the projects or features you're about to build.
- 02
Rate confidence in the problem
How sure are you that this problem matters to the people you serve? Base it on things like usage data and support requests.
- 03
Rate confidence in the solution
How sure are you that this particular solution will fix it? Prototypes and past results count. Hope doesn't.
- 04
Read the recommendation
Low confidence in the problem means move fast. High confidence in both means build for quality. Confident in the problem but not the solution means balance the two.
- 05
Revisit as you learn
Each release gives you evidence. Move initiatives on the chart as your confidence changes.
When to use it
- A team disagrees about how polished the first version should be.
- You're planning a roadmap and want the investment to match how certain you are.
- A project is stuck being polished, or keeps shipping work that has to be redone.
Common pitfalls
- Rating confidence by gut feeling. For each rating, ask what data backs it up.
- Using speed as an excuse to cut corners on things that are hard to undo, like security or data loss.
- Never moving an initiative. Once the evidence comes in, the right balance changes.
- Treating the zones as hard lines. Confidence is a sliding scale, and so is the right response.
Origin and references
Attributed to Brandon Chu.
- Chu, B. Product management mental models for everyone. The Black Box of Product Management.