Working in software long enough, you stop noticing that the ground is always moving. Ambiguity is the default state. Things that were true last sprint aren't true this one. The product you released three months ago isn't quite the product that exists today, and it won't be the one that exists in six months. That's not failure — it's just what software is.
You get comfortable with it. Most people do eventually. What I find genuinely interesting is what happens when you're working with people who come from a completely different relationship with the word "finished" — because the collision of those two worlds, handled well, tends to make both sides better.
Take someone who's spent their career in physical product design. They understand iteration — they've done it. They sketch, prototype, test, revise. They build a manufacturing process and a supply chain around something that has been made as good as it can reasonably be. And then it ships. It's done. It sits on a shelf or in a box or on a production line and it does what it does, unchanged, until it's discontinued.
That model of work has a satisfying shape to it. The problem was identified, attacked, and solved. There's a version of the object that is the answer. And there's a real discipline in that — the rigour required to commit to a thing, manufacture it at scale, and not get another shot at it is genuinely demanding in ways that software teams rarely experience.
Software is different in kind, not just degree. (Though if you want to see what happens when software people build physical cars, look no further than Tesla's panel gaps.) A product released into the world is immediately in conversation with its users — their changing expectations, the platforms it runs on, the competitors reacting to it, the data coming back from it. Intercom's blog put this well in an early post on how products become obsolete: the way users want to interact with your product will always change, sometimes in ways you never anticipated. A product isn't a solved problem. It's an ongoing relationship.
Marty Cagan has written about this as the fundamental difference between organisations that truly understand software and those that don't — the ones that get it treat their products as living systems, not deliverables. Melissa Perri names the failure mode the Build Trap: teams so focused on getting things out the door that they lose sight of whether what they're releasing is actually working. The answer to "what did you build?" is satisfying in a way that "what did you find out?" often isn't, but the second question is usually the more important one.
When you're working across these two worlds, the interesting thing isn't that one is right and the other is wrong. Physical product people bring things that software teams genuinely lack — rigour, constraint, the discipline of finishing. The translation challenge comes when the assumptions of one world get applied directly to the other without adjustment.
In practice it looks like reading a roadmap as a set of binding commitments rather than a current best guess, or treating an unresolved bug as evidence of poor execution rather than normal operating conditions. These aren't unreasonable instincts at all — they're just calibrated to a different kind of work. Understanding that is more useful than being frustrated by it.
What I've found works is finding the right analogies rather than explaining iteration theory. A physical product person tends to get the idea of a living product quickly when you compare it to something they already know — a city rather than a building, or a garden rather than a sculpture. Something that has to respond to its environment to survive. The principle lands faster than any framework.
The subtler shift is around ambiguity itself. In physical product work, ambiguity is something to eliminate as early as possible — you can't retool a factory halfway through a production run. In software, Perri's point is that sitting with uncertainty long enough to learn from it is actually where the value is. Getting someone to genuinely believe that uncertainty is information rather than a problem to be fixed takes time. But it does happen, and when it does, it tends to stick.
The teams I've seen navigate this best don't spend much time explaining the philosophy. They show their work. They make the iteration visible. They talk openly about what they learned from something that didn't land the way they expected, and they treat a change of direction as a result rather than a setback.
People come around a lot faster that way than they ever do from a conversation about agile principles.