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.
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, where we bring people together to discuss the product requirements.
We spend time framing the problem. It’s important to diverge and think about many ideas before converging on the problem definition. In workshops, we find people are often not aligned on what the problem is, and they bring important perspectives so we can all get alignment on the customer and problem.
We pull the whole product together, using iterations of increasing maturity. We think about the first prototype, the questions we need to answer, and how many iterations we’ll need before getting a design that meets all the requirements we can reasonably test with prototypes. We iterate the whole product in time-boxed cycles that can take months to a year, while also keeping a shorter time cadence to move forward. Back to the wedding cake example, we’re refining our recipe and also thinking about what machines we could use to make the cake. We improve the product and scale manufacturing.
We demonstrate how to replicate the product. At this point, there’s less uncertainty and we use a more conventional project management method. We don’t use iterations, although there’s still value in timeboxing. This phase includes waiting for tools to be manufactured and parts to come from the supply chain.
Action Guide: Put the information Brian shared into action now. Click here to download the Action Guide.
- Connect with Brian on LinkedIn
- Visit the Aspire Innovation website
- Learn more about product practices and process from episode 340 with Steve Stucky
- Learn more about Rapid Learning Cycles from episode 250 with Katherine Radeka
“Chance favors the prepared mind.” – Louis Pasteur
Thank you for being an Everyday Innovator and learning with me from the successes and failures of product innovators, managers, and developers. If you enjoyed the discussion, help out a fellow product manager by sharing it using the social media buttons you see below.