The Iteration Imperative
21 June 2020 ‧ 7 min read
Back when people first started building complex software, the natural approach was to do this in a planned methodical way that resembles physical engineering. You make a detailed plan, validate the plan in theory, build it, test it in practice, and then deliver the final product to the customer. While there are variations of this approach, it is commonly called the “waterfall” model, since you have a cascade of stages that the process goes through, and once you've “fallen” from one stage to the next, you generally don't go back.
Over time, people realized that this approach was not optimal for the development of digital products. After all, software is more malleable than physical items. You can't easily add another story to a house once it's built. It's much easier to add new functionality to software—especially in today's world of software that's either run directly in the cloud or at least delivered and updated via the Internet, where you don't have to physically ship an updated software package to your customers.
Additionally, developing and improving digital products is risky. It is generally unknown what the best way to deliver value through the product will be. More concretely: when starting out, we don't know what functionality and user experience the product should provide in order to be most beneficial to its users. The more innovative a product is, the more risk there is. This is another key difference to many physical engineering projects, that are often more similar to previous constructions.
Today, many companies—big and small, incumbents and challengers, old and new—have adopted iterative software development practices. They use Scrum or similar practices, and ship new versions of their software more frequently than as one big annual release. On the surface, it seems they are now working iteratively... but they are not. To truly develop products iteratively, you have to start earlier.
The scrumfall trap
The trap that many companies fall into, whether they transitioned to an iterative, “Agile” development methodology or started out with it, is the “scrumfall”. In the “scrumfall”, software is delivered incrementally, often using the Scrum methodology, but that delivery is embedded in a waterfall-like process. The backlog items that the Scrum team works on to deliver get specified and prioritized top-down without participation of the Scrum team. There might be a “refinement” meeting in which the Scrum team asks clarifying questions and ensures that they can confidently deliver the item, but that's it. These items were first ideated and prioritized (by business stakeholders or product managers), and then designed (by product managers, business analysts, and/or UX designers), before they landed on the Scrum team's board. Once delivered, they will often go through separate, waterfall-like test and release stages. The different stages are “owned” by different stakeholders, which necessitates a handover and therefore enforces a waterfall-like structure.
Often, this process will be overall more iterative than a traditional waterfall in the sense that what moves through the waterfall isn't the whole software system, but rather individual features or “projects”. At any given time, there will likely be some features being ideated, some in design, some in development, and so on. Accordingly, releases happen more frequently than in traditional waterfall.
For each individual feature, however, the process is still very waterfall-like. There are few feedback loops before something is built and rolled out. The scrumfall has iterative delivery, but not iterative discovery.
Iterative discovery
Product discovery is the process of understanding the needs of users and customers and determining how value can be best delivered to them. It includes researching customers and their needs, identifying opportunities or problems, ideating solutions, and validating them.
Product discovery starts with generating insights into the problems to be solved. This could be done by reviewing existing information or conducting original research. In any case, based on this information, a product vision is formed, describing beneficial outcomes if this problem is solved in a better way. The vision provides the north star for then discovering the best solution.
This discovery process should be iterative. You should “think big, start small” (one of Intercom's product principles), meaning you should have the long-term vision in mind but make progress in small steps, not all at once. The reason the discovery process should be iterative is that most of the ideas we have to solve the problem will turn out not to work. We therefore need to fail early and often in order to double down on the ideas that work and kill the ones that don't. If we were certain that our ideas would work out, if there was no uncertainty whether our ideas will deliver the value we hoped for, then a waterfall-like process could work. However, since a lot of them won't, iteration is crucial.
This means that for every problem definition and every solution idea, you should identify what the most critical assumption is behind it, and then validate or invalidate that assumption as quickly and cheaply as possible. With that learning, you can then either double down or change course. This loop is at the heart of iterative discovery.
The misunderstood MVP
Product people who don't fully understand this need for iteration often ask “what should be the scope for the Minimum Viable Product (MVP) for this idea?” This is the wrong question, though. You shouldn't just have one MVP. You should have a series of MVPs, each testing another assumption. The first of these MVPs are likely not going to be real products, but rather prototypes of some sort.
This is at the heart of the Lean Startup build—measure—learn loop. Identify the most critical assumption, build the smallest thing possible to test it, learn from it, iterate. In Eric Ries's own Words:
To apply the scientific method to a startup, we need to identify which hypotheses to test. I call the riskiest elements of a startup’s plan, the parts on which everything depends, leap-of-faith assumptions. The two most important assumptions are the value hypothesis and the growth hypothesis. (…) Once clear on these leap-of-faith assumptions, the first step is to enter the Build phase as quickly as possible with a minimum viable product (MVP).
In contrast to these MVPs, the scope for the first “real”, shipped version of the product should be determined in a different way. Here, you don't just want to test a single assumption. You want to ship a product that makes sense from end to end and that customers will want. Now, I am not saying that you should gold-plate your v1. The scoping for a v1 is likely going to be more of an 80:20 exercise: can we get 80% of the potential customer value with 20% of the effort? If you've validated the critical assumptions using a series of prototype MVPs before you ever ship v1, you should be pretty confident in how to provide customer value, allowing you to make this tradeoff decision.
The elusive v2
Another way that lots of organizations fail to iterate enough is not revising features once their initial iteration has been shipped. This means that the build—measure—learn cycle stops when v1 is shipped. This can break the trust of team members who had been promised that something would be fixed in v2 (often designers and engineers). It is also not a good way to build a great product. It means you are leaving a “good enough”, 80:20 scoped feature in the product in order to chase the next shiny thing.
The reason organizations do this is because they feel they never have enough time and resources to do all the things they would want to be doing. So once something has been shipped as “good enough”, let's not waste more time with it, right? After all, we've already built the 20% that deliver 80% of the value!
This thinking is a fallacy, however. It is caused by not focusing enough. A great product isn't one that does a lot of things “well enough” (meaning “mediocre”). A great product focuses on a few things and really nails them. So if you've found something that works, consider doubling down instead of moving on. Make a good idea a great one—by iterating.
Another reason to avoid always moving on to the next thing instead of iterating is that it increases the complexity of the product. Every feature that is added multiplies the complexity of the product, which incurs additional efforts in design and engineering down the line. Improving an existing feature by iterating might add some complexity, but rarely as much as adding something new.
Iterative does not mean incremental
One potential risk when embracing the concept of iterative product development from discovery through delivery is to settle for only incremental changes. After all, it's easy to be iterative by continuously making small improvements to the product. This approach is great if you want to optimize an existing experience. However, you can't build a great, novel product that way.
Iterative doesn't have to mean incremental. Think about the development of the first airplane, clearly a completely novel product. However, the development was very much iterative: prototype after prototype was built and tested, until finally a working model was identified. Of course, if we take this analogy further, what these prototypes were testing was the feasibility (is there a technology that can achieve what we want to achieve?), because the riskiest assumption was the feasibility of manned flight. The same iterative approach is also possible to test assumptions of value, usability, and business viability. This way, even a big, long-term vision can be realized incrementally.
It's important in this approach to move away from the idea that every iteration has to produce working software. That is true only in delivery mode. During discovery, every iteration should produce learning. This could be achieved for example through creating prototypes or conducting research.
In order to achieve more than incremental progress in an iterative way, it is paramount to have a long-term vision and a strategy to achieve that vision. That strategy can then be broken down into assumptions, and they can be tested iteratively, starting with the most critical ones.
Many organizations believe they develop digital products iteratively, but have indeed only adopted iterative delivery practices. For true iterative product development, you need iterative discovery as well. Iterative discovery is critical due to the high uncertainty involved in creating new digital products. This means you have to start with a long-term vision of the product and a strategy to get there, break that down into assumptions to be tested, validate them one by one, often using prototypes, and finally deliver value on the confirmed assumptions by delivering scalable solutions.
I hope you found this article interesting. If you did, feel free to follow me on Twitter where I share thoughts and articles on product management and leadership.