Sometimes our products evolve over a tortured, chaotic, inefficient path. Other times development unfolds like clockwork, bringing the value to market almost exactly as predicted. We do our best to control the process, hopefully experiencing more of the latter, and less of the former. 

Since the first time man made something for the second time, we’ve pursued a better process. We seek the best methods, checklists, and step-by-step guidance that enable us to replicate our efforts, eliminate inconsistency, and maximize our return on investment. Yet, it’s often difficult to know what will work best in which context, and for which project, and with which team. 

It might be helpful to take a step back and consider if there is an underlying nature we can assign to product development. We might ask, to what degree do we believe an idea will evolve into its final form vs be built on a preordained design? The examples in the previous chapter run the spectrum between these two notions. My design school project, The Traveling Clog Family seemed to pop into existence fully formed, leaving “only” the matter of  well-executed craft. On the other hand, the modern smartphone evolved, sometimes painfully, over decades of revisions in form, function, and technology. At the risk of conjuring a debate between evolution and intelligent design, this discussion has no intent on delving into religion or Darwinism. That said, the terms provide a useful metaphor in the context of product design. 

An evolutionary metaphor is probably best drawn to the Minimum Viable Product (MVP) philosophy, or to the Agile methodology. As the barriers to production and making keep lowering, particularly in regards to software products (e.g., with the help of AI), but also with some physical products and with services (e.g., with access to more turn key vendors, and ready-made resources), this approach becomes more and more attractive and accessible. This in turn lowers the barrier to risk-taking and iterative market experimentation that we might generally call an evolutionary or an MVP approach. In this way the product team accepts that there are some aspects of the user experience that they cannot determine ahead of time, and the more they attempt to, the more risk they are imposing on their return. For example, it could be that large swaths of the product experience (i.e., its features and/or UI design) that stakeholders argued must be included in a product’s initial design prove to be of little value, thereby costing the company multiple times over in terms of longer development time, more costly production, and loss in sales and brand loyalty. In that case, an MVP philosophy could potentially save countless hours and dollars. Hence, the goal is to establish the minimum amount of design, features, and development that could constitute a viable product, then release that. Through diligent market surveillance, the designers can then rely on market performance and real-world user feedback to inform, even validate, the next iteration of the product, and presumably its added or improved features. 

Agile development provides similar characteristics and benefits to MVP, but is not exactly the same. Agile development is not only synonymous with a means of producing iterative design changes, but more fundamentally a logistical framework for breaking down work and coordinating team members. Agile is also associated with software products, and iterative releases of established software at that, whereas an MVP approach is perhaps more of a general strategy for taking any type of new product to market. In either case, Agile and MVP design philosophies rely on real world performance and rapid feedback and iteration as an integral means of steering product development. Such a pattern, we could argue, is evolutionary in nature. 

Intelligent design, on the other hand, is arguably more analogous to a Waterfall development approach. In a way, evolution and intelligent design are ultimately based on the same sequence of steps. They differ in that one commits to repeating those steps more often on a smaller scale, the other attempts to accomplish its business and product goals by iterating less and conducting those steps on a larger scale, assuming the extra time, care, and investment will yield less risk. In other words, releasing a product, then learning from the market, then revising and re-releasing it again, and then repeating that sequence could take too long and cost too much money all together. Not to mention could be catastrophically unsafe. Consider the phased approach to drug development, or the building of a new airplane. I don’t know about you, but I’m not really interested in the “move fast and break things” approach there. No matter where you land on the spectrum, the modeling of cost, revenue, and timing is an exercise every company conducts. Thus, in some cases, investing more time and resources to plan and design a solution prior to release could be the more effective means of addressing the risk of ultimate failure. It seems clear we’d have to take this on a product by product basis. 

What category would we place Henry Ford’s Model-T? He supposedly said that if we asked people what they wanted they would have said a faster horse and carriage.* Among his other insights, I would assume Henry Ford looked at the problem of moving around this country and understood the primary issue was that people limited their travel based on the needs of an animal. One that required a certain amount of care and cost per mile. One that could only move a certain amount of material per mile. If people were traveling because of the need to exchange goods in an evermore industrialized country and extend their ability to work, then first principles would dictate that replacing the horse with a more efficient machine would be successful.

It didn’t really matter whether people had ever seen or imagined a motor vehicle. People had a need. That need could be better served with this machine. Of course, Ford did not invent the automobile. While he clearly had insights about why people would want an automobile, he is credited mostly with making it affordable through his implementation of the assembly line process and mass production. Ford seems to have predicted the pressures industrialization would put on labor as production became more centralized, and the cost of producing machines continually reduced as volume went up. In the modern age, people* would benefit from being able to provide their labor and connect with hubs of production and commerce more efficiently. A motor vehicle was a product that sat at the nexus of these phenomena.

In a more modern example, Apple chose to create the iPod and iTunes because they believed they had a better way to provide an experience people enjoyed having (finding and listening to music), and conveniences that were fundamental (having a device that delivers those experiences in your pocket). For both Apple and Ford, we could easily argue that these products were not the first products in either category, because they weren’t. However, instead of only taking a simple single step forward from their predicates, they trumped the competition with solutions no one to that point were able to achieve at that scale. This is informative as an example of a very deliberate development venture whose success as a revolutionary idea hinged heavily on a fully realized and complete solution. Had Ford or Apple applied an agile or MVP approach (e.g., an engine-assisted horse drawn wagon?) it’s possible their products would not have performed well enough, been too cautious, or provided a great enough value proposition to create the tipping point for the public to take on a new paradigm. Having said all of this, it’s interesting to consider that we could point to the succession of iterations to come from both products and say that those initial versions were better categorized as the MVPs. 

Rather than give ourselves a headache trying to frame the Model-T and the assembly line as an example of evolutionary or intelligent design, or choosing Agile vs Waterfall, these concepts might be better considered as a spectrum. Similarly, it’s probably unproductive to argue over which is better, but rather which point on that spectrum is most appropriate for the product vision at hand and for the team and its resources. 

Despite the infinite variety of combinations of products, people, requirements, resources, technology, constraints, and creativity, when we set out to develop anything we expect to be able to set our clocks to it – literally. I can’t think of a project, Agile or otherwise that didn’t try to establish a schedule. Predictability is at the heart of planning and executing a project. Perhaps it’s simply that when we feel more uncomfortable with the unknowns we make smaller slices of plans, check points, and executables. When we feel like there are less unknowns we are more comfortable making larger plans and executables. 

To aid us in organizing our efforts we employ abstractions to model the process we will take planning and executing our project. There have been countless process improvements and theories to help us do just that.

The goal of this chapter was not to come to a distinct conclusion about which point on the spectrum you and your team should be on, or provide a definitive checklist to do so. Perhaps the best way to think about this spectrum is that it provides flexibility. Our company, our team, our project does not need to be defined by a point on a process spectrum. If we are going to be defined by anything, it seems to me we’d be defined by the quality of our products and the commitment to a vision, a greater good, an expertise, and our ability to deliver that value to the people that can use it and maybe need it. The next chapters discuss a few of those methods and ideas as touchstones across that spectrum.