How can Theodore Levitt’s classic Whole Product approach help with defining a product roadmap? I’ve been revisiting his concepts and their use recently, thinking about how to revise them for some exercises I’ve been doing with product teams.
Whole Product Game Background
In 1980, Mr. Levitt published his article through the Harvard Business Review – also available for sale as an eDoc through Amazon. Gamestorming has an article describing the Whole Product game and a link to Innovation Games’ online version. Back in 2011, Luke Hohmann introduced me to this concept and technique, and I used it with success with a team I was working with at the time.
It was a really effective elicitation exercise for us that helped us characterize market problems. For that particular team, we were addressing a lot of chaos and trying to drive some clarity around the vision of the product. We stood up a straw man of saying that there were two ways to think about what we wanted the product (as one piece of dozens of products) to be.
The product could be a promotional product – we wanted people to “talk about it” and promote it. It would generate buzz, by being awesome and noteworthy. To do that, it needed to allow users to address differentiated problems, or be differentiated in how it addressed those problems. Awesomeness – either in selection of focus (e.g. great prioritization), or execution against the target problems (e.g. great design, great implementation), would be the philosophy that would inform our direction.
The product could be a “make tedious activities less tedious” product – we wanted people to “not talk about it” (in a negative way). The product would avoid bad reviews, by making sure people were not highlighting its shortcomings. To do that, we needed to focus on the expectations in the market, competitive feature sets, and “keeping up with the Joneses.” This choice would free up some resources to work on other more important (at the portfolio level) products, and mitigate the risk that “starving” this product would have a negative impact in the market.
Before doing this exercise, we had a big pile of ideas, a muddled mess, frankly. Addressing half of the expectations, and not building a sufficient amount of “wow” capabilities would leave us with a mediocre product – one that would neither mitigate the risk of bad PR nor cause us to realize positive word-of-mouth from customers / users who were blown away by the life-changing capabilities we provided them. We had to decide which way to take the product, and the whole product game was a great tool for us for informing this decision. I’ll add that I, and other team members were more excited about the product after this exercise than we were before it. Always a bonus when you can love what you do, and who you do it with.
How We Used the Whole Product Game
We stayed pretty close to the script for following the “rules” of the game as described on the Innovation Games and Gamestorming sites. I don’t know if the game was even online at the time, but when I look at the instructions today, they match what we did based on the conversation Luke and I had. Thanks, Luke!
Theodore Levitt’s model is one for developing marketing strategies around a product, but we were using it to develop a roadmap. Applying the model to the early visioning of the product is a pretty agile way (in my opinion) to infuse some of that collaboration and outside-in, market-driven thinking early into the process. Much better to build what customers need (in a way that integrates with a holistic strategy) from the get-go, rather than scramble to “spin” a message that resonates around a product that has already been built.
Mr. Levitt characterizes products (in this model) in terms of how they address market expectations. His premise, in the paper in which he introduced the model, was that there is no such thing as a commodity product, when you consider the totality of the product. There’s some deep thinking in the paper, so you should read it – but for the purpose of this article, a simple example might describe the tip of that iceberg.
Calculator software is pretty much viewed as a commodity. Addition is always addition, subtraction is always subtraction. Skeuomorphism drives us to the standard key layout that has been a standard for mechanical and electronic calculators since the ten-key adding machine was invented 99 years ago. Calculator applications standardize on this design and a set of capabilities. Advanced calculators include scientific functions, graphing capabilities, etc. Most people would call this a commodity product. Mr. Levitt would classify these different products as “functionally undifferentiated” – generic products. Finding the intersection between two curves, determining the area under a curve, normalizing a matrix – while more specialized, is always basically the same. While solving additional problems, and being appealing to different user personas, any given civil engineer (or whomever) would consider the different “advanced” calculators to also be functionally undifferentiated, and the non-advanced calculators would not even be considered as suitable for solving the problems they want to solve. These users expect a calculator to be able to tell them the n-th root of a number without breaking out the scratch pad.
Addressing the problems that get the “generic” label and the “expected” label is how you get a product that no one complains about.
Mr. Levitt’s point was that by focusing on the customer’s perceptions about problems (“the need to get some math answers”) is the way to differentiate what otherwise would be functionally undifferentiated problems. A carpenter may need to know how tall to cut a board that will hold up the ridge of a roof that is supposed to be at a particular angle, or what angle to cut out the notches for a stair riser. A calculator could be used for this, but it is unwieldy for the carpenter – who will probably use a speed square (a metal triangle with markings on it that correspond to different angles) to identify where to make her cuts. A calculator specifically designed for carpenters could be a winning product. While the speed square may still be the best tool for marking the boards, could the calculator be used to help the carpenter know how long of a board she needs (before the cuts are made)? How would the calculator-app designer design a calculator-for-carpenters application? If you made an app that let you input what you know (the desired angle of the roof, the rise and run of the stairs, etc), and the app gave you a diagram showing where to make the cuts (instead of just the answer to a math problem), you now have a functionally differentiated app.
Mr. Levitt characterizes products with these types of enhancements as augmented products and potential products. The definition he uses for augmented products is “when a product goes beyond what was required or expected by the buyer.” He somewhat avoids defining potential products, but says “Everything that might be done to attract and hold customers is what can be called the potential product.” I think he knows that this distinction is weak, because he goes on to say that what is augmented for one buyer may be potential (or expected) for another buyer. When trying to coach my team through our exercise, I struggled to explain his distinction to them, and it has bugged me ever since. Apparently, I hold a grudge, because I’m typing about it a couple years later.
In our exercise, we discarded his (not-really-clarified) distinction and used a different definition. Augmented product capabilities represented the differentiators for our product. Things that would pull a customer towards our product (versus the absence of expected capabilities, which would cause customers to exclude us from consideration). Potential product capabilities was where we would put disruptive capabilities that would redefine expectations, change how customers think about their problems (or our products), etc.
For the calculator app, “saved multi-step calculations” might be augmented, where “show me where to cut the boards” would be potential.
Potential Changes – Whole Product Game 2.0
Given the context above, I’ve been thinking about how I might customize (or improve, if I’m wearing my arrogance-hat) the whole product game. My overall goal is “helping my team reboot (or define) the vision for our product.” Specifically, I want to drive the divergent-thinking aspects of eliciting, discovering, and brainstorming the capabilities that might become part of our product. I also want to drive the convergent-thinking aspects of characterizing those ideas, so that they coalesce into driving the strategy / philosophy for the product, specifically, should the product “be awesome” or “suck less?” As a bonus, I would then have a whole bunch of contextual fodder that I can use as a foundation for doing competitive analysis, validating importance to personas, and prioritizing in a roadmap.
What goals would you add (or challenge)? How would you do the whole product game differently, given these goals? Would you rename the game? Maybe all I’m trying to do is fork this game for a different intended use. How would you characterize this adaptation?
Oh – and I hate the circle as visual metaphor for this exercise. I’m going to use a vertical metaphor instead. Generic is at the base, then you build on that to meet expectations, augment, and innovate.
One thought on “Whole Product Game”