Day in Life PM Courses at Product School
•
4 gefällt mir•875 views
The document summarizes a presentation given by Lucy Meadow, a Senior Product Manager at Expedia, about her day-to-day work. It discusses the key roles of a product manager, including leading teams, executing on visions and strategies, and using data and the scientific method to validate product decisions. It also outlines Meadow's process for identifying customer opportunities, gathering stakeholder input, developing roadmaps, and continuously measuring results to refine products. The presentation was given on the website Productschool.com to provide information to students in their online product management courses.
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie Day in Life PM Courses at Product School
Ähnlich wie Day in Life PM Courses at Product School (20)
Mehr von Product School
Mehr von Product School (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Day in Life PM Courses at Product School
- 1. www.productschool.com A Day in the Life of a Product Manager by Expedia Senior PM
- 2. FREE INVITE Join 30,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 Learn the skills to understand web analytics, SQL and machine learning concepts
- 6. COURSES Digital Marketing for Managers Learn how to acquire more users and convert them into clients
- 7. COURSES Blockchain for Managers Learn how to trade cryptocurrencies and build products using the blockchain
- 9. A Day in the Life of a Product Manager What would you say you do here? Lucy Meadow Sr. Product Manager Expedia Group www.linkedin.com/in/lucy-meadow
- 10. Agenda ● What defines Product Management? ● High level Product Development process ● Product Manager roles ● The Synthesis of Product Development Process and Product Manager Roles ● Agile Product Methodology ● The Scientific Method ● Let’s recap ● Questions
- 11. What would you say you do here? “The role of a product manager is to discover a product that is valuable, usable and feasible” - Marty Cagan, Inspired: How to Create Products Customers Love
- 12. How do we get all this done? Technology User Experience Business Product Manager
- 13. LEAD DO THINK PARTNER Identify the opportunity Validate opportunity Get the required buy-in Build out a vision, strategy & plan Execute on the vision, strategy & plan Assess performance and decide on next steps
- 15. CEO ●Emotional intelligence ●Relationship building ●Wits and influence to get sh*t done ●Combo of instincts, energy and decisions ●Buck stops with you ●Get none of the glory and all of the blame ●Satisfaction comes from knowing you’ve created and driven a good product
- 16. Coach ● Product Managers might not “do” anything but still “in the mix” ● KYP (know your personnel) ● Understands how people work together ● Intuits which plays to call in the crucial moments ● Inspire, motivate, and convince their team
- 17. Janitor ● Do as much dirty work as possible so everyone else doesn’t have to ● Unblock the team so can keep the engine running ● Fade into the background when needed ● Making unsexy little decisions that need to be made by someone
- 18. Hammer ●Decisive decision making ●Influence and persuasion to gain alignment ●Force, grace and authority to gain trust and respect ●Confidence and humility ●Make people commit to a clear position and establish course of action ●Drive to resolution
- 19. Expert User ●Know the product better than anyone ●Use the product every day ●Can speak the language of the engineering team ●This helps drive vision and prioritization as well as conversations with stakeholders and partner teams
- 20. At the end of the day… …you’re the product itself.
- 21. How do these roles overlay onto the Product Development process? LEAD DO THINK PARTNER Identify the opportunity Validate opportunity Get the required buy-in Build out a vision, strategy & plan Execute on the vision, strategy & plan Assess performance and decide on next steps
- 22. Make the customer’s experience better and make $$$ Be measurable Consider scalable product loops
- 23. Engage the partner teams to size, validate and refine the problem and/or opportunity
- 24. Identify, engage and influence key stakeholders and sponsors about the value of investing in solving the customer problem
- 25. Identify key stakeholders and align vision, strategy and goals to address the opportunity Obtain feedback and refine the vision, strategy and plan from the key stakeholders and sponsors Publish and evangelize the final vision, strategy and plan for the broader audience
- 26. Build roadmap and prioritized backlog to show how and when you plan to deliver key results Set expectations and establish workflow with core working teams Provide detailed product requirements and make necessary trade-off decisions Communicate status to all stakeholders
- 27. Measure and validate accuracy of performance Use data, observations and insights to validate the success of investments Use this information to define next steps
- 28. But how do you know when to stop?
- 31. And how do you know if you’re building the right product?
- 34. Observations • Search Landing Pages display the same content to returning visitors • Repeat visits represent almost half of all visits • Returning visitors are worth almost 2x as much as new visitors • Our competitors display more relevant and personalized information to returning visitors
- 35. Hypothesis By adding different yet relevant content to returning visitors on SEO Landing Pages based on information we analyzed from their first visit; They will keep our brand top of mind when they are ready to purchase; By being more likely to click, engage and return throughout the various phases of their travel purchasing process
- 37. Success Metrics • Primary: Click Through Rate • Secondary: Do no harm to Traffic/Visits, Repeat Visitor Rate, Conversion, Bounce Rate, Gross Profit (GP)
- 38. Conclusion • Inconclusive • Not enough traffic • Learned a lot about underlying technical platforms • Used connection built to run 3 more tests, 2 of which were winners
- 39. Many Product Managers work on a portfolio of products across many different stakeholders
- 40. So how do we make this all happen?
- 41. Core skills ● Listening ● Communication ● Influence ● Presentation ● Organization ● Data analysis ● Strategic thinking
- 42. Product vision ● Ask “What if?” ● Customer empathy ● Competitive analysis ● Design and systems thinking
- 43. Product execution ● Define MVP/milestone ● Maintain roadmap ● Prioritize backlog ● Unblock teams ● Make trade-off decisions ● Report status
- 45. Lucy Meadow Sr. Product Manager www.linkedin.com/in/lucy-meadow
- 46. www.productschool.com Part-time Product Management, Coding, Data, Digital Marketing and Blockchain courses in San Francisco, Silicon Valley, New York, Santa Monica, Los Angeles, Austin, Boston, Boulder, Chicago, Denver, Orange County, Seattle, Bellevue, Toronto, London and Online
Hinweis der Redaktion
- Hello and welcome to A Day in the Life of a Product Manager. I’m Lucy Meadow, a Sr. Product Manager currently working at Expedia and I’ve been working in Product Management for the last ten years.
- The goal of today’s presentation is to provide a high level overview of the Product Management development process and better understand the different roles that a Product Manager assumes within each step. Product Management is a murky role. It varies from company to company, and even from team to team. My hope is that you take away a better understanding of what it means to be a product manager and how product managers engage in cross functional teams. Please hold your questions till the end.
- So what does a Product Manager do? Marty Cagan, who is widely recognized as the primary thought leader for technology product management, says that the role of a product manager is to discover a product that is valuable, usable and feasible. Considering this definition, there are two main parts of a Product Manager’s role. The first is knowing the customer and understanding what is valuable and usable to them. And the second is deciding what you’re going to build and how, which determines what is feasible.
- And we certainly don’t do it on our own. One of the most important jobs of a Product Manager is establishing relationships with the many teams that help us execute on our vision. Simply stated, it’s our job to properly understand the customer problem, confirm with the business that we are meeting their needs, and then work with User Experience and Engineering to understand how to solve it.
- In order to understand what a Product Manager does, it’s really important to understand the Product Development process. The first part of the process is Identifying the Opportunity. Product Managers do so through competitive analysis, internal product teardowns and direct customer engagement. To validate this opportunity and get the required buy-in, Product Managers must partner across other groups. Other groups might include stakeholders, other Product Managers, Legal and even Finance. Product Managers need alignment across all relevant teams in order to secure the help to successfully build out their product. The next part is often the hardest. Thinking. And lots of it. Once Product Managers have validated the opportunity and gotten the necessary buy-in, they need to translate it into something that can be built. That vision or strategy needs to be shared across teams to further solidify alignment and buy-in. Product Managers then work with their internal engineering teams to flesh out an executable plan. This includes a Backlog and Roadmap consisting of Engineering Tasks that can be developed, tested, released to production and then quantified and measured. As development begins Product Managers will take a step back to let engineering do their thing, but will be in close communication to understand progress and help unblock the team so as to not slow down development. Finally, after the process is completed and something has been shipped, Product Managers will need to understand the overall impact of the effort and determine next steps. Success will need to be evaluated in understanding what comes next.
- https://medium.com/all-things-product-management/product-manager-you-are-664d83ee702e So that’s a lot of things on a Product Manager’s plate. But how does this boil down and what kinds of mind sets enable Product Managers to get this all done? One of my favorite articles on Product Management was sent to me by the former Chief Product Officer at Orbitz. In the article, Mat Balez, a Product Manager who has worked at Google as well as several start ups, breaks down a Product Manager’s role into different more recognizable “jobs”. I like using this as a framework for discussions on Product Management because I think it helps provide recognizable analogies to better understand the job. As I mentioned earlier, Product Management is a “murky” role, changing drastically from company to company and even between teams within the same company. My role as a Product Manager on a platform team varies greatly from someone who works on the mobile app. As you’ve probably seen from the first several slides, Product Managers wear many “hats” and there is a lot of “dark art” to the role. My hope is through these comparisons you’ll see that there are many different facets of Product Management, but they all connect together to help us build successful products.
- The CEO analogy is a popular one, as Product Management requires a lot of emotional intelligence, relationship building and using one’s wits and influence to get stuff done. Those relationships are what make a CEO, and Product Manager, successful. Additionally, Product Managers are often the “face” of the Product itself, and are responsible for showcasing its capabilities, marketing its strengths, and road showing its functionalities to partner groups. Furthermore, the “buck stops” with the Product Manager, meaning we have the final say in terms of prioritization and which features get developed. It is also a bit of an overstatement. In reality, Product Managers drive forward relatively small dimensions of the product with little meaningful control over resourcing, zero actual reporting authority over anyone, nor much, if any, say in the budgeting process. Our primary satisfaction comes from knowing we’ve created and driven a good product.
- Another appropriate analogy is that Product Managers are like coaches. Product Managers, in the development sense of the word, don’t really “do” anything. Instead Product Managers, like Coaches, know which team members to put into which situations. Coaches and Product Managers alike understand that teams are composed of people and the relationships between each member influence the effectiveness of the team. Product Managers, like coaches, need to be motivational and rally their team members to find ways to inspire.
- This is my favorite analogy for Product Management because it couldn’t be more true. A Product Manager rolls up his or her sleeves to do as much dirty work as possible so that the rest of the team can keep their heads down and focus on the end results. Some examples might be finding a meeting slot that works for 14 different people across 5 different time zones on a Friday before a long weekend, or triaging 300 low priority bugs that remain in the backlog. Product Managers make a million unsexy little decisions to keep the engine running every day. Additionally, like a Janitor, Product Managers often need to fade into the background and not interfere with the day to day goings on if they aren’t needed. An instrumental role of Product Managers is unblocking their team while remaining unseen.
- As I previously mentioned, one of the most important parts of a Product Manager’s role is alignment and partnership across multiple teams. Without that alignment, we can’t actually get anything done. We need to convince other people to do what we need them to do for the good of the product. Sometimes forcefully. Like a hammer. With hammer-like confidence sprinkled with humility, Product Managers need to influence, persuade and communicate a passion for our product. To do this we blend data with argument, fact with opinion, and logic with emotion. We are a force that makes things happen. We don’t let people waver in their decisions; we make people commit to a clear position and establish a course of action. We are decisive.
- Finally, Product Managers are the product’s most experienced and avid user. We use our tools daily and often are its most prolific bug reporters. Think about it: how can you build a valuable, usable and feasible product if you don’t know that product inside and out? Not only must Product Managers know everything there is to know about their product, but they also need to work closely with users and stakeholders to understand how they use the product and what their pain points are.
- But at the end of the day, you’re the product itself…The product your team builds and ships is the most faithful representation of your success as a Product Manager. It is the sum product of all your effort. Your success in making your product greatly hinges on your ability to be, at every moment in time, the most valuable thing your team needs you to be at that very moment.
- So that’s all fine and good, but how does that help to better understand the Product Development process? My hope is that by better understanding what it means to be a Product Manager, we can overlay that new understanding onto the Product Development Process and understand how these roles can enable Product Managers to be their most successful.
- The first step in the Product Development process is identifying the opportunity. This involves working closely with stakeholders to identify customer needs and business opportunities. The main point here is that at this stage it is important to understand opportunity across all groups using established relationships. Here, the Product Manager operates as a CEO, using emotional intelligence across these relationships, as well as instincts and energy to make sure no stone is unturned. At Expedia, this can take the form of competitive analysis, internal product and workflow teardowns, and direct customer engagement often spearheaded by UX. At this stage a Product Manager, operating like a CEO, takes a leadership role to drive the process.
- The next step is to validate the opportunity, which involves engaging the partner teams to size, validate and refine the opportunity. This part of the process is difficult because we mostly rely on theoretical validations rather than analyzing something in production. We sometimes write code first and then use it to validate the original hypothesis when ideally, we should validate the opportunity prior to development efforts. This can be done with smoke testing or other projections. An example we sometimes use at Expedia is including a link to an “in development” page for a new feature or functionality to measure click through and understand end customer interest. In this part of the process, Product Managers should act as a hammer with CEO tendencies, working his or her relationships to help validate across various teams. This means beginning to persuade and convince partners to take the opportunity seriously. In parallel, the Product Manager will market and showcase the opportunity and how it can benefit the product and company as a whole.
- Next in the process is getting the required buy-in and support, which involves identifying, engaging and influencing key stakeholders and sponsors. Product Managers need to be a hammer and convince them it is valuable to invest in solving the customer problem. For this part in the process there is no handbook or framework. While requiring a lot of data to support the opportunity, it also requires a ton of emotional intelligence. This is where a Product Manager’s role as a hammer comes into play. In this phase, Product Managers need to be convincing to make sure everyone is in alignment. We have to be persuasive in getting that alignment and drive other people to do what we need them to do for the good of the product. Sponsorship and support across all stakeholders is required for a successful product. This is the turning point in the process as without this required buy-in, there is no way to eventual success.
- Once the required buy-in is achieved, the Product Manager can move forward with building out a strategy. This will need to be shared with key stakeholders to obtain feedback. This strategy will need to be buildable and contain a cohesive roadmap and backlog that the engineering team will be able to execute on. At this part in the process a Product Manager acts mainly as an Expert User, understanding their product more than anyone else. They use this expertise to filter the ideas and requests coming in from various sources into a realistic plan. They also need to consider technical impacts so that they can create a plan that enables them to understand value quickly, sometimes in the form of quick smoke tests.
- As the Process reaches the execution phase, the Product Manager builds the roadmap and prioritizes the backlog to identify when key results will be delivered. They set expectations on timelines and create a workflow with the core working teams. In my experience, this has manifested as bi-weekly planning sessions with engineers as well as syncs with stakeholders to update them on progress. Additionally we hold envisionings to flesh out requirements prior to the beginning of a sprint and retrospectives at the end to improve efficiency. Product Managers also make any trade-offs in terms of features and prioritization to always build towards value and solving the customer problem. After completing this, the Product Manager’s role is mostly hands off as the engineering team takes over to execute on the plan. Acting like a coach, the Product Manager rallies their team and find ways to inspire and motivate. This might be with positive feedback or even donuts or snacks after a particularly grueling sprint. Additionally, it is crucial that the Product Manager works to unblock the team so that they have as few distractions as possible. Like a Janitor, the Product Manager works behind the scenes to make sure everything runs smoothly.
- Finally, once the product has been shipped, the Product Manager steps back into their CEO role in order to assess performance and decide on next steps, often using analytics along with customer and stakeholder feedback. As the CEO, the Product Manager is on the hook for the success of the product. In reality, we often get none of the glory if the product is a success (with that rightfully going to the team that actually built it), and all of the blame if it doesn’t perform as expected (since it was our job to validate the opportunity in the first place). We do, however, get satisfaction from knowing we’ve created and driven a good product. And with that, we will need to assess the performance of what has been shipped and determine next steps. Do we iterate? Are we done? And how do you know if you’re done?
- That is a great and difficult question. It is difficult to know when to sunset a product and let it go into maintenance mode enabling us to move onto a different problem. The biggest questions a Product Manager needs to ask his or herself at the end of each Product Development Cycle is What’s the next big thing? Should I continue investing in this product because there’s still impact? Or move onto to something else? This definitely differs from product to product and team to team. There are some forums at Expedia we use to identify where we are. There are internal product reviews done on a team level, as well as a larger portfolio review that happens at a leadership level. But it is definitely important for a Product Manager to constantly be asking themselves if the product needs continued investment or not. And that is not always an easy question to answer.
- https://www.youtube.com/watch?v=502ILHjX9EE So we’ve been talking really high level, and that’s OK because Product Management is often times theoretical. But how does this shake out in the day to day? This is where the Agile software development cycle comes into play. Agile takes the Product Development lifecycle to a whole new level. It requires constant communication and feedback to ensure alignment while the teams builds out the plan. This means that stakeholders will never be surprised with what’s being built and Product Managers can constantly assess the impact of the engineering effort.
- So what is Agile and how does a Product Manager fit in? We start with our PM (CLICK) who has a vision (CLICK CLICK). Stakeholders and users (CLICK) are supported by the product being built from the Product Manager’s vision. And their needs and vision are expressed in terms of user stories (CLICK). These Stakeholders and users often times have lots of ideas, and it’s the job of the Product Manager to turn these (CLICK CLICK) into concrete stories. But somebody has to build the product (CLICK). This is a small collocated self organizing development team. This team releases early and often (CLICK) – let’s say 4-6 stories per sprint (CLICK X 4). Some of these stories are big and can count as 2 (CLICK). So for the sake of argument we’ll say their capacity is 4-6 stories. So the problem arises when the stakeholders have a ton of ides (CLICK) that aren’t limited to 4-6 per sprint (CLICK X 11) and we know this will be the case. Every time the team delivers something to the stakeholders, they want MOAR. So let’s say the team starts working on 10 new stories (which would be their input), and delivers 5, their output. This means there is an overflow of 5 stories (CLICK X 5), which start to build up and can become overwhelming for the team. This is where the PM steps in to filter (CLICK) the next 4-6 stories for the team to work on (CLICK X 2). The side effect is that there is a queue that forms (CLICK X 11). This is the backlog that needs to be managed (CLICK) by the Product Manager. The only way from stopping the queue from getting out of control is for the PM to say NO (CLICK X 3). The PM decides what goes in and out of the backlog, as well as what gets worked on in what order, including determining how long the backlog needs to be. But, as I’ve stated many times already, they don’t do it alone (CLICK). There is constant (CLICK) communication between Product (CLICK X 3), development and stakeholders. The PM also needs to understand the value and size of requests being made – some stories are bigger than others, some have a higher value than others, and there is no correlation between the two. The Product Manager will need to work with both engineering and stakeholders to understand how big a story is vs. how much it will return in value. So let’s say there are two stories of the same size but one will provide more value than another (CLICK CLICK)? That one will be prioritized higher (CLICK CLICK). Two stories of differing size but providing the same value (CLICK CLICK)? The smaller story goes first (CLICK). So how does PM know the value and size? Well they don’t, it’s a guessing game that everyone is involved in. The PM is constantly talking to stakeholders to understand value, and talking to the dev team to understand size. At the beginning of new project guesses will inevitably suck but that’s OK, because the value is in the conversations – and it will get better over time. That’s why we need a feedback loop so that we are constantly understanding what’s important to the stakeholders and project and how big things actually are so we can continue our prioritization efforts.
- So great. We’ve built something and delivered it. But how do we know if it’s the right thing? This is where it gets even more complex. That’s where at Expedia the Scientific Method comes into play. The scientific method allows us to calculate value for incremental changes that we make across our products. It is defined by Dictionary.com as “consisting in systematic observation, measurement, and experiment, and the formulation, testing, and modification of hypotheses.” So let’s break that down.
- There are several steps. First we observe a customer problem which is where we identify opportunity, and that can come from internal observations as well as competitive analysis. Then we turn these observations into a hypothesis in the form of the following statement: By [making a change] We will [accomplish the following] By [achieving pre-defined success criteria] Then we flesh out a test design, which is how the test will get implemented and measured. And finally we define success criteria, which is how we will determine whether this particular effort is a winner, loser, or often times (and most disappointingly) inconclusive. The importance of the Scientific Method is to not stop there, and to make sure to always learn from the output of a test so that you can iterate within the process, always refining your hypothesis and driving towards measurable impact.
- So how does that look at Expedia? We’ll walk through an example of a test that we ran as part of an effort to increase engagement among returning visitors to the website. The goal of this test was to target users we identified as less likely to book a hotel room by showing them more relevant information the second time they visited the web page. So, let’s see why and how we chose to pursue this opportunity.
- These are real observations that came from working closely with our analytics team to understand customer behavior as it related to the website experience, as well as looking at our main competitors in the same space: Search Landing Pages display the same content to returning visitors regardless of what we know about them or how they have interacted with the site previously Repeat visits have been steadily growing and represent almost half of all SEO visits Returning visitors are worth almost 2x as much as new visitors And our competitors display more relevant and personalized information to returning visitors
- We then turned those observations into a hypothesis: By displaying different yet relevant content to returning visitors on SEO Landing Pages based on information we analyzed from their first visit, they will keep our brand top of mind when they are ready to purchase by being more likely to click, engage and return throughout the various phases of their travel purchasing process.
- We then broke that hypothesis into a test design: There are 2 variants. The control is the same list of hotels that a user sees regardless of how many times they have visited the page. The variant, displayed to returning visitors, features an additional image relevant to the destination, which links them to more information for that location. The test is split 50/50 meaning visitors will be bucketed evenly into either the control or the variant.
- Finally, in order to under whether the test is successful or not, we will track the following metrics: Our primary success metric is the percentage of click through rate in the variant versus control. We also track secondary metrics to make sure that we do no harm to other traditional markers of success. These include doing no harm to Traffic and Visits, our Repeat Visitor Rate, Conversion, Bounce Rate, and Gross Profit (GP).
- Unfortunately this test was inconclusive because we were unable to generate enough traffic to reach significance. Despite this, we did learn a lot about the underlying technology that we needed to connect to in order to power the test in the first place. This enabled us to run 3 more tests over the course of the year to provide more relevant information to returning visitors, 2 of which were winners. Our ability to learn from the test and iterate on that learning is one of the most important parts of the Scientific Method. This is an example of where we decided to invest in the technical implementation rather than do a quick smoke test because we felt the underlying technology was important to us and future endeavors.
- The reality of the situation is that Product Managers generally work on a portfolio of products that span across many different stakeholders. This means that they have multiple products at different parts of the development process, which are often times related, but can also be spread out across different parts of the business. It’s very much a balancing act and understanding of how much attention to give each one depends on the level of maturity of each product, as well as other players in the space.
- As you can see, Product Managers are responsible for a lot of things. We’ve gone through the various roles and how they relate to each part of the Product Development Process. But what job and personality skills are crucial to being a successful Product Manager?
- My hope is after everything we’ve talked through up until this point, these won’t be much of a surprise, but more of a recap of everything discussed so far. I know this has been discussed already, but listening, communicating and influencing are incredibly important skills for a successful Product Manager. These skills help Product Managers develop relationships, identify, validate and get buy-in for opportunities and then showcase their plans to stakeholders. Product Managers must also have presentation and organizational skills so that they can properly articulate their vision and plans while balancing multiple across their portfolio. As previously mentioned, Product Managers must also use data to influence stakeholders to buy into their vision, as well as strategic thinking to tie all of these skills together and drive a product vision forward.
- Speaking of a Product Vision, Product managers must continually ask “What If?” What if we could build anything without constraints? This is always where Product Managers should start when building their vision. They must also have customer empathy or compassion when identifying customer problems. This allows them to build products that solve actual problems. They must also be well versed in competitive analysis to understand the problem area. When building this vision, they must think broader in terms of system engagement and how to make things scale. One cannot build a product vision in a silo.
- Finally, when executing on this product vision, Product Managers must use all their skills to do the following: Define measurable milestones and maintain their roadmap. Prioritize the backlog using agile product management methodology, unblock teams so things run smoothly without distractions. Make trade-offs using their analytic skills and ability to convince others that they’re right. And finally, report on status to stakeholders so that no one is ever surprised.
- As you can see, Product Managers are responsible for a whole hell of a lot. I hope I haven’t overwhelmed you. My goals have been to broaden understanding of what Product Managers do and how they fit into cross functional teams to drive business value while solving customer problems. I’d like to now open it up to questions.