Hi There…

First, who am I?

Right now, I am a Product Manager at Intuit and one of the lucky few in their Rotational Product Manager program. That means I get to rotate between three teams within my first two years at Intuit. It also means I onboard and offboard a lot and have to switch between projects often. Talk about adaptability ??.

Why am I writing?

I want to grow in my product manager craft. And the best way I know how to grow is to learn. Writing about my PM experience will help me document and share my experience as a PM so I can a) help others in their PM journey and b) learn from others in their PM journey. I’m only a year and roughly eight months in, but I have learned so much already that I am willing to share.

Let’s start by discussing what I do as a PM. I feel like I often get this question because most people aren’t sure what a PM does. Another question I get asked is how it compares to Project Management or Technical Program Manager. I’ll start with this. The Product Manager role varies from company to company. But we PMs generally do four main things.

Identifying the problem

First, they identify the solution the team will focus on. How the PMs do this varies. In some cases, this is already given by the senior leadership team (what we call a top-down approach). In other cases, the PM analyses customer feedback, competitive analysis, market trends, etc, to identify opportunities and gaps in their product. Then, they try to get buy-in from the leadership team (this is a bottom-up approach). There won’t be just one problem or issue that needs to be worked on. So, you’ll be the one to prioritize them for your team. You’ll also need to define the metrics to confirm that you’ve solved the problem. In my experience, I’ve worked with my marketing partner and analysts to size up problems and help identify which would cause the most significant lift for our north metric or the best benefit for the customer.

Coming up with a solution

Once the problems have been prioritized, the PM works on the solutions for the top issues. In most cases, you’ll work with your XD partner or the marketing partner to create the proposed experience. At this point, the team should expect a Product Requirements Document or a Product Brief. That document is one of the core deliverables at this phase in the product journey.

Implementing a solution

After you have the solution, you have to work with teams to implement the solution. That’s when is where the real fun begins. In the ideal case, you’ll have over the requirements to the devs, and that’ll be it. But that isn’t always the case. Often, your devs might come back and say the solution isn’t feasible with the current tech stack or that they’re waiting on a dependency from a different team before the solution can be implemented. This is when the team sees the benefit of their PMs. Good PMs unblock their dev teams so they can focus on just coding. Some teams don’t have devs and must go to other teams to implement a solution. It’s not easy to ask another team to do something that’ll benefit you. And this is where your persuasive skills come into play. We’re all human and want what’s best for us. So, the best way I’ve seen to navigate this situation is to sell your idea to boost the metrics or customer benefits they’re trying to drive. It could be as simple as explaining how that work adds more revenue for the customer or raises engagement for the teams’ features. Do not lie! Be as transparent as possible with your analysis.

Launching the product! (My favorite part)

After the solution is implemented, you work on the release plan and get the product out there. Post-launch, you monitor the metric you outlined in the PRD to ensure you hit the target. If you’re not, in some cases, you might roll back the solution and reevaluate the experience. My favorite part of this stage is sharing announcements that a product is live. It is rewarding to see something you’ve worked out out there getting used.

As you grow in your craft and role, you’ll focus less on the execution side and more on the strategy piece, i.e., what area teams should prioritize and focus on.

Hopefully, this sheds light on what a product manager does. Project management, which is making sure a project is delivered within a timeline, is only one part of Product Management. A project manager might not work on prioritizing what problems the teams need to solve, for example. At places like Amazon, the product manager focuses heavily on the vision and strategy of the product, while the TPM handles the execution of those projects. So, the TPM would be heavily involved in the last two parts. At Intuit, mature teams have TPMs, but in my first rotation, my GPM did a lot of the strategy, and I worked on executing the vision. Now, I’m doing a bit of both.