AMA: Optimizely Chief Product Officer, Rupali Jain on Product Management Career Path

Based on your question, you already realize that title is a very small part of making this transition. If you want to move to product, start thinking about the types of projects that you take on that get you working with the product team closely - on partnerships, its better to focus on tech partnerships for example, which work more closely with product teams. Become the partner liaison to the product team or to a part of the product so you can take on projects that help you see what good product management looks like and get you some experience closer to the function you'd like to move to. Most importantly, if you have the time and ability, I'd highly encourage you to take on a project or two that helps the product team in some way, no better way to learn a job than by doing it. You can obviously also learn through mentors, buddies, trainings etc, but I find that product management is learned best through apprenticeship and by doing.

I'll start with the second part first. Be direct about what skills you are hoping to develop or share that you are hoping to break into product management, and let the person you are hoping will mentor you know that. Whether you position as a formal request for mentorship, or simply let the person know you respect them and would love advice, the focus should be on establishing the relationship. For me personally, the word mentor has a higher bar than someone simply asking for advice. If I've never worked with you before, I'd prefer starting a casual series of conversations before giving the relationship a name such as "mentoring". The construct is the same, just the bar feels lower :) - mostly because in a mentoring relationship, I expect the mentee to put in the work to think through what they need, and if I'm meeting someone for the first time, I don't know if they expect to put in the work, or if they expect me to figure out what they need. I love folks from different disciplines moving into product. At this point in my career, I'm probably best suited to someone looking to transition from outside product into a product leadership role vs. an early career product manager, but I've mentored several folks in the past that want to make this transition and have enjoyed it. Based on research that has been shared with me in the past, a mentoring relationship is most successful if you are within a couple of levels of your mentor -- too much distance, and its hard to get concrete suggestions.

I'd always encourage you to think through impact and understand it before building a feature. Ask whoever is pushing you to build, ask your peers, validate with customers -- do whatever you can to understand and describe the problem your feature is solving for and how you'd measure impact. That said, especially earlier in your career, if you do have features that you think drive no impact, a couple of thoughts to help you think through - Uplevel your thinking to that of your boss or whoever gave you the feature to build. Think about the context they have on the business and why you think it was important for them to have you build this feature. Think about what assumptions may have been different for them vs. your understanding and try to unpack those differences to the best of your ability. While this may not fully get you to your definition of impact, you may understand the assumptions and expected impact and compare to that. Of course, there is always the option to assume good intent, and think about the best possible outcome for the feature, and measure to that. When representing on a resume, think about the skill a feature helped you develop or the metrics it did drive, even if not perfect and use that lens to capture how the skills add value to your next role. If you have other features/deliverables/work that actually drove impact, you can easily leave out one or two features that you dont believe had any impact on the customer or business. It's much better to focus on what you did that drove value or helped you learn than being comprehensive in capturing every feature you built on your resume.

The biggest strengths (and believe me its a huge benefit, and one I look for in all candidates) are being scrappy and getting sh** done. As an entrepreneur, you are forced into an environment that isn't perfect, that doesn't have all the structure or support you need to succeed, so you are forced to figure out your path to goal by trying different approaches and you quickly learn what does and doesn't work. This is an incredible way of learning and one that will serve you well in product management and as a candidate. You are also likely more willing to take risk, which depending on the company can be a net positive. If you are looking at startup roles then I'd say all your experience comes to play and you should shine as a candidate quite naturally. I would balance that scrappiness with identifying where structure could help you move faster, especially if you are looking at roles in mid or large size companies - they also want to know that you can work within the structures and teams that already exist. On comparison with FAANG - there are advantages of learning the craft from folks that have done it for a long time, so you learn a lot of really good habits on how to be a good product manager, you also learn how to influence larger teams and drive alignment. As long as you recognize where you bring strengths and where you need to learn, that's a lot of what matters.

Oh, I could write about this for a loooong time :). I'll condense down to a few key traits * Critical thinking - do you have the ability to understand and articulate the problem you are solving for and then finding a solution that works * Collaboration and communication - PMs work through influence. Being able to work with and communicate with peers and stakeholders is critical to success. I look for the ability to structure your thoughts and have strong verbal and written communication as part of this. * Execution chops - PMs absolutely need to be able to write a spec, work with engineering to deliver a feature, measure and track success, and iterate. This is non negotiable. You maybe the best at everything else, but if you can't be strong at execution, its going to be hard to deliver value * Define product direction - Understand customer needs, the market, your specific value proposition and define the roadmap for your area - for a more junior PM it may only be 1-2 quarters, for a senior PM 2-4 quarters and longer for principal and above. You may change it but can you help the team set a path and show them a way to get there * Make people around you better - PMs always lead a team, as an early career IC, you are still setting the direction i.e. leading your engineering team. Do you take the opportunity to help people around you get better i.e. do you help raise the bar across the folks you work with- could be as simple as sharing the business goals towards which you are headed, helping someone get better at written communication etc.