Data & Insight Archives - The P-Zero PM - Tips and Tools to Ensure a Successful Start to Your Product Management Career

Progress vs. Perfection: Bugs & Edge Cases (The Trade-off Series Part 1)

Joseph Akoni — Mon, 26 May 2025 22:13:48 +0000

This is the first installment of the Trade-off Series, where we compare two aspects of product management and give you actionable frameworks for determining how you can more easily approach the trade-off and make the best decision for your situation.

I know you’ve heard the phrase “perfection is the enemy of progress,” and you’ve probably said to yourself, “I don’t even know what that means.” But guess what?

That’s right … it gets the people going!

My problem with the phrase is that the person who says it usually never explains what it means or takes the time to give actionable tips on HOW to not make perfection the enemy of progress.

But like the great philosopher-turned-NFL legend, Marshawn Lynch, once famously said, “I’m just about that action, boss.” So despite others not giving you actionable tips to approach the perfection vs. progress trade-off, I will do just that. The goal of the Trade-off Series is to provide actionable frameworks for handling common trade-off scenarios.

There are two scenarios that normally force us to make the progress vs. perfection trade-off in product development:

Scenario 1: A newly uncovered edge case or bug introduces unexpected requirements.

Scenario 2: An overly optimistic PRD (usually for an MVP) forces the team to re-prioritize features because everything can’t be built in the allotted amount of time.

For this article, we’ll focus on #1, and I’ll delve into #2 in a future article.

To set the foundation for the framework that will guide us in handling edge cases and bugs, let’s first define perfection and progress.

If you want to skip the foundational framing, you can get straight to the action (although you’ll regret it because there are more Marshawn Lynch quotes, and we stan for a Marshawn Lynch quote.)

Defining Perfection and Progress

Below is a flowchart explaining how we get to the states of perfection and progress (because if you’ve read any other article here, you know I love flow charts). In summary, a PM’s principles guide a set of actions that lead to the end states of perfection and progress.

The foundation of our framework lies in the principles, so let’s uncover those for both the perfection and progress end states.

The principles of perfection

A PM seeking the state of “perfection” is attempting, for that single upcoming iteration, to solve everything that could possibly lead to a negative user experience. No edge case is left unresolved. Every issue is fixed.

I refer to the mindset of proactively eliminating all known risks as a “possibility thinking mindset” – i.e., if there’s even a small possibility that a user’s experience will not be ideal, then the risk causing that possibility must be removed. This approach is binary in nature and deeply risk-averse, focused on ensuring success by attempting to systematically remove every risk/concern. Emphasis on the word attempting … but we’ll get into that more later.

Perfection = Possibility thinking mindset. For each decision made in the product’s current iteration, if the possibility of a risk exists, the response must be to attempt to eliminate that risk.

The P-Zero PM

Going back to the perfection/progress end state diagram, let’s fill in the blanks for the possibility thinking mindset:

The principles of progress

For someone to seek the state of “progress,” it means that the “perfect state” is not attempted at every stop (like in the aforementioned possibility thinking scenario); rather, the “perfect state” is a long-term vision for the product. On the path to success, every known risk is not eliminated at every stop. The risks are acknowledged, and a probability-based assessment is conducted to mitigate critical risks to ensure the rate of user experience success outweighs the rate of user experience failures.

Here’s an example of what progress could look like when building a product.

Iteration 1 – This is good, I like … I like.
Iteration 2 – This is f*cking awesome!
Iteration 3 – Ummmmm, who said we should make that change? Oh sh*t … that was me?
Iteration 4 – This is f*cking awesome!

Here’s the stereotypical “path to success” chart that basically sums up what “progress” is:

I call the principle of acknowledging imperfection and mitigating its impact on your product “probability thinking mindset” — while assessing the impact of the risk, analyze the probability that the risk will significantly affect the experience for your target users and respond accordingly. When leveraging the probability thinking mindset, you will fix some issues and leave some as is. Either way, most of the user experience will be ideal, setting up your product for success in the long run, while enabling you to use every iteration as a learning opportunity to improve your rate of success.

Progress = Probability thinking mindset. For each decision in the current iteration, if a risk exists, leverage a probability-based assessment to analyze and mitigate critical risks to ensure the rate of user experience success outweighs the rate of user experience failures

The P-Zero PM

The philosopher-turned-National Football League legend, Marshawn Lynch, also eloquently explained the result of a probability thinking mindset when he said:

“I know I’mma get got, but I’m gonna get mine more than I get got, doe.”

For those who aren’t familiar with Shakespearean English:

Get mine = incrementally building the ideal user experience for your users
Get got = dealing with imperfections in your product

“Get mine more than I get got” = The impact of the ideal product user experience outweighs the impact of the product imperfections.

