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.
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 terms. Roadmaps 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.
