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

Question

Aleks Bass · Accepted Answer

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.

Lizzy Masotta · Answer

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.

Mike Flouton · Answer

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.

Related Ask Me Anything Sessions

Shopify Senior Product Lead, Lizzy Masottaon Product Development Process

Barracuda VP, Product Management, Mike Floutonon Product Development Process

Momentive Vice President Of Product Management, Aleks Basson Product Development Process

Related Questions