LLenny's Podcast
← All episodes
Marty Cagan, Silicon Valley Product Group21 August 2022

The nature of product

9Frameworks
15Insights

Frameworks in this episode

Innovation4 steps

Evaluative User Research (Hunt for Reasons They Won't Use It)

Test prototypes to find every reason people won't use it — and never let the researcher go alone

Read →
Leadership5 steps

Feature Team vs. Empowered Product Team Diagnostic

Tell in minutes whether your squad is handed features to ship or problems to solve

Read →
Innovation4 steps

Solution-Weighted Discovery

Spend a little time validating the problem; spend most of it winning on the solution

Read →
Mindset4 steps

The Best-Teams Adoption Heuristic

Adopt a practice only if several of the best teams already use it — then strip the culture from the technique

Read →
Strategy4 steps

The Diseases of a Devolving Product Company

Four diagnosable diseases that turn a great product company into a feature factory

Read →
Innovation4 steps

The Four Product Risks and Their Owners

Valuable, usable, feasible, viable — any one fails and the product fails

Read →
Leadership5 steps

The One-Quarter Empowered Team Experiment

Convert a single feature team into an empowered product team in one low-risk quarter

Read →
Self-Mastery4 steps

The Product Manager's Four Areas of Homework

The four knowledge domains a PM must own because nobody else on the team can bring them

Read →
Leadership5 steps

The Three Sacred Accesses

Delegate anything off the PM's plate except direct access to customers, engineers, and stakeholders

Read →

Insights & moments

The myth-busts, hot takes, explainers, and tools worth keeping.

Myth Buster· 2

Myth Buster23:00

The Idea Is Minor — The Craftsmanship Is Everything

Jobs named a 'disease of the stakeholders' where managers believe an idea is 90% of the work. Cagan agrees the idea is minor — just a start — and that the real work is the craftsmanship of going from idea to product, which is product discovery. Executives who think a room full of leaders can produce a prioritized feature list miss that only about 20% of such features generate any positive return.

  • Jobs' 'disease of stakeholders': believing the idea is 90% of the work
  • The idea is just the sparkle in the eye; getting to a product is the real work
  • Only ~20% of executive-prioritized features generate any positive return
  • Arrogance drives it — every executive thinks their ideas are the better ones

“they think that an idea is 90 of the work”

Marty Cagan · 23:00

“only about 20 percent of those things will generate any kind of positive return”

Marty Cagan · 24:00
#ideas#product-discovery#stakeholders#execution
Myth Buster27:30

No, PMs Aren't Just Responsible for the 'What'

Cagan rejects the popular claim that a PM handles the 'what' and leaves the 'how' to others — joking he'd only need 15 minutes a week if that were the job. Using the valuable/usable/feasible/viable framing, the PM is responsible for making the solution valuable and viable, two of the hardest risks. Monetization, go-to-market, privacy, and security are all part of the 'how' and are product responsibilities.

  • The 'PM only owns the what' idea is uninformed — the how is a big part of the job
  • PM owns valuable and viable; designer owns usable; engineer owns feasible
  • If any of the four risks fails, the product fails — they're table stakes
  • Monetization, security, privacy, and go-to-market are all 'how' and all product responsibilities

“i'd phone it in 15 minutes a week i'm done i did my part this is ridiculous”

Marty Cagan · 27:30
#product-management#what-vs-how#risks#role

Hot Take· 4

Hot Take12:00

Cagan Invents Nothing — He Just Copies the Best Teams

Cagan is emphatic that nothing in Inspired or Empowered was invented by SVPG; they only share practices already used by the best teams. His heuristic: if several of the best teams use a technique, start recommending and testing it; if none of them use a proposed tool or process, it's snake oil or unproven. The real work is untangling a company's culture from the transferable technique.

  • Nothing in Inspired or Empowered was invented by SVPG — they share what the best teams do
  • Heuristic: adopt what several top teams use; dismiss what none of them use
  • Books like Working Backwards (Amazon) and No Rules Rules (Netflix) describe the same techniques in their own terms
  • The hard part is separating a company's specific culture from the underlying technique

“all we do is share the practices we see being used in the best teams”

Marty Cagan · 12:30
#best-practices#product-culture#heuristics#technique
Hot Take15:30

Only 10–15% of Companies Are Good Product Companies

Asked what fraction of companies actually work like the best, Cagan gives a purely anecdotal guess of 10 to 15 percent among commercial product companies. He notes most software people historically build custom solutions rather than commercial products, which muddies any real count. What bothers him is that despite the obvious profit incentive, so few companies choose to work like the best.

  • Cagan's anecdotal guess: ~10–15% are good product companies
  • Custom-solution builders historically outnumber commercial-product builders
  • Even the profit motive alone doesn't push most companies to adopt the best practices

“my purely anecdotal guess is uh maybe 10 to 15 percent are good product companies something like that”

Marty Cagan · 16:00
#product-companies#industry#estimates
Hot Take26:30

People Don't Buy the Problem — They Buy Your Solution

Cagan warns teams against spending weeks re-validating a problem the founder already knows exists. Many products already solve what customers care about; the real question is whether you solve it better than everyone else so customers buy you. Spend a little time on the problem if needed, but save time to win on the solution — that's where teams succeed or fail.

  • Customers buy your solution, not the validated problem
  • If the founder already knows the problem, don't burn weeks re-validating it
  • The real question: do you solve it better than everybody else so they buy you
  • Steve Jobs' '5,000 things you keep in your head' was solution discovery

“people don't buy the problem they buy your solution”

Marty Cagan · 26:30

“the real question is do you solve it better than everybody else so that they buy you and that's where you need to take time”

Marty Cagan · 26:30
#problem-vs-solution#discovery#validation#prioritization
Hot Take55:30

Scale With Leaders, Not Process

Cagan says there are two ways to scale — with process or with leaders — and only scaling with leaders reliably leads to good outcomes. Process is the easier, more appealing path, which is why frameworks like SAFe grow despite being, in his view, repackaged waterfall dressed up as agile. Echoing Steve Jobs' 'disease of process people,' he warns that betting on process as the answer will destroy a company.

  • Two ways to scale: with process or with leaders — only leaders reliably work
  • Process is easier and more appealing, so it spreads (e.g. SAFe as repackaged waterfall)
  • Old-school CIOs who don't understand software are drawn to process-based scaling
  • Jobs' 'disease of process people' — process is never the answer

“you can scale with process or you can scale with leaders the only way i know that leads to good outcomes is scaling with leaders”

Marty Cagan · 56:00

“be careful of the disease of processed people they will destroy your company”

Marty Cagan · 57:00
#scaling#process#leadership#agile

Explainer· 4

Explainer06:30

Feature Teams vs. Real Product Teams: The Real Difference

Cagan explains that a feature team is handed a prioritized roadmap of features (possible solutions) and asked to design a little, code a lot, and serve the business. A real product team is instead given problems to solve and the skills to find the best solution, pushing decisions down to the people closest to the users and the technology. Designers and engineers on a real team are true peers, not order-takers.

  • Feature teams get a quarterly prioritized list of features; product teams get problems to solve
  • Features on a roadmap are really just possible solutions handed down by stakeholders
  • Netflix principle: push decisions down to the people with the knowledge to best solve the problem
  • Engineers and designers are peers who help find the solution, not implementers of the PM's ideas

“the developers aren't there to just implement your dumb ideas they are there to help you come up with a great solution”

Marty Cagan · 06:30
#product-teams#feature-factory#empowerment#org-design
Explainer21:00

Why Companies Get Scared After the Founders Leave

Cagan describes a common anti-pattern: once founders leave, product teams and executives become literally scared because they don't know what is essential versus incidental to the business. Founders had the institutional knowledge and 'moral authority' to know what mattered; without it, companies retreat to low-risk optimization — small A/B tests and tweaks to existing flows. Optimization captures value but never drives the major innovation that discovery does.

  • Post-founder teams fear hurting the thing that fuels the business
  • Founders knew deeply what was essential vs. incidental — the 'moral authority of the founder'
  • Scared companies default to little low-risk A/B tests and flow tweaks
  • Optimization is value capture; discovery is value creation — stopping discovery is the beginning of the end

“so many companies after the founders leave they're scared they're literally scared the product teams are scared the executives are scared”

Marty Cagan · 21:30
#founders#risk-aversion#discovery#optimization
Explainer31:30

User Research Is for Finding Why They Won't Use It

Cagan corrects teams who test prototypes until enough users say they like it, then build — that fools no smart leader. The point of user research is largely evaluative: uncovering all the reasons users won't use your product. He cites an Elon Musk framing that research should focus on finding every reason people won't use it, and notes most valuable research is evaluative rather than generative.

  • Building because enough users 'like' a prototype won't fool smart leaders
  • Most valuable user research is evaluative — surfacing reasons they won't use it
  • Cagan cites Elon Musk: focus research on finding all the reasons they won't use your product
  • We test constantly with users, customers, stakeholders, and developers

“when we're doing user research we're finding all the reasons they don't like it”

Marty Cagan · 32:30

“when you do user research you should be focused on finding all the reasons they won't use your product”

Marty Cagan · 32:30
#user-research#evaluative#prototyping#discovery
Explainer50:30

The Three Sacred Things a PM Must Never Give Up

Cagan says he's flexible on almost everything, but three things are sacred for a PM: unencumbered access to users and customers, to engineers, and to stakeholders. Anyone who inserts themselves between the PM and any of these — often well-intentioned product owners, project managers, or success/sales people — cripples the role. You can offload QA, product marketing, and production operations, but never these three.

  • Sacred #1: direct, unencumbered access to users and customers
  • Sacred #2: direct access to the engineers, working with them daily
  • Sacred #3: direct access to the stakeholders
  • Everything else (QA, product marketing, ops) can be delegated — never these three

“direct access to customers direct access to the engineers direct access to the stakeholders”

Marty Cagan · 55:00
#product-management#access#role#product-ops

Story· 2

Story19:00

Steve Jobs' 1995 Theory for Why Product Companies Decay

In the 'lost interview,' Steve Jobs argued that as companies grow and stop innovating, the celebrated people become sales, marketing, and finance leaders — the engines of growth or cost-cutting when product innovation stalls. Over time those people get promoted into leadership, good product people no longer want to work there, and they leave for companies that value product. Cagan considers this a better explanation than his own and calls it prescient.

  • As companies grow, product historically becomes less important than sales/marketing/finance
  • Those non-product people get promoted and become the leaders
  • Good product people then leave for companies that value product
  • Cagan rates Jobs' 1995 theory higher than his own explanation in Empowered

“good product people don't want to work there anymore and they leave and they go to a company that values product”

Marty Cagan · 20:00
#steve-jobs#company-decline#leadership#innovation
Story39:30

Cagan Had to Visit 30 Customers Before Making Any Decisions

When Cagan was an engineer moving into product, his coach forbade him from making any team decisions until he had visited 30 customers — 15 in the US and 15 in Europe — on a three-week trip. Cagan assumed he already knew the customer because he'd built products for developers, but his coach insisted that assumption is never true. The trip fixed it and taught him a PM must be one of the experts on users and customers.

  • Cagan's coach barred decisions until he'd visited 30 customers (15 US, 15 Europe)
  • It was a three-week business trip the coach arranged
  • Cagan wrongly assumed he already knew the customer as a former developer
  • The coach's line: 'all I know for sure is that's never true'

“i was not allowed to make any decisions for the team until after i visited 30 customers his number was 30 15 in the us…”

Marty Cagan · 39:30
#customer-visits#coaching#product-management#learning

Tool· 1

Tool44:00

Books to Learn Product Discovery

For PMs trying to shift a feature team toward real product work, Cagan recommends Teresa Torres's Continuous Discovery Habits as directly on-point for the needed skills, holding you through the first weeks. He also recommends Jake Knapp's Sprint — 400 pages on a single technique, but a good one. His own book Inspired shares the most popular discovery techniques.

  • Continuous Discovery Habits (Teresa Torres) — on-point for discovery skills
  • Sprint (Jake Knapp) — a whole book on one good technique
  • Inspired (Cagan) — the most popular discovery techniques

“teresa torres's new book continuous discovery habits that's a very good book”

Marty Cagan · 44:00
#books#discovery#recommendations#learning

Takeaway· 2

Takeaway09:30

Product Teams Are About Outcomes, Not Output

When a team is given a problem to solve, the measure is outcome, not output — you either solve it or you don't. Cagan argues that with continuous deployment shipping many releases a day, another release means nothing unless it actually solves the problem. Teams should celebrate solved problems and results, not shipped features.

  • A problem to solve produces an outcome; a feature to build produces output
  • With continuous delivery, shipping more releases is not something to brag about
  • Celebrate when you actually solve the problem and accomplish results

“who cares if you make another release if it doesn't actually solve the problem it's nothing to brag about right it's nothing to celebrate”

Marty Cagan · 09:30
#outcomes#output#continuous-delivery#metrics
Takeaway33:00

If the PM and Designer Can't Attend, Cancel the Test

Cagan's rule for the user researchers he coaches: if the product manager and designer can't be present for a product test, cancel it. The problem isn't researcher competence — it's that a report handed back second-hand is too often ignored. Being there is what makes research useful to the team, and Cagan stresses engineers being involved is where the magic happens.

  • Rule: cancel the test if the PM and designer can't be there
  • Second-hand research reports are too often ignored
  • Presence is what makes research useful to the team
  • Getting engineers into research sessions is where the magic happens

“if the product manager and the designer are not available to be there during your product their products test cancel the test they need to…”

Marty Cagan · 33:30
#user-research#team-participation#coaching