As product people, most of our time is spent thinking about problems: listening and recording problems, prioritizing problems, balancing solutions for each problem, and looking at more problems when a solution is implemented - isn’t it great?!
Problems are super interesting, and we end up learning a lot. Nevertheless, I hope the main reason why we’re so attracted to problems is that we want to be able to come up with the best solutions. The best solutions consider context and constraints, but the issues normally arise when:
You don’t know which are the most relevant levels and angles of each problem;
You’re not aware of different people’s perspectives and the impact the problem causes on them;
You lack overall visibility on the problem’s context and constraints, along with its status and prioritization.
The idea of this article isn't to become a “to-do list” to fuel your “analysis paralysis”.
No organization will be able to afford to spend much time and money in "thinking about problems".
The intention here is to help you to:
Get to clarity in a methodical and experimentational way,
Learn how to include other people in the process,
Find alignment across the usual suspects: your product capabilities, the business objectives, stakeholders and our lovely customers (and/or users).
Not all problems are created equal
Before you put your “problem scoping goggles” on and you disappear for the rest of the quarter, it is important to address prioritization.
The product management community is widely known for the multiple ways of saying “no” when it comes to feature request time. That said, it might be difficult saying “no” to wanting to solve problems you really care about, especially if you feel that they will solve a lot of issues in the organization and for our customers.
For example, when you know that there is a legacy feature that breaks every now and again.
It’s not like that many people are still using that feature, and it only takes a couple of hours (+ merges, testing and release tax) to fix. You can’t really delete it, because: “legacy”, and the topic comes up at meetings every now and again. You get really annoyed by it and you might spend a few hours, days, or months trying to work out what you could do instead and trying to convince some stakeholders that it would be really, really important to prioritize fixing that problem.
Are you familiar with the concept of “opportunity cost”?
In essence, the concept of opportunity cost is about the fact that, when you have to make a choice, you will be missing out on the opportunities of the choice you don’t make.
To put it simply, what do you think will be more beneficial to business and their customers:
Spending 5 hours of your time investigating how to add exponential value, or
Spending 5 hours trying to work out a solution to fix a problem that isn’t that impactful overall (cost and benefit wise)?
“Learn to pick your battles” might be something you’ve heard in the past as a polite way of putting “focus on doing your job first”, or “that’s not your problem to solve”.
While it might sound a bit harsh, it is important to focus your time and energy on solving a problem, rather than trying to solve 30 of them.
Make sure you are clear on what you are prioritizing and why, so that you have a guide for when you might fall off track. As good guide rails you can have, for example, a clear set of outcome-based objectives, success metrics and the constraints associated to meeting those objectives.
For the record, there is nothing wrong with being ambitious, as long as you aren’t taking too long to show the results of your “risky bets”.
Categorizing problems to clarify the context
Breaking problems down is what product people tend to be best at, as the majority of the problems we are faced with have layers (just like ogres!).
A lot of people across the company normally will have a siloed perspective, so they will act based on what they are able to see and experience. Product people, because we are naturally investigators and facilitators, tend to have a more holistic perspective of the problem. As you “peel” the problem off, layer by layer, you will be able to add value by:
Assessing the complexity of the problem
Identifying symptoms, causes and impact
Getting others involved while you discover how the problem is perceived (internally and externally)
Knowing which teams to bring together when aligning potential solutions
Problems sit in a spectrum
The likelihood is that you are handling problems that are more on the left-hand side (complex). Fear not, this is why we need to scope problems!
To scope a problem, is to analyze it. To analyze something, we need to pull things apart (peel things apart if you will), so we can assess each layer individually and how each layer affects the other.
Starting with categorization is helpful because you get to go through a list of questions and assess where the problem sits on the spectrum. Once you know, you will also have a good idea of the cost the solution will have to the organization.
Logically speaking, the more complex the problem, the more time, people, resources and money it will potentially require.
For a lot of organizations, however, the cost of not doing anything might be higher, so I’d strongly advise you to keep a lean and agile mentality. You can start with, for example, setting up some quick experiments to gauge the interest in solving the problem. The objective is to align with the prioritization side of things.
Testing quick and early assumptions
A couple of useful tools you can try at this stage is a Lean Business Canvas and an Assumption Mapping matrix.
With the Lean Business Canvas, you can quickly categorize some assumptions around potential infrastructure, customer segmentation, value proposition and financial breakdown. The idea isn’t to put something together as if you’re presenting to the board. The main intention is to write things down so you can work with them.
Then, get those hypotheses and move them to the Assumption Mapping matrix and allocate them based on how important they are and how confident you are in your assumption. Once again, you’ll want to identify the biggest risks of this solution and what you’d have to prioritize if you were to move forward with this solution.
Working through these two tools is a great opportunity to bring some stakeholders into the conversation. You can always grab some time and walk them through your Lean Business Canvas and learn a lot more from the subject you’re analyzing.
Know thy symptoms, causes and impact
When people talk about problems, they conflate symptoms, causes and impact. They’re different and should be treated differently.
Symptom (what most people refer to as the problem)
A symptom is a manifestation of a problem, there is normally more than one. It is hard to treat, because you don’t know the underlying issue. You can treat the symptom, but if you don’t know the root cause, the solution won’t be a lasting (or conscious) one. Symptoms rarely come in singles, so watch-out for those “ripple effects”.
Cause
The underlying problem that is generating the symptoms. Depending on the complexity depth, there might be many layers and interlinked connections. There are so many times and ways you can ask “why”, so pay attention to those “rabbit holes” (this is a deep thinker’s kryptonite, so if you’re a deep thinker it is a good idea to get accountability buddy).
Impact
Think of impact in the broader sense, so you can connect with your audience. This can be the impact on your constraints (time, money, etc.), impact on business goals, and/or impact on success metrics.
If you’re putting this kind of assessment together to get some feedback from someone else on the team, add a “Proposed Solution” section. It is good to show that you’ve not only analyzed the problem, but you also have a potential solution. If it’s not the best one, then you can discuss it together.
Let’s have a look at a couple of practical examples:
1. Product problem: You’re currently experiencing 67% bounce rate on the sign-up page.
After you’ve done some high-level investigation, you suspect what might be the cause of this disappointing bounce rate, so you’ll put it like this:
Symptom/Problem: We have a high bounce rate on the sign-up page.
Cause: Based on some high-level data, we believe that the majority of the rate is coming from our mobile users, as the sign up page isn’t loading properly on mobile.
Impact:
78% of our users access the site on mobile.
We have had some negative feedback on the current format and it’s driving our Trustpilot score down.
We were also able to look at our acquisition funnel and we have a decrease of 32% in customer activation from last month.
Proposed solution: Get together with Alex (design) and Jamie (development) and review the most relevant mobile pages for the acquisition journey. Maybe get a simpler journey together for mobile, but ideally I’d like to discuss this with them and then take it from there, it shouldn’t take more than a couple of days to come up with a couple of solutions.
2. Team problem: You are launching a new product off the ground and your current product team has a fully dedicated development team and a design team that you work with a couple of days a week.
Symptom/Problem: We are struggling to move forward with product development. I find myself having to put some designs together, so the team doesn’t have to wait a week to work out implementation details.
Cause: There isn’t enough available time with the Design team.
Impact: We won’t be able to have a working product in the customer’s hands by the time the new legislation goes live. We will lose new customers’ trust too, in the process.
Solution: This scenario might’ve been working while we were working on the prototype, but now we need someone who’s dedicated to the product from a design perspective. I’d suggest increasing the time with the design team to at least 3, or 4, days a week and start looking for someone on a permanent basis.
Frameworks to support problem contextualization
The product management community has been picking up and creating a wide portfolio of frameworks, tools, and techniques to support our problem scoping quest. It can get a bit overwhelming, so I picked a few for you to try, depending on what you need.
Personally, I don’t “subscribe” to any of these in particular. They can be useful to get you started when you’re stuck, but feel free to use none of them, or to mix & match!
Whatever you decide to use for your context exploration, make sure you act on the information you’re gathering and that you make it accessible to other people, whatever the approach.
How many “untitled” documents do you have in your personal folder that you never shared? How many workshops lived and died in your digital white boards? - Yeah (same).
The 5 whys
Most people will know about the “5 whys” technique, so I won’t spend a lot of time explaining this.
It is a quick-ish and cheap way of starting to form a better picture of the context. There are a couple of things you have to consider before you start:
Be mindful that some people in the organization might not be comfortable with being "interrogated" ( “why? Why? WHY? But Why?! “).
Treat it as if you are doing a user interview: approach each why from different angles and get as many perspectives as you might find necessary.
People might start with a less relevant answer to your first “why”, which will make the whole thread of” whys” less relevant.
Fishbone / Ishikawa diagram
The “fishbone” diagram might be the answer for you if the “5 Whys” feel a little too intrusive and/or unstructured.
Populating the diagram might be a good collaboration opportunity to work through a problem you might be having at a product, or objectives level.
If you’re tackling a complex problem, it might get a bit cluttered (and useless).
Another potential pitfall, if you’re not careful, is to obsess over “completing” the diagram.
It is important to define what is “enough information” to support you moving towards the next step: to identify what your next steps should be to get you closer to solving the problem.
Pirate metrics
I am going to trust that you, not only know your customer’s journey, but you have also validated that journey with some quantitative and qualitative research and analysis - yes?😬
Either if you’re using JTBD, or user journey mapping, it is important to categorize what is happening from a commercial perspective. Things likepirate metrics are great at this because they help you visualize the customer journey as a funnel, from activation to referral. It can also be a powerful tool for problem scoping.
Source: Startup runner
For example, you notice a drop in daily active users (DAUs) consistently.
Will a new Facebook campaign help increase this? Perhaps, but before wasting time and money on this, you might want to do some investigation:
What is an active user for your organization?
Why do they use your product/ service?
Did you make any changes recently?
Did you have a big increase recently and it's just the numbers going back to normal?
How was the same number last year?
What is the relation between awareness and activation, percentation wise? Has that changed?
…So on and so forth.
The takeaway here is that there are many other experiments you can run alongside the “Facebook campaign”. What you gain from running this exercise is that you will be able to start with the question and context for when you run your experiments.
Opportunity solution tree
The Opportunity Solution Tree can be very useful when you have a clear outcome.
Instead of labeling them as “problems”, Teresa Torres frames them as “opportunities”: “unmet needs”, or issues you have the power to solve as business.
Source: https://www.producttalk.org/opportunity-solution-tree/
Running through the exercise of identifying the potential “opportunities” associated with a specific outcome can be a powerful exercise to go through.
Get at least a couple more people involved in the conversation.
Set a timer to go through each tier of the tree (opportunities, solutions and experiments).
If you’re tight for time, you can vote on the opportunity you want to focus the solutions on, then vote for the solution you will be setting experiments for.
End up with more than a handful of experiments to run in 45 minutes.
Can solutions cause more problems?
It is even more likely that the solution you are working on so very hard will be causing new problems elsewhere. In the end, it needs to be about working towards a balance you, your team, your company and your customers are happy with.
Let’s take an example we are all familiar with: growth.
When you optimize for growth, regardless if you’re looking to grow within your space, or if you are looking to explore some other areas of the addressable market (TAM), you will probably be looking out for new customers, new markets, etc.
These new customers will have different behaviors and needs, so it is also likely that you will have to look into leveraging what your product does today and how it could also expand and evolve.
Money, time and people will be needed to see this new exploration through
Your existing customer base will probably be a bit neglected while this is happening, and it is likely that your daily usage and/or retention metrics will drop
In this case, you’ll want to focus on what is common to both growth and retention, which is to make products customers love. In this case, for example, there might be similar needs across both new and existing customers that you could prioritize.
Learning to identify opportunities that balance seemingly opposite ends of the scale, is a winning strategy.
How to keep track of more complex problems?
As you’ve probably figured by now, it is rare for a problem to require a single solution.
So, how do you make sure you don’t fall into some traps that might come from problem scoping?
Let’s find out…
The danger of “breaking it down”
Let’s be real, some of you won’t have the chance to work through a new big problem more than once a quarter (heck, a year!) when the strategy team comes down from their away day and handles you this plan they’ll need you to follow.
With all the due diligence, you will work through the “plan” with your team, break it down in slices (calling it “MVP”, or “V1”) and you get to work.
Now, three months down the line, you’re still working through that “first slice” that keeps getting more and more inflated.
It’s okay, we’ve all been there.
The lesson here isn’t to try and do everything in one go, the lesson is:
“if you simplify the problem, make sure you don’t fall in love with the simple solution”.
This means, you will have to keep experimenting until you find a solution that is impactful enough for the problem you have at hand.
One superpower you will probably end up developing is what I like to call: “elastic product mindset”. The ability to pull yourself away from the detailed perspective and look at a problem from a detailed point of view and put it into the grand picture. Sometimes all you need is to be able to “step back” and question “why did we start doing this in the first place?”, or “what are we trying to achieve?”.
Enter problem roadmaps
A good proposal to avoid under-delivering on value is to use the theme-based roadmap, proposed by Bruce McCarthy, or what Jared Spool dearly labeled as “the customer problem” roadmap.
Source: Product Roadmaps Relaunched (book)
The main idea is to refocus our attention around solving customers’ problems instead of focusing on the specifics of what we will deliver.
This doesn’t mean we stop delivering things - that’s the only real way to actively add value to your business and its customers. What it means is that, as an initiative, your focus should be to solve the problems. Then, each idea, hypothesis, solution represents a layer of how you’re proposing to solve the problem.
Themes, or customer problems, or opportunities, set out the focus for all the solutions, ideas and experiments we propose to test. This way, you never lose focus on what really matters.
Another great benefit to this approach is the fact that you become a lot more reactive as you learn what works and what doesn’t, allowing you to add and remove solutions and experiments that will really solve your customers problems and have a positive impact in the business.
Why does this matter?
There are many reasons why you should have a methodical and experimentational approach to problem solving. For product teams it is a logical thing, but it might not be so straightforward for the rest of the organization.
It might be useful for you to identify some benefits as you move towards a more discovery-minded company.
Risk
For some organizations it is too expensive to spend organizational power in solving the wrong problems. Yet, spending a lot of time with planning alone will not help with adding value to the business and its customers.
The balance is in looking at the problem at hand and ensuring that you have enough information to invest in a solution. What is enough information?
That will depend on your “risk appetite” and on your company’s risk appetite.
If you’re a small and young organization you’ll probably be fine with having a high-risk appetite - that’s what got you here in the first place.
While, larger and older organizations, that have a brand status to maintain, will tend to be more risk averse.
Fact:you will never be able to be 100% sure. The best way to de-risk a bet / assumption is to focus on what you’re trying to achieve (objective), define success metrics and experiment. Use the success metrics to identify if you should, or not, continue to invest in that bet.
Bring clarity to the organization
I have seen excellent product people (including myself ) going down the rabbit hole of problem scoping and only really sharing their insights with their teams; leaving the rest of the organization outside of the process (and learnings).
Have you thought about setting up some sessions to tell the rest of the company where you’re focusing your efforts? It is a great opportunity to share learnings, get more people involved and create a space for Q&A.
Make sure you’re also show-casing the talent of the whole product team: design, engineering, QA, DevOps, etc.
Nurture collaboration
We have proven multiple times that it is a lot easier to get others in the journey if they feel like they’ve participated in the process.
Use some of the workshop opportunities to connect with other people in the business. You can also make sure you cover your basis, as you go through a problem scoping exercise:
You’re not sure on how to cost an opportunity? - Have a chat with the commercial or financial team.
Uncertain about legal implications on a solution you’re considering? - There’s potentially a legal team who’d be happy to help.
You’re ready to get a solution out of the door? - Make sure you chat with customer support and they are trained on how to use this and support customers.
The true magic happens when they’re the ones coming back to you with ideas on how to solve the problem ;)
Final remarks - Tying up loose ends
Sometimes we get so tangled in the problem space and excited about solving problems that we forget to close the loop, and we end up being tangled in a lot of loose ends.
This is meant to be a system, with feedback mechanisms. It is almost pointless for you to set up a context of experimentation if you’re not going to assess your findings.
A couple of simple thoughts to make sure you don’t lose track of things:
Don’t forget to loop back to the person/people who messaged you originally to let them know the broken thing has been fixed - simple.
Keep a log of what you learnt each week. It shouldn’t be a whole essay, 15 minute and 5 things is enough.
Book a “learnings session” on the calendar for the team, if you have one, stop pushing it back.
Get an accountability buddy.
Take care of yourself, and don’t be too hard on yourself. This is a difficult job, and you don’t have to do it alone. When it gets too hard, there is always a product community ready to support.
Inês Liberato
Read also
Experience the new way of doing product management