Poetry to my ears and a perfect explanation of the probability thinking mindset. The world needs more Marshawn Lynch quotes.

“Get mine more than I get got” = The impact of the ideal product user experience outweighs the impact of the product imperfections.

The P-Zero PM (and Marshawn Lynch) Tweet This

Going back to the perfection/progress end state diagram, we’ll see that we’ve broken down perfection and progress into the following guiding principles and actions:

This framing gives us our foundation for how to analyze the edge case and bug scenarios that we’ll dive into next.

Scenario: Case of the pesky edge case

What is an edge case?
In product development, an edge case refers to a rare or extreme scenario that occurs under uncommon or exceptional conditions. These cases often fall outside typical user behaviors but can still impact functionality, usability, or reliability.

Now, given the reframing of perfection and progress as noted above, which should you choose when dealing with edge cases and bugs? In other words, ask yourself: What Would Marshawn Lynch Do? (WWMLD?)

That’s right … Marshawn would say, “Get yours more than you get got” (or “Have a probability thinking mindset”).

The goal should be to always leverage probability thinking for edge cases and bugs. Why?

Perfection is impossible: Because your product can always be improved. It will never be perfect (regardless of what your mother says about it).
You must show impact: There will be limitations in the form of time and/or people resources. It is your goal to maximize your product’s impact, so you will have to determine the right problems to fix at any given moment to create the biggest positive, immediate impact for your users while mitigating any negative impacts.

So now you’re probably wondering, “Where’s the action, boss?” What tactical steps can I take to execute my newfound probability thinking mindset? Let me introduce you to the Risk to Response Assessment Framework.

Risk to Response Assessment Framework

The risk to response assessment involves three key steps:

Step 1: Analyze the risk to users

Are these users that you are prioritizing currently?
- Note: If you’re dealing with a product that has some form of a marketplace (content creator vs. content consumer) and you have design/engineering resource limitations, at any given moment you may shift focus on who is “important” so your “core user group” can shift. You will prioritize fixes for the current core user group.
How critical is the bug or edge case to the core user journey that this user must complete?
What is the probability that it significantly impairs completion of that user journey?

Step 2: Consider situational factors affecting your team’s risk appetite.

How much risk can you take on (and subsequently endure) based on other factors? These factors are fluid and can change as new information is known. These factors can include:

- Is it an internal or external product? Internal users may give more grace to bugs than external consumers will.
- Maturity of your product (MVP vs v18147.1). You may be able to get away with a less polished product if it’s the MVP (and communicated as such).
- Your personality as a PM. Are you the “no risk it, no biscuit” type, or are you a bit more conservative in your product risk-taking
- Eng resources required. How resource-constrained is your team? How long is this fix expected to take?
- Company priorities. Fixing a bug is like an investment, and with any investment, it should map to what the company values most. A company that prioritizes quality and trust (like in fintech or healthcare) is more likely to fix even minor bugs that could erode user confidence. A startup prioritizing speed to market may tolerate rough edges to stay ahead. Companies prioritizing long-term scalability may fix bugs that contribute to technical debt.

Step 3: Determine an appropriate risk mitigation response based on 1 and 2.

The response can be finalized via various methods. Pick the one that you are most comfortable with and that can handle the various factors that you need to account for. A couple of popular decision methods include:

The 2×2 Opposing Characteristics Framework (more detail). The 2×2 decision-making matrix is a simple tool that categorizes options based on two key factors relevant to a decision, such as urgency vs. importance or risk vs. reward. By plotting choices into four quadrants, it helps clarify priorities and guide action based on what matters most in a given context.
Weighted Average Framework. The weighted average framework for decision-making assigns scores to each option based on relevant criteria, then multiplies each score by the importance (weight) of that criterion. Adding the weighted scores reveals which option best aligns with overall priorities, making complex choices more objective and structured.

The actual responses can be:

Doing nothing. Leave it be.
Mitigate risk completely. Fix it.
Mitigate risk partially. In this scenario, you would find a workaround that enables users to complete the user journey, but not in the exact way the user may have requested or expected. We’ll dive into these partial risk mitigation strategies in a different article.

Let’s explore examples of how we can leverage the three key steps above to come to a decision.

Note: In order to focus on the end result of a probability thinking mindset, I’ve oversimplified the following examples with respect to the factors that go into product decision making. Rarely is a single data point used to make a product decision. Consider all factors before making any product decision.

Example 1

You are the PM for a new cow video service called MooTube, where users share videos of their favorite cows. Pasture Prime is the incumbent and has gotten ahead of MooTube with respect to user adoption, so you have some catching up to do. There is a bug in the iOS app that causes the MooTube logo to inadvertently display at the beginning of all videos for exactly 20 seconds, and the “skip ads” button does not appear. That means users may be subjected to 20 seconds of the MooTube logo and up to 30 seconds of ads before they get to see a single black-and-white-coated animal. What do you do?

