Three Lessons I Wish I Knew Before I Became a PM
Avoid the misconceptions that I had about product management, from the perspective of a former BizOps employee and investment banker.
In my last post, I discussed the five myths investment bankers have when deciding on a career switch into the tech industry. In this article, I want to highlight three day-to-day things I didn't expect when I switched to product management. Until I became a PM, my managers from my prior roles came from investment banking or management consulting backgrounds. I was not prepared for how different product management would be from my past roles.
In my first week as a PM, I immediately started attending 15-minute "standups" three times a week. Our product team also operated in 2-week "sprints" comprised of various "tickets" related to experiments, bug fixes, or investigations in Jira. It was a very different environment than what I was used to before. I quickly learned that this type of process was called "agile." I also met weekly with my designer, data scientist, and engineering manager to discuss upcoming experiments or tickets. This type of close, constant cross-functional collaboration was much more involved and interdependent than how I worked with my colleagues in investment banking or business operations (“BizOps”).
My team was very gracious and welcoming as I learned how to become a PM. However, knowing what I do now, I wish I had known the day-to-day differences between investment banking, BizOps, and product management.
So I'm here to do that for you! Below are the top three lessons I learned about the differences between professional services-oriented fields and product management.
Lesson 1: You are judged by the outcome, not the output.
As an analyst at an investment bank, I was measured by how quickly and accurately I could make all the edits my seniors wanted on “outputs,” such as presentations, financial models, or ad-hoc analyses. In BizOps, my team was modeled like a consulting firm. In consulting, the recommendation is equivalent to the "output," and performance evaluation is judged on the output, not whether or not the recommendation worked (the "outcome").
However, this viewpoint shifted when I transitioned to product management. The experiments we ran were evaluated by the "outcome" rather than the "output" (e.g., What was the magnitude of the results? If we roll out the experiment to 100% of users, what is the annualized impact?) There are nuances where all experiments are evaluated to some extent by the research and methodology. However, two central pieces of the performance evaluation are the project-level and the personal-level impact that I contributed to the company.
This shift in thinking is neatly summarized by Melissa Perri in her book, "Escaping the Build Trap."
Products are vehicles of value. They deliver value repeatedly to customers and users without requiring the company to build something new every time.
Services, unlike products, use human labor to primarily deliver value to the user.
In a company that sells products (e.g., software), you are solving to deliver the maximum amount of value to users in the most efficient way. Users can also repeatedly gain value from the product. Outputs are created if they serve and impact the broader outcome of increasing value to our users.
Professional services firms can certainly deliver substantial value to their clients and customers (by no means do I want to downplay the tremendous talent and extra mile that many professional services firms go for their clients). But by the nature of being services-based, value is often measured by billable hours and project costs. While Partners and Managing Directors are judged by their “outcome” (e.g., ability to close deals or new client projects), junior employees often are far removed from how their hours (the "output") translate into actual client impact (the "outcome").
Lesson 2: There is never a clear "done." There is always a backlog that you constantly prioritize.
In finance, consulting, and BizOps, there is often a "done." "Done" is when the deck is sent before the client meeting, the deal transaction closes, or the recommendation is presented. You mentally can "clear the slate" and then either relax ("on the beach," as consultants call it) or focus on another deal or new client.
This is different in product management, especially for digital products. There is always something to improve, experiments to run, and ideas to test. With software, you can continuously iterate, send updates, and improve the product in real time. There is never the same "done" as in professional services.
Along with these experiment ideas in the backlog, there are also engineering and design constraints to consider, so it's a constant trade-off and evaluation of what to prioritize. For every idea, I ask myself: "What is the expected level of impact?", "How much is the effort?" There is no longer a Managing Director giving top-down orders on what exact projects I am doing.
As a PM, I have a direct say in how the work for my products gets prioritized. For example, one of my product areas was launching a free trial for our Premium product. Although I provided status updates and had review meetings with my leadership team, no one explicitly told me what I needed to do to launch the product. Instead, I had to interview users, work with designers and engineers, run experiments, and analyze results with a data scientist to determine how we should best launch and optimize the free trial experience. As a PM, the scope of my work and how much I want to iterate on free trial experiments before the official launch was up to me.
Lesson 3: Stakeholder management and relationship building are how products get built, measured, and assessed.
How you work with colleagues and other teams in investment banking and BizOps is often very different than in product management. In investment banking, the data often comes from the client via a data room, and your "cross-functional partners" might involve the lawyers or capital markets teams. As an analyst, the team you are on is responsible for executing the work (e.g., financial model, presentation deck) and ultimately pushing through with the deal.
In BizOps, your "stakeholders" are more your clients than team partners. The interactions you have with other teams primarily involve requesting data from the data science teams or project managing a project. However, the role of a project manager is ultimately limited to executing an already agreed-upon decision.
As a product manager, the execution of ideas is entirely dependent on your stakeholders, hence the importance of "influence." PMs don't execute any design or engineering task. Instead, they help gain buy-in and resourcing for an idea, write out the initial requirements and scope, and partner with designers and engineers to make trade-off decisions and prioritize as the work progresses for an experiment or feature.
My experience as a PM is like a coach, thought partner, and listener all in one role.
My cross-functional partners look to me to help set the direction of what to work on and prioritize. Still, as unexpected things come up, I closely listen to the opinions of my engineering, design, data science, and marketing partners. I often agree with their viewpoints, but sometimes, I disagree and have to balance being empathetic while also explaining why we decided on a different direction.
As you think about becoming a PM, I hope my experiences and the three lessons I learned are informative for your decision. This role is very different from finance, consulting, and BizOps, where I could directly work on the output. While I have loved my career switch, it comes with its own set of challenges and new skills. As a PM, I don't do any of the actual "building" of the product. I lean on and trust my stakeholders.