AMA: Volley Head of Product/VP, Roshni Jain on Product Management Career Path

While Product Manager (PM) roles vary based on team dynamics and business context, certain fundamental skills are essential for any successful PM: * Excellent communication skills * Analytical thinking * Leadership and collaboration abilities Beyond these core competencies, the environment in which a PM operates significantly shapes their experience and skill development. In an entrepreneurial setting, a PM often: * Owns a larger product scope: Taking responsibility for multiple facets of the product with broader oversight. * Wears multiple hats: Stepping into roles like designer, product marketer, or data analyst as needed. * Engages in hands-on execution: Doing whatever it takes to help the team succeed, often involving direct involvement in various tasks. As a PM at a FAANG company, the experience shifts toward: * Negotiating and collaborating across teams and departments: Working within a large organizational structure to secure support for projects. * Navigating robust and detailed processes: Following established procedures to get approvals and bring products to market. * Demonstrating strong written and verbal communication skills: Presenting to senior leaders and articulating ideas effectively. * Tackling challenges of scalability: Addressing issues related to massive user bases and high-volume operations. Both sets of experiences are invaluable. Gaining expertise in diverse environments helps build a well-rounded PM profile, enabling you to excel in various contexts.

The great news is that you don't typically need to make this decision early in your career; you can gradually explore both paths to determine which suits you best. The split between an Individual Contributor (IC) Product Manager and a People Leader PM usually occurs at the Product Lead or Group PM level. As a high-performing Senior PM, you might have the opportunity to take on a slightly larger scope related to your area, which could include managing one or two direct reports. Many companies facilitate this transition by first promoting you to a Product Lead, where you act as a player/coach. In this role, you continue to manage your own team while also overseeing and mentoring a junior PM who leads another team. This phase is highly instructive. It allows you, as the Senior PM, to experience the initial responsibilities of a people leader and understand what the role requires. If you find it enjoyable and it goes well, you can progress to a Group PM role, where you might still be a player/coach but with additional direct reports. As you advance further in the people management track, your team size grows, you relinquish direct responsibility for an individual squad, and your role becomes more focused on cross-collaboration. However, if you discover that you don't enjoy the Product Lead or Group PM roles, it's an opportune time to switch back to an IC PM position. You can secure a role as a Senior or Staff PM on a high-impact project or team that requires someone with exceptional skills to drive a large initiative across the organization. By testing the waters in both paths, you can make an informed decision about which career trajectory aligns best with your interests and strengths

That's a great question, and I'm glad you're thinking about it from a Product Manager's perspective. A team's velocity is influenced by many factors and is largely within the team's control. When I've seen teams dramatically increase their velocity, they usually follow a pattern like this: 1. Recognizing the Need for Change: A catalyst emerges that prompts the team to focus on velocity. This could be frustration over a project that lacked impact or dragged on too long, or organizational pressure to increase speed. 2. Measuring Velocity: The team begins discussions and selects a system to measure its velocity. There's no one correct method; the goal is for the team to see improvement relative to itself. Often, teams start measuring how many story points they complete per sprint or the percentage of planned points they actually complete. 3. Conducting Regular Retrospectives: The team holds frequent retrospectives to analyze what's consuming time. They ask questions like: Are tasks taking longer than expected? Are tickets not well-defined? Are we dependent on other teams for answers? Is there too much context switching? Based on these discussions, they propose experiments or process changes to address the issues and observe the impact. 4. Tackling Tech Debt: One major discovery might be a substantial amount of technical debt in a certain area. Addressing this usually requires investment but can greatly enhance velocity by simplifying a category of work. For example, one team I worked with refactored their entire front-end to use React, reducing the time needed for front-end changes from days to hours. Through this iterative process, teams often significantly improve their velocity. This journey takes time but can be immensely rewarding in terms of boosting the team's confidence, satisfaction, and overall impact.