产品管理剧场，以及怎么走出来：Marty Cagan 谈新书 TRANSFORMED

Cagan says he has deliberately turned up his rhetoric because many forces are hitting product teams simultaneously. Companies overhired during the pandemic and often lowered the bar, while the cost of capital rose. The biggest unknown, he says, is the predicted effect of generative AI, which he is convinced is real even though he has a long history of expecting change sooner than it arrives.

He adds that team size has gotten out of hand, especially outside Silicon Valley, where he sees agile coaches, product owners, product ops, business analysts and assistant product managers piling up. He notes that smaller teams often get better results, and he says remote work has taken a real toll on velocity and innovation at the large companies he works with.

Many big companies also lean on heavy processes such as SAFe, he argues, and have little in the way of outcomes to show for the cost. In his view the surprise is how long it took them to react. His advice is that process- and role-heavy companies should study how the best companies do far more with proportionally less, which is what transformation means.

When Lenny notes that many people dislike PMs, Cagan says the examples he hears almost always involve feature teams. In those, he says, the PM role is really project management, which others can already cover, and engineers and designers often prefer to do the work themselves than deal with someone acting as the boss. He bluntly calls these PMs dramatically overpaid for what they contribute.

He describes the difference concretely. A feature team receives a roadmap of output, often from an executive or a large customer, with dates attached. An empowered product team receives a problem, customer or business, usually one or two per quarter, and is judged on whether it solves it. Strong product companies get points for delivering value, not for shipping.

Cagan tells CEOs and CFOs that it is about time to money more than time to market. He says that only when a team signs up for an outcome does it need a product manager, because the solution must be valuable and viable as well as usable and feasible. A PM doing that job has no time to be wireframing for designers or irritating developers.

Cagan says the biggest sign of theater is people who carry the product manager title because it is cool but do none of the work and lack the skills. He stresses it is not hard to develop the skills if they are motivated, and that it benefits both their careers and their companies. He rejects the idea that a PM's job is to say why, since the why comes from product strategy.

A PM is responsible for value and viability, just as engineers are for feasibility. He lists the skills: becoming an expert on users and customers, and he recalls being required to visit 30 customers in person before taking the role. The PM also knows the data on usage and purchasing, represents compliance, sales, marketing, finance, monetization and legal constraints, and understands the market deeply.

Without that knowledge on the team, he argues, empowered teams revert to meetings with twenty stakeholders and design by committee. He contrasts this with the product owner, whose training teaches backlog management in Jira, which he compares to learning Google Docs. A product owner is one extreme, an empowered PM the other, and the feature team PM sits between and does much project management, which is important but not product management.

Lenny reads a line from Cagan's writing warning that delivery team product owners and feature team PMs face a reckoning that generative AI will compound. Cagan says he may be overreacting, but he doubts it. Still, he does not think the answer is retraining for another career, and he urges people to raise their skills.

He tells PMs who feel trapped that individuals can do a lot: do a self-assessment and move from product owner or feature team PM to real PM. At a minimum their company will appreciate it and likely promote them, and it might even lead to trying a few teams the new way. Most product leaders, he adds, have far more agency and are not using it.

The frustrating part, he says, is that most places people turn to learn spread the feature team model, from certification bodies to books, conference talks and online communities. He recalls an article from a major certification institution that described a PM's job in a way he considered 100 percent project manager. Well-meaning community members answer questions with what they learned at their own weak companies, so the problem self-propagates.

His advice is to think critically and take ownership of your career. When interviewing, research your prospective manager's background, because the person who will coach you matters more than the company. He singles out Teresa Torres's *Continuous Discovery Habits* as a good exception.

Lenny says that at Airbnb he doubted the feature-roadmap world Cagan wrote about, and Cagan says he lived in the same bubble. A visit to Walmart's headquarters showed him that most companies work very differently, which inspired Silicon Valley Product Group. He recalls that Shreyas Doshi once voiced the same disbelief, though he no longer doubts it.

Asked whether a feature factory is fine for a B2B sales-driven company, Cagan answers that it is no accident most B2B software is so poor. He asks whether you want to be Oracle or SAP, and notes that he rarely meets anyone who likes those products. He adds that the new book includes a sales-driven financial services company that moved to the product model and improved life for its sales organization.

These companies usually stay as they are, he says, because the CEO is not a product person, until a good product company takes their customers. He adds that an empowered team can do everything a feature team can and more, and asks why anyone in the business would not care what customers think.

Lenny relays that Meta's CTO described the company as top-down, with leaders setting strategy and big bets. Cagan says that matches what he sees in good product companies but that he does not call it top-down. Handing a team a feature roadmap is top-down; product leaders setting strategy and focus bets, then giving the teams latitude, is leaders and teams each doing their jobs.

