Exactly right. Too often I've seen people commit to a schedule where the milestones were of unknown difficulty. When cutting through a new jungle, you have no idea what is between you and your goal, so really all you can say is that the best you can hope for is X if this jungle happens to be like previous ones.

This is especially true in startup situations where you are learning technologies that may themselves not be complete, with people who are learning their own new things, to achieve a result which is only hypothetically possible. It drove my CFO nuts but rather than commit to a schedule for a big deliverable I would walk backwards from the end point and say, "These are the stops between where we are, and where we are going. We measure our progress by getting to each stop, but like a subway map there isn't a known amount of time between stops, only what the stops are." And he would come back with "well we only have money to get to this date, will it be done by then?" and then we would talk about the uncertainty between each of the milestones. At some point you can reach a common understanding of what the unknowns are and how discovering their value will inform on the difficulty of the next step.

That said, I've met managers who just say "Oh we will be done by %x date." and then basically worked the problem the same way I have.

If you're agile you can break down the intermediate stops as sprints but estimating the backlog is still the killer step.

It's not agile to list out 32 milestones on the way to completing a project and estimate them up front. It's agile to list 32 steps and estimate the first step, which you will still get wrong.