To kinda just expand on that because I think the analogy's most of the way there:
You're trying to keep something safe and all you've got is a weirdly infinite collection of cardboard boxes. So you have this brilliant idea... you get a dozen boxes and put your treasure in one of them.
That's great, it's certainly safer than leaving it laying out. It'll take someone at least like... a minute to go check all dozen boxes and find your treasure. But it still only takes you mere seconds because you know which box to open.
Except you'd really rather your treasure stay safe for longer than a minute. So you take all your boxes and put them inside other boxes. And put those boxes inside other boxes like nesting dolls. You nest each one a dozen times.
So now if someone wants to come and find your treasure, they need to open all 144 boxes to find it! But you still only need to open 12 because you know which stack to look in.
The iteration count is basically just how deeply you plan to nest your boxes.
In more concrete terms, increasing the iteration count is just a knob to control how much cpu/memory resources it takes to compute a hash. You want to turn it up enough to make brute forcing prohibitively expensive (make it as high as you can), but not so much that calculating the single correct hash to verify is too expensive (don't make it too high or else it will take too long to check your password at sign-in). People are saying this should go up over time because computing resources generally become more readily available (faster/cheaper), making both brute forcing easier as well as allowing you to perform more iterations to compute the correct hash on commodity hardware without it taking unusably long.