Product Managers, Level Up Your Problem-Solving Skills

I’ve never met a product manager who doesn’t want to get better at what they do.

The challenge is not in the desire, but in putting that desire into action.

Product management isn’t a well-defined function. It’s changed rapidly over the past two decades.

Most of us have had to learn on the fly, doing the best we can. We’ve learned by doing.

There is no better way to learn. But we can accelerate our learning by looking to those who have come before us.

We see evidence of this in our existing methodologies. The Lean Startup was influenced by The Toyota Way and is grounded in the scientific method. Kanban, also inspired by Toyota, comes from just-in-time production practices.

Where else should we be looking for inspiration?

I have a found a wealth of value in research on design and problem solving.

Product Managers Are Problem Solvers

I’ve long held the belief that product managers are designers.

Design is a challenging concept because it has many meanings. The most prominent meaning today is that of aesthetic design - it conjures images of fancy furniture and Frank Lloyd Wright buildings.

But design is much more than that. And good designers have to consider far more than just the aesthetics of their design.

Design is a type of problem solving. It’s a method for creating a solution to a particular type of problem.

If this is true, we might ask ourselves, how do we get better at solving design problems?

Researchers have been asking this question for decades and we can learn a lot from their work.

David Jonassen, an educational psychologist at the University of Missouri, spent much of his career on this very challenge.

Let’s start with his definition of problems:

A problem is an unknown that results from any situation in which a person seeks to fulfill a need or accomplish a goal. However, problems are problems only when there is a "felt need" that motivates people to search for a solution in order to eliminate discrepancies.

The second part of his definition is particularly relevant for product managers. We already know that many products fail because they don’t address a “felt need.” (Ahem, bottled water for pets!)

Jonassen continues by defining a taxonomy of problem types. The distinction that we are going to focus on today is between well-structured and ill-structured problems.

The most commonly encountered problems, especially in schools and universities, are well-structured problems. … these well-structured application problems require the application of a finite number of concepts, rules, and principles being studied to a constrained problem situation. These problems have also been referred to as transformation problems which consist of a well-defined initial state, a known goal state, and a constrained set of logical operators.

Ill-structured problems, on the other hand:

Typically have several solutions, each of which offers advantages and disadvantages to different people and situations in the context of their application.

Product managers primarily work on ill-structured problems.

Our job is to generate solutions that have advantages for our customers and our business as compared to the competition.

Unfortunately, we are raised in schools that teach us how to find right answers to certain problems. But we graduate into a world of ill-structured problems that have no right or wrong answers and instead have several solutions with different advantages and disadvantages.

What makes this story even bleaker is that research shows that competence in solving well-structured problems doesn’t lead to competence in solving ill-structured problems.

How Not to Solve Product Problems

We often fall into the trap of treating ill-structured problems as if they were well-structured.

We look for rules and principles that we can apply or rote procedures that we can follow. Is this not what we are doing when we read blog post after blog post about how to prioritize features?

Many business school courses will tell you that you need to come up with ranking criteria and score each idea, only pursuing the ones that garner the highest scores.

We implement this recommendation by collecting all of our ideas into a spreadsheet and evaluating each based on its business impact, how often it’s been requested by customers, and its time to build.

We decide to build the highest scored features and we go on with our day feeling good about our decisions.

But all we did in this scenario is treat an ill-structured problem - how do we create value for our customers and our business - as if it were a well-structured problem - one where we can apply a formula or a fixed set of rules to find the right answer.

The challenging problems in business are not well-structured. And we shouldn’t treat them as if they are.

How to Be a Good Problem Solver

Fortunately, Jonassen didn’t limit his research to types of problems. He was interested in how to develop good problem solvers.

Here is what he has to say:

design process

This is a great distinction. If your job was simply to take an inventory of all possible solutions and choose the best one, little innovation would happen.

It’s not your job to choose the best option, it’s your job to create a compelling option.

As designers, when we frame a situation we create an initial design structure within which we begin to invent and implement solutions. … the problem solvers must frame the design problem, recognize the divergent perspectives, collect evidence to support or reject the alternative proposals and ultimately synthesize their own understanding of the situation rather than find a solution for a prescribed problem.

This is pure gold. To invent a compelling solution, we must first frame the challenge we face, explore divergent perspectives, collect evidence to help us evaluate different perspectives, and ultimately work to come to a refreshed understanding of the challenge.

We see evidence of this type of process in product management. We talk about defining the problem space before jumping into the solution space.

But how many of us actually do this beyond writing a jobs-to-be-done story or framing our user stories as opportunities instead of solutions?

How many of us take the time to explore multiple perspectives, use research to fully understand the merits of each of those perspectives, and then synthesize what we learn into a better understanding of the challenge?

We have long heard that a product manager’s job is to own the problem space - to thoroughly define the problem.

Jonassen helps us understand why this is critical:

Ill-structured problems are ill-structured because there may be multiple representations or understandings of the problem. So, identifying an appropriate problem space from among the competing options is perhaps the most important part of ill-structured problem solving.

Explore the Problem Space to Generate Better Solutions

We’ve all had the experience where we vehemently disagree with someone and we can’t find a resolution.

Oftentimes our disagreements arise from the fact that we aren’t aligned on one perspective of the problem.

I have my perspective and you have yours. And instead of working to understand each other’s perspectives, we instead argue over what seems obvious from our own perspectives.

In short, how we represent the problem impacts the solutions that we find.

More from Jonassen:

The process of problem representation is better conceived as the creation of a problem space. This process involves mapping the problem statement onto prior knowledge and constructing a personal interpretation of the problem (i.e., problem space).

