Everything you’ve ever wanted to know about SAFe and the product owner role | Melissa Perri

Melissa’s background (0s)

• Melissa Perri has experience working with companies on product management and scaled agile, including the product owner role, which did not originate from product management but rather as a way to help developers prioritize tasks (23s).
• The product owner role is part of the Scrum framework, which is being adopted by more and more companies, especially large ones that traditionally didn't build software (42s).
• Melissa Perri is a well-known figure in the product management community, having written books such as "Escaping the Build Trap" and "Product Operations", and is the CEO and founder of the Product Institute, which trains product managers (1m9s).
• The Product Institute has trained product managers at almost every Fortune 500 company, and Melissa Perri has spoken at agile conferences about product management (1m22s).
• Melissa Perri's work involves helping companies implement agile methodologies, which prioritize moving quickly and delivering great value to customers (54s).
• She has seen companies adopt frameworks like Scrum and scaled agile, but notes that those who found success with SAFe often ended up modifying it to suit their needs (14s).
• Melissa Perri's expertise is in helping companies and product owners level up their organizations and themselves, especially in large non-tech companies (1m48s).

The rise of the product owner role (2m12s)

• The product owner role was found to be the third fastest growing role in Tech in the US, which was a surprising discovery given its relatively low profile in the tech ecosystem (2m31s).
• This role is part of the scaled agile framework and is not commonly discussed in tech circles, despite its growing importance (2m43s).
• Melissa Perri was invited to discuss the product owner role and scaled agile framework due to her extensive experience working with companies that use these methodologies (3m8s).
• Melissa has been passionate about the topic of product ownership and agile methodologies for many years and has spoken about it in both agile and product management circles (3m30s).
• The discussion aims to help listeners understand the product owner role and how to work effectively with product owners in a scaled agile environment (3m25s).

Understanding Agile and Scrum (6m37s)

• The product owner role was not well-known in the early days of tech, and it was not until 2011 that the concept of agile and scrum was introduced, which was seen as a flexible approach to breaking work into sprints and improving job performance (7m7s).
• The initial experience with agile and scrum was not dogmatic, but as time went on, other companies were found to be more rigid in their approach to scrum and standups (7m29s).
• Speaking at conferences, such as Mean UX in New York City, exposed the speaker to a larger agile community and sparked an interest in learning more about agile philosophies and the product owner role (7m38s).
• The product owner role in scrum was found to differ from traditional product management, which emphasizes understanding customers, testing, and hypothesis-driven development (8m8s).
• Many companies adopting scrum and introducing the product owner role were not following traditional product management practices, such as understanding customers and testing hypotheses (8m21s).
• The speaker's experience with agile and scrum began in a startup, where it was first introduced as a flexible approach to improving job performance (7m0s).
• The speaker's background was in product management, and the concept of the product owner role was new and unfamiliar at the time (6m55s).

Challenges in Agile transformations (8m27s)

• Many large companies, such as banks, underwent agile transformations around 2014-2015, resulting in the creation of new product owner roles, often filled by individuals from various backgrounds, including developers, business people, business analysts, and project managers (8m52s).
• These product owners were given their new roles without a clear understanding of their responsibilities, leading to a significant misconception about their duties compared to what is taught in agile and great product management (9m22s).
• The leaders of these companies often did not understand that simply implementing scrum would not lead to delivering amazing products, and that there is more to product management than just agile (9m42s).
• Despite some companies, such as Capital One, successfully integrating product management into their agile transformations, many organizations are still at the beginning of this journey and struggle to implement robust product management practices (9m55s).
• There is a need to help organizations set up end-to-end product management practices that go beyond just development and focus on building better products (10m36s).
• The industry is shifting, and companies are finally starting to understand the importance of product management in agile transformations, but there is still a long way to go, especially outside of the tech and Silicon Valley industries (9m51s).

The history of the product owner role (10m41s)

