The ideal product manager to engineer ratio can vary from company to company and even team to team, but it usually depends on the company size, product complexity, the skill level of the engineers, and the role scope of the product manager. A general rule of thumb is 1 product manager for every 5-10 engineers. * 1:5 - This is common in startups or small teams where the product manager may need to be in the details. * 1:10 - As the team and company grows, a product manager may manage larger engineering teams. Sometimes it's one large team or multiple engineering teams. Since product managers don't have time to be in the details for every project, they are expected to work at a higher level on setting product vision and direction rather than detailed product requirements. It is common for senior product managers to manage multiple teams. * 1:7 - This is the sweet spot where a product manager can still get into the details of a project while also having a lot of impact with a team of this size.

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!

The level of detail that people on other teams need depends on what they are using the roadmap for. Our roadmap planning tool enables us to create multiple views of the roadmap - we tailor each view to the use cases of the consumers. For example, we have the following views: * A view for our quarterly planning process - this view is primarily used to communicate to execs so it focuses on the high level business goals that each roadmap item supports and doesn’t contain many implementation details. * An internal view that go-to-market team members can use to understand estimated delivery dates for items in active development or beta - this view contains much more detail - for example the user needs that the release addresses and how to sign up for betas. * A public view that is available to our customers - this view contains customer facing explanations of each project and information on how our customers can help us develop it. For example, an item might have a few questions about the customer’s use case and interested customers can send us answers to those questions.

This is hard! For me, it's a mix of having a good understanding and confidence that you have (1) a clear hypothesis that you can test with a minimally viable product that is shaped by data and customer/market research, (2) confidence that you have a potential solution that can prove the hypothesis correct, and (3) an understanding of the risk and opportunity for building that solution, including the time it'll take to build, the availability of users willing to try your solution. When in doubt, it's always a helpful rule of thumb (in my opinion) to simplify the scope of your solution as much as possible, to both reduce engineering time/complexity AND to not squander the opportunity cost of shipping too late (see the Reid Hoffman quote question posted as well!). The hardest one in my opinion is 1 - making sure that you get down to the real essence of an unmet customer need and being incredibly clear and specific on how you think your product can solve it, and how you will know.

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.

The following stand out to me for what I've witnessed: * The team is acting like the product they're creating is going to be successful. I'm amazed at how many successful companies try to build new products like they do for their existing successful ones: same processes, same success metrics, etc. They don't have the urgency, move too slowly, learn too little, are complacent. The market is a graveyard of failed products and businesses: the most likely outcome, when creating a product, is that it will fail. As a result we shouldn't assume success but instead focus on doing everything we can to de-risk, test and validate - and make sure we don't over-invest too early. I recently was interviewed in Lenny's podcast to talk about that: if you're working on 0-to-1 in a bigger company I think it's worth your time. * The team built a solution to their own problem and they assumed that many more people would face it in the same way. We hear a lot of success stories that started like that, and while it's true that some successes began like this, it's also where a lot of failures came from. You're not the customer of your product: work with real customers! Or it's only going to work for a small population, and that may not make it a viable business. Mehdi, the founder of Cycle, shared openly a great example of this for how they changed their approach to user onboarding. * The product manager tries to get a big team from day 1. Honestly a small team can move 10x faster than a big one. You need a team of people you can trust who can move mountains on their own and continents together. For the first year of creating Jira Product Discovery we only had 5 engineers, and we moved really fast. It forced us to focus on the most important things, to be nimble and creative when testing solutions, and we could do this with very few meetings (it's very easy to get everyone on the same page at that scale). Once you've proven you have a solution that solves real problems for a small number of users - you can then go back and ask for a (slightly) bigger team. Resist that urge to grow too fast! * The team is fighting too many battles at once. This happened to us at Atlassian when we tried to rebuild Hipchat into another product called Stride. We were trying to launch a new product built on top of a new platform that could be used for all other Atlassian products. We faced this tension product<>platform from day 1, and it was much slower to move on the product front. Like with any failure there's of course more than one reason this product didn't pan out, but this is definitely one of them. * The PM fails to get the right level of buy-in internally - if it's about creating a product inside a bigger company. It's very important to "build chips" in the company (gain trust from leadership) so you can spend them, gain more chips, etc. And it's key to communicate your learnings and progress in a way thatmake your team look like a high speed train - no one wants to get in front of a high speed train. This is one of the topic I cover in an interview on Lenny's podcast.