If we don’t work from the same representation of the problem, we’ll never agree on a solution.

But it shouldn’t be a battle of wills - my perspective vs. yours.

Instead, Jonassen advises, we should explore multiple perspectives. Each perspective opens up more of the problem space, in turn opening up more solutions.

We should start by mapping out our own perspective - making sure we truly understand what we think and why we think it.

We should hear our teammates out as they map out their own perspectives.

We should do the same with our customers and users. Because if our perspective doesn’t align with theirs, we won’t develop a viable product.

Start With Your Own Experience

There are many ways to map out your own perspective.

In my Map the Challenge course, students explore opportunities for increasing the accessibility and ridership of public transportation.

They start by mapping one of their own recent public transportation experiences.

The key is to capture a specific experience - to avoid generalizations. You don’t want to map out how you use public transportation in general. You want to map out yesterday’s trip home from work or last weekend’s trip to a baseball game.

You can apply this same concept to your own work.

Map out a recent experience you had with the challenge that your product addresses. Capture your goals, your motivations, your thoughts, and your feelings throughout the experience.

This metadata around the experience is where insights are formed.

There are many ways to do this. And I’m reluctant to share an example, because the value in this exercise is to capture your own perspective - not map it on to mine.

So as you think about this step, don’t fret about getting it right or wrong. Remember, ill-structured problems have no right or wrong answers.

And right now, we aren’t focusing on solutions, we are just committing to paper our own perspective on the challenge, so that we can evaluate it and understand what we think.

Explore Your Teammates’ Perspectives

If you have everyone on your team do the previous exercise individually, you should now have one map per teammate.

Remember, each map should capture that teammate’s perspective. This shouldn’t be done as a group exercise. Otherwise, you’ll conform to the dominant perspective and lose a lot of the richness of the experience.

If you work on a product (say an enterprise product) where you don’t have personal experience with the challenge, have each team member map out what they think a customer’s experience with the challenge looks like.

Take turns having each person walk the group through their own maps.

Don’t compare and contrast or evaluate. Just focus on understanding their perspective.

Ask questions. Highlight differences. Be curious.

And don’t criticize. Again, there is no right or wrong way to do this.

Remember, the more perspectives you explore, the bigger your problem space becomes, opening up more potential solutions.

Think about this step as opening up possibilities, as laying the foundation for future innovation.

Immerse Yourself in the Customer Perspective

If we don’t take the time to understand our own perspectives (and those of our teammates), we will continue to be unaware of our own thoughts and beliefs.

We’ll argue over our differences with little likelihood of resolving them.

But it’s not enough to explore the perspectives inside the building. We have to get out and understand the customer’s perspective.

Some of you might argue that this is where we should start. After all, it’s our customers who dictate the success of our product.

But if you don’t take the time to fully understand your own perspective, you’ll project your own assumptions and beliefs onto the perspective of your customers.

It will bias your understanding of their experience.

You don’t want that.

Understand your own thoughts and beliefs so that they don’t bias your understanding of your customer’s perspective.

But once we’ve done that, we do want to get outside and start interacting with customers.

Customer research is both an art and a science. And to explain how to do it well is beyond the scope of this article.

The key in this step is to use observations, interviews, and co-creation exercises to understand the nature and the context of the challenge you are tackling from your customer’s perspective.

Develop a Shared Perspective

You’ve mapped out your own perspective. You’ve explored your teammates’ perspective, and you have a pile of raw data from your customer research.

At this point, you should feel like you are drowning in data. This is a good thing.

Now it’s time to start to synthesize and align around a unified perspective across your team.

I recommend that you start with affinity mapping. Use the source material from your interview, not opinion or conjecture.

Put your own perspectives aside as you explore the data from your customer research.

This is a messy process and takes time. The goal is not to complete the task, but to explore what’s there. It’s an active process that involves a lot of trial and error. Have fun with it.

Affinity mapping helps you explore your data and as a group exercise it can help you align around a new shared perspective.

Test that Perspective

There will always be more questions and more research to be done. But the team should converge toward a shared understanding of the challenge.

Be explicit about this shared understanding. Map it out.

Then shift from generative research to evaluative research to test whether your map reflects reality.

Use observations, hypothesis-driven interviews, and co-creation exercises to test your map.

Inevitably, this will lead to revisions to your shared understanding. Your map is (and always should be) a living and evolving document.

What we end up with is a research-backed shared understanding of the challenge we are tackling and a concise visual that represents that understanding.

There is no better place from which to start exploring potential solutions.

Want to Learn More?

We all know that we should explore the problem space - that we need to spend more time defining the problem than we probably do.

This process is a good guide for how to do just that.

If this article is enough for you to get started, great. I’d love to hear how it goes.

But I know for many of us, it’s hard to put what we read into practice. We need help applying it. We need practice space.

If you are interested in getting some real-world experience with this process in a low-risk environment where it’s safe to learn from your mistakes, I’ll be opening up a new cohort of my Map the Challenge course.

In that course, students follow the same outline of this post. We start with a little bit of theory on how to develop your problem-solving skills.

We then work through a case study problem where each student:

• Maps out their own experience with the challenge
• Explores the perspectives of other students in the class
• Immerses themselves in the customer’s perspective
• Synthesizes and aligns around a unified perspective
• Tests that new perspective with real customers

This course will run from February 1st - March 13th. Applications for this course are now closed. If you would like to be notified when a new cohort is offered, please join the Product Talk mailing list.

P.S. All the excerpts in this post came from the following article:

• Jonassen, D. H. (1997). Instructional design models for well-structured and III-structured problem-solving learning outcomes. Educational Technology Research and Development, 45(1), 65-94.