• The product owner role emerged from the business role of product managers in Silicon Valley companies like Google and Amazon, where software is the core business. (11m5s)
• In large companies, product management emerged from Scrum and product ownership, often being the first introduction to product management. (11m34s)
• Agile was a movement started by software developers, with the Agile Manifesto written in 2001 by a group of developers in Park City, Utah. (12m5s)
• The Agile Manifesto was created by developers such as Ken Schwaber and Jeff Sutherland, who were practicing Scrum, as well as others working on different Agile frameworks like Kanban, Behavioral-Driven Development, Feature-Driven Development, and Extreme Programming. (12m16s)
• The Agile Manifesto is a guideline for striving to build better products through software development, with a focus on building better products rather than just coding what people want. (12m50s)
• The Agile Manifesto was written by software developers, with no product managers present at the meeting, although Jeff Patton, a product manager, was close to the group and influenced by their work. (13m8s)
• The Agile Manifesto was approached from a development perspective, focusing on how to build better products from a development point of view. (13m33s)
• Jeff Sutherland and Ken Schwaber, who signed the Agile Manifesto, independently developed Scrum in their companies and later codified it, writing the Scrum guide. (13m42s)

The Scrum Guide (13m58s)

• The Scrum Guide is a widely used resource for agile practices, outlining roles and product development processes for development teams (13m59s).
• In Scrum, work is typically broken down into Sprints, with two weeks being a standard length, although this can be adjusted (14m16s).
• At the beginning of a Sprint, the product owner defines what work will be done from the backlog, writes user stories, and prioritizes tasks (14m21s).
• The development team then discusses the tasks, asks questions, and commits to what they will build, with the goal of producing a potentially shippable product at the end of the Sprint (14m37s).
• This approach is a departure from traditional waterfall methods, where work is done in a linear sequence with little customer feedback, and instead emphasizes breaking work into smaller chunks to get feedback faster (15m6s).
• The Scrum Guide introduces three key roles: developers, product owners, and Scrum Masters, with the Scrum Master responsible for helping teams improve their Scrum practices (15m27s).
• The Scrum Master's primary job is to help teams do Scrum better, addressing questions like "How do I do Scrum better?" and "How do I make Scrum more effective?" (15m39s).

Product owner responsibilities (15m43s)

• The Scrum Master is responsible for ensuring the team works well together, hosting retrospectives, and inspecting and adapting the process at the end of each Sprint to identify what went well and what didn't (15m43s).
• The Product Owner role originated with Scrum and is responsible for maximizing the value of work done by the team, with the team consisting of developers who turn the Product Owner's requests into a potentially shippable increment each Sprint (16m8s).
• The Scrum Master works with customers and management to identify and instantiate a Product Owner, teaching them how to do their job to optimize the value of Scrum, and is held accountable if they don't (16m33s).
• In the first version of the Scrum guide, the Product Owner may be the Product Manager for commercial development or the user department manager for in-house development efforts (16m52s).
• However, the 2013 version of the Scrum guide does not mention that the Product Manager could be the Product Owner, and instead leaves the role open to various possibilities (17m19s).
• The Product Owner role evolved into someone who asks for requirements and listens to stakeholders, but Scrum does not describe how to get items into the backlog (17m55s).
• The early versions of Scrum did not provide guidance on how to create a backlog, but later manuals have been updated to include starting with a vision and breaking it down into smaller pieces (18m20s).
• Product Owner training typically consists of a two-day class that teaches how to break down a backlog, manage stand-ups, prioritize work, and run retrospectives, but does not cover experimentation, market research, data, or other important aspects of the role (18m37s).
• The role of a product manager involves various skills and responsibilities, which were not fully considered when the product owner role was created in Agile transformations (19m3s).
• In the early 2010s and 2000s, large organizations adopted Scrum to build software faster and improve their innovation capabilities (19m27s).
• Scrum training was provided to product owners, who were often newly appointed, through a two-day class, and then they were expected to perform their roles (19m52s).
• The product owner role did not emerge from traditional product management, but rather as a way to help developers prioritize their work (20m5s).
• The primary responsibility of the product owner was to ensure that the development team was working on the most pressing and high-value tasks (20m18s).
• However, this role can also be seen as a way for developers to shift accountability to the product owner, saying "you told me to build that" (20m28s).
• This can lead to a misunderstanding of the product owner role and its responsibilities, particularly in teams that struggle to adopt Agile and Scrum (20m51s).

Adopting Scrum in organizations (21m1s)

