Product Management

I like to look at feedback as a gift and approach it with an open mind. How I would approach this is: 1. Do some soul searching :) understanding your own communication style. How do you communicate? How do you like to be communicated to? What things help you stay open minded? What things make you shut down? What are your values? 2. Once you have that. Setup a meeting with your manager and thank them for being open to giving you feedback but that you are having a bit of trouble understanding how to apply. In this meeting, share with them what you learned about yourself around communication. THEN you want to ask them how they too, would like to receive feedback. 3. Now that you have built your foundation of trust. Pick a specific bit of feedback you were given and ask to do a deep dive. Remember to be open minded. Sometimes when we receive feedback, we over personalize when that was not the intent. Understand what is trying to be communicated and then work together to understand how it could have been better communicated. 4. At the end of the meeting, share how you are feeling about the session. Ask your manager to do the same. 5. At the end of every 1:1 with your manager, ask them for feedback. In the moment, offer feedback on how it is being delivered if you feel it is not matching what was previously discussed.

This is a fascinating one to investigate! The first thing I can say is that I understand your plight since I've been there before (probably on both sides) and I know it's not an enjoyable or enriching place to be. In spite of this, receiving feedback from team members, cross-functional partners, and leaders is inevitable. When you change your perception of feedback and how you use it, it can become your superpower. If someone has positive intentions, they are giving you a gift by giving you feedback. Distinguishing intent is the tricky part. There is a misunderstanding around feedback that I often encounter when I speak with people. There seems to be a widespread perception that a growth mindset requires you to accept all feedback and act on it without question. In reality, just as in human relationships, there is often much more complexity. Sometimes feedback is just the symptom you need to diagnose the real problem, and it might not even be related to the symptom at all. Within an organization, people have a limited perspective. Our view of the world is colored by the tasks we are responsible for, the people we collaborate with, the subsets of company strategy we encounter, and many other factors. Feedback disconnects most often occur because of misunderstandings related to different perspectives or experiences within an organization. As an example, your manager might tell you that you aren't detail-oriented enough when in reality your project was much earlier in its progression and at this stage, you wouldn't expect to have all of the answers. As this example illustrates, there is a disconnect between a manager's expectations and how work is actually being undertaken by the team. This kind of feedback does not necessarily indicate that someone is doing something wrong, but it does indicate a misalignment somewhere. Either a misalignment of values and working styles, processes, information, altitude visibility, or something else. What feedback that you don't agree with can give you is the opportunity to dig deeper. Get curious, and take a step back (this may require stepping away from the issue for a few days). Then, when you're ready, have a conversation with your manager and ask them the following: * What makes them believe what they believe? (You should ask for examples and data points.) * Can they give you an example of how they think things should be done? (Find out what they would have done differently.) * Don't hesitate to ask for clarification if something they say doesn't make sense to you. It's uncomfortable, but a decent leader will lean in and help you close the understanding gap. It's important to keep a positive mindset here, being genuinely curious to understand will go a long way. As you ask questions, provide context as well. Talk to your leader if you have tried a suggestion and it didn't work out because of something your leader isn't aware of. Get their help and leverage their experience. Their job is to help you set priorities, remove roadblocks, and help you perform at your best. Be brave and ask for what you need/want. Not all of these scenarios end well. Sometimes it's a sign that you and your manager do not share the same philosophy on getting work done. You won't be the first or last to experience this. This is a great way to evaluate the fit between yourself, your team, your organization, and your reporting structure.

This is a challenging one, as people's problems could be mentally draining and less exciting to deal with.  Tactically, I'd advise speaking with your HR business partner and seeking their advice by sharing specific examples.  Longer term, I'd suggest practicing radical candor with your manager. This process takes time & energy as you need to build trust. If you haven't yet, I suggest reading Radical Candor by Kim Scott.

I personally have been teaching at The Product School and have seen benefits/value from those coming out of the course. It is really going to come down to your own learning style however. You could also very much find free reading materials if you are unable to invest in taking courses at the moment. You can go on youtube and simply search 'product management' and consuming videos and talks. You could go on twitter and read through the numerous shared docs there. It really comes down to whether you personally need structure or can create your own structure.

