Linus built the working prototype/self-hosted in 3 days mixing a lot of his learnings from bit-keeper and his knowledge of disk management .
To me, that's rapid prototyping. It's enough domain knowledge to make it work for himself well. He didn't spend a bunch of time thinking nor coming up with solution since he was actively building Linux at the time. The key is he employed the help of others to build Git and eventually take it over since he wanted to focus on Linux.
This all comes with a huge caveat in that Linus's 3 days == 1000 of mine. His 'just enough' knowledge is near expert level.
As others have asked, what are you trying to build? A technical solution or an end-user solution.
Technical solutions do require a lot more domain knowledge than a twitter/airbnb (at the early stages).
In the end, I believe in rapid prototyping and failing fast. Learn just enough, whether technical or end-consumer to launch fast.
The thing I agree 100% is though, don't break user-space . I believe this applies to end users of products, whether developers or customers. Once people start consuming something, don't break it. Doesn't matter whether you believe it to be 'correct' or a 'bug'. Expectation management of slow and easy depreciation.
So, for me the distinction between the two approaches (prototyping -vs- hammock driven) is lately about whether you are solving a largely known/understood problem (equivalent to having domain expertise, in an absolute sense) -vs- solving problems to which you don’t know the answers. In the latter case, there is no shortcut getting around thinking time.
Or, as they say: “A month in the laboratory could save an hour in the library”