• Agile methodologies are often associated with Scrum, but other methodologies like Kanban and XP exist and do not have product owners, instead considering product managers as part of the team (21m13s).
• Scrum is just one piece of building great products, and companies should not adopt it as a radical transformation, but rather as a tool to help with product development (21m46s).
• Founders and smaller companies may not need Scrum or other frameworks, as they can build products with just developers and product managers, but this approach is rare and often does not lead to amazing results (22m7s).
• Large companies that traditionally did not build software may turn to Scrum or other frameworks to implement rigor at scale (22m39s).
• Startups can use Scrum effectively if they understand it as a way to get things out the door every two weeks to test with customers, but some teams may not need the rigor and can thrive without it (22m50s).
• The key to success with Scrum or any framework is to have conversations about the work, break it down, and understand it, so the team can hit the road running and ask important questions (23m29s).
• If a team already has a way of working that gets things out to customers, they may not need a framework like Scrum, and can thrive without it (23m50s).
• There is baggage in the industry around Scrum and other frameworks, and product managers and developers can get frustrated when it is done by the book, rather than being adapted to the team's needs (24m9s).
• Many developers and product managers complain that Scrum has too many meetings, which can hinder productivity and prevent them from doing actual work (24m16s).
• The inspect and adapt part of Scrum is often overlooked, and people should regularly evaluate whether certain practices are serving them and eliminate those that are not (24m33s).
• Scrum is often more suitable for larger-scale companies, and its adoption is common in industries such as banking and telecommunications, where companies are not necessarily product-first or software-first (25m0s).
• Some companies that are not product-first or software-first still use Scrum, but they tend to be less dogmatic about it and use it to provide context for their teams to work together at scale (25m21s).
• There are also companies that do not prescribe a specific methodology for their teams but instead focus on breaking down roadmaps, setting themes, and letting teams run, which can be an effective approach (25m41s).
• The adoption of Scrum or other structured processes can be overkill for startups with experienced teams, and it ultimately depends on how they implement it (26m5s).
• The term "Scrum" can refer to both the general idea of Scrum and more structured, rigid processes that include specific roles like product owners (26m16s).

The origins and implementation of SAFe (26m21s)

• The Scaled Agile Framework (SAFe) originated from the desire to scale Scrum and other processes to organizations at scale, and it came out of a more structured approach to Agile called Rational Unified Processing (26m36s).
• SAFe was not the first scaling framework, as there were others like LeSS, and Jeff Sutherland's Scrum at Scale, but it was the one that was marketed the best (27m5s).
• The idea behind SAFe was to tie multiple teams together at scale in an organization and bring some rigor and process to that, which appealed to executives at large enterprises (27m28s).
• SAFe prescribes an operating model for development, but it also gets built as a whole model for software development, which can be seen as a big map that describes different things (27m48s).
• The SAFe image has gotten bigger over time, and it is currently in version six (28m11s).
• The first experience with SAFe was when working with a bank in 2015, where product owners were spending most of their time writing user stories for developers, rather than talking to customers or working on new initiatives (28m20s).
• In this experience, product owners were reorganized into teams and had a product manager who would talk to customers and then tell the product owner what to build, which was seen as a limitation of the SAFe approach (29m15s).
• This experience was not an isolated incident, as similar patterns were observed in other companies that implemented SAFe (29m34s).
• In the past, product owners were mainly responsible for maintaining backlogs for developers and worked on a narrow level, often resulting in teams being too large and having a huge scope, with some tasks not being prioritized correctly (29m42s).
• The introduction of SAFe (Scaled Agile Framework) brought a split between the product manager and product owner roles, with the product owner being part of the agile team and the product manager working with the system architect and release train engineer (30m18s).
• In SAFe, multiple agile teams are grouped into a release train, which helps ensure a smooth process for shipping products or features, and teams join the release train when they are ready (30m40s).
• SAFe prescribes how to manage release trains, bring teams together, and conduct Big Room planning, where all teams in the release train meet to break down what they will work on for the quarter (31m3s).
• However, teams often struggle with Big Room planning due to a lack of good discovery practices, resulting in a scramble to figure out what needs to be done and a reliance on backlogs (31m17s).
• Product owners often find it challenging to conduct discovery due to a lack of time, as they are expected to keep developers busy with tasks and do not have the time to talk to customers, which is seen as the product manager's job (31m58s).
• This approach can lead to inefficiencies, as developers become reliant on product owners or managers to provide them with tasks, rather than being able to work independently (32m47s).
• In organizations using SAFe, product owners often struggle to prioritize tasks, leading to developers not knowing what to work on, despite having a clear vision and understanding of what needs to happen (32m51s).
• This issue can be resolved by having developers work on technical debt, which doesn't require extensive scoping, and allowing them to choose the most important tasks to tackle in collaboration with architects (33m5s).
• The pressure to deliver software in every sprint, as per the company's roadmap, can lead to a lack of time for other essential tasks, and organizations often fail to set up the right feedback mechanisms, user research, and data analysis to inform their decisions (33m28s).
• SAFe does not provide clear guidance on how to balance discovery and delivery work, leading to confusion in organizations, and the addition of frameworks like OKRs and roadmaps can further complicate the process (33m56s).
• In some organizations, product owners report to product managers, which can make them extremely tactical and limit their strategic thinking, making it challenging for them to be promoted to product managers (34m30s).
• This separation of roles can also limit product owners' exposure to strategic tasks, such as determining customer needs, market research, and evaluating the value of potential projects (35m1s).
• SAFe's framework can perpetuate this issue by defining the product manager's role as responsible for strategy, leaving product owners to focus on more tactical tasks (35m11s).

