Product Thinking Got Next, Part 1
I just finished reading a very informative and thought-provoking book by Singapore-based Naren Katakam who is a Product and Experience Leader that writes for ThoughtWorks. He’s a self-described, “kick-ass design leader and an equally bad-ass product leader”. I would agree with both assertions.
His specialty is in gathering little bits of information from people and then weaving these bits together with design elements to make products that solve a problem. I think that’s the core to designing great products that solves users’ problems.
In his book Product Thinking 101, there was a lot of information to digest and synthesize so I decided to break this blog down into two parts.
What is product thinking?
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?
But first, why do products fail? In his 2007 blog post titled — “The only thing that matters”, Marc Andreessen mentions that “the only thing that matters for a new startup is getting to a product-market fit”.
One of the main reasons why a product fails is because it doesn’t achieve a product-market fit. It fails to meet customers (users) need in a way that is better than their current alternatives. In other words, customers need X but the business decides to ship Y. The reason why businesses ship Y could be based on many reasons. Like, their lack of understanding of customer’s needs clearly or their own business constraints on what they can offer at that point in time or lack of resources and team or hundred other reasons. No business wants to ship Y when customers need X but, it happens. A lot.
What can businesses do to avoid this pitfall? How can ‘product thinking’ help alleviate this situation? Keeping the ‘101’ aspect of this post in mind, let’s look at some basic heuristics of product thinking, more like thumb rules to follow to obscure failure.
Rule #1: Love the problem, not your solution.
Love the problem, not your solution. This mantra is from Ash Maurya. His article with the same title elaborates more on how to avoid this pitfall by focusing on first principles. What this rule can do is help you in two ways, one, it eliminates innovator’s bias and two, it helps you embrace the problem space which in turn helps you understand your target market, users, customers, their needs and wants better.
Always, start with the problem. The answers to the questions like what is the problem, who is facing this problem and why are they facing this problem will lead you to the market (a market: is a bunch of people having the same problem) and persona (a typical design persona from the sample size and not the marketing persona). When you apply ‘jobs-to-be-done’ (JTBD) to this persona from the sample size that’s when you will truly begin to scratch the surface of the problem space (more on ‘jobs-to-be-done’ later in this post).
Rule #2: Think in products, not in features.
There’s an interesting article on “Why product thinking is the next big thing in UX design” by Nikkel Blasse. In this article, Nikkel talks about the importance of thinking in products and not in features.
Thinking in products means zooming off from the micros and thinking in macros. Thinking about the problem and not getting lost in one of the possible solutions for that problem.
Thinking in product means understanding the problem thoroughly. And when you do that, that’s when you truly understand why you want to build the product, its purpose. This understanding makes you optimally select the features for your product, which avoid waste and in turn helps you become lean. Remember, successful products have repeatedly shown that users don’t care much about the features. Users only care about achieving their goals through your product. This is where Jobs-to-be-done (JTBD) fits so well to understand the job of a product/service in a user’s life.
Rule #3: Have your product heuristics in place before writing your first line of code.
Building a software product is a continuous process. It’s a journey with many milestones. How can we lay certain ‘heuristics’ in place so that it helps us guide in our journey? Write down specific states to describe what the finished software will be and will do, more like placing strategic beacons in place that can throw light and define the silhouette of your finished product, a set of heuristics. This will help you immensely when the product is ready for launch, you can compare your creation with the pre-defined heuristics and you will know if the product is ready, or not. This action may be too simple on the outset, but I assure you it has profound effects when you launch and hear feedback from your customers.
There are two types of heuristics, one based on the desired physical ‘attributes’ of the final product, and two, desired ‘reactions’ one would like to expect from the end-users. For effective product heuristics, use a blend of these two types.
