Adam Thomas | Product Management Expert

Tag: product manager

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

  • As product manager, what story should you tell?

    As product manager, what story should you tell?

    As product manager, how do you take your plans from theory to action? Simple: Tell the right story.

    sticky notes on corkboard
    Photo by Jo Szczepanska on Unsplash

    Making change is hard. 

    Even harder is making change while projects are in motion. As a product manager, though, this is the job. Remember, as a PdM, you are judged on how you improve the decision fitness of the team you are on. Just thinking about better decisions isn’t enough, though. You have to make them happen.

    Turning plans into reality isn’t as easy as simply putting an idea on the table. Humans don’t work that way. Sure, you can try to force your agenda on people. Unlike other disciplines, however, product management works by influence, not brute force.

    That’s because, while brute force may work, it won’t work for long. PdM’s thrive on influence without control. Using the stick instead of the carrot gets old fast.

    But don’t take that lack of control as a license to not act. PdMs who let inertia take over hoping people just get it on their own don’t last long. Playing tattletale isn’t a winning strategy either. Whispering in the CEO’s ear, much like the proverbial stick, may work in the short term since the CEO has the power to make things happen. Thing is, though, people start to realize that you have no actual influence yourself, and they start to find ways to work around you. 

    No one respects the PdM who can’t influence change without relying on outside help. 

    Storytelling as Product Tool

    So, what should you do if plan alone isn’t enough, but you can’t use brute force to accomplish your goals? In order to turn plans into action, what you need is a good story. 

    Why a story? Human nature means that stories captivate our brains. As you’re reading this, think about the last three things you’ve remembered for any stretch of time. I’m going to bet at least two out of those three were attached to a story that triggered some emotion in you. 

    As PdMs, we need to be storytellers. Our influence takes hold through the stories we choose to tell and the way we construct those narratives. 

    That’s all well and good, but how do you know what you need to include in a story? Well, let’s bring back an old friend: survival metrics. We’ll look at my personal principles of storytelling: leading with proof, repeating the story, and then iterating it inside of your culture. We’ll then explore how to use your story to turn survival metrics into action for your organization.

    3 KEYS TO A GOOD STORY

    • Lead With Social Proof.
    • Repeat the Story.
    • Iterate Within Your Culture


    What Are Survival Metrics?

    Before we begin, let’s have a quick refresher on survival metrics, which help a product team determine if an initiative is worth investing in more, pivoting or stopping completely. They are a forcing function that prevent product teams from suffering due to the sunk cost fallacy. Survival metrics put resource allocation and company incentives, both implied (think politics) and direct (think data), in front of the team before a project begins and again at regular intervals, giving everyone permission to act quickly.

    Survival metrics create a clear picture of what can go wrong while a project is in motion. By spelling out potential limitations early, you’ve created a warning system for both the team and the company that will make any necessary pivots more effective since you won’t spend time convincing the organization to get on board with necessary changes.

    Survival metrics have three levels, each based on the information you’ll get from answering questions about the project. If something is worth stopping the project for, the metrics are STOP statements. Those that lead us to reconsider the direction we’re going in are PIVOT statements. Anything that signals you to lean into the initiative as you build, even if things are a little rocky, is an INVEST statement.

    We Have the Metrics. Now What?

    So, you’ve put together a great batch of survival metrics. What happens next? 

    You need to create a story that can help sustain the metrics and keep them fresh in people’s minds. To do so, employ the three concepts we mentioned above: leading with proof, repeating the story, and then iterating. 

    Survival metrics’ underlying benefit is that they’re iterative. Every time you launch a project with survival metrics, you’ll notice some metrics go away and a few stick around. Those that you keep returning to are a clear measure of what your company cares most about. As you get survival metrics closer to reality through each iteration, the process you build will grow with your company.  

    Leading With Social Proof

    People don’t just accept ideas out of thin air. Concepts need some proof to show that they work before anyone listens.

    This is why conference talks work. The people onstage have been vetted. They are real experts who have some social proof supporting their arguments. The idea here, in short, is that people believe an idea is trustworthy because it has been verified by another source that they trust. The psychologist Robert Cialdini described this phenomenon in his book, Influence. 

    Trustworthiness can come in many forms: Conferences, articles and books can all provide social proof for an idea. This is true for survival metrics, but also for any popular concept. For example, I love opportunity solution trees. Teresa Torres has plenty of social proof, as you can see by typing her name into Google and perusing the pages and pages of results that attest to her expertise. 

    The trouble is, even if you have social proof, that’s not enough by itself. Social proof helps people see you aren’t just creating something out of thin air. There is more to the story, however. 

    If you’re focused on social proof by itself, you’ll notice new concepts start strong but never stick. When it comes to survival metrics, you’ll notice a team starts using the concept, but usage fades during release. 

    Let’s consider an example. A BobCo product leader, Jill, saw someone reference survival metrics in a tweet and began to read about them. She liked the idea and decided to introduce the product team to the concept. 

    Her two product managers, Alex and Erica, took on the task of implementing them with their respective teams. 

    Alex simply introduced the premise of survival metrics to the team. Everyone thought it was a concept that he had created himself. Lacking any broader context, the team just waited to see what was next rather than taking action.

    Erica, before introducing the new paradigm to her team, read the article herself. To better understand survival metrics, she also watched a video from a conference talk and learned that other companies, such as Mailchimp, had used them. She added that background information in her presentation to the team, explaining where survival metrics come from and how other well-known companies had used them. Rather than just mentioning this new concept, she earned some buy-in by telling a comprehensive narrative about it. Thanks to the additional information, people on the team were curious about how they could use survival metrics themselves.

    So, now that you have a story supported by proof, you need to keep telling it.

    Repeating the Story 

    You’ve used social proof to demonstrate the validity of your metrics. Now, though, people keep forgetting that they’re supposed to rely on them during projects. How do you keep things on people’s minds?

    Simple: You keep telling the team. Repeat the concept. Repeat the metrics. Repeat their value. In this case, you’ll repeat survival metrics in meetings, in documents and during standups. Say it over and over. 

    Repeat it until people get tired of hearing it, and then repeat it again. You’re fighting inertia. Since inertia is difficult to overcome when people are settled, you’ll have to continue to sell your work over and over again.

    The story that you’re telling about survival metrics is a story of change. Survival metrics are crucial for an agile organization and its commitment to the Agile Manifesto. Specifically, they allow your organization to “practice responding to change over following a plan.” Keep that principle top of mind and reiterate it along with the survival metrics. Using the agile angle to explain why survival metrics work is the winning move when fighting inertia.

    When you’re doing this, try repeating yourself in different ways. Build a slide that finds its way into every presentation. Write a note at the top of the sprint review to review every week. Make a video that appears with every demo. Just keep talking about survival metrics in a bunch of different ways.

    In marketing, this approach is called the rule of seven, and you’ll hear it every time you listen to a podcast ad. The name of the product and the company will come up at least seven times, implanting the memory in your head.

    Returning to our example, Alex simply said the words “survival metrics” once or twice during the meeting. He never mentioned them explicitly again, instead expecting the rest of the team to remember to use them. Because they were still waiting for more information, though, the team never did anything.

    After the first meeting, Erica added the survival metrics and the relevant storytelling elements into all of the templates the team used. That way, everyone would see them again when they started something new. She also added it to the previous project to bookmark it. When the team saw the updated templates, she took the opportunity to tell a story about the metrics again, segueing into the specific metrics they were using. 

    Of course, repeating the story over and over again will get old, and people will eventually tune you out. This is why the story has to evolve. 

    Retrospect Into Evolution

    So, you’re repeating the point and referencing social proof for support. That is all well and good, but if you do something long enough without adjustment, it becomes white noise.

    Let’s be honest: As good as any tactic is, your mileage may vary since every framework you bring in was made elsewhere. Your company’s culture is unique, so a new framework won’t necessarily land right away. Survival metrics are no different. In my experience, it takes at least six months for a product team to take on a new framework as its own. 

    You have to build your own culture into survival metrics and then let them evolve within your organization’s culture. That’s why you’ll need to have some way to see the continuing validity of the framework and adjust accordingly.

    This is where team retrospectives come into play. In those meetings, you can adjust the tactics you’re using by asking pointed questions and investigating, with your peers, how you can make your procedures better. 

    After introducing survival metrics to his team, Alex only talked about them in one more retro during the quarter. Soon, survival metrics disappeared, becoming just another tool that Alex talked about that never brought any real value to the team.

    Erica noticed the new tool wasn’t inspiring action when she first used them with her team, so she took the time to talk to everyone about why the metrics weren’t guiding action and how to better implement them. They created check-ins to talk about the metrics regularly. The metrics started to improve thanks to having dedicated discussions every few weeks. By the end of the initiative, the team got to a point where they felt very confident in the metrics they selected.

    Remember, frameworks evolve in the team retro. You and the team are the secret sauce for anything to work.

  • How to onboard a product manager

    How to onboard a product manager

    Curology on succulents plants
    Photo by Curology on Unsplash

    So, you’ve made the hire. Congratulations — finding the right product manager who can help your team succeed is a huge burden off your shoulders. As a member of the welcoming committee, you well know that onboarding is extremely important to the success of your new colleague.

    Here are the stakes, according to Harvard Business Review (HBR):

    A bad onboarding process is essentially running that brand-new hire you just made out the door — and a sizable number will leave before they can do anything they promised during the interview process. Onboarding new employees isn’t something that should be taken lightly.

    Except that it is. 

    In fact, Gallup puts the percentage of companies doing poor onboarding at a whopping 88%. That means that you aren’t seeing things — yes, people are leaving jobs rapidly. And while much of that can be blamed on bad management, the specter of bad onboarding can be just as impactful.

    Onboarding in product management

    Those are generalizations about the overall workforce, and while I don’t have a ton of peer backed numbers, I can be fairly confident that the trends follow in the discipline of product management. My conversations with product leaders and founders tend to support that notion, as one of their struggles continues to be keeping great talent. They find that new hires don’t quite find their footing and seem to never reach full productivity. Those folks tend to start looking elsewhere.

    All of that work to bring in someone for them to leave in a few quarters is devastating.

    This article is going to address the difficulties that product managers face during the onboarding process. These challenges are based on the understanding that product managers are there to help facilitate product decision-making within an organization. This means that the first few months of a product manager’s tenure is more akin to being a “detective” than anything else. 

    How a company prepares a PM during the onboarding process can be the difference between a long-lasting team member and a flash-in-the-pan who sends you right back to the hiring boards. 

    The challenges are that product managers have to: 

    • Figure out the company’s place in the market from scratch
    • Understand past decisions
    • Know what their areas of responsibilities are and what power they wield

    Let’s go through each of these in turn. I’ll share a few things you can do to move your new hire along so they can be effective, plus some things to throw into the welcome pack to help them on their way.

    Figure out the company’s place in the market from scratch

    Your company doesn’t exist in a vacuum. Even if you are creating something on the edges, there is often an alternative that your customer base is currently using to solve their problem(s). 

    When a new product manager comes on board, it’s critical that they get this information as early as possible. This allows them to ask questions that can improve the current “map” of the company. After all, you hired them for a reason! When armed with accurate knowledge of the market, a product manager is more confident in the bets they make and less likely to run afoul of silent rules that exist in the marketplace.

    Put these in the welcome pack: A list of current competitors, the rules of the market from leadership’s point of view, and your business strategy, along with all the artifacts that accompany it. 

    Understand past decisions

    The company doesn’t exist in a vacuum, either externally or internally. The team or organization made a number of critical decisions in the past, and the company learned from them. 

    When your new product manager comes on board, they need to know what those decisions were, who made them, and what the company discovered. As they learn this, they get a picture of where they can add value based on their experience and what they don’t need to re-learn. This means they can use their energy effectively going forward. This also applies to the things people in leadership positions won’t do. There’s no need for the new hire to waste their efforts. 

    Put these in the welcome pack: The last six months of major decisions, an org chart, product mission/vision/strategy, and a list of anything that the company won’t do.

    Know what their areas of responsibilities are and what power they wield

    Building on the idea of “wasting energy,” it’s very easy to do so in a new organization, especially as a product manager. When you don’t know what you can do without getting the “ok,” it can be frustrating. It hints at dysfunction within leadership because when these things aren’t clear, people don’t act.

    When your new product manager comes on board, they need to know what they can do. Can they just run a research study without an “OK?” Is it company policy for them to be able to hop on a plane to see customers without your sign-off? How about changing the roadmap? What about bringing in new software? If you are thrown off by these questions, I’ve got more, and they easily compound. Don’t waste your new hire’s time — let them know what they can do without asking permission.

    Put these in the welcome pack: Rules on company spending/training spending/research spending, old research wins and losses, and anecdotes on when the company changed course. 

    Time is of the essence

    You’ve made the hire. The person is coming in the door. They are smart and accomplished and are ready to help make the business better. 

    You trusted them enough with the offer, so help them out, and get them onboarded so they can get right to work, the right way. 

  • 3 common product operations pitfalls

    3 common product operations pitfalls

    person typing on Apple Cordless Keyboard
    Photo by Damian Zaleski on Unsplash

    Product operations (product ops), the product management discipline’s latest way to track and understand the inputs that drive product strategy, is important. Far too long companies have had it “easy” in product development accounting, as projects were often “done” when they were shipped, and the numbers were rarely investigated more than superficially after that point.

    Work from Melissa Perri (CEO at Produx Labs) and Christine Itwaru  (Director of Product Operations at Pendo) in the public sphere, as well as some of the work here at Mind the Product, highlight the importance of product operations. To the uninitiated, product ops represents a systematic way to connect your data and processes to product development outcomes. If you’ve ever wondered what product development “costs”, and tried to model it in a way that helps you forecast, product ops is your skill.

    As a coach for product development leaders at Approaching One, I often chat with leaders about product ops, especially at smaller companies. A very common topic is how they can engage with systematic product ops practices, and use them to make better product decisions with less waste. Of course, this is after the company has committed to embracing product operations. If your organisation isn’t there yet, I recommend looking at Melissa and Christine’s work (linked above) and advocating for it, if you’re encountering that kind of systematic “leakage” in your data and processes.

    Over the course of my conversations with leaders, I’ve noticed a few common product ops pitfalls:

    1. A lack of data fluency
    2. No insight into learning opportunities
    3. Failing to think about innovation

    These pitfalls leave teams not getting the most out of the product ops they’ve set up – which is doubly frustrating for them because the most common goal of starting to deploy product ops is to gain efficiencies! I want to talk about all three, and ways you can immediately use the data you are collecting to get more out of the product operations work that you are already doing.

    1. Lack of Data Fluency

    Many of the tools we use make sure they can import and export data. It’s overwhelming, because suddenly data exists in multiple forms, in multiple tools, for various purposes.

    The key issue I hear about from product leaders isn’t a lack of data, it’s a lack of alignment around that data. To gain organisational alignment, the organisation must have a level of data fluency.

    What is Data Fluency?

    Data fluency is the ability to understand the data that you collect, and being able to apply it to something meaningful. It isn’t how much data you have, but how effectively you can use it.

    As a product leader, you’ll need to be able to judge your team’s ability to understand the data you’re using to achieve business goals. Ask yourself this question:

    If I randomly asked someone in the organisation to tell me what the most important KPI is, where they get the data from and why… could they answer it meaningfully?

    For most teams, the answer is a slightly sheepish “No”. This is a sign that, even though you are collecting good data, there is an opportunity to evangelise better practices and alignment. For product ops to be useful across the organisation, you’ll need to make sure that people understand why the data is important, what are the critical sources of data, and of course – what the key metric is.

    If there is a lack of understanding, well, that’s a great lead-in to our next section…

    2. No Insight Into Learning Opportunities

    Great product teams aren’t judged just by their ability to create things, but also to learn. The more a product team learns in service to a company’s mission, and uses those learnings to create impact while minimising risk, the better the company’s “decision fitness” tends to be.

    person typing on Apple Cordless Keyboard
    Photo by Damian Zaleski on Unsplash

    Learning doesn’t just come with a launch. Every interaction with a customer can lead to learning that improves the decision fitness of the entire company. More importantly, when you have solid product operations going, the data you collect should give you insight on how learning is going across the company, as well as the gaps in the company’s knowledge.

    It’s worth asking yourself this question:

    If I asked people what was the last major learning we had as a company – would people have similar answers?

    If teams are unsure when and where learning opportunities are coming from, then any progress you make on “insights” is random, at best. The point of product ops is to tie numbers to outcomes to improve those numbers, and create a consistent cadence of learning opportunities.

    Speaking of improvement…

    3. Failing To Think About Innovation

    How is your research and development (R&D) going?

    If you are wondering if you have R&D, you do – if you are a young startup, then your entire existence is R&D. If you are a larger company, you still have R&D – and if you aren’t intentionally managing it, then it’s happening in pockets, organically.

    In these ad-hoc situations, this turns into “science experiments”, or projects that come from the bottom up. You’ve probably got a rogue executive with interesting, creative ideas, who may or may not be in line with the vision of the product.

    This might sound like a great idea initially, however, too many uncoordinated science experiments in a company dooms it to being a hamster wheel. If you ever wondered why your team seems to be in the same place despite constantly trying out ideas and experiments – well, I’d bet that you are in the middle of an uncoordinated treadmill.

    Ask Yourself Again – how is Your R&D Going?

    Innovation can happen randomly and organically. However, if you want it to happen consistently, you need some process. If you find yourself in a place where you feel things are the same, like an innovation treadmill, it’s worth investigating that process as a whole.

    Product ops is designed to give you a place to start your investigation. What’s new? What’s different? Where are we gathering information? Is that information useful? How impactful was our last experiment?

    Those questions (among others) will help you understand if you are on that innovation treadmill, or if organisational creativity is a random, chaotic process.  If you find yourself there, asking those questions and making changes to either stabilise or energise can bring some consistency into your innovation process.

    You’ll find some great opportunities through your product operations data.

    Conclusion

    Product operations are important. The data we collect there can lead to massive insights that scale and build across the entire organisation. Having it available and consistent is a huge plus when it comes to finding alignment, and making things happen at high velocity

    That’s why it’s critical to make sure you are keeping an eye on your company’s data fluency, its learning cadence, and its R&D coordination to ensure you’re using your resources to effectively get product operations up and running, and to massively level up your product organisation.

    There’s more where that came from! Access more insights on product ops

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

  • What exactly is a “full-stack product manager?”

    What exactly is a “full-stack product manager?”

    a person sitting at a table with a laptop
    Photo by Microsoft 365 on Unsplash

    What is a full-stack product manager?

    Well, I think we should start by breaking down both terms. Full-stack, in the tech sense, describes someone who is a jack-of-all-trades, but (generally) a master of none. You usually see this term on engineering teams, where job descriptions ask for “full-stack” candidates by requiring skills that are critical for both front-end and back-end work. The expectation is that this individual can fit into any project and drive results.

    Companies generally hire product managers (PMs) to foster and strength alignment between teams, and also to mitigate risk. When the product team is effective, they end up being a force multiplier for all of your resources. When they’re struggling, they become roadblocks to those teams that are creating value for the company. There are several types of PMs, and in this article, we’ll focus on the main three: the product-delivery-focused PM, the growth PM, and the strategist PM. 

    A full-stack PM would combine all three of these types to make the ultimate “full-stack” product manager. Let’s explore these three types and the skills that are most important to each. 

    The product-delivery-focused PM

    This type of PM is responsible for delivery. They often work with engineers often and are judged by the value of the features they ship. When product delivery is going well, it helps teams move forward. But when it isn’t, the team gets stuck in red tape and loses focus on the value of the products the team is putting into market.  

    The product-delivery-focused PM needs to have solid project management skills to keep everything moving on schedule. They also need to be fairly comfortable with the internals of a product, since they are going to be partnered with the engineering team to understand technical debt and feature value. In most places, the “typical” PM is this type. 

    The growth PM

    This type of PM is focused on the business. They work frequently with sales and business analysts and are evaluated by metrics like virality and nominal pricing. When a company is growing, the business is moving toward its goals and increasing its market share. When growth is stagnant or even decreasing, the team ends up trying to balance disparate objectives and KPIs lose their meaning.

    The growth PM needs to be comfortable in sales, marketing, and pricing to keep growth moving up and to the right. In addition, they need to be comfortable with the sales process (whether it is B2B or B2C) because they will be making changes often. Andrew Chen is known as the originator of this position and has written a ton about it here. 

    The strategist PM

    This type of PM is focused on the market. They work with designers and marketing teams and are judged by the alignment of the portfolio. Often, they are also trusted to handle new ideas. When this PM is doing his or her job well, the business is aware/protected from new players entering the market and has some idea of some adjacent markets to explore. When it isn’t, the team is caught off-guard. 

    The strategist PM needs to be a mix of marketer and UX’er and be ready and willing to spend a lot of time with customers and other stakeholders. In general, they end up being the connective tissue of your strategy, tying together intuition and metrics like retention to tell a story. Plenty of companies utilize them when they feel comfortable in a specific market.  

    So, how do you merge all three?

    Alright, let’s be truthful. All of that sounds impossible because it is. The term full-stack is a symptom of teams trying to maximize “efficiency” when it comes to labor costs, without fixing the core issues of the company. If you find the term “full-stack product manager” on a company’s careers page, you should run away, far and fast.

    If your team puts a job description up, it’s worth asking a few questions, such as:

    • What problem does this hire solve for us?
    • How will they integrate with the company?
    • How will this hire position us for the future? What bet(s) are we making by bringing this person in?

    If they cannot answer those questions, then your leadership team is fulfilling headcount just to do so. It might be time for you to save yourself and find a team that is clearer about what they’re looking for in a new PM hire.