Why Melissa doesn’t recommend SAFe (35m20s)

• Many companies are adopting SAFe (Scaled Agile Framework) as a way to work, despite its complexity, in an attempt to build great software, with the incentive being a plug-in process that promises to help achieve this goal (35m20s).
• However, some companies that adopted SAFe have gotten rid of it, such as Capital One, which eliminated all their Agile and Scrum roles after being an early adopter of SAFe (36m0s).
• SAFe is still widely used, with many organizations adopting it, but it can vary from business line to business line, and some parts of a company may use SAFe while others do not (36m20s).
• Executives are drawn to SAFe because it provides a clear map and definitions, making it easy to understand and implement, but this can also be seen as overkill (36m40s).
• SAFe can take away the responsibility from leaders to figure things out themselves, and it does not provide guidance for leaders on how to do their job, leaving a gap in leadership roles such as directors, VPs, and heads of product (37m12s).
• The framework focuses on bringing teams together but does not provide a comprehensive solution for leaders, leaving them to figure out their roles and responsibilities on their own (37m50s).
• SAFe does not define roles for leaders above product owners and product managers, such as VPs and directors of product, leaving a gap in guidance for these positions (38m11s).
• As a result, many leaders in organizations that use SAFe are unclear about their roles and responsibilities, particularly when it comes to owning a product line or being the head of product (38m31s).
• The patterns in software development include platform strategy, APIs, and app strategy, which are not directly addressed by SAFe, but rather by product strategy and vision. (38m47s)
• SAFe focuses on ways of working, which is how organizations do their jobs in areas such as product development, but it does not provide a clear direction on product strategy and vision. (39m3s)
• Many organizations adopting SAFe do not realize the need for a product owner or product leadership to feed the vision down to teams and control the portfolio vision. (39m13s)
• Despite some criticism, SAFe adoption is not slowing down, and more organizations are adopting it, especially those outside of Silicon Valley that are just starting their digital transformation journey. (39m28s)
• Many Fortune 50 and Fortune 100 companies, such as pharmaceutical companies, banks, and insurance companies, are adopting SAFe as a guideline for their digital transformation, as they have not had to think about software development before. (40m0s)
• These companies often come from a waterfall development background and are looking for a framework to help them navigate their digital transformation, which is where SAFe comes in. (40m24s)

Advice for implementing a digital transformation (40m33s)

