The candidate must “spike” (“8/10” or higher) in all of these areas, in order of importance: 1. Critical Thinking Given how many decisions and complex problems are thrown at PMs, this the #1 most important attribute I screen for. They don’t need to be a rocket scientist (top 0.5% of population) but they should be exceptional at this (top 5%). Good looks like: * Take large ambiguous problems and break them down into smaller pieces * Uses logic to convince others * Gets to the root of the issue: Think about things from multiple angles but then focuses on what matters (this is key and hard to find). The more senior a candidate the more critical thinking/problem solving looks like: starting the why and bigger picture, being principles-based, helping others to structure their thinking (good frameworks, simplifies and structures conversations etc.). I usually test for this both in the initial phone screen and through a product thinking interviews (case questions, panels) 2. Drive PMs have a lot of responsibility, get very little direction, and get too much credit and blame, so they need to a) self start and b) be motivated to keep trying even when faced with obstacles. Good looks like: * Ownership over outcomes vs. just doing the activities? A former manager of mine once called this “an insatiable desire to ship” * Self starter - Can we throw them at a problem and trust them to figure it out without hand holding? * Vigilance - do they generally think ahead to the outcome they are trying to achieve? Do they proactively address what may get in the way? This is very hard to screen for in an interview but you can get signals from behavioral questions, their questions to you, and follow ups. 3. Bridge Building There are two parts of bridge building 1. EQ - not easily coachable 2. Communication - this includes both written and verbal communication skills and both the quality and frequency of comms. Verbal and written comms are usually coachable. It’s ok if someone isn't a perfect communicator because people improve on this over time. But it’s not ok if they don’t have sufficient EQ. Good looks like: * Self aware - seeks to know (and improve on) their own strengths and weaknesses, self reflects without defensiveness * Situationally aware - skillfully navigates people situations and figures out how to influence others towards an outcome * Concise and clear answers that are easy to follow, verbally and written. I usually test for written and verbal comms in the panel exercise and interview questions. I test for self awareness and situational awareness in behavioral interviews.

Design a product for drivers driving in rush hour. I am betting every human stuck in traffic has once thought... “Dang this traffic sucks, I wish I could [insert idea].” The best answer I’ve heard is a tablet-sized visual, that is connected to the internet with key apps such as email, song playlist, podcasts, call functionality; along with the capability for partial self-driving in traffic. Once in rush-hour it kicks in, frees your attention to do other things, improves health of the driver by reducing both physical and psychological strain of commuting in rush hours and is highly scalable to autonomous-capable vehicles. I liked the answer because I’d buy this product 🤪 but also because the answer was (1) optimized for reducing real pain points (2) accounted for the future of driving (3) was a little wild, but not too out there. When I heard this answer I could tell the PM was both imaginative but grounded in solving real problems.

Reality these days is that we mostly work in remote settings, and even when we do go to the office, some people will be dialing in. As a result, I believe 80% of the strategies have to do with focusing on the fact that we are all people, 20% are tactics and adjustments for remote settings. General alignment strategies: * Build trust ahead of time. This is fundamental and driving collaboration without it is hard * Focus on common goals. There’s typically a higher goal that teams can easily align on (e.g. Revenue, Engagement, Better experience), and the differences show up as you start double clicking into the “how”. Starting the discussion with a longer term view can also help in skipping tactical disagreements and alignments * Frame, rather than take a position. With common goals in mind, center the discussion on what the characteristics of a good solution are, rather than starting with comparing options. This helps setting a more objective ground before jumping into the solutions * Call out your biases (easier to do when you have trust). In an environment where there is trust, I expect my teams to be able to call out other considerations that may cause them to pull in a certain direction, those can be different stakeholders that push in other directions, past experience and others. Some of those reasons may be valid, some may not be valid. Calling them out can help the entire team work through them. A few remote specific tactics: * Set the right structure, if possible. This includes minimizing the number of time zones each team has to work across (In my organization we are trying to limit ourselves to 2 time zones per team, when possible). If you can, hire senior enough people in the right locations to be able to run autonomously. * Invest in getting to a clear strategic direction. Having an upfront debate on the direction is time consuming, but can then help in setting the guardrails for autonomous decisions that can happen within the teams, locally. * If you do have the opportunity to meet in person, do so. Especially when working across time zones with little overlap, a good relationship would allow you to accomplish more offline, and can dedicate the overlapping time for working more effectively through the tougher topics. While I still mostly work from home I prioritize going to the office when team members from other offices are coming to town (and I am writing this note from the airport, while waiting for a flight - going to visit my team in Austin!)

