People don’t buy a Rolex watch to manage their time better.
What else is a watch supposed to do? They don’t even provide heart rate or walking steps or connect with your phone. In this case, clearly, Rolex is solving a very different kind of problem. Knowing what kind of problem you are solving for your customer, or solving through your product (whichever comes more naturally to you) unveils the way to a more effective product roadmap. Painkillers, Vitamins, and Candies all make million-dollar businesses — only if you know what you are creating and market it that way. If you position a painkiller like a vitamin it won’t sell. If you position a vitamin as a painkiller, you might get sued. You need to focus on the problems, become a Problemist.
Product Management is all about finding real problems of real users who are really looking for solutions. So, in this post, I’ve tried articulating a framework that describes the art of problem analysis instead of thinking of a solution. I have extensively talked about this framework in my talks and workshops and it works wonderfully well for a lot of people.
To begin with, let’s note that the Problems set is a subset of the user’s Needs and Wants. The illustration below should explain it better:
As a Product Manager, you should be spending significant time in exploring the details and finding the root cause of those problems. In fact, this is completely true for UX designers and Startup founders. You must be solving for a pertinent problem of your existing/prospective user base.
I am not suggesting that you are not responsible for solutions. I am saying that solution is not what you should worry about until the problem is well understood. Solutions will either be obvious or will reduce down to some logical or mathematical problem once you’ve done a good job of analyzing the problem.
FAQ: What if I am not really solving a problem?
Answer: Feel free to call your work an Art.
Harsh?
Truth.
If you aren’t solving someone’s problem, you’ve no reason to believe they’d pay you. Even in the most narrow context — if your shiny new feature or design or the CSS change is not going to solve a real pain point of the user, you are putting money down the drain. Btw, if you think that Facebook, Tiktok, and Netflix aren’t solving a real problem, think again.
FAQ: What if it’s a value add (versus solution to a problem)?
Well, if you aren’t concerned about clear ROI, then anything is fine. Typically, the “Value add” products/features make a limited impact for a small set of users, mostly for a limited time. A harsh truth, again. But, if that’s what it is, accept it and you’d still do well. There are other problems as highlighted in the illustration below.
So if you want the product to sell, you better target that pink area in the illustration. The rest of the post talks about the step by step process — which will quickly become a mental model after trying some steps a couple of times, for some of the real situations you come across.
Here’s how you do it. Just like making the next Netflix series.
- Define the problem (Find the plot, the hero and the villain)
- Categorize the problem (Decide the genre)
- Reframe the problem (Rearrange the story)
- Ignore their solution (Kill the lead hero so far)
- Devise your solution (Bring a new hero)
- Build the solution (Hero wins!(sort of))
- Measure it against the problem (Count the ratings)
1. Define the problem
Recently a startup founder was seeking mentoring and he pitched to me a digital business card organizer and I asked him what is the problem he is solving. He started talking about the solution. I stopped him and asked what exactly is the problem he was solving. This time he described it well — the problem he said he was trying to solve was that people miss out on their network because their network is not well organized. And then, at the earliest opportunity, he switched back to describing the coolest features of the solution again, asking me to “Imagine if…”. He wasn’t convinced that I am NOT his customer. He kept asking me to imagine situations I have never gotten in to and use cases I’ve never had.
If you enjoyed this story this far, let me tell you that this is true for roughly 6 of the 10 founders I meet or half the PMs I’ve interviewed. A problem defined as a solution is not the right problem to solve.
If you have a feature idea or a solution ASK what problem is it supposed to solve? Whose problem it actually is?
Ask who’s the “ideal” customer? and if the answer sounds like “Everyone with a smartphone, or Everyone in the city, or All our existing users”, it is very likely a wrong answer.
Quick check: In most cases, if you’ve defined the problem such that there is only one obvious solution, your definition needs improvement. Problems are usually multi-causal and can be solved in many different ways.
2. Categorize the problem
If you are going to remember any piece from this big essay, then remember just this part. Categorizing a problem gives you the approach to solve it, but more important than that, it also tells you whether you should be solving this problem right now or park it for later. If you have been a product manager long enough, you’d have heard about “ruthless prioritization”. This is where it happens.
You need to categorize the problem into one of the following categories as told by Steve Blank — Latent problems, Passive problems, Active problems, Urgent problems. I added Imaginary problems to the list.
Latent — User has a problem but the user doesn’t even know they have a problem. How’s that possible you think? Well, you’d think tooth pain is not new, would have been a problem from before christ, but people didn’t know they need to brush their teeth twice a day just 70 years ago. They didn’t know in India they need a RO (water purifier) 20 years ago. Like they don’t know they need an air purifier in 2020, wait for the next 5–6 years and see how it becomes a ‘need’. A lot of things from personal undiscovered health ailments (mental disorder, diabetes) to your vehicle-is-eating-more-fuel-than-required to global climate change fall under the latent problems. People at large don’t know they have this problem and if you are going to create a solution for that problem, they wouldn’t buy it.
You’d need persistent educational/marketing efforts, for years, to turn a latent need into a want.
Passive — Users know they have a problem but they are not interested in solving it. This seems worse than the latent problem, but it is not. Now that the user already knows they have a problem, you have a higher chance of converting them sooner. But if the user is not solving for it yet, you know that the problem is not big enough for them yet. Insurance, Anti-virus, Inbox-zero, Cybersecurity products, Pay later, accessories like a Health band typically fall under this category.
Bundling your product with something people buy more frequently works great for products in this category. Also sells well if it is part of a new ‘trend’.
Active — Users know they have a problem and are actively looking for a solution. However, it’s not a burning issue. It’s a leaky tap and not a pipe burst. So they’d think more, they’d tend to care a lot about the cost, quality (UI/ Feedback/ Rating), their processes, competitive analysis, etc. The sales cycles will be long and you need to keep retargeting your ads to the prospective leads for a longer period. A book-keeping saas for SMB, a Math tuition app for a 10 yo, a Compliance/Auditing tool for the finance department, a marketing automation tool are some products that typically fall under this category.
Active follow-ups, retargeting ads, discounts, more value-add offer work well for these products.
Urgent — User’s ass is on fire and they know it. If you are making a product that she needs it, and wants it and is a burning problem for her, just make sure you’re there at the right time to take the money. In most cases the big urgent problems of the market are solved already, so you might find a lot of comparable competition. Lending products, Travel booking, Communication apps, etc. fall under this category.
If you don’t have the distribution, being 10x better is the key.
Imaginary — These are imaginary problems. They do not exist, but like for ghosts, some people are convinced of their existence. Solution — VooDoo. It’s more about communication, presenting facts, building relationships, tweaking the UI, changing the error message, standing on one leg, or whatever it takes to change their false perception. Could be some placebo or add-ons in the product, but most of the time, solutions will lie outside of the product.
Imaginary problems need imaginative solutions.
A few things to note:
1. Markets are dynamic — people and their problems, their needs, and their want are changing. So, while you start with a latent problem it “may” become urgent in a few years.
2. Things like a global pandemic or demonetization or Brexit can turn the situation VERY quickly. The same problems can go from latent to urgent almost overnight. Of course, you can’t bet on these grey/brown/black swans.
3. Reframe the problem
Here’s a brilliant HBR article that discusses reframing problems at length. It gives examples of how a slow elevator problem can actually be reframed as “wait time is boring” and can be solved by installing a mirror in the elevator. How a dog adoption problem in the US was actually a poverty problem.
The existing framing may not necessarily be wrong, this step is more about finding a better problem to solve.
Here’s some fun from Reddit, that says adding a faster spinner solved the perceived problem of a slow website.
Here are a few quick questions that you can try to answer, wrt the problem at hand. Particularly, for a feature ask it can help reframe the problem:
- Is it an incentive problem? — They have no reason to do the right thing. If I can guide the delivery boy who speaks the local language, I have no incentive to learn how to locate the delivery address on the map correctly.
- An expectations problem? — They didn’t expect they’d need to do this. They didn’t expect to fill a long-form. Where is all the artificial intelligence?
- An attitude problem? — They just don’t want to do this (no good reason). Inertia is real, no one wants to change their behavior.
- Brand perception problem? — New things have historically never worked, so they don’t want to try.
- Misinformation problem? — They are convinced, that other similar products behave differently. Victims of competition’s sales pitch or content marketing. Other products have that one feature and are obviously faster/cheaper/simpler than yours.
- Is the problem stemming from another solution? — Some other feature/constraint in your product makes them believe that the new problem has to have a similar solution.
I wanted to drop some hints on how to solve each of these problems, but the post is about being a problemist. Trust me, if you focus on reframing the problem, the solution will appear.
4. Measure the problem
How many users are affected?
It’s ok to start by asking around, estimating, back-of-the-envelope calculation so that you can take a quick call on how to proceed further. If your product is instrumented, you should be able to find an actual number of users facing this problem. Even if the product is not instrumented, if there are active users, you should be able to dig data and find some number. If it’s a new product just take guess whether this will be useful for 80% users or 20% of them. Important is to have a number and make sure it is written down in the documentation you do — PRD/Jira ticket/Whatever.
How much are those users affected?
Can the impact be quantified? How much cost or time or life does it save for the users?
Another good proxy is self-discoverability. How likely is the user to discover the change/feature by themselves and use it? If it is very likely, then we are talking about high impact.
5. Ignore their solution
It’s hard to be blunt to the customer or ignore their solution in the face and ask them more about the problem. In their mind, the problem is already fixed by the solution they suggested. So listen to them first. Paraphrase it and in your narration, you may introduce items from your curiosity that forces them to think as well. Then ask more background questions and do a deeper analysis of their problem — need — want.
However, reaching a granular level is secondary. I see most people struggle to even rephrase the user need/problem as a “problem” instead of jumping to the solution. Recently, I spoke to a stakeholder who works closely with the customer and asked him about the customer’s pain. He described that customer wants an attendance management system for their drivers. I asked him what is the “problem” they are trying to solve? He reiterated, that the client needs an attendance management system. He was partially surprised, what about a simple “attendance management” bit I could not be getting. Another stakeholder added that we have tried some basic solutions in the past and now no one uses it. So, now the problem apparently is to create an “attendance management system” that is “usable”. I could sense there is more to it so I spoke to the customer directly.
Hint — A problem defined in terms of a solution is a wrong problem to solve.
Here’s more detail, “The customer was unable to track the presence of the driver within the campus for the prescribed duty hours, because of which they are unable to decide on prorating the remuneration for the driver. The client estimates that this leads to delays in payments and even overpayments of about 10%. As of now, the client depends on manual records and driver’s trip records. There could be exceptions, in which case, the driver may not be working but still getting paid for the day.”
On more prodding, I found that in most cases where they might make a mistake of capturing fewer trips for a driver, if they are paying less the driver will reach out to provide enough evidence and get it sorted. However, if they are paying extra — no one complains.
So, as I spoke to the customer, I found that there is just one distinct problem. The question customer struggles to answer every month is “Am I overpaying?”
All I wanted to know was that the client fears he is overpaying. That’s the REAL problem that needs to be solved.
My solution, a simple report that lists all the drivers who should not be paid the full package. I had everything I needed to create the report so the effort was about 20x smaller than creating a new system. The turn around time was quick and the solution was sufficient to solve the problem. Everything seems obvious in hindsight (said Fredrik Backman).
So, the quick mantra is just to ignore their solution. Follow all the earlier steps and figure a solution from the ground up. It will be fun and will save a lot of time and money, more importantly, the disappointment of creating something that no one ends up using.
6. Devise your solution
Finally, now that you’ve earned a doctorate on the problem, the solution would be clear. More than the solution the problem analysis gives you a clue about how to approach the solution in the right way. How to drag the solution so that it lies somewhere in the problem-need-want area. Many times, you would realize that the problem is not alone, it is a bunch. And there could be more than one solution to solve it. A lot has been written on prioritizing the different solutions and building them so I’d skip that part. However, here are some useful tips for the solutioning process.
– Document it — Write it down. What if you die tomorrow? Leave the world a better place. Make sure you define the problem analysis in the document (at least briefly). Begin your documentation with a problem analysis — whether it is a PRD or a quick Jira ticket or handwritten note. It’s not an afterthought, just begin with it.
– Prototype it — Big change? Always prototype it with a hi-res flowing prototype. Notice how the first prototype and the third one are shockingly different.
– MVP it — If you have a risky assumption about the problem or the client or the solution — do an MVP. Test your assumption. There is a lot written on MVP so I’d not repeat it. Just remember this that if your MVP is not testing the riskiest assumption it is not an MVP. In most cases, fake-o-backends, spreadsheets, and no-code tools work great for MVPs.
– Build the solution — Once you have gone through the earlier steps, or have low stakes or absolute clarity on what needs to be built or it’s a small change. Just build the solution that appeared from the problem analysis.
7. Measure the solution
I’d not call it complete if you don’t measure the solution against your problem. Achieve the problem-solution fit before you go for the product-market fit. Solving the right problem ends up in measuring the right metric. It’s not about how many features you build or how fast you build them, it’s about how quickly are you able to achieve the business outcome.
Once you try to follow this approach with strong intent, after a couple of times, I assure you it takes lesser time to do the problem analysis than you took to read this post.
Be a problemist! It’s goooooood.
Long ago in a PM job interview, the interviewer asked me if I was part of the problems team or the solutions team. Frankly, I did not even understand the question then.
But then, over the years, I’ve realized what it meant. It’s now one of my most frequently used phrases when talking to my team members — “Remember, we are the ‘problems’ team”.
—
Contributed by:
Ujjwal Trivedi,
Director
Headstart Network Foundation
Originally published on Ujjwal’s personal blog — uvtimes.blogspot.com
For more, follow Ujjwal on Medium- medium.com/@ujjwaltrivedi