Moving from Solutions to Problems

People from all over the company come to you with feature requests and ideas. From minor things like UI tweaks to major ones like a new Search feature.

Depending on how pushy and persistent stakeholders are in support of their feature, you might be forced to eventually let it through. Once this happens, expectations are set. “My feature got into the product,” they think. From that, it’s a slippery slope. That person casually talks to others and word gets around. “You should talk to the PM about your idea. It seems pretty cool. I talked to him about this other idea I had, and look, it got released last week.” Soon after, an email arrives. And then you get a visit from someone else. Another email. You know the drill.

Most likely, you even found yourself in this position right from the get-go; you probably didn’t cause this. It’s just how things are done in your organization. Naturally, this is extremely frustrating; you know it’s the pathway to a disconnected and incoherent product.

Rejecting most feature requests, as Intercom’s brilliant posts describe so well, is very important. Tying everything to a strong value proposition and vision is effectively the kind of thing that produces a cohesive product. However, just saying No doesn’t necessarily change the fact that stakeholders will keep asking for features all the time. The reason is that we often fail to be constructive and pedagogic; if we don’t try to change their mindset, we’re sentencing ourselves to be thought of as “those pesky Naysayers.”

What we want is to create a culture where stakeholders come to us with problems, rather than ready-made ideas and solutions (i.e. features.)

There’s plenty of great commentary on the topic of “following the problem” and the value it brings, which ties back to the whole notion of Jobs-to-be-Done. Yet, I wanted to dig deeper into this issue by focusing on:

1. The reasons why a Solution-first culture makes your life harder;
2. A “framework” to drive stakeholders to think in terms of Problems.

(This is a long piece, so take your time or save it for later.)

Why Solutions Suck and Problems Rock #

Everyone has ideas; they’re cheap. Given the creative industry that we’re in, this is only natural. To be clear, there’s nothing inherently wrong with receiving ideas and feature requests from stakeholders. It’s just that they create cultural and practical issues that make prioritization and planning much more difficult than they need to be. You want the stakeholders’ input, but you need it to be (and need them to think) in terms of problems for you and your team to solve.

Let’s explore the different ways in which a Solution-first culture makes your life much harder, and how Problems are what you are really after^[1].

The product is viewed as a set of features #

When the organization talks about what goes into the product in terms of features, that’s how the product will be thought of: a mere set of features. As this mindset deepens, it becomes increasingly easier to add things without fully considering how they fit into the broader picture. The result is that the collective understanding of the product vision gets ever fuzzier and the strategy gets increasingly harder to define.

Instead, looking at the product as a vehicle for solving problems for users and customers, the kinds of questions that get asked are: “is solving this problem within the realm of our product’s value proposition?” and “is this a big enough problem for our customers, that justifies the investment?”.

Keeping you and everyone tuned to the product’s vision and value proposition is key to produce a healthy prioritization environment. People in the organization start to realize there should be reasons behind product decisions, avoiding an ad-hoc development culture.

Solutions and ideas are often half-baked #

Another (big) problem with solutions and ideas coming from stakeholders is that they’re are often half-baked. Perhaps it’s the result of a conversation with some customer, or maybe it’s an idea they came up with by themselves. They put it in the back of their minds and then told you about it when they had the chance.

As you talk through the idea with them, you usually realize there are holes in their lines of thought. “What if this happens?”. “Hmm, I don’t know”. “OK, let’s go on”. After some more idea explanation… “But if we do that, then there would be an inconsistency on this other part of the product”. “Right. I hadn’t thought of that”.

This happens not because they’re not smart. It’s the result of the simple fact that you’re deep into the product and they’re not. Your entire day is spent thinking about and working on the product, and theirs isn’t. They’re concerned with conversion rates, funnel optimization, sales numbers, lead generation, burn rate, pitching to investors, etc.

If you create an environment in which your inputs are driven towards problem statements, you and the stakeholder will jointly get to one of these conclusions:

• the problem is already addressed by some part of the product;
• the problem is not worth pursuing;
• the problem is valuable or should be evaluated further.

