Lexi Lowe

Every company is different but I can tell you what I've been working on as a part of my transition to product leadership: * Impact - as an individual contributor I proactively drove high profile company wide initiatives that helped me to show that I could make a huge impact for the business in addition to evolving the product experience and functionality. This forced me to understand what mattered to the business and how product changes impact business outcomes and helped me to get a seat at the table for company wide strategic changes. * Communication - being a strong communicator in lots of different forums was a huge area of focus for me. I had to get comfortable building relationships with and presenting to our C-suite, presenting to our company & sales organization regularly, communicating through slides and written documents. The biggest strength that I have in communication is conveying complex concepts in a synthesized way and I've found that this is essential as you move up within an organization and work with executives more often. I've really had to focus on developing relationships and being more flexible in my approach because I'm a very direct communicator and building relationships requires evolving that approach to be effective with all different communication styles. * Team Management - the biggest difference between being an individual contributor and a Manager or Director is instead of driving forward innovation directly in partnership with Engineering and Design, you're helping and empowering your team to do that innovation by coordinating resourcing, helping to guide high level strategy and providing coaching and accountability. This is an entirely different skillset and you have to be interested and motivated to make the switch away from the known into this known area. In my experience, I explicitly asked for these types of experiences and helped to drive my promotion because I was interested in growing in this way and I believe that management skills are a lifelong learning, not a check box.

I think the most common mistake that I see is jumping to solutions quickly. This is definitely my biggest mistake as I started as a product manager. For me, it was/is really easy to think I know the answer and to move quickly from the unknown/undefined to the known/defined stage and ultimately check something off the list by delivering it into the hands of customers. However, the role of the product manager is to stay in curiosity and research and the unknown for long enough in order to get enough information from customers and cross-functional partners to define to the best solution to solve the customer's pain while balancing that with the goals of the organization and your core product principles. And all this while driving urgency around achieving results. A tall order!

Based on my experience working at both smaller startups (25-50 people) and larger companies (1000+) as a product manager, there is merit to both. I really appreciated starting my product career at a larger company because there were established processes / best practices and resources like design and dedicated engineering teams and other practitioners to learn from. This allowed for me to understand the mindset and process of doing product at scale which I then took with me when I moved into working at startups, helping to evolve the startup chaos to create industry standard processes for product, design, engineering and stakeholders. However, the pace at the larger companies I've worked at has been slower and therefore it takes a while to get the cycles in and cycles are what allow you to refine your product process and sense. Working at a startup on the other hand offers lots of cycles, which really allows for quick practice, lots of mistakes, and results in acceleration in learning. I don't think you can go wrong either way but it definitely depends on the amount of structure vs. chaos that you're interested in as you're developing.

I have two tips for breaking into Product Management but I'm sure there are many more. The first is to work with Product Management in your current role and/or talk to current Product Managers. Product Management can be seen as a very appealing job but many don't understand the day to day and trade offs of the role. By working with or informationally interviewing folks who are currently doing the job, you'll get more information on whether the job is actually for you and what appeals to you about it. The second is to use Product principles in building something new or improving an existing thing in the course of your current role. This could be an internal process, application, or something else. The idea is to apply product thinking and process to something in your current job to see if you like the way of doing work and the type of work. Both of these suggestions will help you to both understand if Product is a career for you but also will prepare you to interview for the role.

Product management is different at every organization and there are many organizations where it is more of a project management function. If your manager is assigning project management work - talk directly to them about it to understand their expectations of the role and share what you're interested in focusing on. Usually you can find a path forward that will allow you to do the higher impact work. If you can't, leave! There are other organizations that really value folks who can set a vision and strategy and ensure that the execution is building value for users and for the business. I find that directly communicating the issue will get you clarity either way.

This isn't easy and many companies, including Hex, are looking for domain expertise to maintain a super high velocity in driving value for users. Learning a domain takes a lot of time. However, there are things you can do to be a more effective interviewee when you don't domain experience: * Demonstrate strong fundamental product skills (focus on the why and the outcome that you drove). * Practice your interviews and come with strong preparation and communication. Focus on the effectiveness of your communication. * Do your research on the domain and the product and demonstrate an understanding and a perspective in your interviews. Always use the product in advance of your interviews and apply your product expertise to identify hypotheses of strategic shifts or UX improvements that you'd consider if you were to take that role. Talk to product users to understand their current pains or read reviews or online forums to understand the user perspective. * Explain and show your passion and enthusiasm for the new domain that you're trying to crack into. Proactively address why you want to shift domains.

From personal experience, I've made a couple mistakes that I can share: 1. Not doing enough research or having answers to pushback readily available (this makes you look weak and degrades trust in your recommendation or ownership). 2. Pushing an objective without understanding the other perspectives or priorities of stakeholders (this makes you look unprepared and degrades trust and collaboration). Ways to mitigate these: 1. Spend your time to prepare your roadmap with lots of research (customer, prospect, field, data, market, competitive etc.) Work with your manager or peers to brainstorm or identify gaps in your roadmap in advance. Make your roadmap and reasoning bulletproof and well documented. 2. Spend time with stakeholders who are involved on a one-to-one basis to understand their current priorities and their perspective of your area and what they think is a top priority. Truly consider their perspective, they may have a point - people can tell when you aren't actually engaging with their perspective. Ask a bunch of questions to deeply understand. This allows you to prepare to present why you're moving in the direction that you're moving instead of their alternative path proactively and have a meaningful discussion about it. In addition to building a deep understanding of their perspective, building a strong relationship with stakeholders allows for you to have a basis of human connection to build from and tackle misalignment together.

There are different opinions on having an engineering background and the ability to write code for Product people. My perspective is that its easier to come together with your engineering partners when they are empowered to drive the code level details and you are empowered to define the requirements so you can make technical tradeoffs together but each have your respective ownership. I've seen collisions when product managers also are engineers and they get too deep into the technical details and are stepping on engineering's toes. However, a basic understanding of code is helpful. For example, being able to edit a markdown file, write SQL or set a feature flag is something that you'll likely have to do so getting a light understanding is helpful.

When you're first starting out in product, you're building your product tool belt and the focus is on execution, customer empathy, technical depth and collaboration to drive a (measurable) outcome. As you become more senior, being able to drive a strategy based on a deep understanding of users, the market and being able to effectively prioritize to drive the biggest business outcomes becomes critical. Being able to align with cross-functional stakeholders and leadership is a huge focus. This requires really strong collaboration and communication skills as well as a deep understanding of the user and market. To become even more senior, you need to build leverage - this could be helping other PMs to help drive forward the strategy that you've help to set or empowering members of your engineering and design team to drive impact so you can deliver even more depending on if you want to move into management or stay an individual contributor.

Retaining talent is not easy because there are so many options for great product people. I focus on the following and it has been fairly effective: * Challenging them to do bigger and better things with more ownership and responsibility. * Supporting them when they need unblocking and a thought partner. * Providing meaningful feedback around growth opportunities and support to grow in those ways. * Rewarding & celebrating their successes.