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.

[VIDEO] Joseph Akoni speaks about how to use effective communication to facilitate product development with product community and consultancy group, Product People

Joseph Akoni — Fri, 26 Mar 2021 23:45:39 +0000

On 3/16/2021, Joseph Akoni spoke with Product People about the importance of using effective communication to facilitate the product development process. He dives into tools that any PM can use.

The post [VIDEO] Joseph Akoni speaks about how to use effective communication to facilitate product development with product community and consultancy group, Product People appeared first on The P-Zero PM - Tips and Tools to Ensure a Successful Start to Your Product Management Career.

[VIDEO] Joseph Akoni speaks about the intersection of product and culture with Derek Russel, creator of The Data Binge Podcast

Joseph Akoni — Tue, 16 Feb 2021 01:12:32 +0000

On 1/14/2021, Joseph Akoni spoke with Derek Russel, creator of The Data Binge Podcast to discuss the intersection of product and culture. They touch on the importance of understanding how culture affects what product you develop and who you develop it for. Full video is below!

The post [VIDEO] Joseph Akoni speaks about the intersection of product and culture with Derek Russel, creator of The Data Binge Podcast appeared first on The P-Zero PM - Tips and Tools to Ensure a Successful Start to Your Product Management Career.

The Product Development Team aka The Prod Squad

Joseph Akoni — Mon, 15 Feb 2021 08:00:28 +0000

Who’s your favorite ensemble of super heroes? The Avengers? The Power Rangers? Voltron? Or even The Care Bears? I won’t judge you. Everyone likes The Care Bears.

Whoever your superhero group of choice is, you always have to maintain faith that they can overcome any challenge. It doesn’t matter if that challenge is taking down the supervillain who could destroy the world with the snap of his fingers or making the world a place filled with people who care. Another team of superheroes that you should ALWAYS have faith in is your Product Development Team better known as The Prod Squad. Product challenges will always arise (before, during, and after release) and you must have faith that your team will always survive.

Who can you expect to be on your Prod Squad?

Your Product Squad is composed of individuals with a very particular set of skills. Skills they have acquired over a very long career. Skills that make them a nightmare for user problems like the one you’re facing at work right now. (Liam Neeson voice)

Introducing…The Prod Squad:

DESIGNER

Designer – The designer is the expert in analysing how human psychology affects the way members will interact with the layout and design of your product. In other words, they know what buttons, configurations, layouts, etc. will be easier for your user to interact with to ensure they get the maximum value out of your product. Good designers turn your vision into a mockup that works for your members. Great designers work with you to create the visual representation of that product vision to ensure design considerations are taken into account, reducing design cycles and maximizing member value.

ENGINEER

The engineer is the expert in understanding the architectural and technical requirements necessary to turn your product into reality. If you didn’t know, three things in life are certain: death, taxes, and architectural limitations that force you to rethink how you will execute your product strategy.The engineer will give you details on architectural limitations that may alter how you execute your product that may increase/decrease your execution timeline. A good engineer tells you those limitations and simply creates the quickest workaround. A great engineer works with you to overcome those limitations while still giving members the same value they expected from the original idea. Sidenote: Having doubts about how your (lack of) technical expertise may affect your success? Check out “How technical do you have to be? (Engineering)” for tips on how to be technical enough and for reassurance that you will be just fine.

"Three things in life are certain: death, taxes, and architectural limitations that force you to rethink how you will execute your product strategy."

The P-Zero PM Tweet This

USER EXPERIENCE (UX) RESEARCHER

The UX researcher is the expert in asking prospective users of your product the right questions at the right time to validate your product hypothesis or even your product design. UX researchers know the nuances required to lead interviewees into answers that are genuine and honest. The UX researcher will tell you whether you are actually on to something when you claim you have the next greatest idea. I tend to think product managers underutilize the UX researcher because they feel their “gut” or “intuition” supersedes what potential users actually say. If Jay-Z were a product manager, he’d say Men lie, women lie, explicit member quotes telling you why your product idea actually sucks don’t lie. I’ll write an article titled “Why your UX Researcher is Your Best Friend” so you truly understand the importance of the UX researcher. Also, remember that users will tell you what the problem is, but they will not tell you how to solve that problem. It’s up to you to figure out how to solve it.