Solutions are harder to break down #

You get to the moment when everything’s prioritized for the next development cycle. All the important features are spec’d out and the team starts to estimate what can get done. Some of the last features in the list probably won’t get done. You have to go back to the stakeholders that asked for them and give them the bad news: we either go for a smaller, simpler version of the feature, or it will most likely be out of the release. They go for the former option. Here’s what happens now:

• You’re back to the drawing board;
• Since it’s a feature being pushed by a stakeholder, you have to negotiate its new, smaller form with him or her;
• Your time spent on the spec, and the team’s estimating it, was wasted (you have to do it again.)

If you and the team were collectively working from a list of prioritized problems, the situation would be very different. You go through each problem, specifying and estimating its solution. When you get near the end of the team’s capacity, you can approach those problems in a much more efficient manner. You can work out a solution that might not be ideal or complete, but gets you towards the direction that you need to go.

This time, the conversation with the stakeholder is much more positive:

As you know, that problem of yours wasn’t high up the priority list, which means we won’t have much time to work on it. We came up with this solution, that although not perfect, it’s a step in the right direction. We’ll keep working on this on our next development cycle.

Think of this now classic metaphor by the brilliant Henrik Kniberg:

If you start out from “I want a car,” it’s harder to find an alternative when you don’t have the time to build a car. However, if you start from “I need to get from A to B, as quickly as possible”, then there are multiple solutions, along a whole spectrum of complexity.

Solutions get outdated #

The other possible outcome of the previous scenario is that the stakeholder prefers the feature to be delivered whole, as specified. She’d rather wait than have an ‘incomplete’ version. Perhaps that specific solution only really makes sense as originally designed.

Here’s a likely situation: for whatever reasons other things end up having higher priorities over the next development cycles. That special feature sits on the backlog for a while. When it’s finally time to work on it, the product has already moved forward. Maybe the database has been refactored. Maybe the API on which the feature relied has been deprecated. Perhaps the Information Architecture has changed a bit, and the UI design has to be rethought. Once again, the time that was spent on this solution specification was wasted.

Problems don’t tend to get outdated as easily^[2].

Things move quickly. Software is really malleable. (Feature) Solutions tend to make sense within a very concrete version of the product.

Solutions are harder to prioritize #

Products and features are versions of a solution to a problem. What this means is that by thinking in terms of the former, the problem they’re solving gets more difficult to grasp. Either because it’s a non obvious problem, or the product/feature are poor solutions for it.

In practical terms, this makes it much harder to prioritize a list of features than a list of problems. There are added layers of indirection that make us evaluate priorities in a different way. It gets difficult to determine the intent and expected impact from a feature. On the other hand, a problem (“low number of transactions”) can more easily lead to an objective (“increasing number of transactions per customer per month by 30%”).

Since objectives map to a business strategy in a much more evident way than features do, then prioritizing them becomes much more straightforward (“Does this objective contribute to the strategy or not? By how much?”.) From that, multiple solutions may arise. When a solution doesn’t match the objective, it can be rethought. It’s just a matter of where we start: retrofitting objectives unto solutions, or deriving solutions from problems and objectives.

6. Solutions don’t empower the team

When you want to build a ship, do not begin by gathering wood, cutting boards, and distributing work, but awaken within the heart of man the desire for the vast and endless sea" — Antoine de Saint-Exupéry

A modern product team is made of highly intelligent, creative engineers and designers. It’s a vast underutilization of these skills to be accepting fully-formed features from the outside world. Any team loves a purpose and problems to solve. That’s what should be coming in.

Aside from his book, Marty Cagan has a great set of essays around the topic of team Autonomy on his website, going over the different tradeoffs that should be considered when you strive for autonomous product teams. He describes the many reasons why a team isn’t usually fully autonomous - taking advantage of some base technology in the organization, controlling misalignment with the overall business strategy, the need to coordinate with other teams and many subtler points along these lines. However, you can be sure that the motivation level and quality of what is created will be much higher when the team is empowered to design, build and own a solution.

