Who is involved in assessing the problems you choose to tackle?

There is an interesting tension here between looking at problem spaces from a variety of angles to make sure you have a sound and differentiated strategy that is worth pursuing and inciting decision paralysis by having too many individuals involved in the process. And the truth is, it depends on the project. I’ll give you a couple of examples for how we have tried to simplify the investment of time and talent for this particular challenge, but it may not work for all organizations. The approaches we take have to be at least a little malleable for the organization or adoption and usefulness suffer.

I’ve worked in a few organizations where the investment in exploring a problem space (without a confirmation that investment in this problem was guaranteed for the company) took too much time from key product development functions and even some business and support functions. It felt quite similar to the sensation of dating but never really knowing if this is “going anywhere”. That amount of uncertainty caused a ton of friction in our teams. Some people responded by avoiding the problem space until it was “clear” that it’s prioritized. Some people were so bought in that they went above and beyond to try to convince the organization that it was worth the investment but without crucial data or participation from important stakeholders, so the recommendation never reached its full potential. By the time a decision actually was made (if ever), many people on the team were so frustrated with the project and the level of uncertainty around it, that it took twice as long as it normally would to communicate that it was now prioritized and we were ready to start work on it. This causes a pretty major time delay in some areas. An all around a frustrating experience for everyone that resulted in sub optimal outcomes.

Hopefully this example isn’t sounding too familiar to you, but it’s what motivated me to try to leverage our product development lifecycle to create better clarity around who is involved in the exploration of a problem space, what does the exploration of a problem space mean (what activities or information is needed to make a decision), and a ceremony to close the gap of alignment and make a decision on whether it’s something we plan to pursue or not.

The first step for me was finding a way to harness the power of the organization at scale for sourcing ideas around problem spaces to explore. We therefore created an intake process that allows anyone in our organization to submit ideas for consideration. They can also tag a customer in the request if it was a customer request, etc. This allows us to get a head start on assessing the opportunity or impact of a particular problem space.

The second step was to simplify the information needed to make a decision, and provide clarity and a touchpoint to the team around this stage in the process. I shouldn’t need a full development estimate and wireframes to decide whether or not I want to invest in something that isn’t likely to drive the financial or experiential outcomes our team is targeting. So the sooner you can say no to the project you don’t think will make an impact on your product or business, the less spinning your teams will do and the more clarity they will have on executing on the right things.

Here is an example of what our teams will source answers for before a problem space is approved for further work:

Our teams (PM, PMM, Design, & Research) answer the following:

• Alignment with our strategy - what part of our strategy does it support? (Growth, Retention, Competitive Differentiation, Improved Customer Experience, etc).
• Current capabilities - how close are we to having a solve for this space? Is there a workaround?
• Opportunity - How painful is this problem and what is the impact to customers if it were to be solved? How will investing in it benefit the company?
• Success Metrics - what metrics would be expect to move?

On our teams the PM is responsible for the deliverable, but the other team members are contributors with critical points of view and data to contribute. There are potentially many other sources of support within the broader organization that are included depending on the problem space and their unique purview, but we try to keep the teams small so that we don’t slow down the process. Once the team answers these questions, they present their opportunity assessment to our product leadership team who then decides if this is a problem space we will invest in, and provides support via resource allocation, prioritization, etc.

Of course these questions are not enough to fully answer the question - Is this worth investing in? Things like capacity, level of effort, which solution we choose, and many more can have an impact on whether something is worth investing in or not. But this allows us to structure a meaningful touchpoint in the flow of the process that can remove problems we likely won’t invest in early enough so they don’t create unnecessary drag on the team. We have this same opportunity further down the line when it’s appropriate to look at the recommended solution, or the investment in development.

In many ways this process is like a funnel. There are stages and things you can remove early because they just don’t make sense, but there should be more opportunities to change your mind sprinkled thought the process as you get closer to development.

Product management is accountable and responsible for assessing which problems to tackle. But I strongly believe it works best when it’s a process where everyone can provide input, there’s transparency on how decisions are being made (see question on feature planning), and where decisions are made based on market fact - not opinion. Any debate should be decided by data and market (customer) signal.

As a PM, your market intelligence should come from as many sources as possible. Customers, partners, analysts, customer success, sales reps, sales engineers and even engineers. Entertain as many ideas as possible. But work diligently to validate ideas with market data. Never make a decision based on someone’s opinion.

It is the Product Manager’s job to identify, prioritize and shape the problems the team is tackling. We’ll break this into two parts 1) finding problems 2) shaping problems.

Finding Problems

You need to have ongoing sources that you’re plugged into to find problems. Common sources are 1) customer research 2) exec requests 3) support tickets or user feedback 4) product usage data.

In my experience, I’ve found the most fruitful source of problems and opportunities is customer research. Be careful with exec requests - the common behavior is to blindly execute on them. You must ask questions. Where did this idea come from? Why do they think it’s important? Support tickets tend to be a gold mine for problems, but typically more miniscule ones. It’s important here to find greater trends and patterns that point to bigger problems. And finally, data is a great signal, but tends to require interacting with the user to understand the broader problem at play. Follow up on the signals you see in data with talking to users.

Prioritizing Problems

This should be done transparently with your Product Squad (ie UX, Eng, Data). Each week you should review the prioritized backlog of problems you’re shaping (actively researching and defining). Your squad should provide their feedback and input on the problem backlog (add / edit / remove items) and align on the prioritization.

Shaping Problems

Before the squad can work on a problem together it needs to be shaped (ie talk to customers, dig into the product, look at data and answer these 7 questions below):

1. Why is it a problem?
2. Who is it a problem for?
3. When does it happen?
4. What does the current (broken state) journey look like?
5. What workarounds or hacks are used today?
6. How many customers is this impacting today?
7. Is this a problem worth solving? Why?

A shaped problem should always have a 1-pager that concisely summarizes the answers to the above questions. At the start of each sprint, the PM picks a shaped problem from the top of the backlog to focus on. This is when Discovery and Prototyping begins.

Depends on the problem! Who has the best knowledge to help assess?

This could be a product manager, an analyst, a designer, or an engineer!

It is likely a team of people, often informal, that help assess the "right" problem to solve for an organization.

Let’s break this down into 2 workstreams - 1) how to create the complete opportunity space & 2) the process to select the right opportunities to go after. 

1. Creating the opportunity space - Assessing problems always starts with customers/users. As a PM, always factor time week over week to shadow/talk to your customers. If you have a user researcher on your team, they are your partner to start with. Also, problem identification can come from anywhere in the organization - as a PM, you should create channels/forums for the organization to surface these ideas e.g., weekly discussion brown bag sessions with engineering/design. When you have the right partners involved upfront in helping build the complete landscape, you are set up to drive bigger outcomes.

2. Picking the right ones - The right ones can be picked up based on different scenarios:

   • For qualitative insights, lean on voice of the customer insights such as inbound support tickets, account management team. B2B products leans on this methodology predominantly. 

   • For quantitative insights, work closely with your data analysts. B2C products generate stat sig data and hence quantitative insights can be leveraged. 

   • There might be top down priorities that dictate your roadmap e.g., your company decides to enter a new market in which case the problem you choose will be about unlocking this new market. 

   • Roadmaps can also be driven by mandatory legal & compliance requirements. E..g., EU is making a change to their data proivay guidelines, which means you have to update your product portfolio in a given timeline to adhere to the new guidelines.