So you want to be a Product Manager? And not only in title! You aren’t looking to write requirements, hand them off to the development team, release, and repeat. You’re looking to discover the right problems and opportunities to solve for your customers. You want to create an inspirational vision for your product and bring that vision to life. You strive to create products that customers love. (1)
I’ve been on the product team at several companies prior to Realtracs and I can say that being on the product team at one company can – and does – vary from being on a product team at a different company. The title “Product Manager” is becoming more pervasive in the technology industry and it’s often hard to know what it actually means.
But there are distinct characteristics of Product Managers that set it apart from other similar roles – even ones with “Product” in the title.
What does a product manager do?
Product Managers don’t solely write user stories or translate a list of requirements. We work to understand our users, build customer empathy, and understand the problem behind a request. Discovering how our product is being used and identifying what the most valuable things to work on is a daily activity. We want to validate our hypotheses after we release the work — and if we can’t, we want to understand why.
Don’t misunderstand: writing user stories and understanding what is required is important. Outlining expectations on how a feature should work helps set expectations and alignment; but what I’ve learned is that a user story (or job story/whatever format your team uses) is most valuable when it is a conversation starter. Product Managers must be able to collaborate with engineers and designers to articulate the needs of the user, but perfect documentation and having every question answered isn’t required.
Product Managers don’t dictate solutions. We work closely with engineers and designers to build the best solution. It won’t always be the product manager’s idea (just like it won’t always be the designer’s or the engineer’s). In my experience, the best solutions take a variety of inputs from multiple team members. And in the end, the goal should not be whose idea it was, but rather answer these questions: Does this solve the problem? Is this valuable for our users? Is it feasible for us to build?
Customer Value
Product Managers value planning and setting goals, but our primary goal is delivering customer value. Delivery is an important aspect of being a Product Manager, but bear in mind that being a Product Manager is much different than being a Project Manager. Product Managers do come up with plans, set goals, and need to be good at executing, but perfect execution is not the end goal. We want to continuously deliver value to our customers and that may deviate from our initial plan.
On Slack under “What I do”, our CTO’s answer says: “Whatever is most valuable at the moment.” At Realtracs, we are constantly asking ourselves if we’re working on the most valuable thing and we challenge our assumptions frequently. Yes, we set goals for our squads that align with our vision, but we don’t let the desire to finish all our goals trump adding the most value for our users. When we find that we must pivot, we pivot.
Getting into the product manager mindset
When I interviewed at Realtracs, I was asked some really good questions that helped me get into the mindset of being a Product Manager. Spoiler alert: these are questions that you don’t stop answering after the interview is over and you’ve landed the role.
How do you define and measure success?
Not only do you have to know why you’re building and releasing something, you have to know how you’re going to measure the success of it. In some organizations success is measured by finishing on time or maybe even amount of feature usage, but without doing the deeper work of developing the right metrics, you may miss valuable opportunities to learn and improve.
Your metrics may look different over time as your product evolves – and that’s okay. Also, this is something that a Product Manager should be thinking about before and during the development process, not once it has been shipped.
How do you decide what to build next?
This is the Million Dollar Question for Product Managers to answer. Sometimes the answer is clear based on market trends, technological advancements/change, or customer feedback. Sometimes the answer requires more research.
It is easy to fall into a pattern of leaning on stakeholders or customer support to tell you what you should build next. Or to follow a predetermined “roadmap” that has been laid out by a committee of leaders. But as a Product Manager, you will want to have a voice in this. Having a roadmap can be useful, but asking questions and doing discovery can be more useful and produce better outcomes for your team and product.
Teresa Torres has a great model that can help bring clarity about opportunities to pursue. (2) Rather than starting with features to build, you start by asking questions, including:
- What problem are we trying to solve?
- What are the ways we can solve this problem?
- How can we test that our proposed solution is the right approach to solving this?
Keep in mind: the most important word for a Product Manager to know and say is “No.” Just because someone believes their request will be the Next Big Thing, doesn’t mean it is what your team should focus on.
How do you prioritize work when demand exceeds capacity?
Demand will always exceed capacity. Your users will always want more than what your team can produce. It is not uncommon for the expectation to be: “Fix what people are complaining about” or “We’re building this because <fill in person, client, angry customer> told us to.” As a Product Manager, you will play a crucial role in determining the priority of work; you must balance “keeping the lights on” with delivering value that your customers and users are requesting.
At Realtracs, one tool we use to help determine priority is by measuring the cost of delay (3): what is the cost of NOT delivering something, be it a bug fix or a new feature. Two things are considered in calculating cost of delay: how urgent something is and how valuable it is. We also are intentional about strong collaboration with our engineers to ensure we are aligned and understand how to break down the work required to deliver timely and valuable updates to our users.
Know thyself, grow thyself
Having a growth mindset is important in all areas of life, even as a Product Manager.
Becoming a Product Manager is an evolution; it takes time to grow into this role. Depending on your background and previous work experience, you’re probably going to have some knowledge gaps, some may be bigger than others. The truth is that you’re not going to be a 10 at everything.
Additionally, there is no singular path to becoming a Product Manager. I’ve worked with product folks who got into the role from various avenues: customer support, marketing, design, direct industry knowledge and experience, software/technology backgrounds, etc. You may have a lot of industry knowledge, but not as much technical knowledge. You may have a keen eye for design, but not as much experience with strategy and growth. But investing in yourself and in your growth as a Product Manager is an investment that won’t go to waste.
Shape Up!
At Realtracs, we value being “T-shaped.” Being T-shaped refers to having a deep knowledge or specialization in some domains, while having a broader or shallower level of knowledge in others. While this attribute gets applied a lot to developers and technical knowledge, the same is also true for Product Managers; the skills are different, but the principle is the same. Some areas that Product Managers should invest time in to expand their “shape” include:
- Gaining industry and domain knowledge
- Building relationships with customers and users
- Learning your product
- Developing communication and strong leadership skills
- Technical and design skills
There really is no one-size-fits-all approach to being or becoming a Product Manager. There are a variety of skills and responsibilities that set it apart from other roles. But no matter where you are in your Product career, rest assured that there will always be more to learn – demand will always exceed capacity. 🙂
Additional Resources
- Book: Inspired, by Marty Cagan
- Blog: Opportunity/Solution Trees
- Video: Cost of Delay – An Introduction
