Love the Pixar example. I think the rough outline is called the storyreel!?
Most professional artists work the same way. They don't render one part of a drawing after the other ... they go from rough rendering to the details for the whole piece of art.
So I would write the rough game design and the more technical documentation at the same time ... and add details as needed.
The problem is that even with that approach you might fall into the trap mentioned above (having to throw away all the code).
How well do you know the theory behind software architecture?
One approach that might help is developing low-level functionality as libraries that your game project uses.
That way you are less likely to be tempted to write god classes or go for quick/hackish solutions (write code where it doesn't belong).
Of course that complicates the build process.
But if you have to throw away the prototype code of your project ... maybe the functionality in the libraries can still be used.
I'm a fan of this article:
It covers the jumping-the-gun-topic.
I personally would probably use a SCRUM based approach:
- Write the features of the game (product backlog).
- Turn the product backlog content into stories.
- Start working on stories in Sprints.
Your don't need to implement features right away. But you need to be aware of the features you might want to add in order to write a frame that offers a way to add those features.
If you don't know how to do that ... maybe just work on bringing the most simple versions ("Hello World!"-style) of those features together in a simple project.