This is a two-part question. Let me first articulate how I like coming up with ideas for new opportunities, followed by how I like to make decisions about what to build. Hopefully, you don’t mind that I’m thinking about “opportunities” because it might not always be a feature that’s the right solution. I should start by saying that there isn’t one right approach to coming up with ideas. In my experience, I’ve had success ensuring that there are: 1. Insights from the four lenses: Customer, Business, Market, Technology 2. Effective methods to facilitate ideation At the core, you have to have a deep understanding of the underlying user pain point you’re trying to solve through a thorough investigation of the Customer by talking to customers and product usage. You might actually learn very quickly that the user problem is around discoverability or activation, not necessarily a feature gap. Ideally, the customer impact is so deep that it translates effectively into Business impact. The Market context is critical to help understand how your user will experience the product within the broader competitive landscape and the direction an industry is headed. Finally, the Technology lens offers insight into what capabilities could be used as part of a solution. Preferably, these four lenses come together through cross-functional ideation that has the right participants (e.g. PM, UX, Eng, and even folks go-to-market teams). In a hybrid world where we’re working across time zones, I’ve enjoyed having the opportunity to ideate together synchronously and asynchronously. In terms of decision-making, the ideation process should lend itself to initial layers of prioritization. I won’t go into prioritization frameworks here, but there are many out there. They do tend to distill back to impact and effort and sequencing. At HubSpot, depending on the type of decision we are trying to make, we may use a “driver, approver, contributor, informed” DACI model used by other companies we admire like Atlassian.

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.

We have a great podcast episode about this! To summarize, it’s less about explicit processes and more about tools in the toolbelt. It’s all about right tool, right job. The tools that come to mind for incorporating customer feedback are: 1. User research. This typically involves a full user research team, crafted questions and a lab that users visit to provide feedback on designs, prototypes, live product, whatever is being used for testing. But sometimes it’s something you do on your own with the help of a user researcher. 2. Surveys. This usually involves working with someone that specializes in surveys, product marketing or something you do yourself (very carefully!) to survey customers about what things they like and don’t like about new or current product features. You can also ask about how likely they are to promote the product or feature to their friends, prices they’re willing to pay for products, etc. 3. Customer Support Feedback. This is what customers tell your customer support team if you have one. A great way to collect this is to sit with your customer support team and either field calls yourself or listen in while others are fielding calls. 4. Written Feedback. Can come from a feedback widget on a website or app, app store reviews, emails to the CEO, etc. This tends to be lower fidelity but can be really useful when troubleshooting or looking for lots of feedback volume. 5. Quantitative Data. This is not something people usually think of when it comes to customer feedback! But Quantitative data is really just a data representation of customer feedback. It shows what customers are actually doing. And, when analyzed properly, can reflect what you see in the more qualitative methods above. There are more, but these tend to be the most common ones. Depending on what the need is for a product or feature you’re working on, you might want to use different tools for different purposes and project phases. For example, if you’re trying to redesign a product page for the whole website, it’s worth taking your time. It would make sense to start looking at quantitative data and written feedback early in the process. Then, once you have prototypes to test, user research can play a bigger role. But maybe you have some bigger questions to answer before then, like what kinds of elements do users want to see on these pages? Then engaging user research to help figure that out can be a big help since it’s less structured and more complex. And of course sometimes you need something fast to ship in the next few days. Written feedback, quick surveys and customer support feedback can be really helpful. Each of these tools have some bias baked in as well. For example, written feedback is more biased to more engaged, more passionate users. So it’s good to keep in mind what those biases are and figure out how best to use those tools depending. Great question!

I’ll skip the obvious things - pay well, set a vision, growing company, skill building, career pathing - and highlight some under-rated ones: * Hire well and have high talent density. Most people who choose a career in Product Management are motivated by self improvement - being around other talented PMs who they admire and who push their thinking is motivating. * Stay lean. This may seem counterintuitive - isn’t it good to have enough PMs? Honestly, no. If you hire well you want to give people room to grow and stretch. The worst thing you can do is to staff up too quickly, only to have frustrate your stars who are ready for more in a year (or worse yet, sudden shift in the business which requires you to scale back projects). Having too many PMs will also lead to more work being generated, you then need to resource. It’s far better to have PMs that have 20% too much to do than 20% too little. My rule of thumb is: everyone should be just uncomfortable enough with their scope that they drop a few things, but not so uncomfortable that they burn out. * Autonomy. People choose a career in product management because they want to make or be at the center of product decisions. Allowing them to do so is one of the most important things you can do to keep them motivated. As a people leader your jobs is to set goals, give context, guide, and identify blindspots. It’s not to operate the product for the PMs on your team. At Netflix we have a value, “Context over control” - leaders should focus first & foremost on setting context so others can make decisions vs. making decisions for them. * Actually care about them. When I think about the best managers I’ve had they have one intangible thing in common - I felt on a deep level that they actually, genuinely cared about me. This had a ripple effect on every part of my job because I felt supported, was calmer, and did better work. Caring looks like regularly thinking about the growth & success of another person without being asked to. It looks like advocating for or elevating behind the scenes, especially if they are in a disadvantaged position. It’s something that you can’t fake.