He says a common misunderstanding is that empowerment means teams decide what to work on, which would be anarchy, with fifty teams doing fifty things. Instead, leaders choose the bets and the teams work out the best way to solve them. He credits Facebook at the time with strong cross-functional teams that could tackle hard problems.

On a claim that PMs have shifted from growth to building after the zero-interest-rate era, Cagan says yes and no. Many weak teams do only low-risk optimization behind A/B tests, such as changing a call to action, and call it product. That is optimization and not discovery, and he thinks the shift reflects teams learning to move from feature team to product team, tied more to leadership quality than to interest rates.

Cagan says the principles behind the empowered PM role are stable but the techniques are changing radically with generative AI, and that he does not have it figured out. He recently reversed his advice: he used to say to start with ChatGPT, but people took the output too literally and optimized in the wrong direction. Now he tells them to think through the answer and write it down first, then use ChatGPT to improve, challenge and tighten it.

Asked which PM skills will be disrupted, he says change is already happening more on the engineering and design side but will reach PMs, though he cannot say when. A backlog administrator or feature team PM doing mostly administrative work is not a good job prospect. He would not feel confident doing it for years.

For empowered PMs, he says, the hard parts that remain are viability questions, and more of the burden may land on them. He mentions discussions of probabilistic versus deterministic software, where lawyers weigh in on legal and ethical issues and teams must decide if a probabilistic answer is acceptable for something mission critical. He defines value as being for the customer and viability as working for your business: you can sell, market, service and legally offer it, as Airbnb's hard problem was making listings legal in San Francisco.

Cagan explains that *INSPIRED* covers product discovery for teams and PMs, and *EMPOWERED* covers product leadership. The most common reaction to the first edition of INSPIRED, he says, was that readers loved it but their company was nothing like that. His partners spend their time helping companies transform, but there are only five of them, so the new book shares how to actually change, including techniques like pilot teams.

He and his coauthors set a rule that every case study come from outside Silicon Valley, from companies, mostly pre-internet, that had to change dramatically. He cites Trainline in the UK and Almosafer, a Saudi travel agency that he says holds a large majority of its market, and notes the dozen examples span healthcare, car sales and fitness. He says some of the resulting innovation is as impressive as anything Amazon has done.

The goals were to explain what the way of working really means, to convince readers that transformation is possible and to excite them about what comes after. Unlike his earlier books, it is also written for non-product people such as CEOs, CFOs and heads of sales. Cagan suggests frustrated PMs give the book to their CEO and read it themselves, since they can do a lot individually to push their company along.

Cagan says he avoided naming the way the best companies work for twenty years, simply saying work like the best or like the rest. For the book they chose product operating model, or product model, because terms like product-led or product-driven read to the rest of the company as a power grab. It is a conceptual model, not a process, and boils down to a set of 20 principles.

At a high level, he says, it covers how you decide what to work on, which is product strategy, how you solve problems through discovery, and how you build, test and deploy reliably with provable outcomes. The principles include embracing experimentation, instrumenting everything, valuing innovation over predictability and learning over failure, and small frequent uncoupled releases. Most good teams release on the order of twenty times a day, he says, and batching marketing announcements is fine as long as the product is already live.

The four competencies most companies lack in practice are a real product manager, a real product designer, a real tech lead and a real product leader who coaches and sets strategy. Cagan says the leader is a key addition to the classic triad. On product ops, he says it is not the same as the product operating model and is most useful as a small team combining user research and data analysis. He warns against product ops focused on process and governance, or hired to do the product leader's job or the PM's dirty work.

To founders who say they will never hire PMs, Cagan says he actually discourages hiring them too soon. If the PM is really a project manager, you are overpaying, and if they are a real PM responsible for value and viability, that is the founder's job early on and a premature hire creates too many cooks. Lenny suggests after product-market fit, and Cagan adds a rule of thumb that at around 20 to 25 engineers it is better if a co-founder is the product person.

In the lightning round he recommends Tony Fadell's *Build* and Tim Urban's *What's Our Problem?*, and says he starts interviews by asking candidates to define the job of a product manager. He names the Rivian as a favorite product, calling it the Airbnb of car companies because the founder is a designer, and mentions wireless airbag vests for motorcycle riding.

He shares a quote attributed to Leslie Lamport, that if you are thinking without writing you just think you are thinking. He says he has worked for 43 years and would have been happy staying in engineering or design, because he likes building things. The book was due out on March 12th, with his writing free at svpg.com.