Marty Cagan on Product Discovery, Hiring and Empowered Teams

Marty Cagan says his interest is in product teams rather than product managers alone: in his experience, great products come from teams. He spent a decade as an engineer at HP Labs and became curious about who decided what to build, how those decisions were made and how products reached customers.

He moved to Netscape to work on developer platforms and tools, then joined eBay as its initial product and design leader. He later founded Silicon Valley Product Group to help startups, benefiting from relationships developed at the earlier companies.

Cagan recalls learning from Marc Andreessen's close contact with engineers, customers and startups. The lesson he emphasizes most is recognizing what one cannot yet know: whether customers will buy a solution or how difficult it will be to build requires investigation rather than confident assertion.

He describes Ben Horowitz's direct but well-intentioned feedback as another influence. Pierre Omidyar's vision for eBay persuaded him to work on a product for buyers and sellers rather than the developer tools he had usually favored.

Startup founders face many risks, including business model, channels, skills and technology. Cagan says people often focus on risks familiar to them while postponing the central question: can the team create a product customers actually want?

He recalls a founder who spent years changing pricing, target markets and promotion without materially changing a minimum viable product. Cagan's assessment was that the proposed solution did not provide enough value; this is his account of a specific case, not a diagnosis of every stalled company.

He distinguishes establishing that a problem exists from creating a solution better than available alternatives. In his view, discovering unmet or insufficiently served value is often harder than demonstrating that a broad market need exists.

Cagan's discovery framework asks four questions: is the solution valuable to users, usable, technically feasible and viable as a business? Viability includes affordability, distribution, legal and regulatory requirements; any of the four can prevent success.

He contrasts output with outcomes. Shipping features is output; solving a real customer and business problem is an outcome. A team that merely increases the number of features can become what he calls a feature factory without making the product more valuable.

Startups have limited runway, and larger companies may run out of management patience. Cagan argues for rapid discovery rather than waiting a year for each large release, so teams can test many approaches before resources or patience run out.

He offers 50 to 100 attempts as a rough expectation in some product-market-fit searches and says discovery skills can make iterations much faster. The number is his heuristic, not a proven requirement or a guarantee of finding fit.

Quantitative methods can show whether a change works at scale, while qualitative work can help explain why people struggle or reject it. Cagan says good teams combine both and can often learn quickly from prototypes with real users before launching broadly.

He cautions against seeking affirmation by simply asking customers whether they would buy a hypothetical product or asking them to design the solution. His goal in qualitative work is to identify why someone would not use it, then use the team's judgment to respond.

Small qualitative interviews are not a substitute for statistical evidence about a population. Cagan suggests stronger signals of value, such as a real payment, a commitment of time or a nonbinding letter of intent, depending on the product and context.

He views product development as a blend of art and science, with judgment needed to decide when stronger quantitative evidence is worth the time and cost. A high-risk commitment may warrant more evidence than a reversible exploration.

Cagan prefers a founder to be the product leader and says he personally invests only when at least one founder has demonstrated product leadership. That is his investment criterion, not proof that companies with different founding teams cannot succeed.

Assuming such a founder is present, he uses roughly 25 to 30 engineers as a heuristic for when the founder may need additional product leadership. Engineers work in smaller teams with senior technical leads, so the founder is not expected to manage every individual directly.

Before hiring, he asks what the founder actually needs: additional capacity, help executing a vision or a different kind of product leadership. A clear role matters more than a generic title.

Both hiring experienced people and developing junior talent can work, Cagan says. A compelling product vision can attract experienced candidates, but hiring juniors without a manager committed to coaching them sets those people up to struggle.

For inexperienced candidates, he looks for curiosity, work ethic and persistence through obstacles. He is skeptical of simple hiring tests because, in his experience, they can reject capable people and do not reliably reveal the qualities he wants.

He suggests an experienced manager aim to bring a junior hire to basic competence over roughly three months. That is his practical expectation for a supported hire, not a promise that everyone will reach the same level on a fixed schedule.

On domain knowledge, Cagan prefers strong product skills and the ability to learn the field, while acknowledging exceptions. He distinguishes useful expertise from unexamined industry assumptions and says teams must still study customers, financial constraints and regulations.

In specialized areas such as medicine, he says product teams should have access to qualified subject-matter experts. His point is not to ignore expertise, but to combine it with product people who can learn and challenge assumptions responsibly.

Cagan recounts his own transition from engineering to product at HP. A mentor assessed his strengths and gaps and required him to visit 30 customers—15 in the United States and 15 in Europe—before making product decisions.

He says those visits quickly exposed how little he knew about customers, despite building tools for engineers like himself. The mentor also arranged for him to learn both the direct and reseller sales channels, so he understood how the product reached the market.

Cagan had little financial training, so his mentor arranged reading and weekly tutoring with a finance colleague. He learned what the product's key measures meant and discovered that it was losing money on each sale, a fact the engineering team had not understood.

He argues that engineers contribute more than code and should be equipped to understand customers and business context. His criticism of outsourcing core engineering reflects his preference for empowered internal teams; he presents it as a management view rather than a universal rule.

Onboarding begins with an individual assessment and coaching plan, he says. Some people need customer-success experience, some need time in the field and others need financial knowledge; after basic competence, the plan can shift toward developing their potential.

Cohort onboarding programs also help new employees learn customers, culture, leadership and decision-making. The common mistake is assuming a person who succeeded at a well-known company automatically knows how to succeed in a different one.

Asked about tension between product and sales, Cagan argues that a product team should take responsibility for understanding why its product is not selling. That means spending time with sales and investigating visibility, sales tools, references, pricing and product value rather than assigning blame from a distance.

He distinguishes scaling through process from scaling through coaching. Cagan criticizes overly prescriptive processes and offers a broad opinion about their prevalence in Europe; the interview does not provide comparative evidence for that regional claim.

Thoughtful discussion and written narratives can make later execution faster, he says. In quick-fire advice for product managers, he emphasizes outcomes and deep knowledge of customers, data, industry and enabling technology.

An empowered product team owns the value and viability of a solution, while a feature team may simply implement instructions. Cagan believes giving teams real responsibility helps them develop the judgment associated with founders.

For a product leader entering a new role, his first priority is trust with other leaders, built in part by spending substantial time with customers. He wants colleagues to know that the leader understands customer problems rather than relying only on internal reports.

Cagan says he supports Agile but criticizes treating a delivery-process role as a substitute for learning the broader product job. In 2022 he praises strategies at TikTok, Tesla, AWS and Stripe; these are his assessments at that time, not independent evaluations of the companies.

Stebbings thanks Cagan for the conversation, and Cagan closes the interview.