Men lie, women lie, explicit member quotes telling you why your product idea actually sucks don’t lie.

The P-Zero PM (via Jay-Z) Tweet This

PRODUCT MARKETING

The Product Marketer is the expert in translating product benefits into marketing campaigns and material that accurately and concisely communicate your product’s value to the market. The type of campaigns vary based on the type of product you are selling. They can be email campaigns, webinars, in-person seminars, internet ads, etc. Always keep your PMM updated on the latest product features and release date.

DATA SCIENTIST

The Data Scientist understands the most accurate and efficient way to measure the success of any product release. In other words, they are the metric experts. They help analyze data results to ensure the team is interpreting the results correctly. If you have a general idea for the metric you want to track but are unsure if it should be a primary or secondary metric, ask your data scientist. If you know exactly what metric you want to measure but have no idea where to access that information in your data analysis tool, ask your data scientist. If you want to know the probability that Lebron James goes another year with his terrible hair plug job instead of just going bald, your data scientists will probably know that too.

UX Content Designer & Copywriter

Are you having trouble knowing what to label your fields, titles, and buttons? Are you unsure of the best way to organize the content and copy in a way that will ensure your users understand how to effectively interact with your product? Perhaps you even need some assistance with what to name your feature? Seek the expertise of the UX Content and Copywriter! As elegantly put by Callum Dunbar, the UX Content and Copywriter uses the art of language to make branded experiences easier and more enjoyable for the users.

How does all this expertise come together?

That’s right …YOU, the product manager!

YOU: PRODUCT MANAGER

You are the expert in understanding all facets of the customer problem that you are attempting to solve and how to combine the expertise of your Prod Squad at the right time to release an amazing product. You have unearthed a customer problem and have worked with the UX researcher to validate WHAT the problem is, WHY the problem exists, and WHY it needs to be solved. You present an initial solution to your UX designer and fine tune the layout that will define HOW the problem will be solved via user experience design. You then convince engineering of the importance of the solution and they begin to define HOW this will be implemented technically. Simultaneously, you work with Product Marketing to devise the correct messaging that will resonate with your target market to ensure they know that you created the perfect solution for their problems. You also meet with data science to ensure you are tracking the correct metrics that enable you to accurately measure the product’s success. The UX Content and Copywriter aids you in designing the best “literary” experience for your users.

Note: If you work at a startup or an under-resourced team, you may be all of these people yourself. Don’t let that deter you. It just means you’ll be gaining expertise to make you an even more formidable opponent to any future challenge.

Now I know you always hear things like “The PM is the CEO of the product”, but this may give the wrong sentiment with respect to how you and your team actually work together. As a PM, you don’t technically have authority to tell anyone how they need to do their job. You and your team are constantly working together and collaborating to create the ultimate product. If we begin to use the super heroes analogy where you think of your team as a group of collaborating experts, each with the knowledge to step in at the right time to ensure the right decision is made, you’ll ensure a better working relationship with your team and a better end product.

For a list of questions to ask your Prod Squad as you onboard, check out the article “Key Questions to Ask your Product Development Team (The Prod Squad)“

Now with your powers combined…go create something great! (and environmentally friendly too). The power is yours!

The post The Product Development Team aka The Prod Squad 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.

Joseph Akoni speaks with aspiring and current product managers, product designers, and engineers as part of Airmeet’s “The Remote Valley” fireside chat series.

Joseph Akoni — Thu, 24 Sep 2020 05:24:50 +0000

