AMA: Hex Head of Product, Lexi Lowe on Product Management Skills

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.

Every product leader is different but I'd say there are generally two primary flavors: 1) amazing executors who work with strong visionaries or 2) strong visionaries who work with amazing executors. Having awareness about your superpower and finding a company to complement your strengths is critical to being successful. No matter what your superpower is, there are some basic hard skills that are important: * an understanding of your market and market dynamics * user research & customer interaction skills * a design or user experience sense and the ability to provide meaningful feedback on designs * technical depth and the ability to chart a path in partnership with engineering * data analysis and the ability to set meaningful measurable goals * strong written, visual and verbal communication * financial acumen and the ability to make a basic financial model * the ability to collaborate with legal to ensure that you're evolving the legal agreements to sell your software * basic understanding of the tools of the trade such as Figma, Jira, GSuite, BI, Zoom, Salesforce, etc.

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.

I believe being decisive is absolutely essential for product people. This is because it unblocks your counterparts and increases velocity if you're able to make game time decisions. Analysis paralysis is the antithesis of velocity. However, being a good product manager means that your decisions are based on a deep understanding of the business and the user and your own product sense that you've gained through releasing software. Decisiveness without that context will only waste engineering cycles and will not lead to meaningful outcomes for your users or your business.

I'm so excited that you're teaching PM skills to non-PM people. I think everything can benefit from a product approach. The most important thing that you could educate on is building user empathy and research to deeply understand the problem and relative priority that you're trying to solve in the context of your larger business strategy. This helps to understand the value of solving the problem to the user and the business and informs the solution you create. Steps to apply product process to anything, my recommendation would be to focus on STRATEGY and RESEARCH & PRIORITIZATION: * STRATEGY: Understand the larger business strategy that you're trying to drive. Make sure that you focus your time on driving forward those top objectives. * RESEARCH & PRIORITIZATION: Talk to your users about their experience, understand their current pains and the relative priority for them of solving those pains. You may find that the thing you want to do is low priority and doesn't really impact them and there's something bigger to tackle. This is hugely valuable because solving the biggest problems leads to the highest ROI. Make sure that these pains align to the business objectives that you're trying to solve. * IDEATE: Brainstorm ways to solve the biggest problem with other people, maybe even your users! Identify a couple paths that make sense to solve. * PROTOTYPE OR DESIGN: Create potential solutions and present them back to your users for feedback. Understand how their life would change if they had that solution and what they don't understand or have questions about. * MEASURE: Identify a way to measure the impact of your solution and measure it before and after launch. * LAUNCH: Launch your solution with multi-modal communication, maybe in person training, written announcements, and more! * ITERATE: Not every solution is the right solution from the get go - talk to users about the solution that you put out and make it better (if its worth the investment).

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.

Your organization may have resources to build a baseline on data analysis and engineering acumen and you should seek those out first and engage with them. I try to read everything in the internal wiki and the public facing docs when I start a job. Next, find a mentor who does their own analytics or works in engineering who can walk you through a deeper level. Specifically, get mentorship around these skills as a baseline: * running a query to answer a data question that you have * building a dashboard * setting a good measurable target * building a basic financial model * walking through the architecture of your product area * understanding the tech stack that you're using and the overall development process I find that finding people to help you deepen is valuable for two reasons: 1. you're learning skills 2. you're building relationships with people who you can collaborate with more strongly later because you've built a relationship. Usually, it benefits folks to help you strengthen these skills because having a strong PM collaborator makes everyone's life easier.

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.

Effective communication - this is extremely hard because you have to communicate with so many different kinds of people to build clarity and alignment. It is not a one size fits all approach and the only way to get great at this is experience, soliciting feedback and intentional iteration. When I have a product manager on my team who can communicate with sales, engineering, design, leadership, customers across written, visual and verbal mediums - they're worth their weight in gold.

I took the Product Management course from General Assembly and I thought it was a helpful foundation. I recommend reading Inspired by Marty Cagan to any new product manager. However, product management is such a broad set of skills and expectations and is practiced differently at different companies so the best teacher is learning by doing and collaborating closely with your manager to ensure that you're up-skilling on the most impactful dimension for your role. If your manager isn't proactively providing recommendations, come with your own plan for up-skilling and get their input. This will show that you're motivated to learn and grow and ensure that you're focusing on the most important things for you to progress in your role.

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.

I think most great PMs come from a different field first. I have not worked with anyone who hasn't but I know they're out there. This is because the context that you gain from whatever your field is will help you have a superpower as a PM to build on. For me that was coming from analytics, so data is a core superpower. For a software engineer, understanding the architecture and being able to translate requirements really effectively could be your superpower to build from. My recommendation to help transition into product would be to find an opportunity in your current role to act as a PM and see if you like it. This will help you understand if product is the right path for you and will also enable you to have an example of your product work to talk about when you do interview for a product role.

This is a hard situation. My recommendation would be to do two things: 1. to spend time deeply understanding and reflecting on the feedback. Identify what pieces feel resonant and what pieces feel like you don't want to action on. 2. to ask for feedback from others - peers or leaders who you've worked with - and understand if there are patterns in the feedback from your manager. Sometimes we have blindspots and its helpful to get other perspectives to understand if you have those. To provide an example: I had a situation where a manager provided feedback to me to stop asking so many questions in meetings. I asked why and she shared that sometimes it was disruptive. I reflected on the feedback and it felt misaligned to me - one reason that I'm a good product manager is that I'm deeply curious and want to understand why. I like that I ask questions! However, I also heard that maybe in a meeting setting this could be disruptive so I asked other meeting participants to see if they found my approach disruptive. I heard from others that there were cases where I derailed the discussion because I was so excited to learn more. That's not cool! Ever since then, I've been more conscious about when to ask questions and when to allow a meeting to progress to an outcome. I probably still don't find the perfect balance always but it has increased my awareness. However, if you're not hearing the same pattern from others. It may be the case that the feedback you're getting from your manager is misaligned with the way that you want to do work. This may indicate that its worth discussing this with your manager and identifying a path forward. Bring examples of people who you talked to to get other perspectives. If you can't build alignment with your manager, it might be time to find your next job.

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.