After sharing my thoughts on the topic of product discovery vs delivery and how that can fit in to the greater product strategy, I’d like to share a couple of important concepts for product delivery, which I chat to Jeff Patton about during one of the episodes.
If you work in tech product you’ve probably heard people say, “let’s build this thing and iterate on it” but pretty much no one says “let’s increment on it” (is it not fashionable to say so?). To describe the two concepts, Jeff Patton uses the following analogy in User Story Mapping.
Concept 1: Incremental
In an incremental approach, you must know what the finished product should look like before you create any part of it. In the image above, it’s expensive and time-consuming to make changes. If you’d like to change the position of Mona Lisa’s hand, you would have to erase the brushstrokes, complete the hand in another position to the highest detail, and make sure that it merges with the rest of the colors in the portrait. With this approach, you must make each increment, or part, of the painting to the highest level of detail before moving on to the next increment.
Concept 2: Iterative
In an iterative approach, you’re creating the entire painting at a low level of detail. With this approach, making changes is cheap; if you’d like to change the position of Mona Lisa’s hand or the color of her hair, you can do so with minimal effort, as seen in the steps above. An iterative approach can be useful when you’re dealing with a constant change in decisions or needs from teams. The term iterative means “doing more than once”. Does your team claim that they’re iterative? How often do they change their minds about the WHAT of the product that they’re building?
Concept 3: Fidelity
Fidelity is a concept coined by Karl Scotland that refers to the level of detail mentioned in the examples above. Not all products/features are required at a high fidelity. In the iterative release (Release 1 in the diagram above), you develop all the features to a low level of detail, because maybe just by themselves, they don’t individually bring much value. For example, if you’re building Amazon.com from scratch, you create a website with a simple landing page with Search, View, Basket, and Checkout features. After your website goes live, you realize that customers really want a Categories feature, where they can see the #1 selling products in each category and make their choices easier. Taking this feedback into consideration, within the View feature, you build the Categories feature for customers to see the most-sold products. In the image above, this is your Release 2, which is incremental for the Categories feature. Of course, you can work on a product increment, iteratively. The example above is an overly-simple one to explain the concepts in an easy-to-understand manner.
While on this topic, an important distinction needs to be made between quality and fidelity. Low-fidelity products can still be high quality, and high-fidelity products can be low quality.
Think about the Excel calculation above, where cell A6 is the sum of cells A1 through A4. This is a simple, relatively low level of detail but high-quality functionality. The quality could be lowered if the color scheme is black and black rather than white and grey, or if the sum returns an error or incorrect answer; in both cases, the level of detail doesn’t necessarily change but the quality does.
A similar high-fidelity functionality could be a scientific calculator app that calculates sum, percentage, log, exponent, factorials, and can be used across different Operating Systems on different devices. The fidelity in this case is high because you have many more functionalities, and like the Excel example above, the quality can either be high or low.
Putting the concepts together: Value/Fidelity matrix
As a product manager, it’s a game-changer to know when to use an iterative and/or incremental approach, depending on the level of fidelity. By amalgamating the aforementioned concepts, the Value/Fidelity matrix can be used as a general rule of thumb for deciding when to use what.
When you’re working on a product or a feature whose value is predictable (ie if you deliver feature X, the user click through rate will go up by Y%), and the required fidelity is low, it could make sense to work in an incremental manner. Since the required fidelity, or level of detail, is low you can complete the increment and roll it out for users. In this case, a partially completed feature will bring no value. Imagine a low-budget house as your product. You build the different parts of the house incrementally – first laying the foundation then setting the skeleton for the walls, then windows and doors, etc. We are certain of the value in laying the foundation – it is needed to support the rest of the structures. Since the foundation has a low level of detail (compared to something like the interior) we use an incremental approach and lay it first completely. This allows us to move on to adding the skeleton for the walls.
Rule #1: When creating modern tech products/services, it’s best to use a combination of iterative and incremental approaches (because of their primary existence in the complex and complicated domains), depending on whether the product/service brings value in smaller standalone increments/iterations or not.
Rule #2: Shifting between the quadrants based on user feedback is suggested. When you discover user problems or opportunities that fit into your business objectives, you may need to pivot and alter your approach. For example, if you have iteratively created an MVP of an online travel magazine and receive feedback that users would like to use your product to book upcoming trips, then you can incrementally build and roll out the “book now” features. In the image below, this fits into the appropriate “Complex domain” quadrant.
Adding Cynefin theory to the Value/Fidelity matrix results in the above. This is not to say that iterative approaches should not be used in the simple domain or incremental approaches should not be approached in the chaotic domain. As per Rule #1 above, you must also assess whether the product/service brings value in smaller standalone increments/iterations. It’s simply a heuristic that says, for example, because in the chaotic domain, the cause and effect relationships are unknown, it could make more sense to use an iterative approach and learn about the possible value/lack of value in each iteration and then build on that. Similarly, in a simple domain, you can use an iterative approach in some cases but as a heuristic it may make more sense to start incrementally because you theoretically know the value proposition the product/feature has for the customer. You can gain this information by qualitative/quantitative methods like diary studies, JTBD user interviews, split tests and statistical modeling.