The factors in this example are fairly straightforward, so we’ll go with the 2×2 decision matrix to help us make a decision. Let’s map out the risk appetite on the y-axis and the user risk on the x-axis.

2×2 Matrix explanation

Note: The suggested responses can vary based on your unique situation, so use this as a guide and not Gospel.

Quadrant 1 (bottom left): Low risk appetite and low user risk
- Response: Lean fix because of the low risk appetite (i.e., you cannot tolerate much risk)
Quadrant 2 (bottom right): Low risk tolerance and high user risk
- Response: Always fix because of high user risk and low risk appetite
Quadrant 3 (top right): High risk appetite and high user risk
- Response: Lean fix because of high user risk
Quadrant 4 (top left): High risk appetite and low user risk
- Response: Lean don’t fix because of high risk appetite and low user risk.

Analyze risk to user:

User risk here is high. You’re a new service, needing to lure users away from the incumbent service, Pasture Prime. The last thing you need is for users to not be able to see the cows they’ve been dying to see for almost one full minute. By the time the logo and ad disappear, so will your early adopters. If there’s ever an edge case or bug that makes the product feel “broken” or unusable, it’s a clear sign that the user risk is significant and the negative impact needs to be mitigated.

Risk appetite:

Your personal risk tolerance is high. You’re the type to ask for permission later, but you realize MooTube must succeed because cow lovers are hard to herd back once you’ve lost them. Although this is the MVP (which means product teams usually can get away with non-ideal experiences), the risk to the user is high for this bug because it leaves a broken and unusable experience, so it is unlikely that your users will give you grace. You want to get your first moooovers udderly excited to use your product (Side note: My cow puns are on fire right now). Risk appetite here is low.

Response:

You end up in quadrant 2 (bottom right). Fix this now.

Example 2

You’ve launched, and your supply of cow videos is getting viewer traction nationwide, especially in core markets. You’re getting reports that a subset of users in rural Texas are having playback speed issues: With every new video viewing session, the playback speed starts at 0.75x. When the user updates the speed to 1.0x, the speed remains for the entirety of that session. Once the session is closed, the user must reset the speed to 1.0x again if they have another video viewing session. What do you do?

For this one, we’ll leverage weighted averages to make a decision. Let’s think about all the factors we’d have to consider. We’ll also assign a grade (0-5) and a weight (0-1) for each factor. The weights you assign to a factor depend on your team/company context but normally the user affected and the risk to user have the highest weight. Let’s assume that a cumulative score of at least 4 (when all factors are added together) means that the bug will be added to the priority list.

User affected – The core users at this moment are video viewers (your video supply is satisfactory and growing steadily, and you need to get viewership engagement up). Rural Texas contains a significant subset of your core viewers (Texas loves them some cows), so the grade here is a 5 (the high grade reflects the importance of the user affected).
- Grade: 5 (due to the viewers being core users)
- Weight: 0.4
- Score: (5) x (0.4) = 2
Risk to User – The risk to the core user journey of watching a video, to me, is pretty minimal. It is annoying that the user has to change the playback speed to 1.0x, but it only happens at the beginning of each session. I would rate the risk to user here pretty low.
- Grade: 2
- Weight: 0.4
- Score: 2 x 0.4 = 0.8
Expected eng/design resources required – You’ve mentioned this to your eng team and they said the fix should be completed pretty quickly, but you have more high-priority fixes that need to be tended to. The grade here is 5. The higher score means fewer resources are required (this factor is more heavily weighted towards fixes that are expected to be completed quickly).
- Grade: 5
- Weight: 0.2
- Score: 5 x 0.2 = 1

Total Score: 3.8. Doesn’t make the cut

Summary

In summary, we’ve:

Defined perfection vs. progress as possibility and probability thinking mindsets, respectively.
Analyzed that probability thinking is better than possibility thinking with respect to attacking bugs and edge cases because the goal is to ensure the rate of user experience success outweighs the rate of user experience failures (i.e., make continuous positive impact, not the perfect impact). This is a great lesson in product development and in life.
Introduced the Risk to Response Assessment Framework to assist in coming to a decision on whether to prioritize a bug or edge case.
And, most importantly, learned that we should always ask ourselves, “What Would Marshawn Lynch Do?” And then do what Marshawn would do.

The post Progress vs. Perfection: Bugs & Edge Cases (The Trade-off Series Part 1) appeared first on The P-Zero PM - Tips and Tools to Ensure a Successful Start to Your Product Management Career.

Why Your Data Scientist is Your Best Friend – The PM and Data Scientist Relationship

Joseph Akoni — Sun, 14 Feb 2021 02:20:10 +0000

