Adam Thomas | Product Management Expert

Tag: product biases

  • What does a product manager actually do?

    What does a product manager actually do?

    Product management requires flexibility and adaptability in its practitioners. So, with so much nuance, how do we define what product managers actually do?

    man standing in front of group of men
    Photo by Austin Distel on Unsplash

    Product management (PdM) is a flexible discipline. It means different things to different people for a few reasons. 

    • Different organizations require their product teams to do different things. Sometimes you find yourself in an environment that appreciates SAFe while others are fully “Empowered” with everything in between as well. 
    • Your day is never the same twice. If I asked one PdM to list ten things they did this week and another one to do the same, the lists likely won’t match up, even if they’re both in the same organization.
    • There is no discrete output. Engineers produce code, designers produce experiences, and salespeople produce revenue. Product, however, can do any of these things, depending on the circumstances. 

    I could continue a list like this for quite some time. The theme would remain the same for each item on it, however: Product goes where it is needed. So, with so much variation in its day-to-day practices, how do we define, at a high level, the role of the product manager and the work it entails?

    After several years of doing the job, I’ve landed on the following definition: “Product managers should help their organizations make better decisions over time.” For us to support the teams that deliver the outputs that make companies successful, we have to take charge of improving the quality of decisions that everyone in the organization makes. 

    PdMs should spend time prioritizing issues based on business and technological need, and then come together with different parts of the company to solve those problems. This process becomes a cycle. The longer product people work in this cycle, the better and faster they get at understanding problems and using the right tools to solve them.

    In my article on survival metrics, I talked about the need for teams to be fast, data-informed, and politically safe, and I think these are three modes of operation that allow product managers to get comfortable with the change that comes with focusing on complex problems. Your job as a product manager relies on dealing with complexity, and your value to the business is in how you can help it navigate those decisions over time. 

    So, what constitutes fast, data-informed, and politically safe decision making? And how can you draw on these principles to remain flexible so that you and your organization consistently improve in the quality of your decisions?

    WHAT DOES A PRODUCT MANAGER DO?

    After several years of doing the job, I’ve landed on the following definition: “Product managers should help their organizations make better decisions over time.” For us to support the teams that deliver the outputs that make companies successful, we have to take charge of improving the quality of decisions that everyone in the organization makes. 

    Fast, Data-Informed, Politically Safe 

    Don’t think of the concepts fast, data-informed, and politically safe as having fixed definitions like everyday words do. When you incorporate them into your thinking, you’ll find that they’re flexible enough to fit several different situations. 

    So, what does each of these principles mean in practice?

    FAST 

    How might I increase the speed with which I make any necessary choices? In product development, and especially in agile product development, the shorter your decision cycle, the sooner you can adjust to the changes that dealing with complex problems necessitates.

    DATA-INFORMED  

    How might I improve how closely our team performs to reality instead of the ideal? Teams often make decisions in workshops or based on what comes from the boardroom rather than what’s really happening in the business and the marketplace. Better decision-making involves taking the influence that the stakeholders wield and pushing back with data based on reality. 

    POLITICALLY SAFE 

    How might I enhance the psychological safety of the team around me? When people feel heard, they feel safe, which means they’re willing and able to take risks. Political safety extends that concept to the team level so that teams feel better with interpersonal tension. As a product manager, the more trust you can foster across teams, the better the decisions you’ll all make. 

    Operating with these frameworks allows you to make better decisions over time. Think through some of your past decisions to see how you can improve your processes in these three ways. Doing so will help you define the role of a PdM to your team.

    The frameworks are important to lean on because you are going to be fighting a lot of fires. In fact, I’m sure your Slack is going off right now. 

    Fires, Fires Everywhere

    Put down your laptop. I’m sure no one is going to come around the corner and threaten you for not immediately answering that incoming Slack. 

    Why did I ask you to do this? You have to stop reacting. You need time to think. You need time to respond.

    Let me know if this sounds familiar to you:

    • Stakeholders are pounding on your door, demanding “innovation.”
    • Bugs threaten the viability of the next release.
    • Sales added something to the roadmap again.

    I bet you’re nodding your head. Well, sorry to break it to you, but this kind of adversity is the nature of the job. Product classes usually leave out that, although managing all of those things and more is important, your primary job is to facilitate better decision making. And this happens when you are able to respond rather than react. 

    Responding Versus Reacting

    Responding means that you’re thinking about the outcome you want instead of whatever is ahead of you. As a PdM, you must keep the outcome in mind so you can remain flexible and apply the fast, data-informed, and politically safe principles.  

    Let’s go a little deeper here. Imagine that we have two product managers, one named Jeff and the other Anna. They are both dealing with a push for innovation from leadership, a hyper bug tracker, and pressure from sales on the upcoming release. Everyone wants a meeting. Jeff says yes to them all and finds himself in meeting after meeting, dealing with every single one of those fires. 

    Anna pushes back on the request and promises a response in three hours. She then takes those hours, looks at all of the requests, sends some probing questions via Slack to those involved, and creates a list of tradeoffs and possible outcomes based on company strategy. 

    Who would make a better decision about what to do next: Jeff or Anna? The answer, I think, is clear. This hypothetical illustrates the difference between reacting and responding. Those that simply react will find themselves being output-driven. They can’t see past the next fire. Reactionary teams are always trying to figure out how to “launch” the next thing. 

    By contrast, those that respond are able to take a step back and adjust to the entire picture. They’re able to communicate in a data-informed way that helps teams gain trust in one another. Responsive teams are focused on the “why” behind the outcome. Those responsive teams focus on the big picture since they spend time thinking about strategy. 

    How does this make a team faster? Well, PdMs who take time to think before they act understand the priorities of the business better. So, once they have a better grip on what’s important, they can ultimately move faster without getting bogged down in details.

    MORE IN PRODUCTHow to Survive a Crisis, According to Eventbrite’s CPO

    Remember That You Do a Lot

    A lot of your work happens in the background. There isn’t a day-to-day PdM map to follow. Because of that, this job gets frustrating. Moreover, proving impact is hard since a lot of your time can be devoured by people asking you to put out their fires. Creating the space to respond is incredibly important to help you improve the decision making in your company. 

    That said, implementing this kind of culture is also the most rewarding part of the job. Helping teams dig through ambiguity is the essence of product management. Making sure everyone is making better decisions shows up not just in the releases, but the overall efficacy of the company.

  • Great product managers leverage cognitive bias

    Great product managers leverage cognitive bias

    All humans are susceptible to cognitive biases. As a product manager, your job involves turning those weaknesses into strengths for the team.

    brown tree
    Photo by Neil Thomas on Unsplash

    roduct managers (PdM) don’t make anything. Well, at least they don’t in the traditional sense. When it comes to product development, the product manager, unless under duress due to a lack of resources, bad planning, or maybe both, isn’t writing production code or crafting customer interactions. What they are doing at their best, though, is managing the decision science of the team.

    PdMs spend their time making decisions that affect how the team decides … well, anything. They are busy prioritizing the needs of product development, managing the velocity of the decisions that the team is facing, or working on any number of projects that shape how the team makes decisions.

    Today, I’d like for us to take a trip with cognitive science and talk about two concepts: availability bias and recency bias. Whether you realize it or not, you’re susceptible to both of these biases. In fact, they can even shift how product teams operate. The good news is that you, as a product manager, can actually leverage them to improve your team’s decision making.

    THE BIASES

    Recency bias is exactly what its name implies: A bias that privileges things that have recently happened. Have you ever sat in a meeting and noticed that decisions seem to largely get made at the end of the meeting, and the players inside of that meeting only reference data from the last 15 minutes? If so, you, my friend, have seen recency bias in action.

    Availability bias is similar to its recency counterpart in that it privileges data based on ease of access rather than quality. It involves making decisions using whatever information is immediately available. You’ve also probably seen this one in practice as well. If you’ve ever been in a meeting and watched people choose the first idea that comes to mind, that’s it. Its main difference from recency is that availability bias isn’t time-locked. Someone may have research they rely on that they’ve collected months or even years ago.

    As product people, one of our roles in an organization is to improve the decision-making process for product development. Both of these biases affect our output, which we can think of as the company’s “decision fitness,” or how well we make the decisions that affect our outcomes. Without managing these biases, you’re lowering the fitness of the company and are on a sure road to shallow decision making.  So let’s ask how well we’re making decisions.

    WHERE DOES PRODUCT MANAGEMENT COME INTO PLAY?

    Since we product managers don’t have any tangible output, upgrading everyone’s ability to make decisions is a way for us to show our value and also functions as a metric for us to gauge ourselves. Our battlefield is often the research lab. For product managers, this isn’t the stereotypical science lab that comes to mind, but rather the place where we do research and one-on-ones with other stakeholders. We also ply our trade in the meeting room, and, in both spaces, we need to be vigilant in watching for the following red flags from our teams.

    On recency bias:

    • Meetings without any agenda or facilitation. If no one is managing the conversation, our brains will default to the last thing we heard.
       
    • The roadmap is just the highest-paid person’s opinion (HiPPO). The tactics you use to get to the outcomes you want should have a variety of sources. If you only have one source, you have a problem.

    On availability bias:

    • Quick decisions and buzzer logic. We’ve spent all the time in the meeting talking about potential strategies only to take the first one available.
       
    • Teams not using research. Research always has curveballs. For example, it might show that your customers are using features to solve unforeseen problems and maybe causing new ones. If the decisions you come to haven’t considered even the possibility of alternatives, you’ll have shallow outcomes.

    SO WE CAN IDENTIFY BIAS. NOW WHAT?

    Now that we know how to spot bias, let’s leverage it. We can’t change how the human brain works. Trust me, I’ve tried. You aren’t going to get rid of cognitive bias — but if you have, please, email me!. What we can do instead is put processes in place that understand these biases exists and use them to help our decision making.

    So, let’s talk tactics.

    • Strive for short decision-making cycles. Ask yourself, “How can I make the decision-making cycle in a meeting as small as possible?” Far too often, teams wait until the end of meetings to make decisions. That timing falls into the traps we saw earlier. This likely means structuring meetings in decision cycles instead of theme, which brings us to our next tactic.
       
    • Meeting discipline. We all hate meetings, and I get that. Despite their unpopularity, they’re a useful tool for finding alignment and making decisions. PdMs should own meeting management for product development and ensure that people walk into meetings with context. Those cycles should leverage availability bias by making the right artifacts available at the right time and recency bias by making decisions in each cycle instead of waiting until the end of the meeting. That way, you’re structuring the meeting to take advantage of the bias instead of letting it derail your process.
       
    • Research discipline. Much like meetings, your participants, whether they are internal or external, will fall into the trap of biased thinking. Make sure you have a few good questions and set the table for those who want to understand the research can access the information. If the team trusts the research, and it’s available, they will add it to what’s “available.”

    These strategies are just a few things you can implement immediately to manage those biases and improve decision fitness.

    WHEN WE LEVERAGE OUR BIASES, SOME THINGS CHANGE

    Large-scale shifts in team thinking take time. Some things will start to happen immediately, however.

    • You’ll have more collective insight into the customer. Shorter decision cycles with more “just-in-time” context that includes different voices, including some that often don’t get into the conversation, means more voices will feel comfortable joining the conversation.
       
    • Less HiPPO wrangling. As a shift occurs in the power structure, the HiPPO will see that there are plenty of voices that are contributing and feel less pressure to “fill air.”
       
    • More usage. People will feel comfortable with product artifacts (research, strategy). Teams will have better inputs for their own decision making since they know where it is.

    When a PdM manages this process, the team and org get better outcomes.

    BOTTOM LINE: FIND BIAS, UNDERSTAND IT, LEVERAGE IT

    Product managers, since they are usually outside of the solution business (read: making shit), are far more useful when they understand the mental pitfalls an organization may fall into. Since they have the mental space to look at things from both the customer and business P.O.V., as well as associate with the product makers, they should see where cognitive bias is helping or hurting an organization.

    The best work we can do as PdM’s is to understand the outcomes we’re going for and use the environment around us to give it the best chance of success. Cognitive bias is a part of that environment. In particular, recency and availability bias have some silent consequences that affect the day to day that can lead to sustained mediocrity in product development.

  • Identifying and addressing common biases in product management

    Identifying and addressing common biases in product management

    a man sitting in front of a laptop computer
    Photo by Priscilla Du Preez 🇨🇦 on Unsplash

    Product management is “thinky” work. 

    As a product person, you need to bring about organizational alignment through product strategy while also keeping things running smoothly with product operations. I don’t need to tell you this is a delicate balance. And without time to sit and think, you’ll end up making rash decisions based on your biases.

    So, what is bias? Well, our good pal Wikipedia defines bias as:

    “Disproportionate weight in favor of or against an idea or thing, usually in a way that is closed-minded, prejudicial, or unfair. Biases can be innate or learned. People may develop biases for or against an individual, a group, or a belief. In science and engineering, a bias is a systematic error.”

    The first sentence of this article was about “thinky” work, so let’s add something to our bias definition that focuses on the brain: the word cognitive. 

    Cognitive biases

    Here is the definition of cognitive bias, once again from our friends at Wikipedia:

    “A cognitive bias is a systematic pattern of deviation from norm or rationality in judgment. Individuals create their own ‘subjective reality’ from their perception of the input. An individual’s construction of reality, not the objective input, may dictate their behavior in the world.”

    The word system is there, too.  In fact, we should discuss systems before we go any further (especially because product exists somewhere between science and engineering). Our bias is an error in a system. If you don’t think your work involves systems, it does. And if that took you by surprise, take some time to audit your product organization to see just what systems exist. Org charts and meeting lists are a great way to start, as are team retrospectives. 

    Once you have a basic understanding of the system(s) your product development team exists in, this article may be helpful. If not, bookmark this article and come back to it after you’ve got a clearer picture of the system(s) your team is part of. 

    If you’re still with me, I’d like to spend some time talking about three biases that are affecting your teams, how they affect your teams, and some ways to identify them. These biases — confirmation bias, availability bias, and recency bias — can leave a product team spinning its wheels and keep your organization from reaching its goals. 

    Confirmation bias

    Wikipedia defines confirmation bias as:

    “The tendency to search for, interpret, favor, and recall information in a way that confirms or supports one’s prior beliefs or values. It is an important type of cognitive bias that has a significant effect on the proper functioning of society by distorting evidence-based decision-making.”

    Confirmation bias is the most common bias within product teams. In fact, it’s the “patron bias” behind feature factories. Since every result seems to “make sense” to the product team, they end up proceeding, full speed ahead, with their plans. Feature factories are incentivized and tracked by “feature release velocity (FRV)” and “can’t afford” to stop shipping things as rapidly as possible.

    The problem? Your product strategy is about customer outcomes, not how many features you’ve created.

    Your team may be experiencing widespread confirmation bias if:

    • Research always “makes sense.” If user research always goes smoothly and never reveals anything surprising, then it’s worth questioning how deeply you are interrogating the world around you.
    • There is no tension in meetings. Teams come from different perspectives, and there should be a healthy level of conflict that comes from those perspectives.

    Recency bias

    “What just happened?”

    If we are always thinking about that, then we’re focused on recency bias:

    “Recency bias is a cognitive bias that favors recent events over historic ones. A memory bias, recency bias gives ‘greater importance to the most recent event,’ such as the final lawyer’s closing argument a jury hears before being dismissed to deliberate.”

    Recency bias means we aren’t actively listening to different perspectives  — we’re just checking boxes until we hear the last word. Too often, this ends up being the highest-paid person’s opinion (HiPPO). When product operations is very top-down or if there is no rigor behind your decisions, then your teams are really just waiting until the end of the meeting for a decision. The problem here is that the work you are doing ends up not mattering to the product strategy. And in the long run, teams can slowly lose their agency, which harms operations and slows down processes.

    Some symptoms of recency bias include:

    • Meetings not having any agenda or facilitation. If no one is managing the conversation, our brains will just remember the last thing we heard.
    • The “roadmap” being the list of the HiPPO’s thoughts. The tactics you use to get to the outcomes you want should come from a variety of sources. If there’s only one, you have a problem. 

    Availability bias

    Relying on “what’s on hand” might seem like a smart practice, but it can lead to trouble:

    “The availability heuristic, also known as availability bias, is a mental shortcut that relies on immediate examples that come to a given person’s mind when evaluating a specific topic, concept, method or decision.” 

    I left this one for last because it’s a bit complicated. While the other two biases are almost always bad, this is one the pros can use to their advantage. Unfortunately, many teams can’t, which means we get stuck with the downsides, including lower decision quality. Our work isn’t a game show. How quickly you hit that buzzer doesn’t really matter — outcomes do. This bias leads to shallow outcomes and releases that may get even worse when combined with the other two biases mentioned which is an operational waste.

    Your team might be struggling with availability bias if: 

    • You’re reliant on quick decisions/buzzer logic. For example, you spend entire meetings talking about potential outcomes, only to take the first option available. 
    • Research is being ignored. Research almost always comes with curveballs, and if the decisions you come to haven’t considered them, you’ll end up with shallow outcomes. 

    The importance of time

    Biases come into play when teams don’t have time or space to carefully consider their decisions. In short, they are acting too fast with little time to process. If you feel that the team just moves from project to project, you’re most likely running right into bias traps. As a result, you’re probably making lower-quality decisions that can hurt your team long-term, both in how product development operates and when it comes to strategy.

    The solution is often simple: SLOW DOWN. Identify what’s important to the system you operate in and spend time paring away any processes that don’t make sense to your product strategy and operation. This includes projects as well. More often than not, it means getting rid of things and prioritizing so the team has time to think.

    This is “thinky work,”  and without allowing time for real thought, you’ll ultimately need luck for success. And I’ll end with a word of caution — luck is biased toward the patient and the prepared.