The nature of product | Marty Cagan, Silicon Valley Product Group

The episode opens with a clip from later in the conversation. Marty Cagan argues that a problem is only the entry ticket: customers do not pay for a problem, they pay for the solution, and many products already address problems they care about. The decisive question is whether a team solves it better than everyone else. He therefore tells teams to spend only a little time on the problem so that most of their time goes to finding the winning solution.

People don't buy the problem, they buy your solution.

Lenny introduces Cagan as the author of Empowered and Inspired and the founder of Silicon Valley Product Group, which the host says Cagan started more than 20 years ago. The host adds that Cagan was VP of Product at Netscape and, as the transcript says, a senior VP of eBay. These are the host's claims in the introduction and are not independently checked here.

Several segments are advertising. The host reads a sponsor message for Whimsical, a collaborative visual workspace tool, and then a sponsored exchange with Ashley, identified as head of marketing at Flatfile, about CSV import problems in B2B SaaS onboarding. In that exchange Ashley says at least 40% of B2B SaaS companies need to import customers' CSV files and that, based on Flatfile's own data, about a third of people will consider switching after one bad onboarding experience. The transcript also renders the product name as "Wallace data onboarding", which is evidently a recognition error for the sponsor's own product. These are vendor marketing claims with no supporting evidence offered, and they are unrelated to Cagan's argument.

After a brief greeting, Lenny frames the conversation around Cagan's recent writing on the nature of product. He says Cagan describes a core misconception: people who have not seen a strong product culture cannot grasp how different it is from a weaker one, much like trying to explain the Grand Canyon to someone by showing photographs of it.

Cagan says the situation frustrates him. He had expected that by 2022 there would not be such a chasm between how good companies work and everyone else, especially given the strong incentive of profit. He reports an odd symmetry from his own friendships: friends at weaker companies often do not believe his description of how good companies work, while friends at good companies are baffled that anyone would work the other way. This is his anecdotal observation rather than measured evidence.

Cagan describes the mental model he keeps running into. A product manager writes requirements in some form, such as PRDs or user stories; a designer makes the result look good and perhaps produces wireframes; and the package is brought to sprint planning with engineers told what to build next. The transcript's wording for the last step is garbled ("the whole mess is taken its sprint planning to the engineers"). He calls this view not so much old-school as obsolete, and says it is so ingrained that people who have only known it hear a different language when he describes real product teams.

In the contrasting model, designers and engineers are genuine peers who help find the solution, and the product manager's job is different too: bringing skills the rest of the team lacks. Cagan goes as far as saying the two kinds of team should not share a title, because the jobs differ so radically that using the same one is misleading. The transcript says "the same string product manager", which most likely means the same title, although the transcript does not say so.

The developers aren't there to just implement your dumb ideas, they are there to help you come up with a great solution.

Lenny asks for three to five signs that a listener works on a feature team. Cagan says the difference is easy to see if you have experienced both. A feature team receives a typical roadmap, which he describes as a prioritized list of features and projects that stakeholders assemble, usually quarterly. Those features are in fact possible solutions, and the team is asked for a little design, a lot of coding, some QA and deployment, in the service of the business.

instead of being given a roadmap of prioritized features, they're given problems to solve.

A real product team, by contrast, is handed problems, whether customer problems or company problems, along with the skills to find the best solution. Cagan invokes what he calls the Netflix principle: push decisions down to the people who have the knowledge. His reasoning is that engineers work with the enabling technology every day and product teams work with users and customers every week, so they are closest to the problem.