354: Agile Product Development – with Brian Cohn

Discovery, Detailing, and Deployment for hardware product management Today we are talking about applying Agile and Lean development practices to product projects that are not purely software-based. Our guest is Brian Cohn, who began his career with roles in optical engineering and mathematics. For the last 10 years, he served as the Lean Product Development Specialist at Danfoss and has recently co-founded Aspire Innovation, a group that applies a business acceleration model to help organizations be more innovative. Summary of some concepts discussed for product managers [5:11] What are the issues with applying Scrum to projects that don’t involve only software? Hardware development is iterative, while software development is incremental. Think about making a wedding cake: If you make it incrementally, you make the first layer the first year and the second layer the second year, building up a full cake. But if you’re trying to sell 1000 cakes a day, you need an iterative process; you build your first whole cake and then iterate repeatedly to make the whole cake better. Scrum works well for software because it’s designed to be incremental—you build one piece of code and then another, building up your software. Scrum is also built around the idea of product owner, someone who prioritizes the future of the product and translates that future to project work. In hardware, you have to develop everything together, and the features that the product owner is focused on may be dissociated from the project work. More disciplines are involved in hardware, so it’s harder to move the work from person to person on the team. Finally, the pace of hardware development is dependent on the supply change, buying components, and getting parts manufactured, and that can take a long time. Because of all these challenges, Scrum doesn’t fit with hardware development. [9:52] How can we apply Agile principles to hardware products? We need to be agile in hardware development because there’s a lot of uncertainty in solving a problem and time boxes are valuable. We start a project with an idea about a problem and a lot of things we don’t know. We have to go from a wild idea to a product concept for how we’re going to manufacture, market, and sell the product. We have to make many decisions, and the decision-making process can go on interminably because everyone wants more information before making decisions. We need a model for decision-making. We use Rapid Learning Cycles to make decisions at the right time—after we have the information but not too late. We need to know what knowledge we should have before making each decision. Then, we put our decision-making into a cadence. For example, we investigate a decision for two weeks and then make the decision. This allows us to learn from each time box and adjust for the next box, so we’re always learning the most valuable things. [15:53] Tell us about your D3 Model for hardware products. Hardware products go through 3 phases: Discovery, Detailing, and Deployment. In discovery, we start with a core value proposition and turn it into concepts for the product, including manufacturing, assembling, marketing, and launch. In detailing, we use engineering to move from concepts to form and function and design the manufacturing system, assembly system, and plan for selling the product. In deployment, we work on commercialization, scaling production, and sales, with the goal of releasing a product that’s easy and inexpensive to manufacture and that customers are ready to buy. [17:20] Discovery We move from an idea on the back of a napkin to well-formulated concepts for the product, process, and launch. We weigh the decisions we want to make and the gaps in knowledge we need to close to make those decisions. We have a workshop called the Market Requirements Event,