In software development, we love to make plans. We plan everything from 2-week sprints to 5 or more year roadmaps. And yet I sometimes think that the point of planning is misunderstood.
The point of having a plan, for me, is not to have a concrete set of steps. Well, it is that, but that's not the real value of it. The point is understanding the why of the plan, and the how of the steps.
The why of the plan is this: Why does this plan make sense? Why does this plan bring us closer to fulfilling our goals? Without a purpose behind it, a plan is meaningless. I would even go so far as to say that sometimes having a fixed plan at all is counterproductive. Sometimes the product may be in an exploratory phase, and the only plan would be to try a lot of things and see what works. But the why behind this plan is clear: To evaluate a lot of options. Then we could go into the details and schedule the evaluations and timelines for the options we want to explore. The point is that the goal dictates the plan. Not the other way around.
And on a smaller scale we have to understand how the steps of the plan contribute to achieving the goal of the plan, how they contribute to fulfilling the why. The point of this understanding is that often plans can't be executed exactly as they were initially created. But if we understand how something we can no longer do was supposed to contribute to the end goal, then we can intelligently search for a replacement to that something. We can do this because we understand the new situation we're in and we know that we need to find something else to do that fulfills the purpose of the step we wanted to take, but can't.
Actually, I would summarize this whole article with one concrete advice: For every component of a plan, understand the purpose of the component. For the plan as a whole that is the why, and for the steps of the plan that is the how.
Thanks for reading :)
Top comments (0)