Tag: PRODUCT CALCULUS

  • Can common challenges in project management be solved through calculus?

    Can common challenges in project management be solved through calculus?

    Because the world moves so fast, product management is seldom a linear process. We can’t afford to let our thought processes be linear, either. Welcome to product calculus.

    student sitting on chairs in front of chalkboard
    Photo by Shubham Sharan on Unsplash

    Think back to your school days, and specifically math class. As you moved past arithmetic, you probably started your journey into advanced mathematics with algebra. As you built up your mathematical skills, you may have taken any of several different classes: geometry, advanced algebra, trigonometry, probability and statistics, and so on.

    Often, a high school course of study in math culminates in calculus. That’s because, to master calculus, you need to have a solid foundation in all the other forms of advanced math. Calculus encompasses and builds on aspects of each of the other branches of math you’ve learned to that point. It challenges you to synthesize all your skills and take a step forward in your intellectual journey.

    So, why am I talking about high school math? Well, it turns out that this provides a pretty good analogy for product management. When it comes to product management, some people are doing product algebra and others are doing product calculus. I’ve found that a lot of people in product think algebraically long after they should have progressed to calculus. So, let’s talk about how to avoid that and how to deepen your product thinking just like you did with your mathematical thinking.

    WHAT IS PRODUCT CALCULUS?

    Product calculus is a philosophy that embraces the fact that, as product managers, the ground is constantly shifting under our feet. Rather than settling for the easy answers and false certainty of a linear process, product calculus uses a mental model based on its namesake branch of mathematics to account for constant change.

    Product Algebra

    When I talk about algebra, I am focused on equations. Think about the equation 2x + 2 = 8. You can easily solve for x here because you’re looking for exactly one answer that fulfills the problem.

    You can show the answer, and you can easily tell people how you got it. This entire process is a straight line. So, when I talk about product algebra, what I’m talking about is that straight line.

    Product algebra boils down to how we, as product managers, can get straight answers to people. Now, if you’ve done product management, you automatically know that idea sounds weird because most of our work has nothing to do with straight answers.

    How often do you get a chance to give someone a straight answer in your role as a product manager? Product management is contextual, which is why straight answers are hard to give with regard to how to do product, or even how to operate as a product manager. The ground is always moving underneath the PdM.

    If you say you give straight answers all the time, then I’m going to guess that you aren’t actually doing product management. More likely, you’re doing product development delivery, helping things go from ideas to market. This is a serious role, but it’s more suited to project managers who have tools and processes that are designed to get teams aligned and ship products.

    Product management isn’t here to help a team just ship software. In fact, sometimes, when a product manager is doing their job, no software gets shipped at all. Why? Product management’s main job is to heighten the decision fitness of an organization.

    That doesn’t always mean shipping software. Your success shouldn’t be tied to how many lines of code flew out the door. Your job performance should be tied to how well your work empowers the organization to make smart decisions. This means helping to clarify strategy, which is always contextual.

    Contextual factors include everything that can affect the work you’re doing. This might be the product itself, the customers and the marketplace, the internal environment of the company or even the politics of the U.S. as a whole. None of these factors are static. Anyone who has woken up to find alarms ringing thanks to a massive bug or a piece of legislation like General Data Protection Regulation can attest to how quickly things move in the world of product management.

    This incredible pace of change means that strategy can’t be linear. You’re trying to synthesize all kinds of complex issues, and you’re trying to determine the probability that the next action is the best action. If all this were as simple as solving for x, then algebraic thinking would be fine. But again, if you can give straight answers, then you’ve probably found yourself doing delivery. I’d argue it’s not a great use of your time or talent as a PdM.

    Product Calculus

    So, if everything is contextual, how can we think about our work in mathematical terms?

    If only there was a branch of math that focused on continuous change. Well, we’re in luck because there happens to be one devoted to just that: calculus.

    Why is calculus relevant here? Well, since product management is primarily about improving the decision fitness of the folks involved in a product’s development, and all of those factors are constantly moving, then the job is a lot more like calculus than algebra.

    Product managers are in the strategy business. Strategy isn’t about telling you where the puck is right now. It’s about telling you where it’s going.

    The biggest mistake that product teams make when it comes to strategy is treating all the information they receive as if it’s static. That outlook leaves the decision fitness of the team dead in the water, and I’ll show you why.

    Product Roadmaps and Product Management

    When I see a team’s product roadmap, I can instantly tell if they’re stuck in algebra land.

    Why talk about roadmaps here? For many folks outside of the discipline, the roadmap is where the rubber meets the road. It’s how people gauge the worth of a PdM since they’re often the most impactful document that they see come from the product manager. Look at any product management job description, and especially one written by a non-PdM, and “Make a roadmap” is often at the top of the list of tasks the PdM will be doing.

    Most companies get roadmapping wrong, though, because they’re thinking about things in product algebra termsRoadmaps are not themselves strategy. They are an output used to get folks aligned around the strategy. When a team isn’t careful, they can mistake the artifact, the roadmap, as the strategy itself.

    When a team thinks this way, they can find themselves looking to solve an equation. That equation often looks like feature X + feature Y = market success. This almost never happens, though. More often than not, a company then goes back to the drawing board, just trying in vain to remake whatever the hot new startup is.

    So it bears repeating: Roadmaps are not strategy. They are a communication tool designed to prepare a team to execute the strategy.

    Let’s talk about two teams. One approaches their strategy with a product algebra lens, and another that practices product calculus.

    RELATED READINGHow to Become a Product Manager, According to 3 Experts

    Tackling the Roadmap Algebraically

    Leadership gives the product team the following direction: They need to satisfy the market, improve customer relations and make investors happy.

    The product leader, working with the product algebra lens, immediately thinks about the roadmap. They do a competitive analysis and look at feature requests from their most preferred customers. Soon, they have a roadmap, looking about a year in the future, ready to go.

    They feel good about themselves, and leadership feels great about everything as well. After all, knowing where the market is going is a good thing, and they have some features that are ready to take the world by storm.

    This is all well and good, except you can expect any and all of the following to happen:

    • Timelines Slipping: As a product person, you have more than likely seen timelines slip, oftentimes just by pure acts of God. All it takes is one bug, and that perfect map you’ve set up is out the window.
       
    • Backchanneling: As the timelines slip, teams often politicize decision making. Things are falling behind, so they need to rely on whoever they know “gets the job done.” As communication happens along multiple axes, more than one version of the truth begins to emerge. There’s the roadmap and the “roadmap.” Different teams make different decisions based on whether they’re in the in-group or whether they’re following the company messaging. When this happens, one thing is for sure: It will end up as a big mess.
       
    • Customers Changing: While this is happening in the background, your customers are continuing to ask for things. Sure, the customer had ideas about what they wanted three months ago, but I mean, that was three months ago, right? How long are they going to wait?

    As these problems unfold, the team is still diligently working through the roadmap that the leader put together at the beginning of the year. The problem is that the product algebra mindset is linearly focused, looking to solve equations and get a single output. Nobody in this model has the capacity to handle changes to the plan.

    Why do teams do things this way? Despite the obvious problems, algebraic thinking has one benefit: It provides false certainty. Making something, anything, fit an equation is so much easier than worrying about the rate of change.

    Roadmaps are fragile communication documents that unfortunately often take on the characteristics of doctrine. The mistakes outlined above are only going to compound. Remember, context is always shifting. Some people will cling to the roadmap, given its doctrinal qualities, and others will ignore it altogether. Nobody will be aligned, nobody will have any way to adapt to changes, and things will only get worse as the context continues to evolve.

    You can see how these issues really start affecting the long term health of your product team.

    Let’s take a look at how the other team deals with the same circumstances.

    Calculus Thrives on Change

    Leadership gives the product team the following direction: They need to satisfy the market, improve customer relations and make investors happy.

    This product leader sees the roadmap as a communication tool for the strategy. It’s a means to an end. Knowing that the ground is constantly shifting, that leader makes a strategy based on bets that are focused on outcomes.

    These bets should have a few components. They need a question or a problem we’re trying to solve to give teams a place to start. That leader also makes some decisions that can help guide the team by laying out priorities. For example, the team might prefer quality over speed. There should also be a confidence level of completion to help teams gauge risk.

    Following the instructions given by leadership, a product calculus roadmap could look like this:

    • The market is trending towards AI, and so let’s bet on automation. This bet means that question X (based on the situation) should have our focus due to problem A. We prioritize failure over building product this quarter. Due to our circumstances, we foresee this as an investment and have 35 percent confidence that we’ll end the quarter with a prototype.
       
    • Customer relations are disconnected, so let’s increase our investment in them. We’re looking to answer question Y, due to problem B. We prioritize building deep relationships with our current customers over generating new ones. Due to our circumstances, we have a great relationship with our customers and have 95 percent confidence that we’ll end the quarter with a prototype.
       
    • Investors are pushing us toward an IPO, and so let’s decrease our offering based on question Z, due to problem C. We will prioritize quality. We have 50 percent confidence that we will stay on track to IPO.

    Why are these things important? In each bet, we’ve given those that read our strategy an understanding of our motives. The roadmap that follows can lead directly back to these bets and has the freedom to change when necessary. When teams look at the bets, they can make better decisions and move the product forward through shorter feedback loops that use those bets to get aligned.

    For example, instead of just going through a sprint with goal to build a feature, as we would when doing product algebra, you can now check your work and metrics against those bets during your planning meetings instead of just trying to follow a timeline.

    What does this approach do over the course of a year?

    • There is no timeline slippage since you aren’t making promises to the market. You’re only looking to solve problems. From those solutions, you’ve made the promise to look toward outcomes.
       
    • Teams are free from a timeline based on a magic feature. They can now decide to take on the problem on their own, eliminating the need to toggle between the roadmap and the “roadmap.” That ends any need for backchanneling since they own the bet. They can look for problems to solve and move forward at their own pace.
       
    • What if the customers request changes? Well, which bet do they fit under? If they aren’t critical or tied to the strategy by falling into one of those categories, feel free to ignore them for now. They aren’t important yet.

    Since you are operating as if the ground is shifting and living inside of the ambiguity of reality, you can simply consider how fast it’s shifting and act based on that information.

    Product calculus deals with that shifting ground by saying: “Hey, we don’t know exactly where we are, but we do know things will keep changing. Let’s adjust accordingly.”

    MORE IN PRODUCT MANAGEMENTNew Product Development: A Primer

    Start Thinking About Change With Product Calculus

    There are plenty of concepts beyond just the roadmap that product owns to which you can apply this framework. If I had to leave you with something, though, it’s that being a product manager isn’t straightforward.

    The best thing we can do is improve our decision fitness and use that to communicate clearly. That’s why a calculus mindset is so vital: It primes you to thrive in the real world where context is constantly shifting. When you’re doing product calculus, you’re less likely to be blindsided by anything because you’re always anticipating changes.

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