We are back with another installment of the Best Friend Series at the The P-Zero PM.

Correlation, causation, confounding variables, confidence interval…confused? These are terms that will become more familiar as you interact with your next best friend…The Data Scientist!

By the way, I love alliteration, in case you didn’t directly deduce that in the previous sentence.

Am I right?

Ha! I’m here all night…leave the tips at the door!

Alright, back to the article…

Now, I know I have said that one of the most underrated best friends is the UX Researcher, but if there was a best friend that was a CLOSE second in terms of being underrated, it would be the Data Scientist. I say this because when people speak about the role of the data scientist, they usually relegate them to the stakeholders who simply take in data requests and send the requested data to the requester of said data. It’s as if data scientists simply service data requests like Lucille Ball on an assembly line trying to package chocolate coming down at an ever increasing speed.

I’m here to tell you that the data scientist is not ONLY here to service your data metric requests. Your data scientist is as much of a discoverer of information and problems as you are. They help turn a daunting amount of data into actionable and understandable insight. Additionally, your data scientist is the ruler of the infrastructure that supports the collection and monitoring of the data (i.e., the infrastructure that enables you to track your metrics). So, what are all the ways the data scientist (aka your new best friend) supports the entire product development process?

How does the Data Scientist support the product development process?

Validating the extent to which a problem currently exists – In the Why Your UX Researcher is Your Best Friend article, I detailed how the UX researcher assists the product manager in validating or refuting a product hypothesis through research studies. Your data scientist can also provide data to assist you in the validation/refutation process by letting you know how prevalent a problem is on the platform for your users. For example, let’s say that you expect a specific subset of your user base (e.g., users in Australia) is not using a specific feature you created for the entire member-base. You have a potential solution that will encourage the use of this feature by your Australian demographic but want to be 100% sure this problem explicitly affects the Australian demographic. Your data scientist can uncover usage for the specific demographic you requested and, in their investigation, can perhaps uncover other demographics exhibiting the same behavior of your Australian userbase.
Product Metric validation and consultation (Pre-Launch) – You’ve uncovered a problem and validated the need for a solution. You have mapped out a preliminary solution and its associated metrics. You have also worked with your engineers and designers to finalize what the actual solution will look like and how it will operate. At this point, you can (and should) consult your data scientist to answer the following questions:
- Are there any downstream metric effects that could occur after your feature is implemented? I.e., could your feature positively or negatively affect other core metrics or metrics of other teams’ products? As a new PM to the team, you won’t have a complete picture of the product ecosystem, so it’s best that you consult your data scientist to ensure you understand all of the potential downstream effects of your product.
- Are these the right metrics to even track? Just like the PM incorporates the expertise of the UX designer to finalize the product design and the expertise of the engineer to develop the technical infrastructure that will support the product, the PM should incorporate the expertise of the data scientist to ensure the metrics he/she will track are correct. It’s very possible there are other data contexts that may be missing in your analysis which would aid in determining the correct metrics to track. Additionally, the PM should confirm north star metrics and sign-post metrics (metrics that track your progress to potentially reaching your north star metric) with the data scientist. For more information on north star vs sign-post metrics, check out this article by Carl Anderson.
- Are these metrics actually measurable by the current infrastructure? If they’re not measurable directly, perhaps there’s a proxy metric to select that will tell the same story. If time permits, then perhaps your data scientist can set up the infrastructure to directly track the metric you desire.
- What is the pre-launch metric snapshot? Once you have finalized the metrics you will measure, you will want to get a snapshot of the current state to compare to the post-launch state to verify any metric increase or decrease.
Data infrastructure tutorial – Learning your company’s experimentation and database infrastructure will seem like a daunting task. Your Data Scientist can assist you in:
- Understanding all of the data sources available to you and how to access them – For instance, what portal gives you access to experiment results? Which portal gives you access to time-mapped values for team metrics? Where can you go if you wanted to get your hands dirty with SQL and which databases do you have access to?
- Understanding the experimentation tool -Your experimentation tool may not be the most intuitive to understand. You have to ensure the experiment control and treatment groups are defined correctly and that all other experimentation demographic values are set up correctly.
Product Metric validation and consultation (Post launch) – After product launch, your data scientist can help make sense of any confusing results. They have a solid foundation in statistics, so they can give insight into whether certain results are valid or should be taken with a grain of salt. In the case an unexpected metric is affected, they will help you build a case for why this result occurred.
Provide ongoing trend analysis in platform user behavior. Guess what? You have 3 products you’re coordinating with 3 different sets of engineers, designers, and marketers and you may not have the time to analyze current behavioral trends occurring in the ecosystem. Additionally, you weren’t hired for your SQL skills, so you probably couldn’t provide an adequate deep dive analysis even if you wanted to **shrug**. Your data scientist can assist by providing reports on how current user behavior is affecting the core metrics for your platform/product and uncover trends with a level of expertise that requires more than a basic grasp of SQL SELECT and WHERE statements. Their analysis on trends in user behavior can give suggestions on ways to facilitate positive user behavior or reverse negative behavior. This analysis can help spark ideas to improve your current products or develop a completely new product.
Assist with random data requests – FINALLY, what you thought the data scientist main role was: random data requests. Do you need to know how many users in Canada have filled out the last name field or clicked the “Follow” button between May 1, 2020 and August 20, 2020 at 1PM everyday on an iPhone 8 running iOS 12.2? Your Data Scientist can help you with that. My personal opinion is that I don’t think they enjoy these requests that much, but it’s a tough job and somebody’s got to do it. Well, they’re the only ones that can do it but damn do they make it look good!