I’ll try to answer this first question along with the question of - “What metrics do technical product teams look at to define success, what do you find to be the most important?“ because they are similar. KPIs or Metrics are essentially a way to measure how successful your program or product is. There are a few traits any ‘metric’ should possess - they should be explainable, able to move/influence by the team, able to test for impact, without any bias and more importantly tied to the business goal you are trying to accomplish. The metrics you’d want to define and track will likely vary based on factors such as - what type of program/product you are building (Eg: External consumer focused Vs Internal scale focused)?, what stage in the lifecycle it is in (Eg: Prototype Vs Growth Vs Mature), what matters to you within that lifecycle phase (Eg: During growth - User Acquisition Vs Revenue). Generally speaking you’d want to have a set of business (Eg: User growth, Revenue) and technical metrics (Eg: Availability, Latency) to provide a more balanced view. And don’t be afraid of (re)defining your success measures as your products/programs evolve. One of the common pitfalls I see is technical product/program managers having a myopic focus on legacy metrics that has far outlived its purpose.

I love this question! It happens a lot and working through it is part of our role as PMs. There are a few layers to my approach here: First, start with building the relationship. (I hope this theme is clear by now ;-). While your goals may conflict, at a higher level you are playing for the same team, and having constructive, trusting relationships is a key for any team’s success. You don’t need to agree, but at least seek to understand and show empathy. Second, focus on higher level framing, rather than your own goals - You both want the company to succeed, and if you start double clicking into what success means, you will likely be in agreement for the first few clicks. As you go deeper, call out the framing e.g. “We want to grow revenue, but also want to ensure good customer satisfaction. We may disagree on the relative importance of those factors”. I specifically recall a leader I worked with with whom I philosophically disagreed on the overall direction of my product, but could still have very productive conversations about how to think about the space. We were not trying to persuade each other, but rather use those conversations to enrich both of our thinking. Third, As you lay the framework and get to the crux of the disagreement, try to think of the “what needs to be true” statement. If two reasonable, capable groups of people look at a problem and get to a different conclusion it may be because they put different “weights” on different considerations. You can then enumerate “A is better than B if X, Y and Z are true. Otherwise B is better than A”. Example: Driving revenue up by X is more important than driving customer satisfaction up by Y if we believe that the change in customer satisfaction will lower attrition by XX and drive increased spend fro existing customers of YY”. Then the discussion can be about the conditions, not the goals. Fourth, when the discussion does move to goals, look at counter metrics. “Grow metric X while keeping metric Y within certain guardrails”. I’ve seen this technique used a lot at Meta. Last - Escalate. I encourage my teams to escalate disagreements so we, as a leadership team, can unblock them. If the work above does not solve the challenge, at least it allows for a very structured discussion among the leaders of the conflicting parties.

Market trends can be a good indicator of what will matter to users, investors or stakeholders. Don't ignore them, but also don't let them distract you from the fundamentals. * Do you think this trend will drive a permanent shift in the market you operate in? If so -- consider how you can position yourself for success in the long term and the pros / cons of investing in alignment. If not, consider whether there are short / mid term changes you want to make to take advantage, or whether you just want to ride it out. * Identify where the trend is coming from. Is it driven by macroeconomics? A technological innovation? And are you and your org well positioned to take advantage of it? * Are you moving early enough vs other competitors? If you have an opportunity to be out in front of the crowd -- can you position yourself as a leader in this trend and drive marketing value from doing so? * Does it genuinely drive economic advantage for you, either directly or by second order effects?

Product management decisions should ideally be data-informed rather than purely data-driven. Being data-informed means leveraging data to guide and support decision-making, while also acknowledging the context, the subtleties of customer behavior, and the broader market trends that quantitative data might not fully capture. Data is invaluable for validating hypotheses, understanding user behavior, and measuring performance against goals. However, it's equally important to recognize the limitations of data and the potential for it to lead to suboptimal decisions if relied upon in isolation. Product Managers should indeed lead with an informed intuition—a blend of experience, understanding of the customer, and strategic vision. This intuition is then refined and validated through the use of data. By using data to back up assumptions, Product Managers can challenge their biases and ensure that their strategic direction is grounded in reality. Ultimately, the most successful Product Managers are those who can adeptly interpret data, understand its implications, and also know when to question its suggestions. They balance the art of intuition with the science of data, using each to enhance the other. This holistic approach allows for innovation and creativity, driving product decisions that resonate with customers and succeed in the market.