• Many organizations adopt SAFe (Scaled Agile Framework) as a solution to their problems without fully understanding its implications, and it often doesn't work out as expected (40m35s).
• To successfully undergo an agile or digital transformation, companies should develop an operating model that includes understanding product strategy, organizational design, product operations, and culture and incentives (41m34s).
• Developing a product operating model involves breaking down key components such as determining product strategy, organizational design, product operations, and ensuring skilled product managers are in place (41m51s).
• Companies should assess their product strategy to ensure it aligns with their business goals and is effective in driving growth (42m5s).
• Organizational design should be examined to ensure it supports product development, including having skilled product managers and adequate coverage of products (42m8s).
• Product operations should be evaluated to ensure the necessary infrastructure is in place to support teams, including access to data and customer feedback (42m19s).
• Leaders must understand the role of product managers and create an environment that allows them to be successful, including providing the necessary resources and support (42m51s).
• Companies should re-evaluate their culture and incentives to ensure they are rewarding value creation, not just shipping products (42m58s).
• Many large organizations lack a clear product strategy and struggle to tie their product development to business goals, leading to a lack of transparency and ineffective product development (43m19s).
• Implementing processes is not the enemy, but rather a necessary step for a transformation, as it provides transparency and efficiency in achieving business goals, and having enough process is crucial for an organization to be efficient in getting things out the door (43m59s).
• SAFe was trying to address this need for process, but it's not working because it's not solving the problems of product management and connecting the value back to the product teams (44m35s).
• The product owner role is often seen as babysitting developers or telling everyone what to do, rather than focusing on discovery and connecting the value back to the product teams (44m49s).
• Lean UX is not enough to solve the problem of how to do discovery and customer research on a cadence, and organizations need to think about how to enable product teams to talk to customers and do discovery (45m0s).
• Starting a transformation requires thinking about how to build the product, launch the product, and ensure it's the right product, which involves product strategy and career paths (45m16s).
• Agile transformations often create new roles like product owner, but many organizations don't have a career path for them, leaving product owners wondering what their next steps are (45m46s).
• The product owner role is not just a team role, but a business role that can lead to running multiple teams, an entire product line, and furthering the business (46m1s).
• Leadership and organizations need to pay attention to the fact that some traditional roles may not serve them in the new way of working, and be willing to create new career ladders and paths for product managers (46m28s).
• Organizations are often afraid to overhaul their traditional ways of working and create new career ladders, but this is necessary for successful transformation (46m56s).
• Transforming an organization requires a clear direction from the top, as middle managers may be hesitant to change due to job insecurity, and it's essential for the C-suite to understand that transformation is a new way of working, not just a project (47m16s).
• Some people push organizations to try harder and transform internally, often with the best of intentions, but the C-suite must rise to the occasion and lead the transformation (47m46s).
• Kota is a tool used to coordinate workflows, such as podcasting and newsletter management, and combines the best of documents, spreadsheets, and apps to help teams stay aligned and ship faster (48m6s).
• Kota's features include managing planning cycles, setting and measuring OKRs, mapping dependencies, creating progress visualizations, and identifying risk areas, with hundreds of pre-tested templates available (48m27s).
• Companies like DoorDash, Figma, and Qualtrics use Kota, and startups can take advantage of a limited-time offer to get six free months of the team plan by signing up at coda.io/Lenny (48m48s).

An example of SAFe adoption (49m12s)

• The recommendation is not to use SAFe, as it may not be a good approach, and people who found success with SAFe often ended up modifying it to fit their needs (49m15s).
• Those who found success with SAFe typically ripped it up and made it into something else, so it's not actually SAFe by the book (49m34s).
• It's essential to be open to understanding that SAFe may not be the way to do good product management, and there's not a lot in SAFe about doing good product management (49m56s).
• SAFe can help in certain areas, such as bringing rigor to things, but taking it too far can be destructive (50m7s).
• An example of a company that adopted SAFe is a water company in the Netherlands, which ended up going bankrupt due to the teams getting caught up in the process and taking too long to deploy their new invoicing system (50m21s).
• The company's focus on the SAFe process led to their inability to collect payments from customers, highlighting the importance of prioritizing what's really important, such as serving customers and winning in the market (50m49s).
• Rigid processes like SAFe can lead to a focus on the process itself rather than what's being achieved, which is not ideal (51m22s).
• Instead of talking about stand-ups, release planning, and sprints, the focus should be on what's really important, such as serving customers and achieving business goals (51m5s).

The value of experienced product leaders (51m27s)

