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.
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 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.
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.
