The desired path

To make effective decisions about building a product, we need to dive deep into the problem, challenge ourselves to think bigger, ask consecutive “whys”, and zoom out to the ideal scenario. We must first understand and align on the desired path and the reasons behind it. ¹

The obvious path is not always the right choice. ² The easiest is not always the most effective, especially in the long term. The easiest path carries the risk of adding work that needs to be managed later. Its cost to quality and cost to change only grow with time. Know your constraints.

When the time to finish exploring feels right, reduce the options. Keep the ideal state in mind while choosing what to ship first. Software is liquid. ³ It can be changed, molded, shaped. That’s not an excuse to skip the exploration, it’s a reason to do it. The tools we have today allow us to explore closer to the final product than ever before. ⁴ Start from a place worth iterating toward.

For better decisions, ask yourself and your team:

• What’s the impact of doing the easiest path? And what is the impact of doing the desired one?
• What do we lose if we take the easiest and fastest path?
• What is the essence of the desired path?
• Why is the desired path worth pursuing?
• Have we explored ways to achieve the desired path?
• Can we commit to a minimal path that will incrementally get us closer to the desired path?

Thinking small then going big means rework. Thinking big then going small means direction. I like to start with where I want to go, and then find the smallest step that gets me closer to the desired path.