• Implementing SAFe (Scaled Agile Framework) should not be seen as a replacement for skilled and talented people, but rather as a process that requires skilled individuals to run it effectively (51m28s).
• The people hired to run SAFe are key to its success, and it's essential to have experienced leaders who have run large-scale technology organizations before (51m55s).
• Many organizations adopting SAFe lack experience in running large-scale technology organizations, and they hope the framework will solve their problems (52m0s).
• It's essential to intersperse people who know what they're doing with those who are new to the roles, and to bring in experienced leaders to help run the transformation (52m31s).
• There are more leaders who have experience with SAFe and agile transformations, and it's crucial to bring them in to help run the process (52m42s).
• Examples of experienced product leaders who have successfully applied SAFe in their organizations include Shudi Patel, Chief Product Officer at US Bank, and Melissa Doris, CPO of Green Dot Bank (52m47s).
• The most successful transformations occur when there is a mix of experienced leaders and new talent, allowing for knowledge sharing and growth (53m33s).
• Bringing in experienced consultants and trainers can help, but it's also essential to have experienced leaders within the organization who can provide guidance and mentorship (53m44s).
• Organizations are starting to realize the importance of having experienced leaders and are actively seeking to bring them in to help with their transformations (54m20s).
• The key to success is recognizing the need for experienced leaders and providing opportunities for growth and development within the organization (54m35s).
• Powerful product management can be applied at all levels of an organization, from teams to director and business partner levels, by adopting a continuous learning mindset and recognizing skill gaps (54m47s).
• Some Chief Product Officers (CPOs) and Vice Presidents of Product in large organizations are new to this way of working but are committed to learning and figuring out how to do it best, often by seeking knowledge from other CPOs and experts (54m57s).
• Successful CPOs and VPs of Product often have great market and business knowledge, are fantastic at strategy, and hire people underneath them who are great at execution and getting software out the door (55m22s).
• Some organizations use SAFe or similar frameworks as a crutch due to a lack of knowledge, but those who adopt a continuous learning mindset and want to propel their organization forward will consider other options and think beyond just SAFe or Agile (55m43s).
• Product management is not just a role in Scrum, and product owners should fundamentally be product managers, as product management is still necessary even without Scrum (56m10s).
• Not all product owners need to go into management, and some companies have principal IC product managers who continue working on product management tasks without going into management (56m36s).
• There should be no difference between an IC product owner and an IC product manager, as they are essentially the same role (56m50s).

Career paths for product owners (56m53s)

• Product owners can become product managers by building the necessary skills and taking ownership of their role, rather than just working with developers, as their role is more than just that (56m56s).
• Leaders may argue that product owners are necessary for scalability, but this is a weak argument, and companies can distribute work evenly and provide strategic guidance to product owners or product managers (57m14s).
• If a product owner feels they don't have the opportunity to talk to customers or be more strategic, they should try to take ownership and push back on the things being given to them (57m50s).
• Product owners should ask leaders about their career path and what's next for them after their current role, as this can prompt leaders to think about creating a career path (58m44s).
• Product owners can ask product managers if they can participate in customer research to gain more experience and skills (59m1s).
• Instead of focusing on quantitative metrics, product owners should think about the value they're delivering with their team and whether they're working on the right things (59m14s).
• When presenting their case to leaders, product owners should focus on the goals and outcomes of their work, asking questions like "what do we hope will happen when we release this?" and "what metrics are we going to change?" (59m27s).
• Asking these questions can help get alignment on outcomes and ensure that the company is focused on delivering value (59m49s).
• Many organizations are starting to realize the importance of the product owner role and are working to codify it, creating roles and responsibilities within their companies, as seen in a Fortune 10 company that recently made this change due to high churn in the role and the need for clear career paths (1h0m25s).
• This change is often driven by leaders who are looking around at other companies and hearing from their teams, particularly product managers, about the need for better support and career development opportunities (1h1m7s).
• Product owners and managers can bring about change by speaking up and advocating for their needs, and leaders are more likely to listen and make changes to avoid losing good people (1h1m18s).
• If an organization is not supportive of product management, it may be necessary to look for a new job or consider moving to a different team or division within a large corporation (1h1m35s).
• Many top tech companies, such as Google, Amazon, and Netflix, do not have product owners, but instead have product managers, highlighting the difference between these roles in different types of companies (1h2m43s).
• The lack of product owners in some companies does not necessarily hinder their ability to scale, as seen in the success of companies like Google and Amazon (1h2m15s).
• Product managers and owners should seek out leaders who know what they're doing and work for them, as this can be a key factor in success and career development (1h2m7s).
• When applying for a job at a tech firm, such as Google, it is essential to describe the product owner role from a value perspective on the resume, focusing on the value brought to users and the metrics that were moved, rather than agile cadences or Scrum processes (1h2m59s).
• A product owner's resume should highlight their ability to push the strategy and build better products for customers, rather than just implementing processes (1h3m45s).
• When hiring, the focus is on finding individuals who can understand the customer's needs and translate that into great products and desired outcomes (1h4m5s).
• In an interview, a product owner should be prepared to discuss their approach to understanding the customer and building better products, but the initial focus on the resume should be on the value they can bring (1h4m2s).
• Chief Product Officers should also be evaluated based on their ability to push the strategy and build better products, rather than just implementing processes (1h3m44s).

Transitioning from product owner to product manager (1h4m14s)

