产品的本质：功能工厂为什么赢不了被赋能的团队

Lenny opens by noting that Cagan has become more philosophical about product, citing a recent post called “The Nature of Product” and Cagan’s analogy that explaining a strong product culture to someone who has never seen it is like explaining the Grand Canyon with pictures. Cagan responds that his frustration comes from expecting, by 2022, that the gap between how the best companies work and how everyone else works would have narrowed. He points to the profit motive as an obvious incentive for more companies to copy the best.

Cagan finds it telling that friends at weak companies often do not believe his descriptions of strong product companies, while friends at strong companies cannot imagine why anyone would work the other way. He says the obsolete model is deeply ingrained: product managers write requirements, PRDs, or user stories; designers make things pretty or produce wireframes; and the whole package is handed to engineers at sprint planning. Quarterly roadmaps reinforce the belief that the job is to crank out features, and many people have never seen anything else.

In real product teams, Cagan says, developers are not there merely to implement someone else’s dumb ideas and designers are not there merely to make things look good; they are peers helping to find a great solution. The product manager’s job is also different because the PM must bring skills and knowledge the design and engineering peers do not have. Cagan argues that feature teams and real product teams should not share the title “product manager,” because the jobs are radically different rather than superficially different.

Cagan says a feature team is easy to recognize because it is handed a prioritized roadmap of features and projects, usually assembled quarterly by stakeholders who believe they need those features to run the business. Those features are really possible solutions, so the team is asked to do a little design, a lot of coding, some QA, and deployment. The team’s broader purpose is to serve the business by delivering the requested output.

A real product team, by contrast, is given problems to solve—customer problems or company problems—and the skills to discover the best solution. Cagan invokes the Netflix principle of pushing decisions down to the people closest to the knowledge: engineers work with enabling technology every day, and product teams work with users and customers every week. Real product teams are measured on outcomes, not output, because shipping more releases means little if the problem remains unsolved. That is why good teams celebrate solving the problem rather than merely deploying another change.

Cagan says the designer and engineering roles do not change as dramatically as the product manager role when a company moves from feature teams to empowered product teams. In a feature team, the PM is mainly herding cats: gathering requirements, documenting them in Jira or another tool, and getting them into sprint planning. In an empowered product team, the PM must help discover a solution that is valuable, usable, feasible, and viable; engineers own feasibility, designers own usability, and the PM owns value and viability. Those are big shoes to fill, which is why Cagan says real product managers must do their homework.

Lenny asks whether the empowered model actually exists and which companies exemplify it. Cagan stresses that nothing in Inspired or Empowered was invented by Silicon Valley Product Group; the firm shares practices it sees used by several of the best teams. His heuristic is to recommend a practice only after multiple strong teams have used it, and to treat unproven processes or tools with suspicion.

Cagan says SVPG tries to untangle company culture from technique, because Amazon, Google, Netflix, and Stripe all have different cultures even though their best practices share common threads. Readers can find those threads in books such as Amazon’s Working Backwards, Netflix’s No Rules Rules, and Build on Apple. Cagan also names Stripe, Shopify, Slack, and Spotify as examples of companies that have competed effectively against larger rivals.

Lenny asks for a rough estimate of what fraction of companies work this way. Cagan says counting is difficult because many people write custom solutions rather than commercial products, and it is not clear how many companies build commercial products at all. His purely anecdotal guess is that roughly 10% to 15% are good product companies, though he admits the number could be orders of magnitude off.

Lenny introduces The Lost Interview, the documentary interview with Steve Jobs after he was fired from Apple and before he returned. Cagan values it because Jobs rarely discussed the nature of building products, even though he loved talking about his products themselves. Cagan recommends watching the whole interview—at the time of the conversation it cost $4 to rent on Amazon Prime—rather than relying on summaries.

Cagan had a theory that companies fail to copy the best because their people have never worked at a company like that and therefore do not know what good looks like. In the interview, Jobs offers a better and more prescient theory from 1995: as companies get bigger, product becomes less important, and the people celebrated and promoted are marketing, sales, and finance people. Once those people become the leaders, good product people leave for companies that value product.

Cagan says Jobs was describing a disease that still spreads: companies with market share and growth stop needing to innovate, become afraid of breaking what works, and settle into low-risk optimization. After founders leave, product teams and executives may fear they cannot tell what is essential from what is incidental, so they run little A/B tests on existing flows instead of doing real discovery. Cagan sees that retreat from discovery as the beginning of the end.

Cagan highlights another Jobs disease: the disease of the stakeholders, where managers believe an idea is 90% of the work. Jobs understood that the idea is only the starting point and that the craftsmanship lies in moving from idea to product through constant iteration, trade-offs, and change. Cagan calls that craftsmanship product discovery.