I usually recommend starting with the following books: 1. Cracking the PM Interview by Gayle Laakmann McDowell 2. On Design Thinking by Tim Brown 3. The Lean Startup by Eric Ries As for the courses, I hear great things about: * Reforge - www.reforge.com * Managing your PM Career in 2023 & beyond - https://maven.com/shreyas-doshi/product-management-career

There is definitely a fine line here. Every decision cannot be data driven and will likely be informed to some extent BUT part of the excitment of product management is leaning on that intuition. In some cases, you will have data to back up your assumptions and in others you will not. Every situation is going to be different and you'll have to become an educated risk taker. Leaning on previous experiences or patterns you've seen somewhere else.

Data should be used to inform product management decisions rather than drive them. A product manager should lead with intuition and use data to support their assumptions. Data should be used to inform decisions, but it should not be the only factor in making decisions. It is important for product managers to use their experience to make informed decisions, and then to use data to validate those decisions.  Data can provide insight into: * customer needs * market trends * and product performance  It can also be useful in identifying opportunities and risks. Data alone, however, cannot provide the full picture. Data needs to be interpreted by product managers using their experience and expertise in order to make decisions that are in the company's and product's best interest.  These decisions can be validated and supported with data. For example, your key customers' needs cannot be understood by data alone, you need empathy, context, interpretation, and intuition to make a decision.  In your role as a product manager, you should be deeply engaged in the product, market, business, and customer pains/experiences which should help drive the intuition you feel for the product strategy.

Classic PM answer - it depends.  The longer you are at the organization, the better intuition you will develop. The same applies to the product maturity, e.g. 0-1 vs. 1-N. New product to market requires PMs to look at trends and have a better sense of the customer needs. Well-established product decisions align more with data e.g. Google's conclusion that ms of latency = impact on $ revenue. 

A CEO once told me that he would only hire a person if he thought that he would enjoy the time spent with that person despite being stuck at an airport with them waiting to board an indefinitely delayed flight. Despite the exaggeration, I've always imagined the equivalent scenario as whether engineers would want to spend hours with a PM in a war room or a bug bash. Be an engaged partner. Be in the trenches with them. Work hard or harder. Follow-up and follow-through on your stuff. Be transparent about the real business context, the one they may not have heard. Tell them about what you are up against. Bounce ideas off of them, ask about options, be curious. Be their ally, advocate, or sounding board when needed but not blindly. Don't just toss a problem over the wall. Write a technical PRD vs a one-pager. If they are "not delivering" don't just report it as late in a status meeting. Meet proactively- ask what can you do to help them do their part. There could be a zillion other reasons- they are working on something else that's more important, or even less important but they didn't know otherwise, they don't know how to "fix it" yet, or they are dealing with personal issues, etc. Admit your mistakes and help them recover from any of theirs. This does not mean sweeping real issues under the rug. Address things that cause real damage head on privately or less privately as needed. By now you may have noticed that none of my answer contains anything about having more technical knowledge. It is also true that getting increasingly more technical will always help. But it won't impress or influence. Being real and human is more impressive these days; it will build trust, and trust paves the path to true influence, one that cannot be confused with coming from title or power.

Being a team player and sharing team responsibilities e.g. sharing scrum ceremonies with your EM, will help you be equal partners.  Don't forget that while you're doing customer calls, aligning stakeholders, or writing PRDs, your EM is directly managing the engineering team. This takes energy and time. 

To be a strong product manager, you will have to learn to balance your art in the science. That is your hard and soft skills. When you are new to a team, naturally you want to show your value and start to contribute right away. However you don't take the time to understand the dynamics of the existing team, build the right relationships, understand communication styles, you may set yourself up for failture even before you start. My recommendation would be to come in, get an understanding for the team and what their needs are. Build relationships, understand what skills are best used in the beginning.