Perhaps a contrarian take, but technical skills aren't the most critical for the majority of PM roles out there, except for deeply technical products or platform positions. For the general PM role, it's much more important to demonstrate your ability to delve into customer problems, set strategy, execute, and drive impact that aligns with your organization's mission and vision. Technical skills matter, but they are secondary. They usually revolve around your ability to work with engineering counterparts and understand enough technical concepts to make trade-offs, and to work with data and perform analysis for decision-making. In my experience, both of these skills are often inquired about directly.

This one is fairly easy, add value. We as Product Managers need to ensure that we are adding value for our organization by understanding the market (and our customers) and guiding the strategy to be successful in that market. It's easy to be a product expert, but we need to focus on being market and strategy experts. In my career, some key examples of adding value are: 1. Knowing My Market Better Than Anybody Else. When I am the expert on what our market needs, both short and long-term, I add significant value in defining and driving our strategy. My product can't be successful without this. When we are proven right in terms of our strategy definition and market validation, we win. 2. Build and Foster Relationships I work hard at establishing relationships around the organization where I am working. These enable me to be effective in cross-team collaborations and makes driving alignment across the organization easier. My relationships add value to me and my team. 3. Be an Expert When you are viewed as an expert and continually show your expertise in an area that is needed within the organization, it's easy to be seen as somebody who deserves that promotion. Show that your expertise drives direct value for your organization with clear successes.

Going from an IC PM to a manager role was one of the most gratifying transitions in my career. Having been a manager before in a different context prior to becoming a Group Product Manager at HubSpot, I had some prior experience leading teams and operating in an environment with broader scope and complexity that helped ease the transition. That said, I do recall a couple of things: * Saying no to your pet rock: As an IC PM, you’re the biggest fan of your own product ideas first and foremost. Given my drive for intellectual honesty, I’ve generally taken pride in my ability to arrive at the best possible answer (even if it’s not originally my own) throughout my career. I do still remember early on as a GPM saying no to ideas I thought were great in the past was a practice of self-restraint. Fortunately, this comes naturally now. Now my role has shifted to ensuring teams are focused on the most impactful work, and having strong empathy for teams when we have to say no to the incredible ideas they harbored. * Finding the right cruising altitude: Within the context of HubSpot, there’s a Product Lead player-coach role between PM and GPM. During my time as a Product Lead, I found it challenging and thrilling all at the same time to be at the right cruising altitude depending on the task at hand and who I was communicating with. The way you communicate with the team you’re PM-ing is probably not the same way you would communicate with executive leaders. * Finding your people: This is something I recall from shortly after I shifted to GPM. As an individual contributor (IC) PM you develop very deep relationships with the designers and engineers you work with day in and out. You’re in zoom meetings or on slack with them most of the day. Especially in a hybrid world, it took me a moment to shift my mindset to a broader definition of team and intentionally spend more time with the PMs and peers in the product leadership team. Fortunately, I love building new connections and HubSpotters are very warm and eager to meet new folks so this was a fleeting moment. I’m sure there are a lot more, but these were top of mind.

1. Not validating the problem statement enough. Is this really a problem? 2. For a B2B product, I think its important to think through early on whether this is a problem they are willing to pay for. Often times, this is an after thought and expensive to pivot. 3. Giving up too soon. Its easier said than done to validate the problem statement. Sometimes this take iterations where you get live feedback from real users. So you might be dancing around the problem space for a bit and that's okay. 

