Donald G. Reinertsen’s Managing the Design Factory: A Product Developer’s Toolkit
isn’t the type of book I typically read or review. But that’s fine; sometimes you need to look at the same thing through a different lens, and Reinertsen provides that: taking a cold, hard look at the design process and its outcomes. Despite the subtitle, I would say this more a book for product managers than for designers, but it contains plenty for designers to chew on and at least try to swallow.
Reinertsen’s first point: there are no best practices.
[T]he idea of best practices is a seductive but dangerous trap. Best practices are only “best” in certain contexts and to achieve certain objectives. A change in either the context or the objective can quickly transform a “best practice” into a stupid approach.
Instead of best practices, Reinertsen suggests we utilize “tools, not rules” and sets out to show and demonstrate some of them.
But first, he tackles some of the big questions, like what is the objective of the design process (what he calls “The Design Factory”)? Simple: to make a profit. Sales are the measure of how much users appreciate the value of our product, and we should be efficient in “converting time and resources into things people value.” (I told you it was a cold, hard look!)
[T]he only measure of the value of a design is its economic value. Our designs are not important because they are beautiful or because they are innovative; they are important because they make money. Our designs will only make money if we create recipes to turn material, labor, and overhead into valuable functionality better than our competitors do.
For Reinertsen, the purpose of the design process is to generate information (the “recipes” mentioned in the quote above). These recipes lose value over time (a recipe for a great 8-Track tape player wouldn’t be as valuable now as it would have been in 1974, say), so they must be managed and delivered in a timely manner. These recipes are also usually one-time processes. “There is no value,” Reinertsen writes, in creating the same recipe twice…we can only add value when we do something differently. If we change nothing, then we add no value.”
To make good recipes also requires good information, and the sooner the better. As most designers know well, making changes late in a product is far more costly than making them earlier on, so we need good information as soon as possible in the process to make the correct decisions throughout.
Information is a key theme throughout. One nugget of wisdom I found instructive was Reinertsen noting that “events that are less probable contain more information” and thus we should balance our risk/success rate to obtain more information. “When success is likely, the message of success contains little information, whereas if success is unlikely, the message of success contains a lot of information. Likewise, a message of failure contains more information if the failure is highly improbable.” We maximize the amount of information we can get by “approaching a 50 percent failure rate.” We need failure and risk. “When a design fails because we try something new that does not work, we generate useful information,” Reinertsen says. In fact, expert knowledge only comes from “being exposed to and remembering low-probability events.” What a great way to think about failure.
Risk isn’t to be avoided, but embraced. Reinertsen says we can make risk more attractive by
- decreasing the magnitude of the downside
- reducing the probability of the downside
- increasing the magnitude of the upside.
Easier said than done of course. He goes on to note that “most product failures are caused by market risk” which is “a much tougher problem than technical risk.” Market risk is “determiend by how well the product specification meets customer requirements…Two factors that increase this risk are that customers often do not know what they want and that their requirements may change during the development process.” He then goes on to offer suggestions for managing this risk, including using a substitute product, simulating the risky attribute, and making the design flexible enough to accommodate changes.
Another thing that rings true is about deadlines in the design process:
[W]e rarely stop when we achieve a satisfactory solution, because this will simply result in a satisfactory product. Instead, we stop when we run out of time…activities are completed on-time or late. They are never completed early.
Interfaces are another key point throughout, but not interfaces how interaction designers typically think of them (as UI, say). Instead, these interfaces are the connections between different modules of a design–where one component of a system connects and communicates with another. An organization, too, is one such system, and Reinertsen looks at the various types of organizational structures and the communications between the different parts of a company. “The key driver of good communication is the amount of usable information communicated compared to what is needed to make good decisions.” In other words, you don’t necessarily have to increase the information flow to solve communication problems.
When designing products, Reinertsen says, it’s not enough to just find out what the customer wants. You need to find out “why they want it, and how they know they have gotten it.” This should be spelled out in what he calls a Product Mission, which outlines the product’s value proposition.
Why should a customer buy this product instead of a competitor’s? If this question cannot be answered in a compelling way in twenty-five words, then there is a fundamental problem with the design of the product…Most successful products have a clear and simple value proposition. Buyers typically make their choice between competing products on the basis of three or four factors.”
These factors should drive the design above all else. The Product Mission becomes “a compass for the design team, always pointing them towards true north.” One trick to do that, Reinertsen says, is to “write the advertisement for the product as one of the first team activities.” Another is to ask “what the mission statement excludes.” If it doesn’t exclude anything (the product is targeted to everyone, everywhere, at all times), it is useless.
Once you start having documentation (“specifications”), it is best, Reinertsen says, yto treat it as a flawed, living document, not something that is a fixed target. It’s a moving target and should be treated as such.
If you are a product manager or into the business side of design, I recommend this book for its clear-eyed view of the design process. Its economic perspective on our often-fuzzy art (“make the design resonate with more emotion!”) is a much needed tonic to design’s gin.