Turning Solutions into Problems #

Now that you’re (hopefully) on board with thinking in terms of problems, let’s start to dig in on how to turn a solution prescription into a problem statement. It’s doing this over and over again that will foster a culture of problem-first thinking around you.

A Mini-framework to Drive Stakeholders Towards Problems #

You want to be in a healthy working environment. So, a major part of your role as Product Manager is to be incredibly aware of sensibilities, personalities and personal interests of those you work with.

Even when the answer to some request is immediately obvious to you that is a ‘No,’ you absolutely need to make the other person understand why. You can’t just say ‘Thanks, but that doesn’t fit with our plans’. In addition to saying ‘No’, explaining why you think it doesn’t work is not going to cut it. First, you’re not really helping your reputation as a considerate or thoughtful person. Second, the person might not understand your reasons and thus will have learned nothing from the exchange. Finally, you might be wrong and be missing out on potentially important insights because of an unwillingness to understand the person’s reasons.

I’ve found that using a straight-forward set of steps and questions to create what we may call a “Problem Case” with the Stakeholder works pretty well. This figure summarizes the entire approach and I go into the details over the rest of the article.

(Download)

Step 1: Getting to the Problem Statement(s) #

This step is based on the “5 Whys” technique originally developed by Sakichi Toyoda. It is an important part of the induction process into the Toyota Production System, namely their problem-solving training. The basic concept is to use iterative interrogation, starting from some visible issue. By repeatedly asking the “Why” of the previous answer, the goal is to get at the root cause of the issue. The number 5 was derived from empirical observation.

I prefer to call this technique something like the “relentless whys”, because I’ve found that it’s often not necessary to reach that many questions, but also that within the realm of software ideas, as you start to question people, they might drift into other considerations and come up with new ideas on the fly. In these cases, it’s best to keep digging.

The following examples show you how to quickly get to a problem statement that can then be further analyzed in the next step of the “framework”.

We should have some sort of geo search feature to find car parks

1. Why do you think we need that?

   Because users could then find a car park close to their destination

2. Why do they need to find a car park?

   Because they can plan their trip and know where to park

3. Why do they need to plan their trip?

   Because they can save time and know where to go, instead of driving around

So we’ve gotten to the problem statement: “people waste time looking for a place to park.” We still don’t know if this is a valuable problem to solve. However, it’s the stakeholder’s hypothesis, and we have to move on to the next step to continue to explore it. Let’s have a look at a couple more examples.

I think a data visualization dashboard would be great as a first screen in the back-office.

1. Why do you think that?

   Because users should have a quick view over the most important metrics.

2. Why do they need a quick view over their metrics?

   Because otherwise users have to go to the reports screen, and they shouldn’t.

3. Why is it a problem to go to another screen?

   Because they need to access each report individually, get the data from each and calculate the metrics in a spreadsheet.

4. Why is that an issue?

   Because that takes a lot of time, and it should be faster

The problem statement here would be: “users spend too much time to get to their core metrics are doing.”

I think users will not be sharing content via email because they don’t care about that medium. We should really work on sharing via NewSocialTrendr

1. Why do you think they don’t care about email?

   Because I read this article on Gizmodo that said that our core demographic no longer uses email.

2. Why do you think that article is trust-worthy?

   Because it was written by a good analyst, and there were a lot of comments in support of this idea.

3. Why do you think they would care about NewSocialTrendr?

   Because that service has been growing like crazy this year, specially in our demographic.

When faced with clear conjectures from the part of the stakeholder, it’s preferable to stop with the ‘why’ line of questioning. You usually won’t get to a problem statement, because these ideas are usually derived from some opinion. There are multiple paths you may take from here:

• Move on to the next 2 steps, with particular focus on the third one: getting testable value premises that can quickly (in)validate the stakeholder’s proposition;
• Ask the stakeholder to come back to you with more compelling evidence that the current product strategy should be changed.

Which way you go will depend on the stakeholder, and your own sensibilities as to the type of relationship you have with them. —  At this point, it’s important that you consider the following:

