Tag: Biases in Product Management

  • How to conduct better product management interviews

    How to conduct better product management interviews

    Hiring is one of the most important parts of product leadership. Use these principles to make sure you’re landing the best talent.

    three women sitting beside table
    Photo by Tim Gouw on Unsplash

    Product leadership is difficult. 

    That difficulty comes because it’s often very different from product management. As a product manager (PdM), your focus is squarely on making sure that your team is consistently making the best decisions they can. 

    When it comes to product management, you can easily access help to upskill yourself. Plenty of resources describe how you can do this more effectively. I’ve written a few myself. Some great voices in the space, such as Matt LeMayTeresa Torres, and John Cutler, among others, lay out frameworks that help PdMs figure out how to increase the decision quality of their teams.

    But what about product leadership? Well, product leaders’ job is to build product teams, which involves less framework and more coaching. You aren’t the star anymore. Instead, you take teams and make sure that they are ready for primetime.

    Accomplishing this requires a completely different skill set from strict product management. You start to assume responsibilities that take you outside of a tracker or prototype and have you spending far more time focusing on the people themselves. 

    This work includes bringing people onto the team that you’re developing. One skill that product leaders must cultivate is learning to hire effectively. If you aren’t adding the right skills to the team, no amount of work you do individually can fix things when they go askew. 

    The simple truth is that when you become a leader, you have too much to do, from team to resource management, to continue doing your old job. As an executive told me in a previous product leadership position, “You can’t do both.”

    And you can’t. So, you’re now hiring new PdMs to do the work you used to do well. But how do you go about that?

    Free Toolkit: Successfully Onboard Remote Employees

    Download this remote onboarding toolkit to access actionable resources you can implement and see the impact of immediately.

    DOWNLOAD NOW

    Hiring Pitfalls

    Have you ever heard the saying, “Just because you can do something doesn’t mean you can teach it”? Well, the same thing applies to hiring. 

    The skills necessary to hire someone who will be a good fit for the role aren’t as simple as one would think. You risk becoming a victim of expertise bias, where you end up looking for someone exactly like yourself. You also have to consider cultural bias, in which the hiring manager prioritizes candidates who look, talk, and think exactly like the other team members. Both of these biases lead to building a team that thinks and looks alike. In a discipline like product management, this can be a fatal error. 

    No tension on teams means no growth. Unless you get some measure of luck, your team will remain stagnant because no one challenges each other. After all, we’re here to increase the decision quality of the teams around us, and that can’t happen without the team coming together from different backgrounds and points of view.

    The bad news, as a product leader, is that you likely won’t be trained on how to do this. The teams around you probably don’t know much about product manager, let alone hiring for it. Even if they did, they hired or promoted you to be a product leader to handle these things. 

    The good news is that I’m going to give you a quick tutorial on how to avoid some of these traps and push you in the right direction. First, we’ll talk about the importance of being clear about the problem you’re trying to solve with your hire. Next, we’ll use that information to formulate good interview questions. And finally, we’ll talk about being honest about the time you have. Getting all three of these things right drastically increases your chances of making the right hire.

    3 STEPS TO BETTER HIRING

    1. Focus on the problem you’re solving.
    2. Craft good questions.
    3. Allot the proper time.

    Focus on the Problem You’re Solving

    Every team needs a certain headcount. Likewise, every team has a million problems they have to handle. Product leaders definitely understand this since they engage with other teams at the strategic level. Sales could always use another SDR and engineering another back-end developer, just like you can always use another product person. 

    The fact is, everyone will say yes to another hire if it’s offered. But do you know what you need them for?

    The most important part of the hiring process is getting the right mind in the job. The second most important thing is onboarding that person correctly. Third is making sure that the new person knows what they need to do to be successful.

    All three factors rely on your understanding what you’re hiring for. What problem are you trying to solve with this new team member?

    Product is a flexible profession. As a product leader, I’m assuming you’ve had a couple of product management jobs in the past. Have they ever been similar enough to have the same job description? My bet is no.

    Despite that, every product job shares one element: flexibility. As they say, the only constant is change, and that’s as true of product management as anything else. Yet many product job descriptions look the same. And before you copy that mistake, taking a job ad else someone wrote and making some superficial changes, I would like to point you to Kate Leto’s bookHiring Product Managers. In it, she says that one of the most impactful tools in the discipline is the product role canvas.

    In her words, “Ensuring there’s a clear and shared understanding of the role that you’re hiring for is an essential first step to thinking more collaboratively and comprehensively about what a new role might be before the interviewing even begins.“ 

    How you understand the role in your organization’s context is incredibly important for the people who want to fill it. Product means different things to different people. How can you set someone up for success if you can’t define it for them before they walk in the door? 

    Use the product role canvas to define the problem you want to address before you move forward. Doing so will give you and the rest of the team (usually your designer and engineering peers, but this also can include folks like customer success and sales) an idea of what you are looking for. 

    Then, you can think about interview questions. 

    What Questions Should You Ask?

    So, you know the problem you need to solve with your hire. With that in mind, you should write a clear job description that matches your problem. Don’t just copy and paste whatever you find on the internet. 

    Once you publish the job ad, you’ll start receiving applications, and you’ll invite promising candidates for an interview. What do you ask them?

    I’ve seen teams blow this part of the process. Instead of being prepared and curated, the questions are either haphazard or clearly ripped from a how-to article. Product is far more calculus than algebra, and so you should know that anything that’s called “the perfect question for product interviews” is only perfect for the context in which the question was created. 

    Much like a good product, good questions help you tell a story. Even better, you create an environment for the person across from you, usually stressed and hurried, to show you their unique self. Strive to uncover “unique” traits rather than the “best” ones because that best isn’t who a candidate is day in and day out. “Best” is a character they have prepared to show you; unique is who they really are. 

    Tap into unique by asking questions like these:

    • Tell me a story about X on your resume.
    • What was the hard part about making X real?
    • How did you convince opposing forces about X to make it work?

    These types of questions can lead to stories that give you the unique flavor of a candidate. Uniqueness wins here since you’re looking for someone interesting and adaptable rather and who meets every item on a checklist.  

    In product, you’re always looking to solve an ambiguous problem, How you rate the uniqueness of a candidate against the problem set you want to solve is important. Think about the problem and the types of both hard and soft skills necessary to solve it. 

    Your questions should also get the candidate to talk about their experience so they can form a tapestry of their experience. The follow-ups you ask should aim to give you a better understanding of who the candidate truly is instead of the “best” person they have prepared to show you. 

    Because we’re looking for a story, ask open-ended questions. For instance, ask “Walk me through a time you’ve done X” instead of direct questions about some specific item. This will allow the candidates to tell you their stories.

    How Much Time Do You Have?

    It’s important to get to the candidate’s uniqueness quickly because we’re on the clock. You don’t have much time to devote to this process.

    As a hiring manager, you’re conducting interviews and hiring on top your actual job. Finding time to look over assets and grade things can be a hassle. So, why do teams act like they have a million years to do so?

    Generally, you don’t have time to look at that long presentation, nor do you have time to dig into that case study, or to relisten to that hour long interview that the candidate gives you. Sometimes, you may not even have enough time to do more than Mad Libs on a review.

    So, create a key for scoring interview answers. This document gives you the ability to do reviews shorthand. You can answer what others need to know without a ton of investment on your behalf. 

    As a part of that key, define the time that it is going to take to review the answers. Share those targets with both the interviewee and interviewer. Being honest about the time can help you and the team get clear sightlines on how much work you are asking of them. You can even bundle the time (e.g., a standing 30 minute meeting to review interviewees each week) to get through the review process cleanly.

    Free E-Book: Core Values in the Workplace

    How to create core values that will inspire your workforce.

    DOWNLOAD HERE

    Hiring People Is Hard

    And getting it right is the most important thing you are going to do as a manager. When you’re ready to take your team to the next level, you can’t afford to fail. Be clear about the problem, put the right amount of rigor in the questions, and set reasonable time expectations.

    This may seem like a lot of work up front. Over time, though, you’ll spend less time thinking about the hiring process and more time thinking about the candidates themselves while being transparent about needs, which can help your team get a lot stronger in the long run.

    Being a product leader is a different job and requires a few different skills you won’t learn as a PdM. Take the time to learn these new skills, and you’ll get better outcomes.

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