On 9/19/2020, Joseph Akoni spoke with aspiring and current product managers, product designers, and engineers as part of Airmeet’s “The Remote Valley” fireside chat series. He details how to succeed as a PM during COVID and how to successfully work with your engineers and designers.

The post Joseph Akoni speaks with aspiring and current product managers, product designers, and engineers as part of Airmeet’s “The Remote Valley” fireside chat series. appeared first on The P-Zero PM - Tips and Tools to Ensure a Successful Start to Your Product Management Career.

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

Joseph Akoni — Mon, 21 Sep 2020 05:42:42 +0000

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

Ready to meet your new best friend!? You better be!

Meet the User Experience (UX) Designer!

Now, I’m sure EVERY designer can relate to the above sketch. Everybody thinks they’re a designer (Product Managers included, and I admit, I’m guilty of this too). I’m also sure this annoys the hell out of UX designers (no, but really, it does).

Repeat after me:
Just because I’ve used Microsoft Paint to add text to a photo to create a dog
meme does not give me the credibility to critique every design decision my
designer makes.

Did you repeat it?

You’re lying.

Do it again.

Ok. I believe you now.

Just because I’ve used Microsoft Paint to add text to a photo to create a dog meme does not give me the credibility to critique every design decision my designer makes.

The P-Zero PM Tweet This

So, how can you ensure you don’t piss your designer off every time you work with them? Before we dive into how to grow your relationship with your designer BFF, let’s understand exactly what they do and how your designer assists in the process of taking your product from idea to reality.

What does a UX Designer do?

At a high level, the designer creates a product experience that enables each member of your target audience to complete the product journey efficiently and with minimal mental effort.

This experience that the designer creates expands beyond just understanding the user interface (UI) elements available to them, such as buttons, font size, font color, selection menu options or the text that is visible. They must also deep dive into the psychological aspects of user experience design. They must understand how human behavior and thought processes determine which UI elements are used and where they are used.

To put it more tangibly, the UX designer decides, taking into account the user’s mind state, what layout and processes (i.e. arrangement of buttons/icons, flow of information entry, text and toggles) would facilitate that user’s successful completion of the product experience — the product experience being the task that you, the product manager, want them to accomplish.

What does this psychology include?

I’ve mentioned the words “human behavior”, “psychology” and “mind state” but what exactly does this mean in regards to product design? The designer must dig deep into understanding various aspects of the target user. The UX designer must:

Understand who the user is.
Understand what the user is expecting to accomplish when presented with the product experience.
Understand the context in which a user is completing the product experience (e.g. why they are completing the task at hand and for whom? How long should it take to complete a task such as the one they are presented with?)
Understand how the user may be feeling when beginning the product experience.
Understand what the user could be thinking when they are immersed in the product experience.

“Okay, the designer has to know the user in and out, so what’s a UI element?”

A UI Element includes input controls, navigational and informational components, and containers that make up the overall layout of the screen.

You may think that regardless of the complexity of the product experience, picking a UI element to use is a simple process. I mean, a dropdown is a dropdown, right? Wrong.

There are numerous types of menus, buttons, navigation, media content holders, text fields and forms. Additionally, there are endless ways to organize various design elements. The designer must:

Understand which UI elements to use.
Understand when to use them in the product experience based on how humans perceive the function of each design element.

All while making sure the UI experience:

Is not complex. Which reduces user efficiency
Is useful. ensuring the user can actually complete the task.
Is intuitive. Ensuring the user understands how to interact with the UI elements with minimal thinking. The last thing you want is your user thinking to himself, “WTF does this button do?”
Abides with platform design standards. This means that all UI elements have the same function and design across the entire platform.

“Okay, so the designer is basically a genius and a mind reader…got it!”

I did tell you that you were working with superheroes, right?

The designer creates a product experience that enables each member of your target audience to complete the product journey efficiently and with minimal mental effort.

The P-Zero PM Tweet This

Where does this genius designer fit into the overall product development process?