Cagan notes that only about 20% of the features on a prioritized roadmap generate any positive return, which should be enough evidence that top-down feature lists are fatal. He attributes the persistence of the pattern partly to arrogance: every executive thinks their ideas are smarter than everyone else’s. Good product companies know an idea is just the sparkle in someone’s eye, and getting to a product is the work that matters.

Cagan distinguishes discovering the problem to solve from discovering the solution people will buy. When the founder and much of the company already know the problem, a product team can waste weeks or months validating what is already understood while the clock ticks. People do not buy the problem; they buy a solution, and many products solve the same problem, so the real question is whether the team can solve it better than everyone else. Cagan coaches teams to spend a little time on the problem if needed but to save as much time as possible for finding the winning solution.

Lenny raises Cagan’s view that product managers are wrongly taught to own the “what” and not the “how.” Cagan laughs that if finding the what were the whole job, he could phone it in for 15 minutes a week. He says the solution must be valuable, usable, feasible, and viable, and the PM is responsible for making sure it is valuable and viable. That responsibility is a central part of the how, not a trivial handoff.

Cagan is careful to say that PMs do not tell engineers how to code or designers how to design. But the how includes how the product works, how it monetizes, privacy and security issues, and how it goes to market—all product responsibilities. If any one of the four risks fails, the product fails, so value and viability are table stakes rather than optional extras.

On user research, Cagan agrees with the point Lenny raises from the Collison tweet that research should refine a mental model of the user rather than mechanically dictating what to build. He warns against teams that test prototypes only to hear users say they like them; the more useful evaluative research finds all the reasons users will not use the product. He quotes Elon Musk’s advice to focus on reasons for non-use and insists that PMs and designers attend the tests themselves, because reports are too often ignored.

For people stuck on feature teams, Cagan advises trying one bounded experiment before leaving the company. Ask your manager to let the team run like a real product team for a quarter or two, with the promise that if it fails, the team can return to the old way. Cagan says product-team-level experiments are much cheaper and less risky than transforming an entire business unit.

The first move is to turn a requested feature into a problem by reverse-engineering the stakeholder’s intent. If someone asks for buy-now-pay-later on an e-commerce site, the team can ask how success will be measured—usually conversion rate, average cart value, or another KPI—and confirm the belief behind the request. That conversation gives the team a problem to solve and a way to know whether the solution worked.

Cagan says the PM usually needs preparation in four areas before the team can operate this way. The PM must become one of the experts on users and customers; Cagan’s own coach required him to visit 30 customers, 15 in the US and 15 in Europe, before making decisions for the team. The PM must also know the product data, learn the different parts of the business—marketing, sales, monetization, compliance, regulatory, privacy, and security—and understand the competitive landscape, industry, and trends. If the PM is ill-equipped or incompetent, empowered teams fall down, because no one else on the team brings that knowledge.

The team also needs strategic context—product vision, product strategy, and how other teams’ work fits together—and the PM may have to go learn it if leaders do not provide it. Finally, the team needs discovery skills and techniques, which Cagan calls the fun part and the reason he wrote Inspired. He recommends Teresa Torres’s Continuous Discovery Habits and Jake Knapp’s Sprint for hands-on guidance, and he emphasizes the value of a coach or manager who cares about developing people. Cagan says good managers mattered in his own path from engineer to tech lead and into product discovery.

Cagan says the product management role at good companies has not changed much in more than 20 years, even though discovery techniques have improved dramatically. Across the wider industry, he sees a mess of product-related titles, especially product owners taught by agile coaches who have never done product themselves. He compares that to teaching someone Scrum and expecting them to become an engineer, and he warns that the industry has never had such a high proportion of unqualified product people. Product ops can be useful, but some definitions create the same problems.

Cagan’s core prescription is that product managers need unencumbered access to three groups: users and customers, engineers, and stakeholders. Anyone who stands between the PM and customers—whether in customer success or sales—cuts off the PM’s lifeline, and anyone who mediates between the PM and engineers prevents the daily problem-solving that defines the job. Stakeholder access matters because good products solve what is newly possible in ways that work for the business. Product ops can help by absorbing runtime triage or building tools that make PMs more productive, but it is harmful when it filters customer data or becomes an intermediary to the PM’s three sacred relationships.

Cagan remains worried about the disease of process people, which Jobs also warned about. Scaling is hard, and companies can scale with process or with leaders; Cagan says only scaling with leaders reliably produces good outcomes. Process-heavy frameworks such as SAFe are attractive because they promise an answer to scaling, but Cagan calls SAFe repackaged waterfall and says it has nothing to do with agile. He warns that process people will destroy a company.

Cagan publishes SVPG’s material for free at svpg.com and siliconvalleyproductgroup.com, and he uses social media only reluctantly. At this point in his career he is having fun and is not looking for anything from listeners, but he loves hard questions because they inspire his writing. If someone has tried to answer a hard product question and cannot find a good answer, Cagan invites them to email him.