• This tool was created to understand a problem’s root cause. In this case, we’re adapting it to get to an underlying reason or problem statement that led the stakeholder to have an idea or to request a feature. These concepts feel backwards, but what we want is to use this kind of inquisitive questioning;
• This should go without saying, but just to drive the point home: do not just ask ‘Why?’ when someone comes to you with an idea or answers to one of your questions. I’ve used a dry ‘Why’ here to get the point across. In real life, you need to be sensitive to the other person’s mood and personality; never stop being polite and treating every idea with respect, even if it doesn’t make sense to you;
• People sometimes don’t react well to their idea being put into question in this way. In these cases, it’s best to move on to the next step and try to get to the problem statement as part of a more unstructured conversation;
• Another caveat with the ‘Whys’ technique is that once you go down one path of reasoning, you risk stopping at one root cause, while there might be multiple ones. The same can happen when using it to look for the underlying problem statement. To counter this you should: (a) explore multiple paths of questioning when you sense there is more than one issue behind some answer, and (b) don’t skip over the next step of this “mini framework”.

Step 2: Walking Through the Scenario #

The second step of the “framework” is to understand the scenario in which the stakeholder believes the problem occurs. There are two main results that come from doing this:

1. It lets us have a better picture of how the problem occurs, in the mind of the stakeholder.
2. If the problem doesn’t really make sense, the stakeholder will come to that conclusion along with ourselves.

This step is based around an unstructured conversation with the stakeholder, exploring:

• the different situations that lead to the problem;
• variations on the problem;
• alternative solutions already possible with the product;
• additional problems that may need to be solved or validated if this problem were to be solved.

To get the conversation going, it’s best to use a cue like: “OK. I see where you’re going, but I still would like to understand how you see the point of view of the user. Imagine you’re an user of our product. Could you walk me through the steps that lead to this issue?”

The goal is for the other person to feel comfortable and be more open to share their worldview. From this, it’s a free-flowing conversation, but you should really try to explore the 4 points mentioned.

Let’s try going over a possible conversation, using the first example from the previous step (which is actually a real life conversation I had with a client), to give you a sense of how to go about this:

— PM: I realize that people waste time to find a place to park. I’d just like to understand how you see it, as if you were the user. Could you please walk me through the scenario?

— Stakeholder: Sure! Say I’m a user of our parking app. I know I’m going to a meeting in downtown Madrid. I’d like to know in advance where there are parking spots available, so I don’t waste any time. If our app had a search feature, we could provide that info to the user.

— PM: So users would be using the app before they start the trip, is that it?

— Stakeholder: Yeah, exactly.

— PM: But then wouldn’t it be very likely that the occupancy levels change by the time they get to the car park? We wouldn’t be able to ensure that there would really be available spaces.

— Stakeholder: Oh right, hadn’t seen it like that.

— PM: In terms of guiding people, there are two ideas that come to mind: first, we could just show the occupancy at the current moment, so if people check it out in the vicinity of the car park, the information will be more accurate. The issue to test there would be safety and practicality; would people be willing to use the app while driving, just to see if there are spaces? The second idea would be to create a navigation feature that dynamically updates based on occupancy. Of course, that would be a major undertaking, and there are apps that do that much better. That’d be a strategic shift in our roadmap, which doesn’t seem reasonable based on our other goals.

— Stakeholder: You’re right, I guess we can put this idea in the back-burner. I’ll reach out to some navigation apps to see if they’d be interested in using our parking occupancy information as an input.

— PM: In the meantime, remember we do have the car park geographical visualization and search on our roadmap. We know that will help people planning their trips, specially those from out of town on longer stays.

— Stakeholder: Yes, that’s true. Thanks for talking this over with me.

These conversations are unstructured and open-ended. Their outcome depends as much on the person’s openness as your ability to truly appreciate their goals and motivations. It takes practice, but being able to truly explore the problem scenario can lead to deep buy-in in the decision to pursue or ignore an idea.

Step 3: Setting the Value Premises #

