Goal vs Process

Imagine if you had to drive your car to the store by giving it a full set of instructions (with as many contingencies as possible) - "turn the wheel 13 degrees, accelerator to 10% for 15 seconds, brake until 15mph...". I wouldn't want to ride in it! The odds of the car getting to the store are pretty low and only non-zero if the environment is very simple and doesn't have many surprises. This is waterfall development, and process-orientation.

Instead, we iterate our way through the process, interactively, making many adjustments along the way. We have a capable agent in the car (us) that can interpret many changes and react to them in realtime, and we are (mostly) safe getting to the store. There are still accidents and mistakes, but the iterative, goal-oriented approach is much more robust. 

As it is for cars, it is for software teams, and even software products. For teams, the analogy is obvious, and in the title - we tend to do better if we are goal-oriented ("what problem are we solving for the user or customer, and when") instead of process oriented ("here's a spec, implement it"). Goals have value all the way through the team - to the degree that the team understands the goal and intent of the business and product, it can act much more effectively (there is a very fun, and funny, video about this from a naval submarine commander, that's worth a view).

And it's true for products as well - to the degree that we can help users with a goal, rather than presenting them with a rigid process, they will be happier and more effective. This means designing with intent in mind, and with a tool and modular mentality - give the user well-defined behaviors and pieces that compose and combine. The best feeling is when a user surprises you with something you didn't think your product could be used for. 

Users really only care about goals, to the extent that they care about process, it's to have as little of it as possible to get to their goal. Teams too. The best thing you can do is to be as clear about goals as you can be, and to help your team, and users, find their way effectively.

(I wrote the above a few months ago on my substack: Goal versus Process - by Sam Schillace - Sunday Letters (substack.com).The really interesting thing about this is that the capabilities of advanced LLMs are allowing us to code in the realm of goal now. This is very different, and is probably the most disruptive thing about the current moment. I'll have more to say about that soon).