Get answers from product management leaders
My current product team has about 40 PMs (And we are hiring!). I would not dive into what each of the team does, but maybe talk about how we went about structuring it, which may be a more transferable skill. When I first joined Meta my VP asked me if the current team structure is the right one. Naturally, I did not know the answer. Frankly, I don’t think it was the right question for me to answer at the time. Instead, I engaged with the team on setting a 3 year plan - Write down what our strategy is, at a high level, and what are the key milestones that such a strategy would hit, if successful. This happened both at the org level and for the individual teams in the org. As the team presented the strategy to the stakeholders we started seeing some gaps in our org structure and the team leads started to raise a desire to organize differently. We recently re-organized the team accordingly. Setting a direction was a critical prerequisite before talking about team alignment. As for measuring success, it goes a bit to the first question I answered - I expect each team to define their own strategy, then set the milestones of that strategy. Our discussion can then be focused on the three elements I highlighted: * Strategy: Was the team able to set a good strategy? * Execution: Is the team hitting the milestone? If not, is it because the execution is not tight, or because the milestones are not achievable and we should pivot? This is a very important distinctions that some people are missing - A team can be executing really well and proving that the strategy is the wrong strategy. Being able to prove that point and move on without wasting years of struggles is a big win! * Org health: Are we hiring well? Growing talent? Retaining talent? How is the cross functional relationships going?
...Read More15325 Views
Upcoming AMAs
Ajay Waghray
Udemy Director of Product Management, Consumer Marketplace • August 25
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!
...Read More22138 Views
Katie Cubillas
Twilio Sr. Dir, Product - Technology Partners • April 28
In taking an end-to-end business leadership approach to this role, it opens up multiple career paths. For example- if your goal is to become a product GM, this is well aligned. If your ambition is to be a future COO, I think this is a great role to dig into. I think it's also a great extension to leadership roles in customer success and GTM as well. I definitely see it as a choose your own adventure skillset.
...Read More9184 Views
Tamar Hadar
The Knot Worldwide Senior Director of Product | Formerly Trello (Atlassian) • February 2
As a first PM, you will need to be very judicious with how you allocate your time and resources. In fact, I think that’s true for larger companies as well. There are always going to be more ideas than resources available. As a product manager, you are responsible for translating the company’s vision into a roadmap so your first priority should be internalizing the company’s goals. Is it to drive sign-ups? Increase retention? Increase MRR? Or something else altogether? Narrowing in on that top goal helps to weed out work that may be less relevant. Once you’ve identified the top goal (there may be more than one), filter out any initiatives that do not map to this goal. The exceptions being pressing engineering initiatives (i.e. a platform upgrade, reducing technical debt etc.) or time-sensitive projects. Hopefully, you’ve been able to narrow down your list through this process of elimination. This is where a prioritization framework will come in handy. My go-to is the impact/effort matrix. It is very similar to ICE and RICE but simpler and more visual. For each initiative, assign an estimated impact to a measurable goal and a level of effort. Make sure to collaborate with your engineering and design counterparts when evaluating each initiative. This will reduce the chance of your own bias getting in the way and lead to better prioritization. For those initiatives left on the cutting room floor, think of a way you could still make some progress—is there an MVP you could run to learn something while the teams are working on the selected initiatives? There might be a low-cost way to validate assumptions via user research or data deep dive so that by the time you go through this exercise again, you are able to make a more informed decision.
...Read More13186 Views
As you progress from PM to senior PM, competencies in these 3 areas should grow: Autonomy💪🏽, Scope 🌫️ and Leadership 🙋 . There are a few clear indications that someone is ready for the senior level, like increased scope, being a reliable partner and being results driven. Here are some less obvious ones: #1 You recommend initiatives based on your strategic evaluation, instead of waiting for them to be handed to you. You are influential in your field and feel confident putting forward these initiatives. #2 You leverage relationships across the org. You can drive results from partners outside of your immediate team. You are fully entrusted to tackle complex, multi-team problems with little necessary supervision. #3 You are seen as an available and trustworthy mentor and actively seek out opportunities to help others be their best. This is my favorite by far. What are the key stages that distinguish the different levels of PMs? I think a little bit of this depends on the problem space and company. In my mind, PMs are professional collaborators, strategic assassins and bring out the best in their peers. If you can look yourself in the mirror and say you’re doing these things at scale, well, I’d say you're on the right track.
...Read More15116 Views
Neel Joshi
Google Group Product Manager, Google Assistant • August 31
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.
...Read More11676 Views
Patrick Davis
Google Group Product Manager • August 18
I'm lucky in that Google has a really rigorous interview process that I benefit from. Google is also known for taking a long time during that process but I promise you that is largely because of the rigor. Post that process though what I look for are three key signals 1. Grit is my first. Big companies are notoriously slow, process heavy, and plodding. But the way I look at this is that with so much user trust, such a large business, and really a huge opportunity that we have to respect we want to get it right. I tell my team all the time that if you want to go fast go alone, but if you want to go far go together. And we've all chosen to go far so grit is critical (and sounds cooler than patience) 2. Passion. Yes this one could seem to fly in the face of the first one. But I often find that I'd rather have somebody always frustrated we can't move faster, always frustrated that we can't do better and help them mature into taking a balanced position than the other way around. Another way to say this is that I can help show somebody the upside of measuring twice and cutting once, but I've never been able to teach passion. 3. Finally EQ. Most of what PMs do depend on building trust and trust is built via relationships. Too much detail isn't likely needed here as this one is obvious but where I will go into detail is that EQ isn't the same thing as being sociable. I have excellent PMs on my team who build strong relationships that aren't loud and in your face extraverts. EQ comes in all shapes and sizes so look carefully.
...Read More2619 Views
Ravneet Uberoi
Uber B2B Products | Formerly Matterport, Box, McKinsey • August 31
One way I like to prioritize problems is based on the level of risk these will pose to the final solution. Which are the riskiest assumptions or riskiest bets that will affect the success of your product? (Risk can be defined crudely in terms of Low, Medium, High or in some cases you might have a model with some sensitivity analysis built in). Regardless, if you can quantify the risk (and thus impact) of the problem to the final solution, you have a clear blueprint of where to begin. A related method is to consider one-way vs two-way decisions. One way decisions are challenging or impossible to reverse - these have multiple downstream effects on the solution. Two way decisions can be reversed easily or adjusted over time once you have more data. I prefer to focus my time and energy on one way decisions first, as these will build the pillars of the product. If there is considerable time or effort spent by your team on a two way decision, you can make the argument to come back to this once you have more information or once all the one way decisions have been made.
...Read More10722 Views
Deepak Mukunthu
Salesforce Senior Director of Product, Generative AI Platform (Einstein GPT) • February 22
Aspiring technical product managers should consider developing the following skills and background: 1. Technical expertise: A strong understanding of technology and the ability to communicate effectively with technical teams is essential for technical product managers. Familiarity with coding languages, software development methodologies, and industry-standard tools can help aspiring technical product managers gain credibility with their teams. 2. Customer empathy: Technical product managers should have a deep understanding of their customers' needs and pain points. They should be able to conduct customer research and use this information to inform their product development decisions. 3. Business acumen: Technical product managers should have a good understanding of the business context in which their products operate. This includes understanding the competitive landscape, market trends, and financial metrics. They should be able to use this information to make informed decisions about their product development priorities. 4. Analytical skills: Technical product managers should be able to analyze data, draw insights from it and use it to make informed decisions. 5. Communication skills: Technical product managers need to be able to communicate effectively with both technical and non-technical stakeholders. They should be able to explain complex technical concepts in a way that is easy for non-technical stakeholders to understand, and be able to negotiate and influence stakeholders to achieve their product goals.
...Read More1841 Views
Marion Nammack
Braze Director of Product Management • February 8
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.
...Read More9304 Views