Your data scientist is as much of a discoverer of information and problems as you are. They help turn a daunting amount of data into actionable and understandable insight.

The P-Zero PM Tweet This

How to continue to cultivate this relationship?

Be patient when requesting data. Upon receiving a request, your data scientist must sift through many datasets to find the exact data point you need. Now add your request to the many others they’re getting from various stakeholders in addition to completing their other tasks mentioned above. Yeah, relax.
Be open to getting your hands dirty with SQL – “Getting your hands dirty” could mean writing your own basic queries, which would require you to know names of all of the tables and their respective attributes. Getting your hands dirty could also mean simply asking your data scientist to send you the SQL code and you can execute it yourself. This will transfer the burden of executing the code and retrieving and organizing the data in a presentable fashion from the data scientist to you. This saves your data scientists time (which I am sure they’ll appreciate) but also gives you an opportunity to understand the schema of your infrastructure a bit more. SQL may seem intimidating at first, but trust me, once you start to pick it up, you’ll realize it reads just like a sentence. Mode has an absolutely amazing SQL tutorial that I highly recommend for all levels of learners.
Involve them early in your product metric definition process. Perhaps your product requires a metric that isn’t easily trackable given the current infrastructure. You want to be able to track your product’s success, right? Make sure you give your DS team an early heads up on the product and the potential metrics to ensure any infrastructure changes are planned for well in advance.
Attend as many DS insight deep dives as possible. This may sound extremely nerdy (blame my engineering background), but my favorite meeting of the week is the Data Science deep dive. It is the perfect opportunity to learn more about the process the data experts go through to uncover trends in user behavior. You also get an opportunity to learn basic to advanced statistics concepts. Recently during a data science deep dive, I learned about the Simpson’s Paradox. Fascinating material! If your data science team doesn’t do this on a cadence, I highly encourage you to encourage them to do so!
Spend time familiarizing yourself with the overall data infrastructure. This is a continuation of #2 above, but the more data you can pull yourself, the more your data scientists will love you because they can focus on the more complex tasks, and the more versatile you will be as a PM. Familiarize yourself with your team’s metric dashboards, which shows the current status of the most important team metrics. Also, familiarize yourself with how to configure these dashboards to uncover the data you need in the format you need it in. Do not get frustrated because familiarizing yourself with the data infrastructure will take some time. One tip is to take notes on everything you learn about how to access/use the data infrastructure. Another one is to bookmark all internal pages which give insight into how to use these same portals.

In Summary...

Data Scientist’s role? The data scientist is a versatile member of the Prod Squad that enables you to integrate data as seamlessly and efficiently as possible into your everyday product decision making.
How often will you interact with the Data Scientist? If I had a penny for every message I sent to a data scientist, I’d have approximately 1,348 pennies (give or take). Use their expertise early and often because it will make your life 10 times easier.

And here’s another comic to conclude the article….

Now that you understand the importance of data scientists, I assume your level of excitement is directly correlated to the fact that you read this article. Right?! Right.

Now go build great products with your new best friend!

The post Why Your Data Scientist is Your Best Friend – The PM and Data Scientist Relationship appeared first on The P-Zero PM - Tips and Tools to Ensure a Successful Start to Your Product Management Career.

Product Manager = Problem Manager? Where to Find Problems to Solve

Joseph Akoni — Fri, 11 Dec 2020 18:00:16 +0000

We’re taking a break from the Best Friend Series and exploring problem discovery!

As a product manager, one of your tasks is to manage the process in which problems are solved and not to solely focus on developing the solution. Aditya Kothadiya put it perfectly when he stated in his Medium article that Product Managers should be Problem Managers, not Problem Solvers:

Product Managers shouldn’t be problem solvers. Their focus should be to:

Identify the right problems their company and team should solve

Prioritize which problems to solve first and which can wait until later

Communicate the rationale behind these decisions to their team and other stakeholders

