Can you give an example of an ambitious problem you solved backward this way.
1. What would have to be true for us to have reliable transmission of messages over an inherently lossy network? 1a. some kind of method to ensure that a message got to its intended destination
2. what would have to be true to ensure that a message got to its intended destination?
2a. some kind of method of ensuring that failures don't occur, or if that is impossible, some kind of method of making intermittent failures not prevent the system from eventually functioning.
3. what would need to be true to make intermittent failures not prevent the system from functioning
... etc...
Slightly misleading because I'm obviously working back from a familiar example, but I think the technique is applicable in some cases. At the very least your solution is born out of trying to make the impossible just barely possible rather than seeking to build layer by layer to achieve something possible.
However, with TCP/IP you can also see how using traditional methods also work.
The challenge there ended up localized around a couple of really hard sub-problems. One was that Netapp's storage model was file based (rather than block based) and so part of the problem was scaling the operation of a file state machine, and the other serious sub-problem was the creating a reliable way to keeping protocol/process state that was in "flight" in order to recover from failures. Working backwards led to what I ended up calling the "three layer cake" model which split the storage stack into parts that were loosely coherent and tightly coherent.
I have always started on the solution to an ambitious problem by asking "what would have to be true for this to be solvable?" and from each of those things working backward until you get to things that are all true now. Then you can start solving the "almost" true things and work forward to the ambitious solution at the end.