How to Work with Teams as a Product Manager by fmr NY Magazine PM
•Download as PPTX, PDF•
0 likes•110 views
One of the most important parts of product management is how you work with other people - whether it is communicating with stakeholders or managing a cross-functional team. In this talk Morgan Cohn talked about experiences driving the product cycle in various work environments and the challenges that you can encounter during the process - from disagreements to scope creep to burn out. He explored how her role and approach as a Product Manager has changed in this respect and hopefully empower others with tools to successfully drive cross-functional teams and build great products.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to How to Work with Teams as a Product Manager by fmr NY Magazine PM
Similar to How to Work with Teams as a Product Manager by fmr NY Magazine PM (20)
More from Product School
More from Product School (20)
Recently uploaded
Recently uploaded (20)
How to Work with Teams as a Product Manager by fmr NY Magazine PM
- 1. How to Work with Teams as a Product Manager by former NY Magazine PM www.productschool.com
- 2. FREE INVITE Join 22,000+ Product Managers on
- 3. COURSES Product Management Learn the skills you need to land a product manager job
- 4. COURSES Coding for Managers Build a website and gain the technical knowledge to lead software engineers
- 5. COURSES Data Analytics for Managers Build a website and gain the technical knowledge to lead software engineers
- 6. COURSES Blockchain and Cryptocurrencies Learn how to trade cryptocurrencies and build products using the blockchain
- 10. Why is this talk important?
- 16. First 30 Days ● Get to know everybody, not just your stakeholders. ● “What makes you want to throw your computer out the window?” ● Coffee, lunches, drinks - you will end up being the company therapist. ● Get a deep dive into your technical architecture. ● Find the low-hanging fruit
- 18. Ideation ● Identify the problem ● Come prepared - gather data, conduct user interviews, and usability tests beforehand. ● Keep it focused.
- 19. Crazy 8s ● You’ll need: paper, sharpies, stickers ● Get a bunch of people into a room and identify the problem ● Have them fold papers into eighths ● Set a timer for 8 minutes and have everybody sketch 8 quick ideas ● Ask everyone to pick their top three ideas and give them 6 minutes to sketch them out further and then present them. ● Hang up the ideas on the wall. ● Give everyone two stickers and have them vote on their favorites.
- 20. 5 Day Design Sprints Monday: Define the end goal and spend the day gathering information and interviewing the different “experts” at the company. Tuesday: Review existing ideas and sketch out new ones; Start planning out user testing (to be held on Friday). Wednesday: Critique and choose the best solutions; create a step-by-step plan for your prototype. Thursday: Make the prototype. Friday: Test the prototype; interview users.
- 21. Collaboration ● Not every feature needs a huge brainstorm, but collaboration is still key. ● Come with business goals, not requirements. ● Flesh the requirements out together. ● Use a whiteboard.
- 22. Group Discussion Pitfalls ● Parkinson’s Law - “A task will fill the time available for its completion.” ● Sunk Cost Bias - We stick to plans even when they’re inefficient and/or ineffective because of the investment. ● Fundamental Attribution Error - We tend to explain behavior through internal factors and underestimate external factors. ● Confirmation Bias - We like information that confirms our beliefs. ● Self-Serving Bias - Egos are important, so sometimes people manipulate information which makes it hard to make informed decisions. ● Action Bias - Doing something for the sake of doing it, even when it is a bad idea.
- 23. Group Discussion Pitfalls ● Bandwagon Bias - Everybody’s doing it! ● Conformity Bias - Everybody’s thinking it! ● Authority Bias - Your boss wants to do it!
- 24. Sometimes, people need to fight.
- 25. Sometimes, they fight too much.
- 26. Conflict Resolution ● Stay chill. ● Force everyone to take a break for a few hours and then reconvene. ● Outline the problem that you’re trying to solve and the different perspectives. ● You should identify why an approach does or doesn’t work. ● Guide everyone to a resolution. ● If you can compromise without messing with the product integrity, it can be a good idea.
- 27. Unless someone disagrees with you.
- 28. Just Kidding ● You’re not always going to be right, surround yourself with people that are comfortable disagreeing with you. ● Sometimes you will be right, back up your perspective with data. ● Don’t be combative, lead people to the right answer. ● Say ‘No’ without actually saying the word.
- 29. How To Not Lose Your Mind ● Stay chill. ● Choose your battles. ● Exercise empathy. ● Move on. ● Keep feedback contained. ● Be very clear about what your MVP is before you start building it.
- 30. Design ● Never isolate Design and Development. ● Try to identify any limitations at the beginning of the wireframe process. ● Don’t aim for design consensus, it waters the direction down. ● Schedule walkthroughs of design with development during kickoffs. ● When working with stakeholders, don’t host an open call for feedback. Instead, walk them through decisions that were made and why they work well.
- 31. Build ● Establish milestones ● Standups ● Office Hours ● Town Halls
- 33. Burnout
- 34. Pre-Launch ● Paired design QA ● Avoid scope creep and piecemeal feedback. ● Choose your battles (again). ● Conduct user tests with your design and development teams.
- 35. Launch ● Don’t sell out on the launch moment. ● Overcommunicate with your stakeholders.
- 36. Part-time Product Management Courses in San Francisco, Silicon Valley, Los Angeles, New York, Austin, Boston, Seattle, Chicago, Denver, London, Toronto www.productschool.com
Editor's Notes
- The easiest way to summarize product management is the intersection between business, design, and engineering. When we talk about product management, we talk a lot about the design aspects and the engineering aspects, but we don’t talk enough about the business side. Sure, there are tons of articles about defining KPIs and product strategy, prioritizing, whatever. but not enough about working with actual people. As much as it’s a PM’s responsibility to be an advocate for the user, it’s also your responsibility to be the advocate for every single person at your company. You are the one person that every department has in common. It’s your job to find the balance between all of the departments, as well as the overall business strategy. You are also the face of the product - which is awesome when things are going well, but it can be terrible when things aren’t. And, as the person driving product development, leading the meetings and brainstorms and launch cycle, it’s also up to you to deal with conflicts, burn out, and scope creep. When people ask me what my favorite part of product management is - it’s obviously building cool shit on the internet, but it’s also working with people. When people ask me what my least favorite part of product management is - it’s also working with people.
- So, let’s start at the beginning - you’ve just started as a product manager at a new company. Your stakeholders are going to have a laundry list of wants to overwhelm you with. While you’re uploading your custom emojis to Slack and downloading too many productivity apps, you should also take the time to do all the things that you won’t be able to do when the world becomes chaos. Get to know everybody, not just your stakeholders. More often than not, the most valuable perspectives at a company aren’t going to come from your stakeholders. It’s going to come from the people who deal with the day-to-day aspects of your products. Their perspective can redefine your entire product strategy. I met with the editorial director of New York Magazine every week, but talking with the copy editors completely changed the UI of our CMS because they were the ones responsible for publishing every single article. Your social and customer service teams have a direct line to your users. Get to know them, establish that communication, because they’ll be able to provide insight that data can’t and that the marketing or operations stakeholder may not prioritize. My favorite question to ask people is “what makes you throw your computer out the window?”. It’s important to understand every team’s day-to-day and constantly try to find ways to make it better. More importantly, framing questions like this rather than asking people for requests or wish list items tends to yield way better results. Sometimes people don’t even know that they can ask for a new feature or a bug fix, especially if they aren’t considered a stakeholder. It’s important to prioritize internal tool cleanup as much as possible, especially at companies with aggressive roadmaps. If people are frustrated with things that they do or use daily, that frustration is going to leak everywhere and it’s bad for company culture. At New York Mag, the slack emoji for their legacy CMS was an actual dumpster fire. More than half of the company has to use a dumpster fire multiple times a day. When you ask these kinds of questions, you often end up being the company therapist. Because product people touch every aspect of the business, they are usually the people with the answers. Take advantage of your position, get coffee or lunch or drinks with people at the company and develop a rapport. You should be the advocate for your co-workers as much as you are an advocate for the users. Plus, having a good relationship with your colleagues means they will be more patient when you’re dealing with a buggy launch. Sit down with your lead developer and get a deep dive of the technical architecture. Pay attention and take notes because most developers hate repeating themselves. This will help you understand your technical constraints from the get-go and also get some respect from your engineering team for wanting to understand and be engaged with the more technical side of things. Find the low-hanging fruit and fix it. Don’t try to hit the ground running and completely redesign or launch a huge feature. Find the easy wins, see good results and make people’s days easier. It will help a lot in the future. It’s kind of like when you first start a job, you should show up earlier than everybody for the first couple weeks because from then on, you’ll always be seen as an “early” person, even when you’re not. Applying that same theory to product management means that people are always going to see you as somebody that gets things done, even when you can’t.