I’ve been a product designer or member of a product development team for over 50 new products and services. There’s a magic moment, which never gets old for me, when I see one of my products out in the wild being used by someone I don’t know. These days, the most common encounter is on the streets of San Francisco when I see someone commuting to work on a Xootr scooter. It’s a huge thrill to see evidence that I created something that a stranger felt offered enough value that they were willing to give me more money for for the product than it cost me to deliver it.
I did use the word “magic” to describe a moment, but I don’t want to convey the wrong impression about the overall activity of product innovation. One of the key roles in entrepreneurship or product management is leading the creation of new products, often from nothing. This is sometimes called “zero to one” product development. While luck — or exogenous factors — always play a role in determining outcomes, I believe that any dedicated team with the appropriate technical skills and with effective product leadership can reliably create a great product by using the right product development process, and that the outcome does not depend on some magic ingredient.
Why a process? The zero-to-one process is a codification of the collective expertise of thousands of developers, accumulated in government organizations, companies, consulting firms, and universities from about 1960 to the present, more than a half century of experience. A process informs the team what to do and ensures that no critical step is left out. It allows relative novices to benefit from the learning of others. As an innovator within an established enterprise, you benefit from accumulated experience in your organization codified into a process. As an entrepreneur you can reduce the risk of costly mistakes and more reliably find a compelling solution for your customers by adopting the best practices developed by the many product developers who have come before you.
in this chapter, I’m going to give you an overview of a baseline process, found in almost all organizations, called the phase-gate, stage-gate, or waterfall model of product development. This model is a useful starting point and provides an overall structure to the process of creating a new solution. In the next chapter I’m going to circle back and provide a second, simpler model of design called the triple-diamond model.
Why two models? Let me invoke an analogy to give these two models context. I love tools of all kinds. I have a fancy table saw in my shop that I really value. It takes on big jobs. It’s safe and reliable. It’s powerful and precise. It’s also big, noisy, relatively expensive, and must be connected to a dust collection system. Even so, I couldn’t do without it. That’s like a corporate phase-gate process. But, I also have a compact utility knife that I carry in my pocket pretty much all the time. I use it several times a day. It too is a cutting tool and can even be used for some of the same tasks as the table saw, but it’s unobtrusive, comfortable, and instantly deployable. That’s the triple-diamond model.
Both models are intended to be centered on the customer and to pull from customer needs. In fact, both models include engaging with users in order to identify the needs that are most relevant to product success. Furthermore, the triple-diamond model may be applied recursively dozens of times within the context of an overall phase-gate model — say at a very high level of abstraction to create an overall solution concept, or at a very fine-grained level when refining the user interface for a specific feature.
Phase-Gate or Waterfall Product Development Process
The phase-gate or waterfall process is pretty simple conceptually. First, clarify the job to be done, then understand the needs of the customer, then create a great concept for a solution, then specify details with sufficient clarity that the solution can be delivered reliably and repeatedly to customers. That simple flow is comprised of phases (or stages) — a set of development tasks — separated by gates verfiying that the tasks have been completed before moving on to the next phase.Hopefully you can see how this is a process that pulls from the customer needs to create a solution.
Phase-gate processes are also called waterfall processes because information cascades in one direction, generally from the “what” to the “how.”
Most established companies have their own phase-gate process, and they vary across different product domains. Here’s a fairly typical version. It has these steps.
Mission Statement – this phase results in the definition of the target market, an identification of a persona or representative customer in that market, and an articulation of the job to be done. It could also include a competitive analysis and goals for how the new product will be differentiated.
Product Requirements – This phase results in the creation of a product requirements document or PRD. The PRD includes a list of customer needs, and a set of target performance specifications.
Concept Development – This phase results in an articulation of the solution concept, along with documentation of the concept alternatives, the concept selection analysis, and the results of concept testing with potential customers.
System-Level Design – This phase establishes the product architecture, the major chunks of the product and the interfaces among them, and an analysis of which chunks will be custom, and which will be standard chunks provided by suppliers.
Detailed Design – This phase results in component design and specification, prototyping and testing of the chunks, and key sourcing decisions.
Quality Assurance and Testing – This phase comprises both internal and external testing to verify performance, test customer satisfaction, and to identify bugs.
Launch – This phase includes ramping up production and sales, while assuring early customer success.
For hardware products, there will be a significant parallel set of supply chain and production planning activities to ramp up the supply of the physical product. And, for service products, a pilot will often be conducted.
In any specific organization, the phases in the process are often represented as columns in a table with an implied flow of time from left to right, and the tasks, responsibilities, and key deliverables for each function within the organization are shown as rows.
The gates in the process usually involve a document (e.g., a PRD) and one or more meetings associated with a decision (a) to proceed, (b) to return to the preceding phase for additional work, or (c) to pause the effort entirely.
Evoking the waterfall metaphor, the phases are pools along a river in which substantial work occurs, including some swirling around. The gates are vertical drops between pools, marking the transition from one phase to the next. Water does not typically flow back upstream.
Phase-gate or waterfall processes have gotten a bit of a bad rap, with the critique that they do not allow for downstream learning to affect upstream decisions. However, in virtually every situation I’ve encountered, while the flow is generally from the what to the how, there is some iteration, some hiking back upstream in the process when downstream learning requires a revision in plans.
If you work in software, you know that an alternative process, Agile Development, is very common. Agile deserves its own dedicated explanation, but suffice it to say now that in an agile development process, rather than attempt to fully and completely specify the entire software product in a product requirements document and then build the system in its entirety, the team rank orders the desired features of the system and then builds and tests the features a few at a time, organized into short sprints, usually just two weeks long. Then subsequent sprints take on additional features, but only a few at a time. With an agile approach, the team is guaranteed that it always has something working, and the flexible element of the effort is the scope of features that are eventually built, but not the time allocated to complete the product. Agile processes also benefit from continual feedback on early versions of the product, which allow the development process to be responsive to new and emerging information.
Still, even for software and even in an agile environment, the creation of the first version of the product, the first embodiment of the concept, or what is sometimes called the minimum viable product or MVP, usually benefits from application of the more-or-less standard phase-gate waterfall development process, particularly the first few phases. Once a software or service product exists, its refinement and improvement over the lifecycle is highly suitable for an agile process.
Phase-gate development processes are generally logical and efficient ways to organize the effort of teams and to provide oversight and governance to the creation and improvement of products. For products pulled from customer needs, the process proceeds from a mission, to a detailed description of what the user cares about, to an articulation of the basic approach or solution concept, to a description of the details of the solution, whether that solution is software, a physical good, or a service. When thoughtfully applied, a phase-gate process ensures the organization focuses on the customer, that the landscape of possibilities is explored thoroughly, that no critical tasks are forgotten, and that different functional roles are coordinated.
Appendix – Push versus Pull Approaches to Innovation
One of my former students, Lindsay Stewart, started a company called Stringr. Lindsay had been a producer in the television news business. One of the biggest problems she faced at work was sourcing high-quality video of breaking news. So for instance, if there were a fire in the city, she would really want video footage for her story. She would have to contract with a videographer to go get that footage, edit it, and then to put it into production. That process was time-consuming, expensive, and uncertain.
Lindsay recognized the pain associated with this job and thought there must be a better way. In response, she created an app called Stringr. With Stringr, a news producer can enter a request for a particular piece of video footage via a web-based interface, and then freelance videographers can shoot the video and submit the footage using their smartphone. When the video is accepted, they’re automatically paid about 80 USD.
Is Stringr an innovation? By my definition, unambiguously yes. I define innovation as a new match between a solution and a need. Stringr employs technology to create a marketplace connecting requests for video with the people who can create it, clearly a new match between solution and need. I call this approach to innovation the pull. Stringr was pulled from a pain point Lindsay herself experienced and has proved to be a great solution.
But, innovation can also come about in a completely different way. It can be pushed from the solution. Here’s an example.
The inventor Dean Kamen created a self-balancing wheelchair called the iBot. The big idea was that the device could rise up on two wheels allowing the user to be at eye level with people standing on their feet. The iBot was sold by Johnson & Johnson as a medical device, but once developed, Kamen thought, “Wow we have this amazing technology to balance a wheelchair on two wheels. I wonder if we could find any other application for this solution.” Several of the engineers on the development team said, “You know what? I bet you could stand on a self-balancing platform and ride it around. We could create a personal transportation device for anyone, whether or not they were disabled.”
That thinking led to the Segway personal transporter. One of the applications that the Segway team eventually found was for Police officers, who could use the Segway to get around in environments in which space was constrained, where they wanted to be able to move slowly, and where they wanted a high degree of maneuverability. The Segway was a push – start with a solution – the two wheel self-balancing mobility technology– and find a need that the solution can address, in this case police patrols.
The problem was that once Kamen’s company proved that police officers wanted a low-speed mobility device like the Segway, competitors took a pull approach to innovation and discovered alternative solution concepts that could address that need. In fact, once the police and security markets were proven, established competitors did enter with alternative solutions.
A three-wheeled personal transporter is much less complex than a device that balances on two wheels, and so competitors were able to sell this product at lower prices and with greater performance than the Segway.
While an innovation can be any match between solution and need, and that match can be discovered via a pull or a push approach, three conditions must hold for the innovation to create substantial value.
First, the need must be real. That is, a significant number of customers must have a significant amount of pain, a real job to be done.
Second, the solution has to make the pain go away. It has to actually do the job.
Third, the organization must be able to deliver the solution at a cost significantly lower than the customer’s willingness to pay, and that is, the organization must have sufficient alpha assets to sustain competitive advantage.
Let’s apply these conditions to the Segway example.
First, Segway identified a real need for police officers to get around. The Segway satisfied criterion two as well, the solution concept met the need. But, Segway struggled to be able to offer the product at a price the customer was willing to pay.
The three-wheeled configuration is a lower-cost solution that addresses that same need for police officers to get around. Ironically, Segway itself later introduced a three-wheeled version of its scooter once that configuration was shown to offer greater value.
The big risk with the push approach to innovation is that as an innovator you fail to consider all of the possible solutions for the need that you’ve identified, and someone taking the pull approach runs around you with a better solution.
The innovator that pushes starts with an existing solution and often only considers whether or not their solution will meet the need of the target market. That is a necessary but not sufficient condition.
With the push approach to innovation, an important discipline is to consider how a competitor would approach the identified need, but taking a pull approach. That consideration would probably have led the Segway team to conclude that a three-wheeled solution offers better performance at a lower price, suggesting the team should probably pursue the three-wheeled solution, and abandon the push approach, or else find a different job to be done in which dynamic self-balancing did offer some unique advantage.
While both push and pull approaches can be taken to innovation, In my opinion, the pull approach is much more reliable. The pull approach is at the heart of the zero-to-one product development process I teach, and forms the basis of a reliable and repeatable approach to creating value in product innovation.
Notes
Ulrich, Karl T., Steven D. Eppinger, Maria C. Yang. Product Design and Development. Chapter “Development Processes and Organizations.” Seventh Edition. 2019. McGraw-Hill.
Ulrich, Karl T. Design: Creation of Artifacts in Society. University of Pennsylvania. 2011.