• The key difference between a product owner and a product manager lies in their approach, with product owners often focusing on process-oriented tasks, whereas product managers are valued for their ability to lead and drive business results (1h4m15s).
• When transitioning from a product owner to a product manager, it's essential to shift the focus from process-oriented tasks to highlighting leadership skills and business outcomes in resumes and job descriptions (1h4m32s).
• Instead of listing tasks such as prioritizing the backlog, working with developers, and writing user stories, product managers should emphasize their ability to lead work, solve problems, and drive business results (1h4m56s).
• A product manager's resume should tell a story, highlighting their achievements, such as leading a project, solving a specific problem, and achieving measurable business results (1h5m3s).
• When working on customer-facing projects, product managers should emphasize their ability to understand and interact with customers, and how this led to solving specific problems and achieving business results (1h5m45s).
• To demonstrate product management skills, resumes should include details such as running a function, launching a feature, iterating on it, and making it successful, rather than just listing tasks (1h6m3s).
• Even with a product owner title, it's possible to demonstrate product management skills by highlighting leadership and business outcomes in resumes and job descriptions (1h6m12s).
• Adding "product manager" to a resume, even with a product owner title, can help to overcome any negative connotations associated with the agile methodology (1h6m29s).

Be careful relying on certifications (1h6m41s)

• The Certified Scrum Product Owner (CSPO) certification is a common credential in the Agile industry, often displayed on LinkedIn profiles, but having this certification does not necessarily mean someone can do the job of a product owner or product manager (1h6m57s).
• The Agile industry, including organizations like Scrum.org and Scrum Inc, makes money by offering consulting services and training people to get certified in Agile processes, such as the CSPO (1h7m20s).
• These organizations sell the idea that certifying employees will improve a company's Agile adoption, but this approach may not be in the best interest of the company, as it oversimplifies the complexities of Agile implementation (1h8m1s).
• Having a CSPO certification may help someone get hired at a large enterprise adopting Scrum and SAFe, but it may not be valued by tech companies that prioritize experience and skills over certifications (1h8m25s).
• Some companies require certifications for promotions, but having a certification alone is not enough, and individuals need to demonstrate their skills and experience to transition into new roles (1h8m47s).
• Building a strong resume and explaining one's experience and skills is crucial when transitioning into a new role, especially if someone has a certification that may be perceived as limited (1h8m58s).
• Some Agile agencies offer more comprehensive training programs with different levels of certification, which involve coaching and demonstrating one's ability to do the work over time (1h9m37s).
• These programs are similar to the Project Management Professional (PMP) certification, which requires demonstrating one's skills and experience to achieve certification (1h9m55s).
• The Certified Scrum Product Owner (CSPO) certification is typically a two-day workshop that provides a different type of skill and certification compared to actually doing the job of a product owner (1h10m1s).
• Large tech organizations do not look for certifications in product management or product ownership when hiring people, but instead, look for experience (1h10m21s).
• Some organizations that may not know what they're doing may look for CSPO certifications, and having one might be required by the organization (1h10m32s).
• Having a CSPO certification can help get a foot in the door, but it may not be worth the money if it's not going to help with career advancement (1h11m0s).
• There is no quick or easy solution to becoming a great product manager, and one should be skeptical of plug-in solutions or taking a class as a quick fix (1h11m26s).
• Experience and hard work are necessary to become a great product manager, and there is no way to skip over the hard things (1h11m33s).

Evaluating existing product owners (1h11m43s)

