The Best Products Are Designed Backward

Start with the experience you want someone to have. Not the features you want to build, not the technology you want to use — the experience. Then ask: what would have to be true for that experience to be real? That question drives every decision backward through the design process, from launch to line of code.

This sounds obvious and is almost never done. The reason is gravity: teams are made of people who are good at things — engineers who see solutions, designers who see interfaces, founders who see markets — and each is pulled toward starting from what they already know how to do. Forward design is the path of least resistance because it starts from the builder, not the user.

Forward design produces feature lists. Backward design produces coherent products. The difference is whether you started from the user or from yourself.

Working backward is a chain of "what would have to be true" questions. For the user to feel this, the product would have to do that; for it to do that, the system would have to support this; for that to be possible, we would have to build the following. Each link is a decision, and because they descend from the experience rather than the technology, they stay coherent all the way down.

The test is simple. Pick any feature on the roadmap and ask which experience it exists to create. If the answer comes easily, you designed backward. If the honest answer is "because we could," you designed forward, and it will show.