Rookie Revelations
A Newcomer's Perspective on Product Management
My first 3 months as a product manager were very exciting, but also pretty overwhelming. I remember feeling like I was drinking from a firehose from all the new information that was being thrown at me. Lucky for me, I had come from the implementation and onboarding team so I had experience working with the product I was now helping manage. However, there was still much about the world of product that I had yet to learn. By applying some core principals and being methodical with my approach, I was able to get up to speed as quickly as possible. Below I speak about some of the key steps I found to be extremely helpful while getting started with product management.
Know Your Product
It should come as no surprise, you need to get familiar with the software product you will be helping manage as soon as possible. Start by thinking through the pain points and use cases that a customer would have when purchasing the solution. It is critical that you understand this so you can speak to the value proposition that it has, which will serve as the core function that the future decisions you make should strive towards. With this in mind, put yourself in the shoes of a customer who has just purchased your solution and practice utilizing the product to solve the pain points identified. Make note of the pros and cons. Ask yourself some important questions such as:
Does it cover the functionalities required by a target customer?
Is it intuitive and user-friendly?
What steps/processes need to be completed to begin seeing value?
How can these steps be improved to see more value or see it quicker?
As you familiarize yourself with the product, you will also uncover the data that it is utilizing and how it is being applied. This is the first step in translating the user experience to the nuts and bolts behind the machine that make it operate. Once you have knowledge of the solution from the end user perspective, it becomes much easier to decipher how the product is built from the engineering perspective. The next step in knowing the product is to understand the technicalities of it, which can be learned by meeting the teammates that have knowledge on this subject.
Meet the Team
As with any new job, its important to meet the team members that you will be working closely with. Product management can be a bit unique from many other roles in that it requires cross-functional collaboration amongst various other teams. This includes others on the product, engineering, design, marketing, sales, and customer facing teams. These teams must be aligned on the value the product has to offer and how it should be presented to customers.
Start by scheduling 1:1’s with team members on your product team and learn about what they are working on and some features they’ve built in the past. They will be great resources as you learn to navigate this new environment and help provide clarity on the vision that you will be working to achieve. You’ll need to constantly be in sync with your team to understand the priorities of features and enhancements to your product.
Spend some time getting to know some of the key members on the design team that you will be collaborating with. Have them walk you through some current designs they are working on. The design team will be a great resource for understanding why features are built in certain manners and they will be your go-to for creating new designs for features you will build. Do the same for those on the engineering team you’ll be partnering with to get a sense of how they work and develop the software. As a product manager, you will be regularly meeting with the engineering team to share ideas on how to improve the software and to understand the technical design (and limitations) of the solution. I found that I was asking my engineering team nearly a dozen questions every week when I was getting started just so I could map together the data architecture and back end logic that allows the product to run.
Lastly, take the time to meet members from the customer-facing roles. This will include the product marketing team as well as sales and onboarding/customer success where applicable. These teams are the eyes and ears of the market and will be great resources to get direct feedback from the frontline on what the pain points are for the target audience of your product. Learn how the product is sold and what it takes to assist customers to gain value.
Learn the Team Workflow
When meeting your team members, you’ll want to start thinking about how often to meet with them so that you are in sync with all your teams. Meeting on regular cadences helps improve communication across teams. Here are some of the meetings that I found to be helpful when starting off:
1/week meeting with product team - this is a great chance to learn what projects others are working on and figure out which dependencies are needed from other teams.
Ad hoc meetings with designers (1/week on average) - when creating a new feature for a software product, product managers must work closely with the design team to create a mock (or draft) of what the feature will look like. First, the vision for this feature must be explained. I typically create a ticket with an overview of the pain point this feature solves and some of the details it must include to address it. I will then meet with my UX designer to explain it and answer any questions. My design team then uses figma to create mocks. After each iteration, we typically schedule a meeting to review the changes and discuss what updates are needed.
1 or 2/week meetings with software engineering team - in my current position, the software team I work with is largely based out of China which can make for a tricky time difference to work around. If possible with your work-life balance, meeting with software engineers even more frequently that once or twice a week may be helpful. These meetings will be used to both “groom” tickets you create well as get an update on the status of current tickets being worked on. Grooming typically refers to refining the requirements and technical details of a ticket for a new/updated feature that is assigned to a software engineer. More on this in the next section.
Biweekly meetings with customer success, onboarding, sales, and product marketing teams - these meetings are extremely helpful for receiving feedback from the field. Customer success and onboarding teams can help highlight the pain points and feedback that current customers have. Sales and product marketing can provide feedback from prospects as well as provide insight on the latest trends ongoing in your products’ target industry.
A large factor in determining your meeting schedule will depend upon your release schedule. This is the schedule in which code changes for the software are released to the main users (production environment). The team I work on currently operates using 3 week intervals.
Understand the Project Management Approach
Different teams may have different project management approaches. Oftentimes, an Agile approach may be taken for managing projects. This is how projects are broken down into phases. A few key principles of agile methodology include:
Customer Focused - there is strong emphasis on customer satisfaction and responsiveness to changing customer needs
Iterative - these projects are divided into small, manageable iterations (sprints) that allow for quick feedback
Collaborative - discussions across teams (such as those mentioned in the previous section) is very valuable for constant progression
Adaptable - requirements can evolve over time so there should be some flexibility in project scope and allow teams to shift priorities
Before even starting in my role, I did research to understand the agile methodology that my new team was using. Then when I joined, I was able to take this knowledge and apply it to my work. This impacted how I approached developing and improving upon product features with my team. I used this as the gateway into writing epics and stories (also referred to as tickets).
Based on the methodology your team is using, there is likely a software being used to execute on these projects. In my case, we were using Jira to manage our software development projects. This is where “tickets” (typically a request for changes to a product) were created, prioritized, and assigned to software engineers. After my teammates gave me an overview of how they used Jira and the way that our team organized the tickets, I took some time on my own to read through tickets created by other product managers to get a better idea of how a story should be written. Reviewing others product managers’ work on your new team is very valuable early on.
If you are lucky enough to be able to carry-on the work of another product manager, start there to learn how a ticket get’s planned and assigned for development from beginning to end. Meanwhile, begin crafting your own epics and stories and prioritize them based on which ones would have the biggest business impact. Ask for feedback from other product managers and engineers to see how you can improve.
Over the last months in my new role, I have noticed large and rapid improvements in my ability to craft epics and stories. This includes adding more context for why the changes should be made, specific details about the requirements of the ticket, more clear and concise descriptions and images, and better communication between the teams to ensure we are all aligned on the expectations. Just like agile methodology, I too refined my skills in an iterative and adaptable process.
