产品负责人陷阱：SAFe 如何把人变成接单员，大公司怎样真正做产品管理

Melissa Perri opens by saying she does not recommend SAFe, the Scaled Agile Framework, and that every person she has met who found success with it eventually ripped it up and made it into something else. She argues that the product owner role did not emerge from product management as it is known today; it was a way to help developers prioritize what to work on. That distinction frames the entire conversation about why the role is growing and why it often disappoints.

Lenny explains why he wanted to cover this topic: in a deep dive on the tech job market, he saw that the product owner role was the third-fastest growing role in tech in the US data he examined. He was surprised because he had never worked with a product owner, did not hear people in his circles talking about product owners, and had never wanted to hire one. The role seemed to belong to a different part of the tech ecosystem, and it was clearly growing.

Melissa describes starting in tech as a product manager who had never heard of the product owner role, then using Scrum flexibly with a startup team in 2011. As she worked at other companies and attended agile conferences, she encountered more dogmatic Scrum practices and learned that Scrum included a product owner role. When she began training large banks around 2014 and 2015, she found people had been made product owners overnight from backgrounds such as development, business analysis, project management, and banking.

Melissa contrasts Silicon Valley product managers, who were born from a business role and do market research, customer conversations, development work, and iteration end to end, with large companies that first met product management through Scrum. The Agile Manifesto was written in 2001 in Park City by software developers, including people working on Scrum, Kanban, XP, and other approaches. No product manager signed the Agile Manifesto; Jeff Patton was close to the group but did not sign it. Ken Schwaber and Jeff Sutherland independently developed Scrum and later codified it in the Scrum Guide.

The Scrum Guide defines developers, a product owner, and a Scrum master. The product owner is responsible for defining what goes into the backlog, writing user stories, and prioritizing work, while the development team discusses, commits, and builds toward a potentially shippable increment each sprint. The Scrum master coaches the team on doing Scrum better and hosts retrospectives. The first Scrum Guide said the product owner maximizes the value of the team's work and noted that, for commercial development, the product owner may be the product manager, but the 2013 version that most transformations used dropped that connection.

Scrum does not describe how to get the right things into the backlog, and early versions did not start with vision or discovery. Product owner training was typically a two-day class on breaking down a backlog, running stand-ups, prioritizing work, managing the backlog for developers, and working with retrospectives. It did not teach experimentation, market research, data, or the other skills needed for product management. Agile transformations adopted Scrum to build software faster, converted people into product owners, sent them through that class, and told them to go.

Large companies turn to Scrum because they did not grow up building software and want rigor at scale. Melissa says startups can use Scrum lightly or skip daily stand-ups when people already talk every day; her team at OpenSky moved from two-week sprints to shipping every week and stopped doing stand-ups. Frameworks help when teams are not having the right conversations about the work, but rigid Scrum can create too many meetings and prevent actual work. The inspect-and-adapt principle should lead teams to remove practices that no longer serve them.

SAFe emerged from the desire to scale Scrum and other processes across large organizations, and it drew from more structured approaches such as the Rational Unified Process. Other scaling frameworks existed, including LeSS and Scrum@Scale, but SAFe was marketed best. Dean Leffingwell created SAFe to show how multiple teams could be tied together with rigor, and executives at enterprises with tens of thousands of people liked that it prescribed an operating model. The SAFe map grew larger over time and described release trains, roles, and planning rituals.

Melissa's first SAFe encounter was at a bank in 2015, where a product owner told her she had no time to talk to customers because she spent her days writing user stories for the login API. The product manager talked to customers and told the product owner what to build, and the product owner translated that into backlog items for developers. SAFe pulled agile teams into release trains and used big-room planning to commit a quarter's work, but teams often had not done discovery before planning. They then sprinted back-to-back to keep developers fully allocated.

In these organizations, teams often do not check whether roadmap items actually move metrics, and they lack the feedback mechanisms, user research, and data to know what is working. SAFe lists OKRs and roadmaps on its map, but it does not explain how discovery and delivery should feed each other. Product owners become extremely tactical order-takers while product managers own strategy, and the two roles can sit on separate career paths, leaving product owners without exposure to market research, customer value, or strategic decisions.

Melissa knows many companies that adopted SAFe about eight years ago and later got rid of it, including Capital One, which publicly dropped its agile and Scrum roles after being an early SAFe adopter. Yet SAFe is still widespread, and she gets questions about it every day. Executives buy it because it is the only framework that draws a map, defines terms, and says plug and play; that makes it understandable and sellable. The cost is that it takes responsibility away from leaders to figure out their own operating model.

SAFe does not explain what a director of product, a VP of product, or a head of product for a credit card should do. Leaders in those roles are supposed to do strategy, talk to customers, think about platform and app strategy, and feed a vision down through teams. SAFe focuses on ways of working and team coordination, but it leaves out how people do their jobs above the team level. Organizations still need a head of product to own the portfolio vision and connect it to the teams.

SAFe is not slowing down in Melissa's experience; more large organizations are adopting it, especially pharmaceutical companies, banks, and insurers that are starting digital transformation late. Many are Fortune 50 or Fortune 100 companies that previously outsourced development or treated IT as a back-office function. Some banks realized early that software mattered, but others are still moving from waterfall development and reach for SAFe as a guideline.

