I’ve found that people often conflate the terms “iterative” and “incremental” when it comes to software and/or product development—they often use “iterative” when they really mean “incremental”. I’ve been guilty of this in the past, but feel like I have a good handle on the differences now.
Iterative development involves a cyclical process. While one may still have a general product road map, learning from one iteration informs the next iteration. This learning can come from end-users, testers, or the developers themselves. An iterative process embraces the fact that it is very difficult to know upfront exactly what the final product should look like (no matter how smart or well-informed you might be) and builds in as many learning opportunities as possible.
Incremental development involves breaking a large chunk of work into smaller portions. This is typically preferable to a monolithic approach where all development work happens in one huge chunk. Unlike those using an iterative approach, those taking an incremental approach will stick as closely as possible to the original road map. Few, if any, opportunities for feedback exist until the final product launch.
No one uses a purely iterative or incremental process. Those using an incremental process are unlikely to completely ignore any feedback or learning that happens to seep into the process. Those using an iterative process are unlikely to completely let go of their original vision and preconceived notions and rely purely on outside learning.
Both processes have their places. If the problem and solution are well known, then an incremental process can work well. However, many software and product development initiatives are a search for an unknown solution to a known problem. If the solution is unknown, then an iterative process is critical. If both the problem and the solution are unknown, then an iterative process alone isn’t enough—but that’s a topic for another day.