Rosa Villegas

There are a few different vectors to consider here. There is the effort/impact matrix, which is pretty good at helping identify low hanging fruit - essentially mapping out potential workstreams on a 2x2 matrix (High effort/high impact, low effort/low impact, etc). This can help cut through the noise as a good first step, but isn't the only thing you should be considering. Other lens I apply are things like: * Customer - how many customers does this serve? VIP customers? Is this a want or a need? This gets to the "impact" part of the 2x2. * Urgency/timeline - how flexible is the schedule for this? Is it immovable (like compliance/legal requirement) or can we work to create space on our roadmap (perhaps deliver a smaller milestone, negotiate a different delivery, etc). * Scope - can we potentially cut scope or re-scope to help move quicker (example: do a proof of concept to answer effort questions, running an experiment to get an early read on impact, etc), or is there potentially another way to solve the problem that we haven't considered. Change we change the "effort" calculation? * Expected outcomes - this gets back to the impact, but you will be surprised, especially in an org that may not have a product presence, that there may not be a clear definition of success or outcomes a project is trying to achieve. Part of the role is to apply process and discipline in this area. Keep in mind that in organizations where Product is nascent or does not exist, oftentimes there is no one defining the "why", and potentially there is a lot of discussion on the "how" and the "what." One of the biggest impacts you can have as a product manager in an organization is being very clear on the why. You may find that the team is focused on the wrong things (e.g. focusing on building "bright and shiny" features rather than things that customers may actually care about, or doing custom work for a particularly vocal customer, etc). Part of the hard part of product management is saying no to things/pushing back, making tough choices and potentially killing projects that don't provide clear business value.

Be adaptable to change - don't be afraid to try different things or change a process that is no longer working for the team. For a team that is growing quickly oftentimes process gets ignored because the team is so focused on delivering/executing that they feel process may slow them down. In some cases little to no process can be a good thing, but for a team that is scaling it can be detrimental. What I try to do is understand how they are using product management processes today and then try to understand where product can add the most impact short term and demonstrate early wins to help build trust. Getting buy-in from the team is essential, and typically I try to message that I am adaptable and my goal is to help the team's ability to execute and focus on the right things rather than add more things to their plate. I entered a team that was doing well from a revenue standpoint but was constantly putting out fires and as a result didn't have much time to focus on feature development to improve and grow the product - it was just maintaining with a bit of decline. I focused first on root cause analysis of the fires/incidents from the previous 60 days and found most of them could have been avoided by introducing a lightweight process before a content release. We piloted it for 1 team for couple sprints and found it reduced incidents by about 50%, so we rolled it out to other teams and got similar results. This in turn freed up engineers from firefighting, and also helped me build trust with the team. In general my motto was "what we have now isn't working, let's try X for a few sprints and if it's not working we'll try something else." The general pushback I usually got was from engineers who wanted to avoid meetings or unnecessary overhead - however, I found that if I could show that I was flexible and what I was doing would ultimately save them time/effort, I found most to be amenable to change. Another tool that helped me was retrospectives and post-mortems, and advocating for better processes during these times. Oftentimes in these situations people are open to discussing improvements, and if you can clearly tie in how a product process can help avoid/solve a problem you can get buy in easily, particularly if you are offering to drive it. Better yet, if you can circle back with results and outcomes that show how this benefited the team (fewer CS tickets, better velocity, etc) you can help demonstrate the value that product can provide. 

This is a really interesting question! I think one really great way of doing this is to engage design in understanding the problem you are trying to solve, not just the solution. Oftentimes, we jump straight to execution without always understanding the full customer journey or the vision for the future. In doing this it's easy to treat design as just a step in the process rather than as a thought partner who can help inject customer empathy throughout the product lifecycle. A few things you can do to get Design more involved upfront is in the ideation, discovery and exploration phase where they can more fully understand the problem we are trying to solve. This is things like participating in customer interviews or consumer insights testing. Engage them early and create opportunities to discuss and reflect with them what you learned and potential next steps. Another thing we do is engage them as a stakeholder alongside disciplines such as engineering throughout the process - review product 1-pagers with them to gauge their thoughts and collect early feedback, and continue working with them throughout the process, including iteration and optimization. Many times they see things that I might not have even thought of, or challenge assumptions I am making. I have regular 1:1s with the Design leaders in the org and make sure I am hearing feedback on what we can be doing better for our customers.