A product roadmap is a tool that communicates strategy, goals, metrics, features, initiatives, and timelines to the organization. It is key to achieving alignment and buy-in from leadership and ensuring that teams are on the same page. Regular communication with stakeholders, especially when changes occur, is essential. Below are some key stakeholders and their expectations from a roadmap. * Sales and customer success need to understand feature timelines and the value they add to customers * Marketing needs to understand the initiatives, features, and value to different segments to prepare a go-to-market strategy * Engineering needs to understand the overall vision, outcomes as well as feature details and complexity for execution * Customer support needs to know about enhancements and timelines to keep customers happy Note that depending on the organization, Finance, Legal, Operations and others may also need to be in the loop on the roadmap. By getting a complete picture of stakeholders in your company and understanding each team's needs and communicating effectively, PMs can drive product success and meet customer needs.

There are 2 main types of interviews for Product Management roles: 1. Product case interviews 2. Behavioral interviews (by cross functional partners like UX or Engineering, or by the hiring manager) With either interview type, the surest path to failure is when a candidate shows up and waits to be asked questions. A one-way dialogue doesn’t expose enough about a candidate to make a strong impression. Engaging in an interactive, two-way dialogue helps the interviewer get to know what it would be like to work with you – it exposes how you think and communicate in a real world context. The most impressive interviews I’ve conducted are ones when a candidate can interweave their experiences throughout the conversation and have a two-way conversation with me. The purpose of an interview for the candidate is to tell their story, share their product learnings, and expose who they are in order for the interviewer to assess their candidacy. The purpose of an interview for the interviewer is to assess if the candidate is qualified for the job and if they would be successful in the role. You make the interviewer's job much easier the more you open up and engage. And, the more you engage, the more memorable this interview will be for the interviewer when they have to write up their recommendation and discuss it in a meeting with the other interviewers weeks later. To avoid this common pitfall, you can do two things: 1. Put yourself in the shoes of your interviewer 2. Come up with a list of 2-3 things you want to make sure the interviewer knows about you For #1 - Who is your interviewer? What role do they have? What do they care about? If you had to guess - what are they trying to get out of this interview? Use these insights to better connect with them live. For #2 - How does your current work connect to the work of the role you’re interviewing for? What success have you had that you want to make sure is known?

There are a few that I consider important to set up (and refine) as you grow your team: 1. Processes for top-down sharing: As your team grows, knowledge sharing becomes harder but also more critical. PMs can only do their best work when they have context about conversations and updates from across the organization. For instance, "context" could include new product updates, changes in company strategy, takeaways from executive conversations and board meetings. I'd explore ways that you can provide this context either synchronously (e.g., through a team meeting) and/or asynchronously (e.g., through a "here's what's top-of-mind" slack message or email 2. Processes for upwards sharing: It's important to also think through the best ways for your team to share what they're working on (product updates), but also for them to share feedback on how the team is operating (upwards feedback). This is necessary with a smaller team too, but in larger teams becomes more challenging to do this ad-hoc and 1:1 - additional processes like a recurring survey or a shared product launch calendar. Keep in mind that this is not just important for you, but for the entire PM team and XFN partners too, so be sure to do this in a transparent way. 3. Team-building processes: Often overlooked, these are important to increase the cohesion and connection that your PM team feels. I like to use a weekly meeting or a private slack channel to share wins, talk about product news, share personal updates. It should feel like a trusted space for your team to share their thoughts and get to know each other more personally. Also, in today's remote climate where team members can often feel more disconnected, you might want to think through team rituals (e.g., beginning of every meeting with a win, learn and a "smile" - something that made you smile in your personal life) and in-person bonding (e.g., as a team, we meet in person once a quarter). A helpful tip - carve aside 30 mins each quarter to also do some "housekeeping" of your team processes. Audit what's working and what's not, which meetings are useful vs. not, what are themes from your team surveys. Iterate on your team processes just like you'd iterate on a product!