Partly due to the advocates of the Lean Startup movement, these days lots of people in the product space talk about rapid product development and looking at ways to get their products to market faster. Actually, one could argue that the roots of this idea are much older and the book “Developing Products in Half the Time” written by Donald Reinertsen and Preston Smith serves as proof of that. This first edition of this book was published in 1991 and still holds true for a lot of the change processes that many companies are going through.

Reading “Developing Products in Half the Time” provided me with some great insights and practical pointers in relation to both making product tradeoffs and managing the product development process:

1. You still need rational decision making (even with rapid product development) – Early on in the book the authors stress the importance of putting the subject of rapid product development on a rational business basis. I can imagine it might be tempting to let the word “rapid” take over the product decision making process, but Reinertsen and Smith make a convincing case for having clear business questions (and drivers) form the foundations of the product development process.
2. Doing the product right (vs doing the right product) – “Developing Products in Half the Time” does not tell its readers how to build the ‘right’ product, it leaves that to (product) managers to ensure there’s a clear product strategy in place. In contrast, the book concentrates on “doing the product right” and highlights 4 key objectives (and 6 trade-offs) to consider in this respect (see Fig. 1 below).
3. The basic modelling process – For me, the greatest value in reading “Developing Product in Half the Time” was the chapter on creating a baseline model to help calculate project product profits over time. I wouldn’t necessarily treat this tool as something that you do as a one-off and then expect (or hope) the product to perform accordingly. Instead, the variables that go into the baseline model can be easily adapted to a range of different situations (e.g. a development expense overrun, a unit cost overrun or a schedule delay- see Fig. 2 below for an example). Similar to when creating a business case, what I liked about creating a baseline model and its subsequent variations are the financial and performance related assumptions which underpin the model.
4. Decision rules – As Reinertsen and Smith point out: “the true value of this analysis comes from converting the results into a set of decision rules for making tactical trade-offs on the project.” Once you have used the baseline model and its variations to work out the profit impact, you can convert this profit impact analysis into decision rules like “I’m only going to allow a 1% cost overrun on this product development project” or “1 month is the maximum delay that we can have for the introduction of this product.”
5. Use the baseline model and the opportunity assessment – Whilst reading the book it dawned on me how I could use the baseline model and Marty Cagan’s Opportunity Assessment in conjunction. This way I could size a product opportunity in both a strategic and a more financial kind of way. It was interesting to read about the “market clock” in the book. The market clock starts ticking when a customer opportunity appears and only stops when the customer need is fulfilled. “The market clock is unforgiving”, Reinertsen and Smith explain. This means that project costs will continue to accumulate even when no one is working on a project. Hence the importance of considering the “cost of delay”, irrespective of whether the delay occurs at the start or end of a project. In short, the key point behind “Developing Products in Half the Time” is all about how quickly one can respond to market opportunities.
6. Pitfalls of incremental innovation – I found it refreshing to read a honest assessment of potential risks and pitfalls related to incremental innovation (see Fig. 3 below). As much as I’m a fan of business agility, I think it’s important to consider some of the risks related to iterative development. In “Developing Products in Half the Time” the authors spend a chapter outlining some approaches to identifying, assessing and managing risk – technical or otherwise – which I found very helpful.
7. Periodic prototyping – Like authors such as Steve Blank, Eric Ries and Ash Maurya (who all came after “Developing Products in Half the Time”), Reinertsen and Smith are all about “periodic prototyping”, creating prototypes at regular, pre-established intervals. I guess that is one of the critical success factors to lean product development; doing certain things constantly in an iterative fashion. I strongly believe that the whole point behind this approach is continuous learning and improvement!

Main learning point: if you’re interested in product development, I recommend you read “Developing Products in Half the Time”. You might feel that not all of the book’s points apply to your product or organisation, but it should nevertheless give you some principles and practical tools to consider or to apply. For me, the main things I took away from reading “Developing Products in Half the Time” were the creation of a baseline model and considering the cost of delay, which will definitely come in handy next time I need to make a business case or decide on a trade-off.

Fig. 1 – Four key product development objectives and six trade-offs (from “Developing Products in Half the Time” by Donald Reinertsen and Preston Smith, p. 23)

• Market introduction date: the date when the product is first available for sale
• Product unit recurring cost: this is a combination of manufactured cost of the product and any variable cost that appear below the gross margin line
• Product performance: the product revenue stream of the product over its life cycle (this is not about the technical performance of the product!)
• Development project expense: one-time costs associated with the product development project

Fig. 2 – Create the Baseline Model (taken from: http://marketingsage.com/3-straight-forward-steps-to-calculating-roi-potential-and-making-better-numbers-based-decisions/ by David Lamont, April 2003)

Fig. 3 – Advantages and disadvantages of incremental innovation (from “Developing Products in Half the Time” by Donald Reinertsen and Preston Smith, p. 78)

Financial – advantages:

• Earlier profits
• Earlier cash flow
• Less investment risk

Financial – disadvantages:

• Duplicate fixed cost per product introduction

Marketing – advantages:

• Shorter planning horizon
• Earlier customer feedback
• More reliable feedback
• Flexibility
• Image of consistent product improvement
• Customer lock-in

Marketing – disadvantages:

• Channel overload
• Sales force overload
• Customer overload
• Service and support overload

Engineering – advantages:

• Lower technical complexity
• More motivating to teams
• Early field experience with technology
• Spreads technological commitments

Engineering – disadvantages:

• Hard to make technology breakthrough
• Boring products

Other – advantages:

• Accelerated learning