We’ve now gotten to the underlying problem statement, and explored the problem scenario with the stakeholder. It’s now time to move on the final step: understanding where he or she sees the value in the idea. The goal here is not to get to some sort of value measurement, but instead get to the parameters where the value could be measured. Remember that value stems from solving a problem for a large enough segment of our customer base. By agreeing to a set of value premises behind some request, we will be able to:

• Get buy-in on metrics on how they can be validated;
• Test the premises based on those metrics;
• Prioritize the problem statement if it is valuable and aligned with the current strategy.

Let’s go back to example #2 from above. The original request was to ‘add a data visualization dashboard as a first screen on the product’. Through the ‘why’ line of questioning we got to the true problem the stakeholder perceived: it took too long for users to know their core metrics. Now assume that by walking through the scenario we also got to more context around the perceived problem:

• situations leading to the problem – “users want to know on a weekly basis how their stats are doing”
• variations on the problem – “do all users look at the same metrics?,” “do users want faster access to the metrics or do they want faster access to all the raw data?”
• alternative solutions already possible - “going to every report screen and exporting the raw data”
• additional problems that come from solving this one – “which metrics should be on a common dashboard?,” “should this be configurable per user?,” “can we calculate these metrics for every user on demand or should we setup infrastructure to do that in the background?”

At this point, we need to set a common set of concrete assumptions with the stakeholder, that we can later validate or invalidate. Both of us need to accept them, as this will be the litmus test for the idea. For this example, we’d be looking at things like:

• what percentage of users facing this problem would be acceptable to let things stay as they are?
• what frequency of access to these metrics is so high that makes this problem unacceptable?

The final question for the stakeholder would be: "say we find out there’s a real issue here. How would solving it help support the product’s value proposition?." The main reason to only ask this at the end is that by now there should be a common, deeper understanding of the problem. Also, it helps to reinforce the culture that it’s not only about solving big enough problems, it’s about focusing on those that make sense for the product right now.

If we get to this point, we now have the necessary agreement and inputs to look at analytics data, do interviews, design experiments and similar things that will show us if there’s something worthwhile to pursue or not. Most importantly, the results should be naturally accepted by the person that brought you the idea.

As you repeat this process, people will start to internalize it and expect it from you. The next time they think of something, they’re much more likely to go through it by themselves and come to you with a different request: “I think there’s this problem that we should work on.” That’s a much better starting point to work from.

Step (back): Sometimes You Have to Give Up #

There are no perfect products, teams or stakeholders. There will be times when you will be forced to take a step back and accept the fact that some stakeholder is impossibly persistent with his pet feature. Or maybe a sales team made a commitment to a large customer that you can’t get out of. Perhaps it’s a request coming from an executive that no one in your management hierarchy could persuade to change his mind or understand his reasons. The key here is trying to:

1. Negotiate compromises

   When faced with an imposed idea, do your best to negotiate metrics that can be tested later on to validate the success of the feature. This can give you leverage later on, if the data doesn’t align with the stakeholder’s beliefs. Also, when possible, it’s good to negotiate a middle ground to the person’s idea. This will keep the person satisfied and at least send the message that ‘not everything goes.’

2. Create an strategy for change

   Identify which parts of the organization still aren’t aligning towards Problems. If they’re within your sphere of influence, great, keep repeating these steps; expectations will naturally form over time. If they’re not within your sphere of influence, you need to identify, evangelize and help those who can reach the sources of imposed solutions.

3. Accept this is a long game

   Cultural changes take time and persistence. Don’t feel frustrated. It is only natural that there’s resistance to change. This kind of politician’s job is often painful to those of us that ‘just want build a great product.’ The thing is that organizations are made of people with many types of outlooks, experience and motivations. As PM’s we are constantly thinking about the product and how best to build it. It’s on us to bridge the gap between our mindset and the rest of the organization. Over time, that’s what will make our job easier.

Start converting Feature requests into Problem Cases #

Give this a try, and start converting ideas and feature requests into Problem Cases. As you explore this line of thinking with your stakeholders, you’ll start to foster an environment that’s closer to the ideal.