What is a Product Manager?
There are many different ways to describe the sole purpose of a PM. Some call it the User’s Champion, The CEO of The Product, The Business’s Visionary, The Strategist, The Connector to Development, etc. If you read 100 job descriptions for a PM, you’ll start to get an understanding of the expectations, but they are usually different from reality.
The Product Manager is a very important role in the company, you are the glue that holds it together and the one who holds the compass to guide the company through the night. First and foremost, you are responsible for being the voice of the User and always keeping their best interests in mind. That being said, it’s one thing to just build features your Users are asking for versus solving their problems with creative solutions leveraging technology.
You are also charged with getting alignment throughout the company in the form of stakeholder meetings and bringing everyone together to achieve a common initiative or goal. To do that, you need to have a strong backbone because as you will learn, it is next to impossible to please everyone at the same time. You will be creating endless proposals and roadmaps to accommodate everyone’s requests while following the vision set by your C-Team (Cheif Executive).
You must also be an expert on your product. Whether you’re just starting out at a new company or you’re building your first product from scratch. Make sure you know every inch of how it actually works, how the sales team is actually selling it, and the workarounds that support is offering your Users. When you do a User interview with an upset User, you should be able to empathize with them, show them your roadmap that you already plan on solving their problem, and provide them with a short-term solution.
Creating & maintaining the roadmap is not an easy feat. You are taking the opinions of all the stakeholders, your User feedback/interviews, competitive research, adoption data, your business plan, development resources & velocity, design capabilities or capacity, and then your instinctive vision and compiling it into a list of features to achieve everything. You will learn that there are much better and more effective ways to do this. There are formulas from Pragmatic, Frameworks from Product School, Templates from Aha, and many other ways.
Some job descriptions ask the PM to be in charge of managing the Development Team. A PM and the Development Manager are supposed to have a healthy tension between them because the PM is trying to build a feature to a 100% of what was spec’d and the Dev Manager is trying to limit the risk and build what their team can handle. If a PM is tasked with both of these roles, he or she will be battling themselves at every Sprint Planning Meeting.
But What Do They Actually Do?
If the product is a success, it was a team effort; if the product fails, it was the PM’s fault.
The reality of the PM life is that you get pulled in a million different directions with 10x more tasks on your to-do list and end up in meetings most of your working days. You're going to be spending a lot of your time collaborating with other team members or departments to either provide your point of view or gather information on theirs.
There are many different ways to form a Product Team, some companies follow Shopify’s model for pizza squads, and some people go with Google’s, or you’re the only PM and running an entire development team. It is always different from one company to another. The structure and size of your team will really change the way you work. For this post, let’s say you’re the only PM and tasked with keeping the entire Development team busy with the help of your Designers.
If this is your first time being a PM, it will be extremely difficult to do this in a 44-hour workweek. In the early morning, you will spend your time looking at your sprint boards, and any new tickets created since you signed off, and then jump into your morning Standups with your team and then join the Dev team’s after. Next, you’ll probably have a management or stakeholder meeting to get input on your progress of the roadmap. During lunch, you’ll take the time to review your adoption metrics and see if you can get any new insights out of your tools, and then you see something that bothers you. There is a big drop in a main workflow’s funnel and you start asking yourself why? That question will stay with you throughout the day until after work when you finally have time to dig deep into the data to see what the cause of the dropoff is.
The afternoon will be spent trying to schedule a User interview for that week, or reading the Support chats to gain some new insights on that week’s release. Up next is to manage the Backlog of Bugs before your next Sprint meeting. You only have time to look at the Highests and Highs, and then decide you should retest a couple to make sure QA understands the issue and reported the ticket properly. As you’re retesting a Bug, you run into another smaller UX issue and take the time to log it properly in your ticketing system. Finally, you’re able to settle on your top 10 bugs you’ll add in the next Sprint.
After that exercise, you decide to open Slack and see all of your unread messages and missed calls from your sales and support reps. You take the time to catch up on everything you missed and handle anything that came up by scheduling a follow-up meeting for the next day. Next, you see your Dev Manager’s message explaining that there are a few unknowns on the next feature’s spec. You quickly open Confluence to see your Senior Developer’s comments and questions about the feature that possibly highlights a technical issue because your legacy code can’t handle the improved workflow.
This makes you question how much technical debt do you need to plan for on your roadmap. You decide you need your CTO’s input on this matter so schedule a quick 15-minute call with them and your Dev Manager to discuss the technical debt incurred from your legacy code. You compare that against the amount of time you have blocked off on your roadmap or increase the percentage of time on each feature to account for the re-write of code.
Now it is the end of the workday and you look at your to-do list for that day and see you didn’t accomplish anything on your list. You decide you’ll spend a few extra hours working to knock off a few tasks.
Product Management Resources
There are many resources available for those who want to get into Product, and no, an MBA is not a requirement, although it is helpful. If you’re truly interested in being a PM, then you are a naturally curious person and will have no issue reading, listening to, or watching some of these resources to up your level of understanding.
First, you should read Inspired by Marty Cagan, it will explain how to build a product that your Users will love. It also gives a lot of information on what frameworks work best, and how a PM’s relationship with other co-workers and departments should be. Next up, jump over to LinkedIn or YouTube and find Product School’s channel. They have endless amounts of video interviews with real PMs from amazing companies that are truly inspiring and teach you a lot of how to be a productive one.
There are many institutes, online Ed companies, or other organizations that can give you an official certification for Product Management. Before committing to one of those entities, do your research to make sure that the certifications are recognizable by the organizations you want to work for. The Pragmatic Institute is an awesome organization that allows you to take your time to become a fully certified PM. They give and teach you everything you need to know to become or continue to be a successful and organized PM. They provide you with the resources after you’ve completed the Foundations course that you will learn throughout the entire curriculum. Most job descriptions will ask you to understand Agile Development & SCRUM. These are two frameworks that will help you save time, and help run an efficient team.
First Few Months as a PM
In the first year as a PM, you will have a lot of days that I described in the second section of this post. Truly, that kind of a day is when you’re in the weeds too much and haven’t built in proper processes to support yourself or your team. Now, not to say that you should never have days like that, but they can be more structured and have a routine instead of following your calendar and being reactive all day.
You need to build and maintain an effective relationship with essentially everyone in your company, obviously, there are few companies where this is possible. Your company needs to believe that the Product Manager is doing all the right things and knows all of the pain points that the Users are having. Again, you will not make friends with everyone, but you should certainly try to.
If you’re coming into a new company, your first month should only be about learning and understand WHY they do things in a certain way. You should be watching all of the Sale’s team’s demos with prospects to understand how it is being sold (maybe oversold or over-promising), but you’ll understand WHY Users are paying for or using your product. You should read your Support Team’s live chat or email threads with Users to understand what pain points the Users are going through. That will guide you in the right direction for where to begin searching for problems to solve. You should schedule meetings with any and all managers of each department to start building those relationships.
Arguably the most important team you need to get to know and become partners with is your Development and QA Team! These are the women and men who are building what you write down and what the Designers prototype. You need to build and maintain relationships with each of them to ensure that you always have an open dialog with them for them to ask questions when they are blocked, don’t understand, or have a better idea than yours. They are the ones writing and working with the code and will have a different perspective on the product than yours, so their input and feedback will be vital to your success. That being said, engineers tend to overcomplicate things, so before accepting their suggestions, think it through from the User’s POV.
You should be having regular meetings with your C-Team to ensure that you’re following the vision set by the CEO, in line with the business plan the CFO created, operating within the resources that the CTO has or has planned, listing to the COO’s pain points of the competition’s sneaking upon you, and then the CMO’s marketing plan to see what volume of prospects you can convert.
Working for a startup, you will most likely be wearing a few different hats such as Data Scientist, Intermediate UX Designer & Researcher, Manual QA Engineer, Junior Designer, Support Specialist, Legal Counsel, Product Owner, SCRUM Master, and probably a few others depending on your industry. I mention all of these roles because you are supposed to be an expert in all areas of your product, your Users, and your industry. That is one reason why you may never experience a day similar to what was written in the second section.
Ideally, for the first month or so while you’re getting started and established at your new company, you would also join the morning standups for the Sales & Support teams too. Most likely they will be at conflicting times of Product & Development’s, so ask if they can be recorded or scheduled before or afterward. This will give you a sense of what these teams are struggling with, what they plan to achieve, and it shows that you’re listening to them. It is a great way for you to build relationships with all of your co-workers.
Product Manager Core Responsibilities
The following is a mix of Core Responsibilities that a PM owns at a Startup, please notice the distinction between Core Responsibilities and a Job Description. A Job Description sets the expectations for what to expect on a day-to-day level, but as a PM every day is different than the previous. Core Responsibilities outline the most important tasks to accomplish to be considered successful.
Product Documentation will be the first and foremost important responsibility that a PM owns. This will range from writing Business Requirement documents to Feature Specification documents, to Technical User Stories. You will also be tasked with writing P&L Statements, Integration Proposals, Build VS Buy Scenarios, Product & Business Strategy plans, and last but not least Competitive Comparison documents.
Building & Maintaining a Product Roadmap will be the second most important requirement of the job. This is tricky because there are two kinds of roadmaps you should have in your Startup, Short-Term & Long-Term roadmaps. Short-Term is within the next quarter to a year, and the Long-Term roadmap is for the next 5 years. These are both vital to the companies success and organization because Development needs to know what they are building in the long-term so that they don’t code themselves into a corner for a short-term need. Sales may have a very long sales cycle, and they are selling what is on the roadmap to win opportunities. Support may be relaying your Short-Term plan to frustrated Users to convince them to not churn.
Stakeholder Collaboration would be next up on that list. These are the opinions of people inside and possibly outside your organization that will have a direct impact on your roadmap. It is extremely important to clarify that these are opinions, and it is your responsibility to find the evidence, data, or research to either support them or disprove them.
Prioritization of Features & Bugs will follow that up because the Stakeholder’s opinion or their value may impact your prioritization. You’ll learn at Pragmatic that there is a simple formula for roadmap prioritization that is all based on evidence. You’ll most likely be using a spreadsheet to develop and maintain your prioritization for the roadmap, but there are many inexpensive tools to allow you to perform this task more efficiently such as Productboard or Jira’s relatively new Roadmap feature. The most important lesson (90% of the time) when determining prioritization is evidence and data. There are cases where you will need to rely on your instinct, and that is why every PM should read or listen to Blink by Malcolm Gladwell.
Conducting Primary Research is an important part of being a successful PM and the main form is by performing User Interviews. You need to get boots on the ground (virtually with COVID) and have a conversation with your Users. If your objective is to uncover or highlight a suspected problem, use the 5 Why’s Framework to ensure you’re digging deep enough into their problem. It is essentially asking the User “Why?” five times after they’ve explained their first issue. You aren’t there to find their desired solution, you need to know the problem to solve before even hypothesizing a potential solution.
User Empathy will be guaranteed to be one of the most repetitive requirements when reviewing different company’s job descriptions. The PM needs to understand who the User is and how they are feeling for a variety of reasons, primarily for uncovering their actual problems. As the PM, you absolutely need to understand your target audience and create your personas to know who you’re building or solving for. You can’t do that without talking to them, listening to them, or reading their messages/emails.
Working with your Development Team is crucial to solving the real pain points that your Users are experiencing. As mentioned above, the PM must build and maintain healthy and open relationships with their Dev Team for countless reasons. Being collaborative with Stakeholders was third on this list, and you should consider your Dev Team as a main Stakeholder with multiple points of view.
Summary
In short, a Product Manager is without a doubt the most important hire in a company and they need to have enough autonomy to be the detectives to find the hard problems to solve and hypothesize creative solutions for your company to be successful. One Core Responsibility that is not mentioned in the above section is Leadership. That is because, for most, this is a personality trait that you either have or don’t. Not to say it can’t be learned or improved, but natural-born leaders will have an advantage over those who aren’t. The reason why Leadership is so important is that a PM leads without authority (in most cases). They are not the sole decision-maker, yet the entire company acts as though they are.
That is why this quote holds so much importance - “If the product is a success, it was a team effort; if the product fails, it was the PM’s fault.”.
