light My Insights: product thinking is an approach and philosophy to build products that makes customer the center and the starting point for all the product development activities. The primary goal is to be able to build the product from the understanding of the problem(s) the customer faces. We can still take other elements in consideration (e.g.: business vision & strategy, technology options, etc.), but customer should be the main driver. This means we start the product development from the “problem space” (which is the space of problems the customer faces) and from there we discover and identify “hypothesis” (with certain “assumptions”) that can be tested/validated while driving the building of a solution delivered as a product (i.e.: specify the “solution space”). Product thinking is in growing adoption, however many organizations still take a “shy” approach to its adoption, namely it still has to compete with the rather prevalent classical “inside-out business-driven” strategies (which tend to be more “sales driven”) or “technology driven” strategies (which are equally “inside-out” design with focus on technical aspects). We still have some ground to cover, but as this articles shows product thinking is a powerful way to build products and is not so difficult to adopt. However, organizations need to embrace and change to maximize its potential. Failing to do so (and rely on sales and technical-driven strategies) leads to building products that are mismatch with customer expectations and with that loosing opportunities or simply fail as a product. An important remark is: product thinking is just one variable in the whole system of systems that need to build and continuously improve our products - more on that in https://esilva.net/sociotechnical

Analysis & Summary

The insights and notes of this record are inspired and driven by an article from Naren Katakam [Product-Thinking-101]. This article provides a quick, clear and pragmatic introduction the the main aspects behind “Product Thinking”, namely: What is it, Why it is important; and How to cultivate it. This is a great article for people that want to quickly grasp the main elements at play in product thinking and furthermore get some useful pointers on how to start on it (i.e.: it makes justice to its name and truly is a nice 101 to product thinking).

What is product thinking?

Naren shows a very interesting visualization to describe the entities at play on the equation of a creating a Product: Users (who define the “need” → the problem space) *, Business (who define the “vision/strategies” to drive product development → solution space) and Technology (the medium that connects Users and Business and delivers the product*).

Product Thinking elements (Image Credits: Naren Katakam, narenkatakam.com)


In a nutshell: “Product thinking is the journey from the problem space of the users to the solution space of the business. The goal of this journey is to reduce the gap between users and the business.”

Why is product thinking important?

Because it enables to maximize the “product-market fit” equation by start developing the product from the “problem space” (from the customer) instead of pushing things “the business” thinks the customer should have (i.e.: be “solution space driven”). By taking this approach the product will be solving/addressing/alleviating customer problem(s), which should maximizes the odds of success of the product. The author provides some interesting heuristics for implementing real product thinking, namely:

Love the problem, not your solution: “always start with the problem”, ask simple questions such as: “what is the problem?”, “who is facing the problem?”, etc. This helps discover what characterizes the problem space and the “persona” that is in it and for whom we are building/optimizing our product (and its “value exchange”). With this we can start shaping the “ideas” that can define the product (i.e.: the “solution space”). The author presents a nice visualization of this process:

Product Thinking flow (Image Credits: Naren Katakam, narenkatakam.com)


Notes: this is a great visualization, however it may be misinterpreted on the fact that it is a one way activity, i.e.: ends with delivery. However, product development is a continuous cycle and the Build-Measure-Learn is a cycle that does not stay purely on the Solution Space. The product evolution cycle should cross back to the problem space on each iteration, where customer is again central on identifying next steps of evolution of the product (maybe even complete “pivots” - as Lean Startup [Lean-Startup] defines). Nevertheless, this visualization provides a robust strategy to approach each iteration from Problem to Product.

Think in products, not in features: enables to keep the big picture of the problem space as the focus, instead of getting lost into specific detailed solution elements. Features tend to take a micro-view on the world, which leads to “local optimizations” that don’t take the whole context in consideration (i.e.: may even hurt in the overall product context).

Notes: this remarkable heuristic is rather misunderstood, not only in product but also engineering communities (especially people that blindly adopt “agile” as a way to do small things / features and not “think and design” upfront). Enough product discovery is not waste, it is a way to avoid waste! By creating enough understanding of the problem (space) we can set clearer directions for solution (space), which (should) lead to better results (i.e.: increase of value exchange with customer and also less waste in terms of “work done by team” - which is exactly what “blind agile” people end up doing while trying to avoid it badly).

Have your product heuristics in place before writing your first line of code: these heuristics characterize elements and goals for the “end product”. This provides principles for the product development (and end result). Important: this is not about defining step-by-step where we are going - as (most of the times) we don’t yet know everything of what we are building (there are always unknowns to be discovered along the way). The author states that an effective set of heuristics should be a mix of two types of heuristics: 1) physical attributes of the final product (e.g.: “the product should have confidence and common sense”); 2) desired reactions expected from the end-user of the product (e.g.: “the product should always be available when the user needs it”).

Notes: one remark on starting without having a clear plan for the whole solution space. Trying to do so (define the complete end solution) may be a trap, especially on many of today’s products, which tend to fall into the “Complex” and “Chaotic” quadrants of Cynefin [Cynefin]. To understand the problem space of products in those categories (and start shaping the solution space) we must act (build) and discover/learn what are the most interesting next steps. This means we are sort of inter-leaving between problem and solution space. This is very much still in line with the product thinking ideas shared in this article: i.e.: discover before you commit.

How can we cultivate product thinking?

The author argues that in order to cultivate product thinking we must develop systems of tools and frameworks that help shape it and strengthen it in our teams and organizations. He share three tools for problem space and three for solution space.

Problem Space:

  • 5W1H (What, Who, Why, Where, When & How): these are intuitive questions that can help the discussions and understanding. Important element to consider: use “Why” and “What” if you want to “further develop / expand” the understanding of the problem; and “How”, “Who”, “When” and “Where” to converge/focus/narrow-down solution options.
  • Mom’s Test (foolproof your questions): focus on defining simple rules for crafting good questions. The idea is to review questions used to interact with users to make them clear, simple, understandable and non-biased (i.e.: avoid leading users into a specific answer).
  • Jobs-To-Be-Done (JTBD): when trying to understand the problem space, start with the simple question: “what job(s) arise(s) in people’s lives that your product could solve?”. This is a triggering question for the exercise of understanding the user journey, problem, etc.

Solution Space:

  • Get better at constructing hypothesis statements: in the words of the author “a good hypothesis statement is the ultimate testimony of your problem space understanding” (I love this sentence!). So, basically one of the first steps when leaving problem space is to have a clear, crisp and testable hypothesis formulation, which allows us to go into the solution space with a clear direction and munition to validate our developments. The author provides great formulation on the differences between “ideas”, “hypothesis” and “assumptions”. “Ideas” are abundant, but not all can be formulated as a clear hypothesis (i.e.: not tested). Every “hypothesis” comes with a series of “assumptions” and they form the “things to validate” during the product development process.
  • Get creative with problem solving: finding the right starting point is challenging. The author proposes building upon proven models and systems, as for example: “Transform” (transfer solution from one area to another); “Minimize” (reduce an existing solution); “Maximize” (expand an existing solution); “Modify or Rearrange” (modify an existing solution); “Substitute” (substitute a part of an existing solution); “Combine” (combine several existing solutions into one). He gives very nice examples of products that apply such models - this is definitely a great way to set a clear solution focus our product.
  • Start focusing on the outcome and not the output: “As a product thinker or product manager, you should start focusing on the outcome rather than output, the value you are generating versus estimation of development effort, and the accuracy of the product to do a job versus simplicity.”

References

InsighTweet