Structured Thinking in Product Management
--
Product managers are continually being asked to solve problems. It’s arguably our job. For many of us, stakeholders come to us every day with requests like “add this integration,” or “build this feature.” This is where the minefield lies — you must be able to sift through the never ending sea of opportunities, symptoms, problems, and solutions to 1) understand the real problem/opportunity 2) evaluate if it’s a problem/opportunity worth solving and 3) be effective at developing solutions that deliver results. It can be daunting.
In this post we’ll cover the following topics:
1. Prioritize your time and make better decisions2. Scope the problem/opportunity
- Symptoms
- Success
- Constraints
- Actors3. Frame the problem
- Question burst
- Constrained questions4. Decompose the problem
- Create an equation
- Behavioral pressures
- Jobs to Be Done
- User Interviews5. State your hypothesis
- Uncover implicit assumptions6. Identify and manage risks
- Four types of risk
- Conduct a premortem
- Reduce risk with cheap tests
The goal of this post is to extend the same rigor and structure that OKRs provide for high-level organizational thinking all the way down to decomposing and solving individual problems. I recognize this is far from an original idea, however, I strongly believe there is value to adding structure to this process.
1. Prioritize your time and make better decisions
I’m not going to try to tackle the entire product prioritization topic in this post; there has been plenty written on this already. Instead, I want to call out the silent killer of product managers — decision fatigue. We are responsible for making so many decisions, we just cannot afford to be hyper-rigorous with every single one.
Before deciding to even make a decision, ask yourself the following questions:
- Is the decision easily reversible? Imagine if you try something and you don’t like the outcome, can you easily change course and try something else? Jeff Bezos famously refers to decisions with a low cost to quit as two-way-door decisions. If you can take multiple bites at the apple with little cost, don’t spend much energy here.
- What is the magnitude of the decision? Even if you make the wrong call and can’t try again, what is the worst-case scenario? If the potential downside is limited (including opportunity cost), it is likely not worth spending a lot of time making the decision.
- Will the outcome of this decision help your team accomplish its stated goals? If not, deeply consider why you are making this decision in the first place.
- What information would you need to improve your decision quality? Is it possible to get this information? If so, how much effort/time would it take? It’s tempting to wait for more information, but time has a real cost that must be accounted for.
I recognize it’s slightly ironic that I’m advocating for spending additional time evaluating decisions before making decisions. I argue this deliberate consideration helps fight the natural tendency of focusing on the most well understood problems instead of the most valuable.
Additional resources
- Making Good Decisions as a Product Manager
- Gokul’s S.P.A.D.E. Toolkit: How to implement Square’s famous decision-making framework
- Product strategy means saying no
- How we make decisions at Coinbase
2. Scope the problem/opportunity
Note: This section is likely very obvious to many, however, I think it is important to explicitly state it as I have seen too many problems arise because people were not aligned on the fundamentals.
Sometimes the first question that should be asked is not what is the problem, but instead, do I know enough to state the problem? Before diving in, ensure you can clearly describe the issues (or what I refer to as symptoms) arising due to the problem/opportunity, articulate what success looks like, understand the constraints you are working within, and precisely identify the various groups of people that you will need to work with. We go into more detail on each of these items below.
Symptoms
For every problem or opportunity, there are gaps between where you currently are (observation) and where you want to be (aspiration). These gaps represent symptoms of the broader, to be determined problem. It sounds simple, but being able to clearly articulate symptoms is really important part of the process.
A few tips to consider when identifying symptoms:
- Interpretations are not symptoms. For example, someone may say the user interface is confusing. This is not a symptom — it is someone’s interpretation of a more foundational issue. It’s important to distinguish a symptom from an interpretation because if you take the interpretation at face value, you may be closing off other potential explanations.
- Be specific and ask why now. It’s impossible to solve vague issues with massive scope. To combat this, ensure symptoms are clearly defined and timely. If the stated distance between reality and aspiration is an eternal problem, like “we want to make more money,” it is too vague of a symptom to be actionable.
- Consider external/environmental factors. You are not operating in a vacuum — it’s important to be mindful of how changes in the environment may be causing symptoms or creating opportunities.
Success
It’s difficult to solve a problem if you’re not clear on what success looks like. Asking the following question is helpful technique to ensure your team is aligned you don’t fall into the trap of defining the problem with the solution.
We are in the future and this project has been a great success. What is the date, and what do we see?Figuring out how to measure success can be difficult. One helpful technique is the Crystal Ball Test, where you ask If I could know anything about how people are using my product, what would I want to know in order to tell me whether or not my product was successful? Think about how people would be benefitting vs the current baseline - what would be the observable byproducts of this improvement? Follow the value.
Constraints
It’s important to be clear on the box you are operating within so you understand the limits when exploring solutions.
- How much time do you have? What’s the reason behind the deadline?
- What resources are available?
- What is the appetite for risk when developing a solution?
- What are the constraints on the success metrics?
For the last point, the concept of counter-metric guardrails is helpful. For example, you could improve your signup conversion rate by halving the cost of your product, but is this realistic? Having these discussions early will help clarify boundaries and understand what tradeoffs are acceptable.
Actors
From end-users to stakeholders, it is important to be clear on:
- Who is experiencing the symptoms
- Who is responsible for the various aspects of the project
- Who is ultimately accountable for success (Hint: it’s probably you, the PM.)
- Who should be consulted and who needs to give approval when developing the solution
Once you’ve gathered as much of this information as possible, review it with your team to ensure everyone is aligned. There will likely be areas that you don’t have total clarity on — this is expected. You now have explicit known unknowns rather than implicit assumptions.
3. Frame the problem
A lot of times the question is harder than the answer. And if you can properly phrase the question, then the answer is the easy part.
- Elon Musk
Framing the problem is one of the most important steps you make when trying to solve a tough challenge, yet it is often overlooked. Have you ever had someone surprise you by asking what in hindsight seemed like an incredibly obvious question that dramatically shifted the way you approached a problem? This is the power of a good frame. These ‘catalytic’ questions can reveal blindspots and open new paths to explore.
There is a natural tension between narrowing the frame to create focus versus widening the frame to encourage creative solutions. Part of this tension should be resolved by discussing constraints with the broader team when scoping the problem. However, it’s important to consider that focus is powerful for analyzing options, but terrible for discovering them. The general rule of thumb is to keep the frame as wide as possible in the early stages of problem exploration.
Below are a few techniques that can help you uncover catalytic questions that may change the way you approach a problem.
Question burst
In Hal Gregersen’s book Questions Are the Answer, he proposes gathering a cross-functional group of stakeholders and providing them with a high-level overview of the problem (symptoms, success, constraints, actors). Instead of having the group brainstorming solutions, get them to brainstorm questions. What would they want to know in order to solve the problem? What questions do they have about the assumptions that are implicit in the problem? While many of the questions will be obvious, a few will likely jump out and cause you to think about the problem in a different light.
Constrained questions
Think of the problem space you are operating in. There are probably dozens of questions that you would like to have answered. Now consider what question would be the most important to have answered in order to effectively solve the problem. If you could only ask 2 questions, what would they be? Doing this thought exercise forces you to think deeply about what is really important. What you’ll often find is that by answering one really good question, many other questions will also be answered.
Additional resources
4. Decompose the problem
Now that you have the problem scoped and framed, it is tempting to dive in and start coming up with solutions. However, it is important that you take the time to decompose the problem via multiple perspectives so you can identify the individual components and understand how they impact the whole.
There is not a one-size-fits-all approach for breaking down a problem and the nature of your problem will dictate what makes the most sense. Below are a few starting points that I have found particularly helpful.
Create an equation
Your product team is (hopefully) already working with analytics, so this should be an easy way to break a problem into smaller parts. Try thinking about the space from a business metrics perspective (revenue, churn, LTV, etc.) and a user behavior perspective (user goals, key actions to achieve the goals, and metrics associated with these actions).
For example, when I was getting up to speed as a product manager at NBC News, I created this equation to represent the fundamentals of their affiliate commerce business:
Total affiliate revenue = Page views per article X Revenue per article X # of articles published
Once you have your first pass at an equation, the next step is to deconstruct each part into its smaller sub-components (example below). You can use this to get a sense of how the various levers of the business and product interact. It also allows you to understand the potential impact of making improvements to different parts of the product — some will likely have much better potential for ROI than others.
Behavioral pressures
When you boil it down, solutions are often just creating a behavior change in a group of people. People are currently doing X, and we want them to do Y. In Matt Wallaert’s book Start at the End he outlines the process of breaking problems down via the lens of behavioral change and pressures — the factors that cause a behavior to be more or less likely.
To do this, try writing a behavioral statement. A behavioral statement is a description of the world we are trying to create, written from a user behavior perspective (very similar to a user story). A simplified, “mad-libs” version of a behavior statement is:
When [population] want to [motivation], they will [behavior] (as measured by [data]).
- Population = Group of people whose behavior you want to change.
- Motivation = Why are people engaging in this behavior? What is driving them to do it? What job are they hiring your product to do?
- Behavior = What is the behavior you wish to see change?
- Data = How will you measure the behavior?
An example of this would be When business professionals in NYC want to get from point A to point B, they will take a Lyft (as measured by rides).
Once you have your behavioral statement, work with your team to come up with ideas for:
- Promoting pressures = what would encourage the desired behavior?
- Inhibiting pressures = what would discourage the desired behavior?
Many of the ideas your team comes up with won’t be relevant or will be outside of your ability to influence — that’s okay. There will likely be a subset that are insightful and cause you to consider the problem from a different perspective.
Jobs to Be Done
Similar to thinking in terms of behavioral change, you can think of problems through the lens of Jobs To Be Done — a framework developed by the Clayton Christensen. What job is the user hiring your product to accomplish? What is motivating the user to do this job? This macro-level perspective can be helpful to employ if you are getting stuck in the weeds.
User Interviews
Analytics will tell you what, but they won’t tell you why. For that, you’ll need to gather qualitative feedback. Here are a few tactics to help you develop a deeper understanding of the problem:
5 Whys — It’s tried and true. For each of the symptoms listed in the problem exploration step, try going through 5 whys exercise with the various actors. The number of whys is not important, it’s just a guide to help you peel back the layers of the onion and understand the root cause of a symptom.
Mom Test — Rob Fitzpatrick outlines this process in his book by the same name. It’s essentially just a focused user interview — named because moms, who love and support their children, are likely to give encouraging answers that may lead you down the wrong path. With Fitzpatrick’s guidance, the reader learns how to ask questions that even a mom would answer honestly. The core principles of the Mom Test are:
- Talk about their life/experiences. Do not talk about your ideas for solutions or your perspective on the problem.
- Ask about specifics in the past instead of generics or opinions about the future. People are often terrible at accurately predicting their future behaviors.
- Talk less and listen more.
Regardless of the technique used for these conversations, try to tease out the following information:
- How are users behaving today?
- What’s influencing the options they perceive and the actions they take?
- What is frustrating and/or motivating the user?
- How are users currently making decisions, spending their money/attention, and ultimately, determining value?
The most important thing to keep in mind when talking to people about problems is the idea that you aren’t allowed to tell others what their problem is, and in return, they aren’t allowed to dictate the solution. In the common situation they do try to give you the solution, it’s up to you to understand the rationale behind their suggestion. They own the problem, you own the solution.
5. State your hypothesis
A great many people think they are thinking when they are nearly rearranging their prejudices.
- William James
Anytime a product manager wants to create or change a product, they are doing it because they think it will cause something to happen. They have a hypothesis, even if it’s not written it down. All too often people have nebulous ideas of problems, opportunities, and solutions, but they don’t take the time to clarify exactly what it is they are stating or what must be true for their proposal to succeed. Writing a clear hypothesis and making its implicit assumptions explicit is vital to thinking clearly, uncovering biases, and creating alignment across your team.
In its most fundamental form, a hypothesis is just a clear proposition of expected cause and effect.
If we do X, then we expect Y to happen (as measured by Z).
Baked into every hypothesis are assumptions — they come for free! Unfortunately, implicit assumptions are frequently flawed but assumed to be true. The good news is it is often much easier to validate or invalidate your assumptions than it is to conduct an experiment on your original hypothesis.
Uncover implicit assumptions
To uncover implicit assumptions, ask yourself What would have to be true for the proposal under consideration to work out fantastically?. For example, imagine we have the following hypothesis:
If we implement Apple Pay in the checkout flow, then we expect more customers to complete checkout, as measured by checkout conversion rate.To go about validating this hypothesis we’d have to go through a proper experiment design process where we’d set success criteria, experiment duration, etc. and then actually build out the Apple Pay integration. What if before proceeding we spent time uncovering the assumptions that are implicit in the hypothesis? We’d realize our hypothesis contains the following assumptions:
- A meaningful portion of users trying to buy our product want to use Apple Pay during checkout.
- A meaningful portion of users that want to use Apple Pay are abandoning during checkout because their preferred payment method is not available.
With this clear understanding of assumptions you can then start thinking about how to identify risk and create cheap tests to derisk early—more on this below.
6. Identify and manage risks
The process of creating new features or products can be risky business. Risks are not inherently bad, but they are something that product managers need to ensure are understood and managed.
It can be tempting to always try to minimize risk; this can make sense under some circumstances. For example, optimization can be a low-risk, high-reward activity. However, eventually you’ll reach the point of diminishing returns and then you’ll need to enter the uncharted world of creating something new.
Four types of risk
The first step to navigating the world of product risk is being able to identify all of the different types. Marty Cagan has this great framework:
- Value risk — Will people find the thing we are proposing to build useful?
- Usability risk — Will people be able to figure out how to use it?
- Feasibility risk — Can we actually build the thing we want to create given the resources available? This encompasses technical risk and delivery risk.
- Viability risk — Does this product/feature make sense for the business? Is there an appropriately sized market for it?
As a product manager, your primary responsibility is going to be owning value and viability risks, however, to get the best results from your team you need to ensure you’re empowering designers and engineers to contribute in all areas. One helpful technique for this is a premortem.
Conduct a premortem
A premortem is a tool developed by Gary Klein to help teams identify risks and create alignment at the start of a project. To do one, gather your cross-functional team and ask them to imagine it’s the day after the target launch date and things have not gone well. From the perspective of this imaginary future, have each person independently write up to five reasons things did not go well that were due to the actions or decisions of the team. Separately, list up to five reasons that things failed due to things that were outside of your control. Finally, ask the team to try to identify the biggest unknowns (obviously these are not easy to predict, but worth the discussion).
If you want to learn more about how to run an effective premortem, I highly recommend this article by Shreyas Doshi.
Reduce risk with cheap tests
Risk is caused by uncertainty about what will produce the desired outcomes. The definitive way to reduce uncertainty is by shipping a new feature or product and measuring its impact — but this is expensive. Time and opportunity costs are maximized when product teams rely on shipping the end product as their primary method for ‘testing’ if it will produce the desired results. We all know the concept of the MVP, but an arguably more helpful concept is the RAT — Riskiest Assumption Test.
For each of the risk types listed above, there are often experiments that can be run with relatively little cost to get information quickly. While these experiments will not give you definitive answers, they can provide directional feedback that can be used to decide if additional investment or course correction is needed.
In the earlier example about implementing Apple Pay to improve checkout conversion rates, we identified the two assumptions implicit in the hypothesis were:
- A meaningful portion of users trying to buy our product want to use Apple Pay during checkout.
- A meaningful portion of users that want to use Apple Pay are abandoning during checkout because their preferred payment method is not available.
Both of these assumptions must be true for the hypothesis to be true. Knowing this, we could easily turn these assumptions into their own hypotheses and create a quick experiment to understand 1) what percentage of users would select Apple Pay in the checkout flow if it was an option and 2) what percentage of these users would decide to abandon when they discover that clicking on Apple Pay leads them to a ‘coming soon’ prompt.
This is an example of a ‘painted door’ test, but there are many other types that exist depending on your specific situation. Tristan Kromer from Kromatic has created a fantastic (and free) resource called The Real Startup Book that provides a comprehensive guide on cheap tests to derisk products.
To help clarify what you need to learn to reduce risk, he breaks things down into quadrants:
- Market questions vs product questions — Do you need to learn about the market/customers/pains or the product/value proposition/solution?
- Generative questions vs evaluative questions — Do you have a falsifiable hypothesis to test, or do you need to generate a clear idea?
Each of the question quadrants is matched with multiple cheap to run experiments and detailed instructions on how to run them.
I highly recommend this resource as it has a wealth of information from some of the best minds in product.
Phew — if you’ve made it this far, thank you! Writing this was really helpful for me to solidify some of my own product thinking. I hope this post has given you inspiration on areas for improvement with your own product development process. If you have any thoughts or feedback, please reach out or leave a comment.