In the chart below, you will see where the UX designer fits in the overall product development process (highlighted with the orange box and light bulb).

Infuse UX Design insight into the previous PM and UX Researcher insight to create initial designs – After the PM has validated their hypothesis with the UX researcher, they will work with the UX designer to create the initial designs. At this stage, the UX Designer gains an understanding of the product goal and the strategies the Product Manager has proposed to achieve it. The designer then determines how this goal (and its related strategies) can be achieved given company design standards/patterns while also taking into account all of the items mentioned above (UI elements available, human psychology, design complexity, etc.). The designer will also most likely simplify any preliminary designs you had in mind with respect to how the solution should look. Trust me, you may think you have the perfect design in mind, but it can and will be improved by your designer.
Redesigning initial designs based on engineering constraints – In this stage, engineers will take a look at your initial design to determine what is feasible based on the current technical architecture/infrastructure. Note: engineering work has not started yet! Your engineers will tell you which aspects of the design can be done in your desired timeframe and which would take longer to implement. If you are on a time crunch to release the product and the ideal solution requires more engineering time than your engineers currently have allocated, you will have to re-design your solution to acommodate the current engineering constraints.
Re-designing after feedback from user concept testing – Before you release the design publicly, your UX researcher may suggest they conduct a user concept test to see if the new design resonates with members of your target audience. This concept test will give initial insight into whether your solution will actually facilitate in fixing your member problem. If many users deem that the design is confusing or the design does not efficiently help the member complete the desired task, then you, the PM, must work with the designer to re-configure the design. After completing the redesign, I highly recommend showing this new design to your engineering counterparts to ensure the new design does not clash with any other engineering constraints.
Redesigning the solution if new requirements or engineering constraints are uncovered. At this stage, the hope is that you will not have to create any new product requirements or that your engineering team has not uncovered any new design constraints which can extend your launch timeline or cause you to have to re-design your solution. Unfortunately, this is the real world, and sh*t happens. If you do get to this stage and have to create new requirements or find new engineering constraints, then you will have to work with the designer to create a new design solution. **insert sad face**

Two things you probably noticed when reading that last section:

This flowchart is considerably longer than the flowchart presented in our first best friend article “Why Your UX Researcher is Your Best Friend”. That’s because UX Researchers tend to have distinct points in which they interact with product teams, while the designer works with the product throughout the entire development process from start to finish (or at least they should).
You may be wondering, “Why don’t you include engineering first and then go to design? Or engineering and design simultaneously?” This is a personal decision that you have to make, or you may need to follow the standards of your company. From my perspective (and this is subjective), the possibility of engineering constraints is higher than the possibility of design constraints. Design tends to naturally be more flexible than engineering. For example:
The designer can say “Sure, let’s add a button in this section and add another item in the drop-down menu. It would make sense for the user to be able to access the feature here.”
While the engineer says, “Well, we could add a button in this section, but we only have room for one button (which is already there), and to add another button, we’d have to reconfigure the entire section, which requires significant validation work to ensure we don’t compromise functionality. For the additional item in the drop-down menu, we would have to work with any downstream teams (who rely on the data in the menu) to ensure that their systems accurately use this new item selection. Adding the button and new item would probably take an additional quarter of engineering time.”

See the difference?

The possibility of design constraints limiting your maximum level of creativity for the initial designs is lower with design than with engineering. When developing initial designs, you should limit the effect that constraints have on the creativity, innovation, and magic that you and your UX designer can create. That’s why I recommend approaching your engineering stakeholder after you and your designer come up with the IDEAL solution. Who knows, you may impress your engineering manager so much that they get extremely excited about your design solution and they’ll dedicate even more engineering resources than originally planned! Now you have your button and your drop-down selection item. Voila! It’s magic! You’re welcome.

When developing initial designs, you should limit the effect that constraints have on the creativity, innovation, and magic that you and your UX designer can create.

The P-Zero PM Tweet This

