COMPONENT METHODOLOGY
Most frameworks filter ideas. This one refines them.
Component Methodology is a way to decide what an idea is really made of, where it should live, and whether it makes the system faster the next time it appears.
ORIGIN
It started with a team that was doing too much work to move so slowly.
The team was large, capable, and constantly busy. But releases moved slowly because every decision behaved like a one-off decision. Patterns were rediscovered. Exceptions became precedent. Small product choices created new operational weight downstream.
Design systems had already solved part of this problem for interfaces: stop designing every button from scratch. Component Methodology applies the same discipline to product decisions. If an idea is going to recur, connect, or carry weight, it deserves to be shaped like a component before it becomes another dependency.
THE FRAMEWORK
Three questions, in order.
01
Is it Crucial?
Strip the idea down until it can stand on its own. A feature request might really be a rule, a state, a role, a workflow, or a reusable product behavior.
02
Is it Reusable?
Look for the next occurrence before designing the current one. If the pattern will return in another product area, team, or process, it needs a name and a boundary.
03
Is it Beneficial?
The test is not whether the idea is clever. The test is whether it compounds: fewer decisions next time, less explanation, less drift, and more speed.
Failing the test isn’t rejection. It’s direction.
THE OUTCOME
Over time, the framework produces compounding decisions. Teams stop debating the same shape of problem. Systems get lighter because their parts are named, reusable, and easier to change. Speed improves because the organization has fewer hidden choices to remake.
THE BOOK
Component Methodology is being written in public, slowly.
The book will collect the framework, examples, and the practical language needed to use it with teams.