• When entering an organization with existing product owners, it's recommended to eliminate the product owner title and role, and instead, have all product managers on a team, either as individual contributors or in a more senior role. (1h11m45s)
• Product managers can be categorized into three levels: associate product manager, product manager, and senior product manager, with each level requiring specific skills and experience. (1h11m56s)
• Associate product managers are those who lack discovery experience or don't know how to talk to customers, digest their feedback, and turn it into a feature direction and backlog. (1h12m3s)
• Product managers should have the skills to measure things, work with customers, and create a backlog, while senior product managers can work on a scrum team or development team. (1h12m28s)
• Having multiple titles for product managers, such as product owner, can be confusing, and it's recommended to simplify the titles to product manager, associate product manager, and senior product manager. (1h12m35s)
• When transitioning product owners to product managers, it's essential to assess their skill set and provide training to ensure they meet the requirements of a product manager. (1h13m46s)
• In some cases, product owners may already possess the necessary skills to be a product manager, despite their title, and should not be judged solely on their title. (1h13m33s)
• When working with companies on transformations, it's common to provide training for product teams and then assess who has the skills to be a great product manager and who may not be a good fit. (1h13m58s)
• Some individuals may opt out of the product manager role after learning more about the job requirements and responsibilities. (1h14m17s)
• Providing training and opportunities for practice can help individuals develop the necessary skills to become a successful product manager. (1h14m32s)
• In large organizations, some individuals may initially express interest in the product owner role but later realize it's not what they wanted to do, often due to the high level of influence and responsibility required, and may opt for other roles such as operations, data analysis, or user research (1h14m43s).
• This realization can happen after individuals are given the experience and shown what the role entails, allowing them to practice and then decide if it's a good fit for them (1h15m31s).
• After some individuals opt out, it's essential to reassess the team and determine who's doing well, who needs improvement, and which teams require more experienced people to learn from (1h15m40s).
• To address these needs, organizations may hire individual contributors (ICs) or directors of product management to train and help product owners grow in their roles (1h15m54s).
• With the right training and exposure to good product management practices, it's possible to take people and turn them into amazing product managers within a year or two (1h16m23s).
• Leaders should ensure that their organization has people with the necessary skills interspersed throughout, allowing everyone to learn and grow (1h16m45s).
• If an organization lacks visible examples of good product management practices, it's a red flag that leaders need to address by bringing in people with the right skills to train and mentor others (1h16m37s).

Final thoughts on Agile and product management (1h16m55s)

• Agile methodologies, including SAFe, aim to enable companies to move quickly and deliver great value to customers, but it's essential to remember the underlying principles rather than just following a defined process (1h17m25s).
• Embracing agile principles can lead to success, but simply following a rigid process without understanding the 'why' behind it can be counterproductive (1h17m40s).
• There are great agile coaches who take a first-principles approach to product work and development, focusing on making teams better and helping companies produce better products (1h17m54s).
• Some individuals and organizations, such as McKinsey, may prioritize certifying people and consulting on processes over the actual goals of agile, which can lead to skepticism (1h18m27s).
• McKinsey and other large consulting organizations have built businesses around agile transformations, but their approaches may not always be effective (1h18m43s).
• It's essential to be cautious of who is selling agile solutions and to prioritize the company's best interests, culture, and customer value (1h19m35s).
• Companies should regularly inspect and adapt their processes to ensure they are working effectively and make changes as needed, following the agile principle of inspect and adapt (1h20m4s).
• By focusing on the underlying principles of agile and being open to change, companies can successfully implement agile methodologies and deliver value to their customers (1h20m15s).
• Large companies can reorganize the way they build products to deliver high-grade products consistently, and it's possible to learn from companies that have been producing software at scale for many years, even if their approach may need to be adapted to fit the organization's specific needs (1h20m20s).
• Companies should not compare themselves to Google or other successful software companies, as their approach may not work for a 100-year-old insurance company, but they can still learn from their principles and apply them to their organization (1h20m39s).
• Software strategies and digital strategies are becoming increasingly intertwined with company strategies, and it's essential to consider them at the executive level to drive innovation (1h21m20s).
• Companies often struggle with this integration, and pushing software strategy down to the IT department can lead to missed innovation opportunities (1h21m45s).
• The product owner role is crucial in driving innovation, and companies need Chief Product Officers who can think about how software can enable the company to be 10 times better and crush the competition (1h21m55s).
• Companies should consider how software can put them ahead of the competition and the market when thinking about their long-term strategy, and not having these conversations can put them behind (1h22m17s).
• Big companies have the resources to adapt, but they often lack the urgency to change, which can make it difficult for them to keep up with smaller, high-growth startups (1h22m31s).
• Melissa Perri can be found on LinkedIn, and her school, Product Institute, offers product management training and help with related topics (1h23m1s).
• Melissa Perri also runs a podcast called the Product Thinking podcast, which answers questions on topics like SAFe, agile, and product management (1h23m19s).
• The conversation has concluded, with the guest expressing appreciation for the opportunity to share their knowledge and the host thanking the guest for their time (1h23m33s).
• The host notes that many listeners have gained a better understanding of terms related to SAFe and the product owner role, which they had previously only heard occasionally (1h23m36s).
• The host invites listeners to subscribe to the show on various platforms, including Apple Podcasts, Spotify, or their favorite podcast app (1h23m56s).
• Listeners are also encouraged to leave a rating or review, as this helps other listeners discover the podcast (1h24m1s).
• Additional information about the show, including past episodes, can be found at Lenny podcast.com (1h24m7s).