In terms of the actual development of the solution, you must work with and leverage the expertise of your Prod Squad to finalize how things will be built:

Your designer will use their expertise to determine the arrangement of buttons, text and toggles facilitating the user’s efficient completion of the product experience (as noted in Why Your UX Designer is your best friend)
Your engineer will analyze the product requirements to scope the engineering resources needed to build out the engineering infrastructure to support the product solution.
Your data scientist will help in determining the right metrics to monitor and in ensuring the data analysis tools can collect and display these metrics upon launch.
Your product marketing manager will work with you to communicate the goodness your members can expect once they interact with the feature.

Great! Now you clearly understand everyone’s role in the problem-solving process. This article is going to focus on that first bullet of Aditya’s article: Identifying the right problems that your team should be solving.

You may be asking yourself, “Where do I begin with identifying the right problems that my team should be solving?” If you don’t have a user problem to solve then your development team can’t even come up with a solution!

Well my friend, I’ll give you a few tips on how you can do just that. That’s what I’m here for so stop biting your nails!

Let’s break down what it means to identify the right problem. In order to know if a problem is the right problem, you must:

Identify a problem. At this point, you are simply trying to figure out what member pain points even exist.
Determine that it is the “right” problem. After identifying a potential member problem, you need to then more deeply investigate and validate this problem to see if this is something that your team should solve.

I’ll go into detail on what these two steps entail.

Identifying a Problem

In order to facilitate your understanding of where problems can even be found, I’m going to introduce a high-level view of the product development funnel. Once we understand the various steps in the product development funnel, we will be able to determine at which stages problems can be uncovered.

Product Development Process

Organized Discovery – Actions that fall within the organized discovery category include explicit member outreach or planned brainstorming sessions. The purpose is to search for qualitative or quantitative data related to a customer pain point (and its subsequent product) that you want uncover. This can take the form of UX Research interviews or marketing surveys. These actions can also include “How Might We” Ideation sessions which help facilitate the problem discovery and idea generation process.

Define and Validate Problem – After you have completed the organized discovery stage, you will be more clearly defining the problem that you discovered and potentially a high level view of what a solution could look like. You also need to validate that the pain point does indeed exist for your members.

Design Solution – At this stage you work with your Prod Squad to design your solution. The design portion involves all aspects of the product:

UX/UI
Engineering Infrastructure
Marketing Plan
Metrics and Data Tracking plan
Legal concerns and UX Copy are also included here

The solution can be just the MVP or MVP and its subsequent iterations.

Develop – This is when all aspects of the product that have been designed are built.

Deploy – Fairly self-explanatory. At this stage, you launch your product and see how people interact with it.

Assess– After launching, this is where you analyze the success of the product launch. The assessment can come in both qualitative (metric analysis) and quantitative (customer feedback) forms.

Iterate (Decision Diamond) – At this stage you combine the insight from the assessments you have made after launching with your original product plan to determine the best path forward for your product (if iteration is necessary)

Great, Joe. You’ve now introduced me to yet another version of the product development process (which is probably the 10th one I’ve seen online) but I am still unclear on what aspects of the process facilitate the identification of a potential problem to solve!

Okay, let’s get to it…

Let’s dive into where in this timeline you can identify problems. Below you’ll see the timeline with the areas where problems can be identified, which are highlighted in orange.

Where can problems be identified?

Organized Discovery

This is definitely the most obvious portion of the timeline in which problems can be identified given the goal of this stage is to actively and deliberately seek out problems to identify through interviews, surveys, focus groups, or brainstorming sessions.

Deploy

At this point in the process, you are seeing how people are interacting with your product. One fool-proof way to find a potential future problem to solve is to see if people are hacking your product to create their own solution. “Hacking” in this sense indicates that a member is using your product for a purpose outside of the purpose that you intended for the product.

For example, if you created a product to enable members to keep track of their daily tasks by creating short bulleted lists but noticed some members were not only writing tasks but also writing due dates at the end of each task. At this point you think, “Hmmm…if every member adds dates in their own way, this will create inconsistency in our understanding of the data but also puts more strain on the member to then add the information to their own calendar. Maybe we can add our own calendar to ensure consistency in date additions and/or perhaps integrate the calendar of the member’s choice (Google Calendar, Outlook, etc.) with our product so they can see the task as they scroll through their daily agenda.”
Another real life example I recently came across at work includes how members interact with the experience section of their LinkedIn member profile. The purpose of the experience section is to highlight any work-related experience a member has (including accomplishments, responsibilities, location, company, etc). During research I was conducting for international members, I stumbled upon another use case: members were entering in non-work related experiences in their experience section. These non-work experiences included maternity/paternity leave, gap year, military service, general unemployment, and sabbaticals. When trying to uncover the actual pain point that members were indicating by hacking their profile, I worked closely with my UX Research counterpart (the regal and magnificent Renee Reid) to answer the following question: What goal do members want to achieve by entering in these non-work experiences and how can we facilitate the addition of these experiences in a way that enables members to fulfill these goals?