Melissa advises companies to build a development operating model, but to understand that agile frameworks are only that: a development operating model, not the whole product operating model. A fuller model starts with product strategy, then organizational design, including whether the company is organized around products and has skilled product managers up and down the organization. It also needs product operations: data, customer access, and infrastructure that let teams make decisions and stay close to customers. Culture and incentives must reward value rather than shipping as many things as possible.

Many large organizations lack a product strategy that ties the portfolio to company goals such as geographic expansion. They also lack transparency across thousands of teams, which is why Melissa does not treat process as the enemy: a roadmapping tool or planning system can be necessary just to see what is happening. The problem is when process becomes an end in itself and does not connect the work back to customer and business value. SAFe tries to bring efficiency, but it does not solve product management or connect value to teams.

Career paths are central. Melissa argues that product owner is not just a team role; it is a business role that should be able to grow into running multiple teams or an entire product line. Many organizations created product owners during agile transformations but never built a ladder for them, so people ask what comes next. The C-suite has to decide which old roles still serve the new model, because middle managers whose jobs are threatened will not lead the transformation. If the C-suite does not own the change, the organization will struggle.

Melissa does not recommend SAFe, though she acknowledges that some people find success with it. In every such case she has seen, they ended up ripping it up and making it into something else, removing what did not work. SAFe contains little about good product management, so adopting it by the book can destroy the parts of product work that matter. She cites a Netherlands water company that adopted SAFe in its IT teams and went bankrupt after its new invoicing and payment-collection system was delayed by process; teams were learning SAFe while the company could not collect payments.

The people who buy SAFe often have not run large-scale technology organizations before, or they are new to the way of working and hope the map will work. Transformations also pull people into product roles for the first time, and Melissa says it is noble to train people, but organizations must intersperse experienced practitioners. She points to Shruti Patel at US Bank, who worked at Shopify, and Melissa Douros at Green Dot Bank, who led transformation work at Discover, as examples of experienced product leaders who can bring proven patterns into a bank. The most successful transformations mix internal people with experienced hires so people can learn from someone who has done the work.

Some CPOs and VPs of product in large organizations are new to product but committed to learning, and they hire for their gaps rather than pretending to know everything. SAFe can become a crutch for people who do not know what they are doing. Melissa emphasizes that product management still exists without Scrum, while product owner does not exist without Scrum; all product owners should fundamentally be product managers.

Melissa tells product owners that their role should be more than working with developers, and they should push back on the work they are given. She recalls a product owner at a Mind the Product workshop who believed her SAFe team was working on the wrong things but feared getting fired if she said so; she presented the case to leadership and was promoted. Leaders sometimes argue that product owners are necessary at scale, but Melissa calls that a weak argument, and Lenny adds that no top tech company in his data has a product owner, though those companies are software-first businesses.

If there is no career path, product owners should ask leaders what it is, because the question forces the organization to think about it. They should ask to join product managers on customer research, stop treating user stories as a quantitative metric that must always increase, and ask what the team hopes will happen when a feature is released. That question about expected outcomes and metrics creates alignment and opens a conversation about whether the work actually changed anything. Melissa has seen a groundswell of product owners and product managers asking what is next, and one Fortune 10 company began codifying the product manager role after noticing churn; if an organization cannot support good product management, she advises looking for another team or company.

Product owner resumes usually list process work: prioritizing the backlog, breaking down work with developers, checking acceptance criteria, and writing user stories. Melissa wants resumes to describe value instead, such as leading work on a login API to improve security and meet regulatory requirements, interviewing users, working with legal and compliance, and launching without disrupting four million customers while saving millions. Even with a product owner title, candidates should use product owner/product manager and show customer understanding, outcomes, and metrics.

CSPO stands for certified Scrum product owner, and Melissa warns that the agile industrial complex makes money by consulting and certifying people in processes. A two-day class can produce a certificate without proving someone can do product management. A CSPO may help someone get hired at a large enterprise adopting Scrum or SAFe, but software-native tech companies may see it as a negative signal; if an organization requires it, people may have to do it, but they should explain the real work behind the certificate. Melissa will not certify product managers from a short class because she does not believe a brief course can prove job readiness; stronger programs require practice and coaching over time.

Melissa advises replacing the product owner versus product manager split with one product management hierarchy: associate product manager, product manager, and senior product manager. She does not apply this as a hard rule, because some people with product owner titles already do product management well and were only given that title by their company. The usual approach is to baseline and train everyone, then assess actual skills and experience. At Athenahealth, 365 people with varied product titles were trained and given opportunities to practice; many then opted out into operations, data, or user research because they realized they did not want the influence work and accountability of product management, while others left.

In closing, Melissa says agile with a lowercase a means moving quickly and delivering great value to customers; when it becomes a rigid process followed step by step, it stops serving the company. She is skeptical of by-the-book SAFe and Scrum and of consultants such as McKinsey that sell transformations without staying in the organization long enough to see them through. Large non-software companies cannot copy Google or Amazon exactly, but they can learn from software-native companies and adapt the principles to their own context. Software and digital strategy are now intertwined with company strategy, so the C-suite must own that conversation and consider whether it needs a chief product officer to push software-driven innovation.