It takes a solid 6 months for any new leader to make an impact on an organization. My first goal is usually to build trust and gain as much context as possible before making any big decisions or changes. 30 Days - My first objective is to listen and understand the organization, its customers, its goals and challenges. Identify key points of contact, stakeholders/customers, and colleagues. In the past I have done "listening tours" where I sit down with as many people as possible that represent voices within the organization and hear: * Their thoughts on the team and what is working/not working. * What they think the role of Product is and what Product can bring to the table within the org. * What are their biggest challenges short/med/long term goals and how can my team help them * Understand the history, culture and general context of the org - how decisions are made, processes etc. * Identify any immediate or urgent concerns that need to be addressed ASAP Document all my conversations and start process of pattern-matching. 60 days - Developing a point of view and start sketching out short/med/long term goals. * Using my learnings from the above start developing a rough outline of short/med/long term issues and opportunities with basic effort/impact for prioritization * Define what success looks like - can I visualize the customer journey, what are the KPIs I want to move, what does my "postcard from the future" look like? * Start building buy-in and rapport with key people within the organization - solicit feedback on outline and ask appropiate 2nd/3rd level questions to gain better understanding of issues and potential solutions. * Understand the resources/skills necessary to execute and start lining up strategy to acquire - do we need more analytics support, more process or skills/education in a certain area, etc. What are the gaps on my team and what can I do to address? 90 days - Build and learn * Have a more polished short term roadmap, and ideas for medium/long term. Ideally outputs from my short term roadmap can help inform decisions further down the line - discovery tasks, making a prototype/MVP, etc. * Have regular checkins with key stakeholders to provide updates on workstreams and solicit feedback. * Start process of filling gaps defined above with feedback from the team - pilot new processes, securing help from other teams, etc. 

I touched on this a bit in previous questions, but some common challenges are: * Perception that Product may slow the team down. Some teams are very execution-focused, which can be good, but it's easy for team members to not be able to see the forest through the trees, and potentially get into a situation where they may be doing too many things, or not being focused on the right things. * Unclear or misalignment of goals or priorities - Product can add a lot of value but without a clear idea of the outcomes we are trying to achieve and the relative importance of various strategic priorities, it is easy to get in a state where the team is overstretched or not set up for success. Obviously Product has an important role to play in these decisions, but guidance and buy-in from leadership in these areas is essential for success. * Mature leadership that sees the big pitcure and understands the time/quality/cost "iron triangle." Time/Quality/Cost are the 3 primary forces in a project. A good product manager needs to be able to navigate discussions around tradeoffs and opportunities with leadership and stakholders and achieve alignment - essentially challenges around ensuring the team is setup for success and what tradeoffs we need to be comfortable making to do so. Mature leadership understands these forces and can partner with Product to craft a coherent strategy to get to a desired future state. Inexperienced leadership demands all three and may have constantly changing goals or priorities ("flavor of the month.") * Establishing Product in an area that I do not have expertise in. This one was the hardest for me personally because for the first decade of my Product career I was sucessful through competence. I knew my domain and product (mobile games) very well and had managed just about every facet there was on a game team. When I switched over to Platform product, I initially felt lost and questioned if if I could still be capable if I did not have competence in every area. Personally this was something I had to work through myself - what I eventually found was that most of the same product principles still apply: stakeholder management, defining the problem/sucess criteria, etc) but it was not essential that I have expertise in every area. My role was to build a team that did have expertise and empower them to help drive success. This was more of a personal challenge but probably the biggest paradigm shift for me as a Product Leader.

Within Central Technology we are organized into Product verticals: Game Services, Developer Services, and Infrastructure Services. Each of these verticals are comprised of 3-6 teams that manage a suite of products. I have a Product Lead for each of the verticals, and the product leads typically manage the PMs for each of the teams. Depending on the needs of the team a PM may be fully or partly dedicated to a team (for example our Payments team has a fully dedicated PM, whereas our Cloud and Kubernetes teams share a single PM. In addition to their normal day to day team management, some PMs also tackle special projects - for example if a new initiative is introduced that requires coordination from across the org, oftentimes a PM will help drive the project and work on a horizontal basis. This helps PMs go deep in 1-2 areas and have clear ownership, but also allows them to work horizontally and have opportunities to grow their skills and visibility within the organization. As my organization has evolved so has my product team. When I first joined Central Tech we had just 1 PM for 90+ engineers, and our processes changed as we slowly grew the product team. Now we have a much more robust team (about 11 PMs), and have a more mature structure. In general, I try to have a mix of skill sets and styles - since we manage over 80 different products and services and serve both internal and external customers (game teams and players) I think its beneficial to have a diverse team that can flex in different areas. For example having technical generalists as well as PMs with deep domain experience, as well as non-technical PMs who have a clear sense of player empathy are all valuable for the work that we do. In general my organization follows a "three legged stool" model where we have representation from Engineering, Production, and Product at all levels of the org (team/vertical/leadership). This helps ensure we have alignment throughout the org and that each major discipline has a seat at the table.