Assess

At this stage, your product is out, your members are interacting with it, and your platform is collecting data (both qualitative and quantitative) on member usage.

1. 1. Quantitative Data Assessment – You can work with your data scientists to analyze trends in user behavior (i.e. how are specific user segments interacting with the various aspects of your product? Which aspects are underutilized/overutilized? Does this match your expectations?) You can then use this data to devise product changes to further encourage positive user behavior or change negative behavior.
  2. Qualitative Data Analysis – You can work with your customer operations team to get direct quotes from members regarding their use of the product. Your customer ops team will track positive/negative feedback and track trends in member complaints to give back to the product team in order to continue to improve the product.

One fool-proof way to find a potential future problem to solve is to see if people are hacking your product to create their own solution.

The P-Zero PM Tweet This

How to determine that it is the right problem to solve?

Amazing! You've found a potential member problem. How can you ensure that this is the RIGHT problem to solve?

Let’s say you feel you have uncovered a potential member problem that could meet your company’s threshold for attaining engineering/design resources. The next step is to ensure that this is the RIGHT problem to solve. What’s next?

Sidenote: There are many criteria that determine whether a problem is the right one to solve including company/team strategy, timing, available resources, problem validation, etc. Delving into all the various criteria would require an article in itself (which I’ll write at a later date). For the sake of simplicity for this exercise, we’ll assume we will be focusing solely on problem validation and all other criteria (company/team strategy, timing, resources, etc.) have already been considered (i.e. For the remainder of this article, determining if the problem is the right problem simply means you will validate the problem through user experience research.)

As stated in the “Why Your UX Researcher is your best friend” article, you can work with your UX Researcher to validate your hypothesis to:

Ensure the pain point actually exists and gauge its severity.
Ensure your high-level solution has a good chance of succeeding.
Gauge how the solution will scale across all member segments.

Remember the product development process diagram in the UX Researcher article? I’ve included it below for your reference:

