Product Management is vital to running a successful company. Technical product managers are unicorns who turn ideas into reality.
As humans, we have a natural pull toward understanding the world through stories. Stories help us understand and make sense of what we see and feel. Stories also give us a point of reference to better understand our purpose. This blog about technical product management will take a break from the typical day-to-day product management struggles, help you think about product management cycles in a new way, and help you find the bravery you need to succeed in the chaos.
Table of Contents
What Does a Technical Product Manager Do?
What Exactly Does it Mean to be a Technical Product Manager?
Perhaps We Should Use a Metaphor for Exploring What it Means to be a Technical Product Manager?
Technical Product Management in the Real World: Grainger and KeepStock?
Common Product Management Stages
Why is Product Management Difficult?
Two Primary Challenges Contribute to the Difficulty of Product Management
Technical Product Management
As product managers, it is our responsibility to project ourselves into the future and develop solutions to the issues that exist here and now. After that, we travel back to the present and attempt to persuade people that the thing we created for the future should be built and is worthy of investment.
If we’re successful, our work will consist of traveling between the past and the present, removing roadblocks to the team’s development, and modifying the invention based on what we’ve learned along the way.
We repeat the present = future process, sometimes multiple times at once, and sometimes circularly.
But before we delve into those cycles, let’s get technical.
What Does a Technical Product Manager Do?
Product management is the process of creating and managing a range of products, both digital and physical. Product management is the process of managing projects and products that are the result of a design, engineering, or marketing team based on customer needs.
However, there is more to product management. It is more than just ensuring the product is delivered on time and within budget. A product manager also has to consider the product user experience, the brand, and the company’s value proposition. Product managers have to be aware of the technical requirements of their products and the market. In addition, they need to balance functional product requirements with non-functional requirements, such as security and reliability. They also have to be aware of how to communicate the value of a product to both the company and the customer.
Ultimately, they are the ones in charge of taking an idea, a brief, or a customer pain point and transforming it into a product.
What Exactly Does It Mean to be a Technical Product Manager?
While there are technical definitions, they only take us so far. We must probe deeper to get to what it means to be a technical product manager and why product management is important.
Perhaps We Should Use a Metaphor for Exploring What it Means to be a Technical Product Manager?
Imagine that we are living just before the Middle Ages and that our village is facing the difficult challenge of bears continually robbing it of all of its food. This is a problem that we cannot ignore (pain point).
In our capacity as members of the Product Guard, we propel ourselves into the future to find a solution to the issue. We delve into theories (both discovery and ideation):
- We could kill all of the bears.
- We could construct a castle to keep the bears out.
After weighing our options, we decide that building a castle might be a better investment than going on expensive and time-consuming bear hunts.
We start visualizing what this castle will look like, drawing pictures of its dimensions and shape, and making educated guesses about the number of people required to construct the walls and raise the roof. The team makes a rough estimate of how much it will cost in terms of both materials and labor, and then we write down our thoughts on six pages of parchment.
We tell the queen about the idea; she loves it and agrees to give money to help make it happen.
The undertaking is then kicked off by the town’s engineers and architects.
While we are at it, someone suggests that we dig a moat around the outside of the walls as well. It’s a good idea, but it’ll add two months to the total project time (scope creep). They argue that there will never be a time when digging the moat will be easier than it is right now, prior to the construction of the walls (tech debt). They are correct, but we point out that we would also have to construct a drawbridge, which would mean that we would also have to invent a pulley system, which would mean that we would also need to find some strong thread to make rope out of, and the next thing you know, we’d be shaving the local herd of yaks.
After we end the discussion about the moat, we find out that the local rock quarry doesn’t have enough rock for the entire design. Because of this, we are forced to decide whether we should finish the outer walls or the inner buildings first. Additionally, we conclude that we have not adequately considered what we will do in the event of a fire. We will work together with the engineers and architects to find solutions to all of the issues that arise during our trip.
A few months later, the glorious future has already arrived, and we now have a castle.
“We underestimated the time and resources required by 20%, and the cost increased by 50%. People are overjoyed that we successfully excluded the bears from the area, even though the structure does not look exactly like our drawings.”
Now that we know people are getting cold at night, we start hurtling back in time to figure out how to fix our heating problems while also starting to build the moat (continuous cycle).
And so, the quest of the Product Guard continues.
While I’m sure you agree that the above is a great story, maybe you’re like me and would appreciate a little less metaphor and a little more concrete example.
Common Product Management Stages
| Term/Stage | Middle Ages Metaphor | Real World |
| Pain Point | Bears keep stealing our food. We can’t ignore this problem. | Our clients didn’t want to spend too much time calculating how much to buy to keep vending machines stocked. |
| Ideation & Discovery | Product Guard members look to the future for a solution. Theories are explored.
1. Kill all bears. 2. Build a fort to repel bears. |
We thought of ways to help:
1. Customers could place orders with us to ensure vending machines are full. 2. Delegate someone to regularly restock the vending machine. 3. We could program our machines with sensors and an inventory management system to automatically place orders. |
| Scope Creep | Someone suggested we also dig a moat around the walls; good idea, but it’ll add two months to the project. | We suggested adding cameras and facial recognition software to the machine so people wouldn’t have to swipe company badges. |
| Tech & Hardware Debt | They say digging the moat will never be easier than before the walls are built. We agree, but we’d also need to build a drawbridge, invent a pulley system, find a strong thread to make rope, and soon we’d be shaving yaks. | We were limited by outdated, broken vending machines. |
| Continuous Cycle | Now that we know people are getting cold at night, we go back in time to solve our heat problems while starting the moat project. | Even before we were done building, we started adding forecasting models and analytics insights to the re-ordering logic to make it smarter. |
With these two examples, one mythical and one real, it’s clear that the main thing they have in common, aside from being stages of product management, is that they are both challenging.
Why is Product Management Difficult?
Technical product management is difficult because it is difficult to see the future. Product teams are constantly challenged with decisions about what is most important to build next.
Two Primary Challenges Contribute to the Difficulty of Product Management
- Inventing new things and projecting yourself into the future are both creative activities. To be creative, one must be willing to wade into ambiguity and the unknown. That is something that not everybody enjoys doing. It is a difficult and isolating experience. Even though it is definitely a skill that can be learned, the process of doing so is not very enjoyable.
- You are constantly in the wrong. The world is a disorderly place, and any predictions you make about the future are doomed to be proven incorrect. Being mistaken is, in a sense, part of our job description because it indicates that our thinking is sufficiently expansive to be able to address issues that truly matter. However, that does not make it any more enjoyable. Not only are we required to be incorrect consistently, but we must also do so with grace.
Product management is characterized by uncertainty. This is because the product management job is all about taking risks, trying new things, and making big bets. However, not all risks are equal. Some risks can be taken with a high degree of certainty, and some risks can be taken with a low degree of certainty.
Conclusion
Technical product management is often a difficult and stressful job. Not only do you have to have a deep understanding of the technology, but you also have the ability to communicate that understanding to your team.
However, product management is an interesting and challenging job that enables you to have a significant impact on the lives of those around you!
Thank you for reading; I look forward to reading your comments.
