The Problem with Iterative Development

When was the last time you or your team asked the hard question "What is driving our product development iterations?"

Another way to ask it is "Who really owns our product direction?"

Despite being a step-function improvement over waterfall development, iterative development can also create the illusion of product evolution.

If you were to conduct a retrospective on, let's say, the last 6 months of your investment in product development, how would your enhancements break down between the following (while many enhancements check more than one box, be honest about the one key driver for the change):

• Customer requests/demands

• Sales team requests/demands

• Ideas from a senior executive

• Security, Compliance, TechArch, etc. requirements

• Enhancements that support an agreed-upon vision for the product

For late-stage startups and growth companies, too often, the first two bullets above dominate the "why" list. A required culture of being revenue-driven fosters this. Since customers and sales teams can, for the most part, be assumed to be rational, its easy to try to satisfy them with development cycles to support the growth of the company.

The problem with overweighting these is that you are trading short-term satisfaction for sustainable mid/long-term success. The easiest way to remind yourself of this:

• Customers seek to serve their own best interest even when its unique in the market (rightly so!)

• Sales teams are incentivized to land the next prospect (rightly so!)

• Product teams are responsible for supporting the above while building a one-to-many product

What's your product's north star (vision) and how disciplined are your teams and processes to working toward it? To avoid a bloated, Frankenstein product, a healthy product prioritization process seeks balance among all of the above, and especially emphasizes being truthful about how each change supports the agreed-upon product vision.