The problem discovery process described in this post enables you to be that product manager with a hypothesis. Once you are able to identify a potential problem (and come up with a hypothesis you want to test), you can work with your UX researcher to validate the hypothesis to ensure you are solving the right problem (i.e. In the diagram, you’ll move from “I’m a product manager with a hypothesis” to validate/refute the hypothesis. You will then move to “completing your initial product designs” if the hypothesis/problem validation process goes well.

It’s beautiful how it all works together, isn’t it?

You now know a few ways to pinpoint member problems! If you have any suggestions for more to add, ping me at joe @ thepzeropm.com and I’ll add them to the list (along with attribution).

The post Product Manager = Problem Manager? Where to Find Problems to Solve appeared first on The P-Zero PM - Tips and Tools to Ensure a Successful Start to Your Product Management Career.

Why Your UX Researcher is Your Best Friend – The PM and UX Researcher Relationship

Joseph Akoni — Mon, 10 Aug 2020 14:00:00 +0000

This is the kick-off of the Best Friend Series at the The P-Zero PM. We will be deep diving into how the expertise of each member in your Prod Squad assists in creating amazing products, or in other words, why you should treat each expert as your best friend! If someone helps you succeed every time you release a product, they should automatically be your best friend, right? Well, at least at work anyways.

Excited to meet your new best friend?! Your first best friend is the User Experience (UX) Researcher!

“You think you know…but you have no idea…”
–The diary of a UX Researcher (referring to a product manager)

Did I just date myself with that MTV Diary reference? I probably did…

Anyways…

I gave a brief overview of the role of a UX researcher in the Prod(uct) Squad article. But for those who didn’t read it:

Go back and read it.
Continue reading this article.

The UX researcher is the First of Her Name, Investigator of User Behavior, Knower of Consumer Insight, Objective Influencer of Product and Design Decisions.

How does a UX Researcher influence product and design decisions?

The last title “Objective Influencer of Product and Design Decisions” is probably the title that UX researchers feel is most important. Let us dive into how a UX researcher influences product and design decisions. Let us assume we have this overly simplified product development process below (Note: There are many ways in which a product manager may come up with a hypothesis or problem to solve. I’ll cover that in another article titled “How do product managers find problems to solve?”)

Amongst other job duties, UX Researchers help product managers validate product design decisions at two important stages in the product design pipeline ( i.e. the orange states in the diagram above):

Validate/refute product hypothesis – You, the PM, have a hypothesis that you want to test. For example, you may think that changing the layout and copy of the sign-up page will result in an increase in member registrations, as you feel the current copy doesn’t truly resonate with members. Your UX researcher can conduct a study, in which she interviews a subset of your target audience, composed of members who would sign up for your service, subsequently allowing them to determine if this is worth investigating. She will ask members questions to uncover how they perceive the member registration page and how the current layout and copy affects their decision making. This research will tell you if the problem (registration page issues) truly exists in the first place.
Validate product design – Let’s assume you have already validated your hypothesis and your UX researcher has deemed it worth creating a solution for. You have worked with a designer to come up with an initial solution. Before you release it publicly, however, your UX researcher suggests that she conduct a user concept test to see if the new design resonates with members of your target audience. This concept test will give you initial insight into whether your solution will actually fix the problem.

Three things to note:

Though UX research helps validate problems, it does not give solutions to the problem. You, the PM, develop the solution. Your members will not tell you how to solve the problem. Instead, they will confirm or refute that the problem exists.
This insight is not certain. That is, it is not going to tell you whether the solution will succeed or fail because you are only speaking with a subset of your target audience. Do not treat it as something to follow with complete certainty. There will be people in the study with whom your product does not resonate. Work with your researcher to understand which insight to either latch onto or to take with a grain of salt.
If possible, get your UX researcher involved as early as possible in the product development process (even when developing your hypothesis). The UX researcher may have insight that will guide your hypothesis creation.

Though UX research helps validate problems, it does not give solutions to the problem. You, the PM, develop the solution.

The P-Zero PM Tweet This

What happens during a UX research study?

During UX studies, researchers deep dive into the user psyche to understand their thoughts as they interact with the product. UX researchers know the nuances required to lead interviewees into answers that are genuine and honest. This helps you as a product manager know:

What copy or imagery resonates most with members.
What user workflow (i.e. series of steps needed to complete a task) work best for your targeted members.
How to arrange this series of steps.

UX Researchers are trained to know:

What questions to ask.
When to ask questions.
Who you should be asking questions to.
How to ask questions – Note: Presenting UX study participants with a “Did you like it? or naw?” is not the right way to gain deep user insight.

There is an art to not leading someone into an answer. The UX researcher is Mozart with the questions.

There is an art to not leading someone into an answer. The UX Researcher is Mozart with the questions.

The P-Zero PM Tweet This

You may meet a PM who downplays the importance of user research because he trust his “gut instinct” more than UX research data. Well to that PM, I say SHAME! SHAME! SHAME! **rings bell**

Our egos can get in the way of the cold hard facts. Your idea may be terrible. It’s okay. I’m 99.28% certain Andre 3000 was speaking about a product manager when he wrote the chorus to “Roses”. UX researchers are here to let you know that your roses really smell like boo-boo, so use their customer insight (i.e. soap) to clean up your product and make it presentable for your users.

You aren’t perfect. Every idea you generate will not be perfect. Michael Jordan didn’t hit every shot he took, but with every miss, he learned something new to ensure the miss didn’t happen again.

“You think you know...but you have no idea...” The diary of a UX Researcher... (probably referring to a product manager)

The P-Zero PM Tweet This

Why is the UX Researcher your best friend?

In summary, the UX Researcher conducts user interviews in a way that generates genuine and honest feedback from your target audience. They are meticulous in ensuring the data is objective and interpreted correctly. This meticulous search for rich member intelligence will guide you as you:

Validate your product hypothesis to verify you are building a solution for a problem that actually exists.
Validate your product design decisions to verify that your solution (whose problem you have already validated) will resonate with your members and solve the problem you intend for it to solve.

How do you continue to cultivate this best friend relationship?

Volunteer when user study research is happening, ESPECIALLY if the research is for your product. Your UX researcher is helping you attain data so you can create the right solution that solves the right problem. Volunteering can be simply listening, or actually taking notes during a session. I would recommend doing both. Even if the research study is not for your product, sit in and take notes. You’ll get a better understanding of how the Mozart of Questions works.
Have a new product idea? Run it by your UX researcher. They may already have data that will help you validate the problem and/or solution. If they don’t have data, resources permitting, they may be able to set up a user study session to get the data you need. They may also be able to sneak your questions into an already scheduled session (if the topics are related, of course).
Interview customers yourself! You may be given the opportunity to speak directly to customers. Use this opportunity to put on your UX Researcher hat so you can understand the skills necessary to unearth insight from customers. This will help you gain empathy with their role, which in turn, will help you gain more respect for your new best friend. More importantly, your best friend will also gain more respect for you!

Next time you see your UX researcher, appreciate her, give her a hug, ask her how her day was (but don’t use leading questions) like a best friend would!

The post Why Your UX Researcher is Your Best Friend – The PM and UX Researcher Relationship appeared first on The P-Zero PM - Tips and Tools to Ensure a Successful Start to Your Product Management Career.