That's such a great way of putting it! I think what makes this difficult is that it is hard to come up with a formula - so much of it is a "feel" that you develop over years of doing it.
Also, in tech we often account for the development time but not as much the time for everything else. Even though segment.io took you two days to build the MVP, I have a feeling it took you many, many more "passive" hours of thinking about the problem(may be even before you decided to turn it into a startup). When you take that into account the time you spent experiencing the problem and thinking through the various solutions, the MVP took you a lot more than 2 days to build.
One of my most successful projects took me barely a day to code. But it was a painpoint that I experienced and thought about pretty much every week of my undergrad. But for some reason, I did not feel I was in a position to attack the problem until a very particular moment. I'd like to think that if I attacked the problem the very first time I had the inkling of the pain, my solution may have been very different and less likely to gain traction.
It just takes a while to start developing solid, bigger-picture ideas about a problem. This is also why it's hard to realize the negatives of "pivoting" all the time, since we take for granted how much we've already invested in groking a particular space.
The same thing happened recently while hacking on Myth. To everyone on the team it felt like building the entire thing only took a couple days, but really I had been experimenting with a similar idea for multiple months, and it was already being used in production for our own CSS. The piece that took a few short days was just figuring our the best way to design the landing page—much less scope that conceiving the entire idea.
It's really hard to quantify that kind of time investment, and even harder to explain that to friends who think that everyone is launching fully-formed, successful MVPs in a single weekend without much thought. It definitely seems like something that can only be learned through experience. It's just an earlier stage version of the classic problem of founders always thinking that successful startups spring out of nowhere, when really the multiple years of living in a cramped room and almost killing each other is just shielded from view.
At least it makes things more defensible :)
Random other thought: I often catch myself bundling up tons of logic into a "first commit" and wishing that that wasn't a common practice, so that we could learn about how the beginnings of codebases are iterated on.