Skip to content
Get Started
cPrime > Resource Center > Blog > Product Management > Product Managers – Everyday Superheroes Without a Cape

Product Managers – Everyday Superheroes Without a Cape

There’s this product management group that meets at our office in Minneapolis. Unfortunately, I usually don’t have the time to participate in their very cool discussions, but this past month I’m guilty of eavesdropping on their conversation. They were kicking off, going around the table and introducing themselves. One of the icebreaker questions was “Who’s your favorite superhero?” I couldn’t help but think to myself that every one of them is my favorite super hero because they are all product managers.

The people around that table work in varying types of product roles and have drastically different levels of experience. Some call themselves business analysts and spend their days “gathering requirements.” Some are team-level agile product owners, acting as the voice of the customer and the conduit between the delivery team and other stakeholders. Some are technical with engineering backgrounds; some bring expertise in user experience, and others come from the line-of-business their products serve. Some are strategic thinkers, acting as CEO’s of their product while others are fighting to keep up with the day-to-day, tactical demands of their teams. Despite their differences, the people around that table are incredibly united because they have one important thing in common. They are all plenty familiar with the challenge, reward, and yes, struggle of being a product manager.

Product Managers Are Superheroes

Being a product manager is incredibly rewarding. In the best of scenarios, you get to craft a vision for a product, influence the process of bringing it to life, and watch it have an amazing impact on people. Even when you support a mature product, you get to understand user problems and be the driver who helps solve them. It was this that drew me to product management. It was the first time I could see beyond lines of Java code to how we were actually helping people.

The harsh reality, though, is most of us aren’t going to be having any Steve Jobs-type moments any time soon. We are working the day-to-day slog of trying to do more with less while attempting to please all the screaming voices around us. Everyone wants more than we can possibly do. These “to do” requests come from all directions – executives, finance, sales, marketing, UX, engineering, ops, support – oh yeah, and don’t forget the customer.

All types of leadership are hard. I admire engineering leaders, marketers, finance folks, and senior executives who also make difficult decisions day in and day out, but product management offers a unique set of challenges that set it apart. Here’s why:

  1. Product managers must influence without authority. They do not directly manage the people who will execute their vision.

  2. Product managers must continuously make difficult choices on behalf of their product and accept that no matter the choice, at least some people will always be displeased.

  3. Product managers must advocate for the holistic interests of their products and can’t act strictly on behalf of a single stakeholder group or function of the business.

Influencing Without Authority

I’ve always had a little trouble with the title ‘product manager’. A big piece of what makes being a product manager difficult is that you rarely are managing anything. Literally, it means you are managing your product, but that is an innate notion. As you are not actually managing the team of people who design, build, test, and support your product, anything you need to accomplish, needs to happen through a process of influencing that action. It is definitely not as simple as just ordering it up. We should call this job ‘product influencer’ or maybe ‘product advocate’ because that’s what we really do.

When I was a developer, I thought the product managers had all the authority. When I became a product manager, I thought the development managers and senior executives had all the authority. In both cases, I was close-minded in my thinking. Product managers do have authority to make decisions, just not all the decisions. We get to make certain decisions at the level in which we work and must make them within the framework and intent provided by those working at levels above us. Also, to be truly effective, we must constantly get our teammates to understand and buy into those decisions, so we can all move as one. This influencing process is repeated over and over again. Luckily, as we gain experience and build relationships with our teammates, it gets easier.

Making a Call

When I was kid, I used to umpire Little League baseball. Umpiring is a lot like product management. You are a somewhat neutral party but still have to work and move with the players and other stakeholders (like coaches and fans). It is your job and responsibility to make sound and timely decisions. You make calls repeatedly throughout the game based on what you see in a moment. You must make a split-second decision and don’t always have all the information you need. You make mistakes but have to keep going and not let any single mistake cloud future decisions.

That being said, umpiring is way easier than product management. In baseball the decisions are very Boolean – safe/out or ball/strike. In product lifecycle management, on the other hand,the decisions are anything but. There are always a ton of different factors. Also, in umpiring when you make a call, only half of the people are mad at you. In product management that percentage tends to be much higher.

Advocating for Your Product

We are also the main advocates for our products. Scrum defines the role of the product owner as being the voice of the customer. If only it was that simple and the customer’s needs were the only ones we needed to consider. It isn’t that simple. We have to think of our company and our business. Is the product driving revenue? Is it a strategic play or maybe a cash cow? What does the company need from us to justify continued or increased investment in this product?

You have to consider the technology. Products are living things that need to be nurtured and cared for. If we don’t consider their technical health, they will grow old, become obsolete, difficult to support, and break. We have to do things on behalf of the technology that have no visible benefit to the customer in order for the product to be able to continue to serve the customer. Customers themselves have different needs as we consider user needs versus buyer needs, and the list goes on.

People in UX roles and product managers often bump heads and have a lot of questions about which types of decisions should be owned by whom. When this comes up with clients, I always tell the UX people that they are lucky ones. They only have to advocate for the interests of the user while the product manager has to advocate for so much more. This is why at the end of the day the product manager tends to be the final decider (hopefully, only after she has listened to and considered the perspectives of her teammates).

Influencers, Deciders, Advocates, (and Definers)

In short, successful product managers within are influencers, deciders, and advocates. You may be asking within what sort of a framework do we get to perform all these activities. That’s where product definition comes into play and this is also where we get into the nuts and bolts of the real work we do as product managers. Although this simplifies some real-life situations, I like to think of product definition in three layers. We start at the highest level with product vision, strategy, and chart a path for achieving those things with a product roadmap.

The middle layer takes one of the roadmap’s initiatives and brings it to life. We move from a few words in a bullet point to defining what we are building, why we are building it, and who we are building it for. Through the product discovery process, we explore user needs, the experience we’d like to provide, and select paths or journeys that allow us to incrementally construct that experience. These journeys can then be ordered via prioritization and stand as high-level backlog items like epics in Scrum or features in SAFe.

At the lowest level, we take one of those journeys and break it down into user stories and acceptance tests. These describe the behavior we desire and provide our teams with independent, valuable, and testable units that we can experiment and learn with.

Product managers do their magic at each of these levels of product definition. If that isn’t enough fun for you, this picture is often complicated by companies that have multiple products and products that have multiple teams working on them.

In this blog series, we’ll highlight the opportunities product managers have to influence, decide, advocate, and define within three common structures of product organizations.

  1. One product manager owning one product being worked on by one team

  2. Multiple product managers owning one product being worked on by multiple teams

  3. Many product managers owning many products being worked on by many teams

We’ll discuss real-life strategies and share actionable steps for influencing, deciding, advocating, and defining regardless of your level in the organization. Additionally, we’ll discuss the pros and cons of working at each of these levels and dig a bit into common career progression in product management. Stay tuned!

Need a new product strategy? Learn how you can get from planning to launching faster!

Click here!
Anne Steiner
Anne Steiner

Privacy Policy