I don't think it's black & white. There is a broader spectrum of colors here. Leverage your superpowers to shine and learn the skills that help you do your job better. What matters is delivering results that move the business forward. These results will be noticed, and the rest will organically follow. 

Start with your passion for Product Management and DWIT attitude. Find a team who needs an extra pair of hands. Partner with them in your free time. Deliver results that are visible to others. From there, it's an easy sell organizationally for "why" you should become a PM when the organization needs one. 

I care less about specific resources and more about the iterative approach to professional growth. True learning comes from building a network of other PMs and subscribing to content that resonates with you. The more you stay plugged into real-life stories of what works and what doesn't, the faster you grow. That's why the Bay Area is great for accelerated professional growth as a PM.  Currently, I'm obsessed with "All-In Podcast" by top VCs in the valley. Next month, I might come across something more interesting.  https://www.youtube.com/channel/UCESLZhusAkFfsNsApnjF_Cg

Domain experience is not at the top of the list of things I look for in a candidate. I have changed domains a couple of times in my career and it has helped me get a richer perspective. For this reason, I prefer to see some variety in product management candidates.  Domain experience can be a challenge in some scenarios and I have faced this problem in the past when interviewing for roles. There are a couple of techniques I have applied: * Do enough research to learn the fundamentals. It is important for you to be able to have basic conversations on the topic to have a successful interview. It also shows that you are proactive and interested in this domain.  * Take some time to outline a plan for how you would learn about this space. Create a document that you can share proactively with the hiring manager and if the topic arises with others.  * As I mentioned in another one of my answers, it's important for product managers to demonstrate the ability to learn new things. Talk about how you have learned new skills in the past. Specifically call out in your resume when you've had to learn a new domain or skillset for a role. * While you may not have domain knowledge, there's other relevant experience that you bring to the table. Domain knowledge isn't everything! Think about the best way to position your background with the company/role. Ask the interviewers what they are looking for in the ideal candidate. Then talk about how you would bring that to the role.

I like to challenge those I hire with questions that don't fit the usual narrative. Below is an example of my Friday fun question: Imagine humans decided to take the moon and push it through a giant rock grinder. The rock and matter that comes from another side of the grinder are dumped on earth. Question — would a human need an oxygen mask at the top of that rock structure? I look for out-of-the-box thinking and thoughtful process to derive the answer.

Your team size, overall organization dynamic, and product maturity all shape the skills you need to improve day-to-day operations. Distilling to the basics, I'd go with the following: * Customer Focus: PMs who put the customer at the center of their decision-making process often help other departments understand their customers' needs better.  * Communication: being a skilled communicator, both in writing and verbally, is key to enabling cross-functional teams. * Agile: Many PMs use agile methodology to manage their projects. Understanding agile principles and developing your own "secret sauce" would help you rally the teams forward. 

The best way to get better is framing and articulation is to understand what works best for your organization based on lifecycle stage, market type and product type. You may want to try framing using a few different types of strategies to see what fits best. The most popular frameworks are: 1. Lean Product Management: This framework emphasizes the importance of iterating quickly and frequently, using customer feedback to inform decisions, and minimizing waste in the product development process. It encourages product managers to start with a minimum viable product (MVP) and gradually build on it based on customer feedback. 2. Design Thinking: This framework prioritizes empathy for the user, with a focus on understanding their needs, motivations, and pain points. It involves a process of ideation, prototyping, and testing to develop products that meet user needs and provide a great user experience. 3. Jobs to be Done: This framework is centered around understanding the underlying needs and motivations of users. It involves identifying the “jobs” that users are trying to accomplish, and designing products that meet those needs in the most effective way possible. 4. Product-Led Growth: This framework is focused on using the product itself as the primary driver of growth. It involves building products that are intuitive, easy to use, and provide clear value to users, with a focus on viral growth and customer acquisition through word-of-mouth. Ultimately, the best framework for articulating product vision and strategy will depend on the specific needs and goals of your organization, as well as the preferences and skills of your team. It may be helpful to experiment with different frameworks and adapt them to your specific context over time.