How do you continue to cultivate your relationship with your new BFF?!

Treat your designers like you treat your engineers! Realize that design isn’t as subjective as you think. There can be a right and a wrong way to design something. There are design standards and concepts that your designer knows THAT YOU DON’T. Most of the time, your designer will know what’s right and you won’t. Don’t focus on questioning HOW a designer got to a solution because doing so makes it seem as if you are questioning their design skills. Instead, question the WHY, because that is most important and will lead to your understanding of if their design solution will solve member needs. You don’t hover over the shoulder of your engineers and provide suggestions every 10 seconds about changes to make to their code, do you? No. So, don’t do that with your designers.

You would never say something like this to an engineer, would you? Well, I hope not!

2. Discuss with your designer how you will communicate design ideas. Will you send them a bullet list of your ideas? A rough sketch of your ideas? Will you have a collaboration session in which the both of you come up with the initial design? I’m a visual person who is highly proficient in Photoshop, Balsamiq, and Figma. I can throw together a prototype fairly quickly. I prefer to use Figma to create my initial design thoughts or iterate on current designs (and I communicate this to all designers I work with). Regardless of how you like to communicate ideas, please communicate this to your designer! I once presented a design concept in a JPG that I created with photoshop to a designer a couple years ago. She looked at me like, “Who TF do you think you are? So, you’re the designer now?” I learned my lesson pretty quickly and let her know that this is just how I communicate product ideas best! Hahaha…whew…

3. Clearly communicate the user problem. You have to communicate the user problem so that your designer knows what problem she will be solving with her designs. Make sure you have all of your initial requirements upfront. Making a designer have to go back and edit the placement of a UI element three times because you didn’t confirm what use case you were solving will make your designer hate you! Lol (no, really, it will).

4. Clearly communicate any subsequent design changes and keep these subsequent design change requests organized. Design changes after the original design is completed will happen. This is not ideal, but not uncommon, so don’t freak out! Make sure you keep track of all product design requests in an organized manner, so your designer knows exactly what they need to do when they need to do it. More likely than not, your designer will have 10342 other projects she is working on. If you want your designers to like you, make their lives easier by staying organized on every design task that must be done.

Why is the UX Designer your best friend?

In summary, the designer creates an experience enabling each member of your target audience to complete the product journey efficiently and with minimal mental effort by taking into account how human psychology forces us to interact with UI elements.

The designer will be a Prod Squad member you interact with throughout the entire development process. Make sure you communicate product and potential design changes EARLY when necessary.

Welcome onboard Flight #143 en route to Product Launch Success, it’s your captain speaking. Hold on to your new best friend: it’s going to be a bumpy but enjoyable ride.

Bon Voyage! Que te vaya bien!

Oh, and for fun, another comic on how not to treat your UX Designers…

Don’t be any of these people…please…

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

[VIDEO] Jane Jackson Career Coach – Podcast Interview

Joseph Akoni — Mon, 07 Sep 2020 20:11:52 +0000

Event Overview: Joseph Akoni was interviewed by Jane Jackson, an Australia-based career coach, to discuss everything from his childhood passions to his career journey.

Click here to check out the interview!

The post [VIDEO] Jane Jackson Career Coach – Podcast Interview appeared first on The P-Zero PM - Tips and Tools to Ensure a Successful Start to Your Product Management Career.

[VIDEO] Joseph Akoni speaks to the Product Management Club at Georgia Tech

Joseph Akoni — Sun, 30 Aug 2020 20:32:41 +0000

On 8/29/2020, Joseph Akoni spoke with Georgia Tech’s Product Management Club. His presentation was titled “What I Wish I Knew About Product Management Before Becoming a Product Management. There was also a Q&A after the presentation. Full video is below!

The post [VIDEO] Joseph Akoni speaks to the Product Management Club at Georgia Tech appeared first on The P-Zero PM - Tips and Tools to Ensure a Successful Start to Your Product Management Career.