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.

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!

Before investing in engineering resources you want to build conviction around the following: 1. Is there a market need? Are you fulfilling a true gap in the market? 2. Do you have a differentiated vision to deliver on this need? 3. Is there willingness to pay? 4. Does the business model make sense such that you see a path to ROI for the business? 5. Is there a clear route to market (you know how to sell / acquire customers)? 6. Does your business have (or plan to have) the capabilities to deliver on this product (ex operational, technical or other expertise) such that it is strategic to expand in this direction? Overall you want to be able to articulate what the investment unlocks for the company and how.

Without going into specifics, the biggest challenge has been cross-organization influencing. My time at both Microsoft and Google has exposed me to lots of intra-organization projects with varying levels of buy-in from each team. The level of effort and coordination required to pull not one, but two organizations in the same direction can be enormous. As a PM - at any level - it's your role to effectively communicate why what you're trying to acheive makes sense for other teams, your company and ultimately your customers. Even if you're aligned on principles and strategies, there are dozens of other factors that you need to be able to navigate such as resourcing, ownership, tech stacks, recognition, branding, leadership opinions and timelines. 

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!)

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.

Of course they do! It's always a balance between those two sides. Mixing personal contributions with coaching other product managers can create tension if you’re not mindful. Setting clear boundaries around your schedule, defining what success looks like for both you and your team, and communicating these goals openly helps manage these two aspects. Things to Think About 1. Dedicated Coaching Time: I try and dedicate time each week to ensure my team is getting what they need and that I am providing them the opportunities to grow and gain exposure (to new skills, new teams, etc). If the team feels disconnected from their leadership, it's difficult to motivate them and keep them moving forward. 2. Defining Ownership: Whenever possible, I clarify what parts of the product I’m responsible for and what the team needs to own. When PMs clearly know what’s theirs to drive, it reduces the urge for me to dive in and micromanage. We play to our strengths, which allows me to contribute where I add unique value (eg: shaping high-level strategy or unblocking critical issues) while allowing each team member to do the same in their areas. 3. Regular Reflection: Every week and month, I reflect on where I’ve been spending my time. Did I neglect my direct product work because I was too hands-on with the team? Then I need to adjust next week. It's a constant balancing act. As I said, I work to carve out space, define ownership and teach PMs to solve problems independently, All of these ensure that your individual contributions and coaching efforts reinforce each other rather than work against each other. Over time, your team grows, and you free yourself to have a broader, more strategic impact.

FIRST OFF, TAKE A DEEP BREATH AND REMEMBER, CRUSHING THOSE OKRS IS GOING TO TAKE TIME AND EFFORT. NEXT, SET CLEAR GOALS FOR EACH MILESTONE AND BUILD A PLAN AROUND IT. JUST LIKE YOU WOULD WHEN DEFINING A PROJECT, IDENTIFY SUCCESS METRICS FOR YOURSELF AND CREATE A PLAN. HERE’S AN EXAMPLE: First 30 days: Learning and Absorbing * Establish good working relationships with stakeholders: the key to being effective is having open lines of communication with your coworkers. Take the time to get to know them and learn from their experience. * Immerse yourself in data: learn where to find pertinent information, which dashboard to follow and how to query data on your own (or work with a data scientist). * Familiarize yourself with your product’s users, their needs, pain points and Jobs to be Done (JTBD). * Spend time doing competitive analysis to better understand the product landscape. * Integrate into the team’s current work and process and identify ways in which you could be helpful. 30-60: Ownership and Leadership * Assume responsibility for a project: work with your team to define the project’s scope and add requirements. * Define success metrics for the project and work with your engineers and data scientists to ensure impact can be measured and tracked. * Identify cross-functional dependencies and reach out to relevant teams. * Give a demo and solicit early feedback. Continue to do so throughout the project. * Report on the project’s progress and impact to keep everyone involved and interested. Speak clearly about the business impact and how the project ladders up to the company’s goals. 60-90: Strategy and Vision * Leverage your understanding of the business and its users to craft a vision and strategy. * Translate the above into an actionable roadmap and work with your team to define success metrics for each. * Run brainstorming sessions with your team regularly to generate ideas and prioritize them. * Evangelize: this is where your storytelling skills will come into play—make your team’s mission known, its projects familiar and its rationale clear to everyone. Write posts, speak at company meetings and bring feedback back to your team. * Become an expert: be the go-to person for your focus area.

This is a good one. I think there are two that often get missed and largely it is because they are hard to measure and expensive to move. 1. Product excellence. How do you measure customer delight in an impactful way? CSAT and NPS have lots of opportunities to be gamed and are frankly easily ignored. Some of the best products I've used focus on finding the right critical user journeys and continuously measure the success rates of those quantitatively and qualitatively 2. Product health. Cold boot, warm boot, latency for critical actions, crashes, uptime. All of these things contribute to Product excellence but are much more directly measurable and can really sneak up on you

From metrics perspective, it's no different from standard product metrics. I've seen many different metrics frameworks being used, all of which essentially boil down to these 4 metric categories: 1. Operational metrics: Is the product functioning as expected? Success rates, Latency etc. 2. Usage metrics: Is the product being used? DAU/MAU, Frequency of use, customer retention/churn, Requests/sec, data volume etc. 3. Satisfaction metrics: Are customers satisfied? In-product feedback (thumbs-up, thumbs-down), NPS scores via surveys etc. 4. Impact metrics: How is the product helping customers achieve business impact? This is subjective and need to be defined per product and is also typically based on customer scenarios.