In my mind, it's not an either-or. By growing existing talent, you retain organizational knowledge and build a shared culture, while bringing in external hires inject fresh perspectives and sometimes specialized skills lacking within a PM team. When I am looking at my team structure and needs, I often consider the following: Things to Consider: 1. Internal Development Programs: Promote from within by offering training, mentorship, and rotational programs that broaden your team's exposure. This approach (in my experience) strengthens loyalty, develops institutional knowledge, and keeps your product strategy consistent. 2. Hire Externally: Often times PM teams get into stuck patterns and fresh perspectives are invaluable for a team's growth. When I need new capabilities, like a strong data analytics background, or experience in a specific market segment, hiring from outside will usually shorten the learning curve and bring proven experience to the team. This ultimately helps the broader team as their exposure to these new skills raises everybody's value and potential. 3. Do Both: We need to do both internal development and external talent acquisition to manage the best possible team. Keep growing your internal team by providing new opportunities and challenges, while selectively recruiting outside talent to fill knowledge gaps and bring in fresh eyes. This way, I keep our internal culture strong, ensure continuity / grow loyalty and still gain a fresh perspective when you need it.

* Resume: Usually, the biggest red flag for me in a resume is when either the candidate doesn't describe any impact metrics or focuses on a vanity metric, eg, if a checkout PM describes an increase in the number of payment page views instead of an increase in checkout conversions * Initial Interview: PMs are often advised to use a variety of frameworks for their interviews primarily to showcase a PM's structured thinking to a problem. This is good advice as long as the PM uses a framework for reference instead of answering questions with the framework alone. As a hiring manager, I am more curious about how you thought through a problem, what real-world challenges you came across, and what the outcome was. The idea in an interview isn't to understand a PM's knowledge of the various frameworks available but to understand the depth and breadth of their thinking in a real-world use case.

Let’s say that a product team and an executive team are aligned on the goal of improving customer satisfaction with the product (measured by a CSAT survey). The product team will then do research and perform experiments to validate the best way to impact customer satisfaction. Including executives in the research process via stakeholder interviews is a great way to get input early - executives are viewing things from a much different perspective than team ICs and often have great ideas. When the team prioritizes opportunities to pursue, the framework they use for prioritization can also be used to convey their point of view on the best way to impact customer satisfaction. If an exec suggests making an adjustment to the roadmap during the team’s roadmap review, seek to understand why and dig into their thought process. Then, seek the truth. Is there a quick way to validate or invalidate the feedback? What does the objective evidence point towards as the best opportunity to impact the goals? For more on this topic, I recommend “Cracking the PM Career” by Jackie Bavaro which has a chapter on working with executives.

I would say there is no substitute to real user data. User research is table-stakes. But in my experience, not always representative of "actual" usage, so don't overindex on specifics. Rather validate if the problem statement is indeed important for the user segments. Because if it is, then they might be more patient with your iterations towards solving their needs. Else they are very likely to abandon very early on and never return. A good way to test is whether they are willing to pay for the solution. Paper mocks UXR is helpful once you have narrowed themes and want to develop MVP scope. Then go build MVP and ship to a small user segment to learn and iterate. This step is the journey. Scale up only when you see hockey sticks for atleast one feature. Also retention loops should be naturally showing up by then.

Generally the process I follow to prioritize features is: * Aggregating feedback: from customers, users, and stakeholders through various avenues * Review User metrics to help identify pain points, feature requests etc. * Align feature prioritization with long term Vision/Strategy (This needs to be defined ahead of the prioritization exercise) * Assess the potential impact and value of each feature using factors such as customer metrics, market trends, competitive analysis, and alignment with company goals/OKR's/metrics. * Evaluate the effort required to develop each feature, considering factors such as development time, complexity, dependencies, and resource availability. * Prioritize using frameworks such as RICE prioritization framework (Reach, Impact, Confidence, Effort) to rank and prioritize features based on their importance, urgency, and potential impact. * Identify any dependencies between features and evaluate the implications of implementing them in a specific order. * Get feedback from key stakeholders on your prioritization * Continuously review and reassess the feature priorities based on all of the above.

Thank you for the question and I'm sure this is exactly not the answer you're looking for which is, "it depends" You're balancing building trust and relationships, understanding your users and the business, and likely an evolving company strategy. So the question you need to ask yourself is what are you optimizing for? The runway of your company is critical to consider, but I always lean towards how might we prioritize learnings and building trust to build out a strong product roadmap