This is a really cool analogy you’ve identified! I’d like to TLDR it for future reference:

As I mentioned, the “engineering-driven” approach to software… “now that I have X, I bet it wouldn’t be too hard to…” is forward chaining. It’s looking for opportunities to move forward based on the current state of the system, not based on a product goal.

Now the “product-driven” approach, like backward chaining, is goal-directed…. The idea comes first, and then it’s up to the engineers or the software architects to come up with an implementation plan and decide whether or not it is feasible. And hopefully the implementation plan is incremental, and the project is broken up into parts – subgoals, if you will.

a mentality bent on systematizing software teams, that sees software teams like priority queues, the central problem in software as assigning the highest priorities to the tasks with the highest expected net value… In that sort of paradigm, the goals are known, and so “product-driven” backward chaining is favored.

A different mentality wants software teams to be more organic. Software isn’t always the pursuit of known goals – often it is highly exploratory in nature. In this paradigm, the goals are unknown, so “engineering-driven” forward chaining is more favored.