Marty Cagan
Author of Inspired
Where to hear and read about Marty Cagan1 book · 3 episodes and tests
BookInspired
Lenny's PodcastMarty Cagan: Strong Opinions, loosely held
Lenny's PodcastProduct management theater | Marty Cagan (Silicon Valley Product Group)
Lenny's PodcastThe nature of product | Marty Cagan, Silicon Valley Product GroupMarty Cagan is a former HP engineer and product leader who founded Silicon Valley Product Group and wrote Inspired, Empowered and Transformed, the most widely read playbooks on how strong tech companies build products. The thing most worth learning from him is that product work is about outcomes and thinking: give empowered teams problems to solve, test ideas cheaply before building, and never let roadmaps, process or tools stand in for judgment.
I did not appreciate the lengths that people would go to in order to avoid thinking.
Marty Cagan: Strong Opinions, loosely held
Marty Cagan: the story and the lessons
1Marty Cagan's path from HP engineer to product coach
Cagan learned on a well-built HP product that nobody bought. In the mid-1980s he was a young software engineer on an HP team that spent over a year of nights and weekends putting AI tools on a low-cost workstation. It earned patents and excellent reviews, and no one bought it.
The team met HP's strict quality bar, localized the product and trained the sales force. At HP, a product manager sitting in marketing defined products, and Cagan says HP was not good at product management.
A manager pushed him to care about what gets built, not only how. As a new tech lead, his manager told him he had to care as much about what is built as how it is built. That sent him toward customers and gave him his first taste of discovery.
He says most good product people learned the same way, from a manager who cared about their career.
He had to visit 30 customers before he could make product decisions. Before taking the PM role he was required to visit 30 customers on a three week trip, 15 in the US and 15 in Europe. It changed how he saw customers.
"I thought I knew our customers and I really didn't."
A career in developer tools left him with a blind spot on viability. Cagan spent almost his whole career on developer tools and platforms, where his engineering background felt like a superpower. He now says that hid how weak his business viability skills were.
A visit to Walmart's headquarters led him to start Silicon Valley Product Group. Having spent most of his career inside good product companies, he was surprised that others worked differently, and the Walmart visit was his wake-up call. He believes companies in Arkansas and India deserve the same methods as Silicon Valley.
SVPG has five people, is booked almost a year ahead, and runs free sessions for independent coaches in London and New York.
He wrote three books, each answering the question the last one raised. Inspired came out in 2008 after 25 years in product, with a second edition ten years later. Empowered covered product leadership, and Transformed covers how to change a company.
SVPG only promotes a technique if several companies that consistently innovate use it. Cagan says they invent none of it.
2Cagan's core idea: empowered teams, not feature teams
Feature teams ship a roadmap of output; empowered teams solve problems. A feature team gets a dated list of features from executives, big customers or sales. An empowered team gets one or two hard customer or business problems a quarter and is judged on whether they are solved.
"You just don't get points for shipping, you get points for delivering the value."
He calls the old requirements model obsolete, not just old. In it, the PM writes requirements, the designer makes it pretty and engineers first see the work at sprint planning. On a real team, designers and engineers are peers who help find the solution.
He thinks feature team PMs and real product team PMs should not even share the title.
Most companies run a waterfall and call it Agile. Inspired traces the chain from ideas to business cases to roadmaps, requirements, sprints, QA and deploy, with all risk sitting at the end. Engineers used only to code give about half their value, and Agile confined to delivery yields maybe 20 percent of its value.
"Projects are output and product is all about outcome."
Teams should be durable, co-located and cross-functional. A team is a product manager, a designer and two to about 10 to 12 engineers, kept together long term and owning a meaningful piece of the product, including bugs and performance. Co-located means close enough to see each other's screens.
He borrows John Doerr's line: "We need teams of missionaries, not teams of mercenaries."
Decisions go to the people closest to the problem. Engineers work with the enabling technology daily and product teams with users weekly, so they are best placed to solve problems. Cagan calls this the Netflix principle.
He pitches outcomes to executives as time to money. CEOs and CFOs respond when outcome work is framed as time to money rather than time to market. Getting to market is well understood; getting to money is the hard part.
3What Marty Cagan expects of a real product manager
The PM is a creator who owns value and viability. Engineers own feasibility and designers own usability. The PM owns whether it works for the customer and whether the business can sell, market, service and legally run it.
At Airbnb, getting people to sign up was easy; making listings legal in San Francisco was the hard part.
PMs earn decision rights through four kinds of knowledge. They must know customers, product data, the business and its stakeholders, and the market. An unprepared PM is the biggest reason empowered teams fail.
Learning these skills usually takes two to three months. He also recommends an intro programming course and an intro accounting or finance course.
Cagan's PMs spend 30 minutes every morning in the analytics. They review the last 24 hours of sales and usage data and check A/B results themselves. An analyst can help, but understanding the data cannot be delegated.
Three kinds of access are sacred and never delegated. A PM must keep direct access to customers, engineers and stakeholders. QA, project management, product marketing and production operations can be handed off.
Product owners, project managers or product ops sitting in between cut that access, and companies that do it "don't understand why they haven't innovated for years."
He rejects 'asking why' and backlog administration as the PM job. The why comes from product strategy. A CSPO or PSPO class teaches Jira backlog management, which he compares to learning to operate Google Docs.
To a PM who says the job is to ask why: "what do you do for the rest of the week besides the 10 minutes it takes you to say why?" He calls having both a PM and a product owner a huge anti-pattern.
The engineer relationship matters more than any other. The PM shares customer pain, data and constraints, talks with engineers every workday, and leaves how to build to them. Bluffing fails with skeptical engineers; saying "I don't know" and following up works.
Founders should hold the PM job until after product-market fit. Early on, value and viability are the founder's job, and a real PM causes too many cooks. His heuristic is to hire one after fit, at roughly 20 to 25 engineers.
Hiring a PM mainly for project management is overpaying.
4How Marty Cagan teaches product discovery
Plan as if at least half your ideas will fail. Ideas fail on value, usability, feasibility or viability, and the best teams assume at least three quarters will not perform as hoped. Only about 20% of executive-prioritized features generate any positive return.
Value failure is the most common. Even good ideas need several iterations.
Spend little time on the problem and most on the solution. The founder usually already knows the problem, and weeks re-validating it burn time needed to beat rivals. Products rarely fail for lack of demand; they fail because someone ships a better solution.
"People don't buy the problem, they buy your solution."
Test cheap prototypes 10 to 20 times a week before building. Each discovery test should cost at least ten times less than a real release. The MVP should be a prototype, not a product.
"If the first time your developers see an idea is at sprint planning, you have failed."
User research should hunt for reasons people won't use it. Most value from prototype testing is evaluative: finding why users would reject it, not collecting enough likes to build. If the PM and designer can't attend a test, he says cancel it.
He credits Elon Musk with the idea of looking for all the reasons users won't use the product.
Ask why people don't use your product, including churned users. Cagan churns from many products he tries and almost nobody follows up. He calls this the single most important question and says most teams never ask it.
Six paying reference customers in one market prove fit. Recruit six to eight desperate prospects from a single market and do not turn on sales until six are live, paying and willing to vouch. For consumer products, over 40 percent saying "very disappointed" suggests fit.
Struggling to recruit even four or five is an early sign the problem may not matter enough.
Make test users pay with money, reputation, time or access. People are polite, so praise means little. Ask for a credit card, a letter of intent, a referral to their boss or real working time.
Fake door tests and Wizard of Oz prototypes let teams learn demand before building.
Be dramatically better than rivals, not at parity. Most customers switch from something and migration hurts, so matching a competitor, even cheaper, won't move them. He now calls product a full contact blood sport.
5Why Cagan replaces roadmaps with outcomes
Calling a list of ideas a roadmap turns guesses into promises. Leaders rightly want the most valuable work first and dates to plan around. Inspired keeps those goals but gives teams vision, strategy and prioritized objectives with measurable key results instead.
One team was asked to cut new customer onboarding from 30 days to under three hours, with the solution left to the team.
Dates come from rare high-integrity commitments made after discovery. Teams ask for a short discovery window, validate the four risks, and only then commit to a date and expected result. Those commitments are scored delivered or not.
OKRs belong to product teams and measure business results. Use one to three objectives with key results that measure outcomes, not tasks, and aim for a 0.7 score. Functional departments should not issue separate OKRs to people on product teams.
Wean stakeholders by tying every roadmap item to its metric. Keep the old process for six to 12 months, show the current and target metric for each item, and report the real impact after launch. A team adding PayPal did this with conversion rate.
"While you did ship the feature, the result was not successful."
Turn a requested feature back into a problem by asking about success. When a stakeholder asks for buy now, pay later, ask which KPI should move. The answer is usually conversion rate or average cart value.
He now says PRDs and roadmaps are fine once evidence exists. A PRD that turns a guess into engineering requirements is the project model. After testing, it is just a communication device.
"If you put a bunch of features that are somebody's idea of what might work and you put dates there, you're going to waste most of your time."
6Marty Cagan on leadership, strategy and scaling
Leaders set the bets; teams figure out how to win them. Letting teams pick their own work would mean 50 teams doing 50 things. Handing teams a feature list is what is truly top-down.
He points to Meta, with strong leadership on strategy and strong cross-functional teams on hard problems.
One vision and a focused strategy give every team the same destination. The vision looks two to five years out, and strategy is a sequence of product/market fits, one market at a time. Product principles settle recurring tradeoffs, like eBay's buyer first rule.
"Customers rarely leave us for our competitors. They leave us because we stop taking care of them."
Scale with leaders, not with process. Process is the easy path and appeals to old-school CIOs, which is why frameworks like SAFe spread. He calls them repackaged waterfall and warns that process people will destroy your company.
He leans on Steve Jobs's 1995 diagnosis of how companies decline. In the Lost Interview, Jobs said that as companies grow, sales, marketing and finance get promoted and good product people leave. Cagan thinks this beats his own theory that people have never seen good work.
Jobs also named the disease of stakeholders who think the idea is 90% of the work. Cagan calls an idea only "the very sparkle in the eye."
Optimization captures value; only discovery creates it. After founders leave, scared teams fall back to small A/B tests on main flows. Cagan says those are worth doing but are not discovery, and stopping real discovery is the beginning of the end.
Good teams release small changes many times a day. Most teams at good companies release about 20 times a day with CI/CD and instrument everything. Inspired sets a floor of every two weeks.
"Good companies, by the time they message it, it's live."
7How Cagan says to transform a company or a career
Start with a volunteer pilot team for a quarter or two. One team asks its manager to work the new way, with a fallback to the old way if it fails. Changing one team is cheap; switching whole business units is risky.
Pick people open to change and limit dependence on teams still working the old way.
He refuses to let product people see themselves as victims. Someone stuck on a feature team should self-assess and build real PM skills instead of quitting. He says he has seen companies promote those people countless times.
"Too many people in our industry view themselves as a victim of their company."
The product operating model rests on principles and four real roles. Transformed lays out 20 principles across strategy, discovery and delivery, and four missing competencies: product manager, designer, tech lead and product leader. Companies have the titles but not the jobs.
He chose the name "product operating model" because "product-led" sounds like a power grab to the rest of the company.
His case studies come from outside Silicon Valley on purpose. Trainline in the UK did innovation he rates alongside Amazon, and Saudi travel agency Almosafer holds over 80 percent of its market after changing how it works.
Product ops works only as a small research and data group. In good companies it combines user research and data analysts under one leader. If it focuses on process and governance, his advice is "run."
He urges people to vet advice and their future manager. He estimates about 90% of online PM content comes from the feature team world or worse. Before taking a job, research the manager who will coach you.
"Probably the most important skill for product people is really learning how to think critically."
8Marty Cagan's regrets about his own advice
He understated business viability for a decade. The 2008 first edition of Inspired listed only value, usability and feasibility, and viability was fixed in the second edition ten years later.
"I completely understated the importance of business viability."
His biggest regret is underestimating the craving for predictability. Executives and product people want predictability, and it works against humility, innovation and outcomes. He says it matters, but not enough to trade away outcomes or trust.
He fed process as a substitute for thinking. He regrets structuring Inspired as people, process and product instead of stressing thinking and product sense. He fears language models will become another way to avoid thinking.
Inspired barely covered leadership, and readers drew the wrong lesson. Many companies set up teams with strong PMs and expected success. He now says empowered teams need better management, at minimum a strategy listing prioritized problems.
Readers also took "CEO of the product" from his books, which he calls the opposite of humility.
He once believed good product work would carry the day. He now calls that naive. Half of his content over the last three years deals with politics, and he warns that better-shipping companies become targets for people with other motives.
9How Marty Cagan thinks about AI and product work
AI changes the tools but not the job. He defines the job as solving problems for customers and achieving outcomes for the business. AI was the first wave that made him re-examine even principles he was taught as sacred, and they held.
He reversed his advice to start with ChatGPT. People trusted the output too much and optimized a wrong direction. Now he says write your own argument first, then use the tool to challenge and tighten it.
AI will absorb admin PM work and make viability harder. Backlog administration and feature team project work are easiest to automate. Probabilistic software raises legal and ethical questions that land on the PM.
"If you are fundamentally a backlog administrator, good luck protecting that."
Product people should build to learn, not build to earn. Using Jeff Patton's terms, building to learn is discovery and building to earn is delivery. He says anyone who wants to do front-end pull requests should just be a developer.
He says AI makes outcome-focused work dramatically easier, though tokens are not free.
Marty Cagan: Strong Opinions, loosely held
Marty Cagan lists ten regrets about his product advice, covering business viability, problem versus solution discovery, predictability, politics and product leadership. The lesson is that AI makes building cheaper but makes clear thinking, outcomes and discovery matter more than ever.
A career in developer tools left him with a blind spot on viability. Cagan spent almost his whole career on developer tools and platforms, where his engineering background felt like a superpower. He now says that hid how weak his business viability skills were.
He wrote three books, each answering the question the last one raised. Inspired came out in 2008 after 25 years in product, with a second edition ten years later. Empowered covered product leadership, and Transformed covers how to change a company.
SVPG only promotes a technique if several companies that consistently innovate use it. Cagan says they invent none of it.
Spend little time on the problem and most on the solution. The founder usually already knows the problem, and weeks re-validating it burn time needed to beat rivals. Products rarely fail for lack of demand; they fail because someone ships a better solution.
"People don't buy the problem, they buy your solution."
Ask why people don't use your product, including churned users. Cagan churns from many products he tries and almost nobody follows up. He calls this the single most important question and says most teams never ask it.
Be dramatically better than rivals, not at parity. Most customers switch from something and migration hurts, so matching a competitor, even cheaper, won't move them. He now calls product a full contact blood sport.
He now says PRDs and roadmaps are fine once evidence exists. A PRD that turns a guess into engineering requirements is the project model. After testing, it is just a communication device.
"If you put a bunch of features that are somebody's idea of what might work and you put dates there, you're going to waste most of your time."
He understated business viability for a decade. The 2008 first edition of Inspired listed only value, usability and feasibility, and viability was fixed in the second edition ten years later.
"I completely understated the importance of business viability."
His biggest regret is underestimating the craving for predictability. Executives and product people want predictability, and it works against humility, innovation and outcomes. He says it matters, but not enough to trade away outcomes or trust.
He fed process as a substitute for thinking. He regrets structuring Inspired as people, process and product instead of stressing thinking and product sense. He fears language models will become another way to avoid thinking.
Inspired barely covered leadership, and readers drew the wrong lesson. Many companies set up teams with strong PMs and expected success. He now says empowered teams need better management, at minimum a strategy listing prioritized problems.
Readers also took "CEO of the product" from his books, which he calls the opposite of humility.
He once believed good product work would carry the day. He now calls that naive. Half of his content over the last three years deals with politics, and he warns that better-shipping companies become targets for people with other motives.
AI changes the tools but not the job. He defines the job as solving problems for customers and achieving outcomes for the business. AI was the first wave that made him re-examine even principles he was taught as sacred, and they held.
Product people should build to learn, not build to earn. Using Jeff Patton's terms, building to learn is discovery and building to earn is delivery. He says anyone who wants to do front-end pull requests should just be a developer.
He says AI makes outcome-focused work dramatically easier, though tokens are not free.
Product management theater | Marty Cagan (Silicon Valley Product Group)
Marty Cagan explains the difference between feature teams that ship a roadmap of output and empowered product teams that own outcomes, and why project-manager-style PM roles are now exposed to layoffs and AI. He lays out the skills a real product manager needs and the product operating model that companies outside Silicon Valley have used to transform.
He had to visit 30 customers before he could make product decisions. Before taking the PM role he was required to visit 30 customers on a three week trip, 15 in the US and 15 in Europe. It changed how he saw customers.
"I thought I knew our customers and I really didn't."
A visit to Walmart's headquarters led him to start Silicon Valley Product Group. Having spent most of his career inside good product companies, he was surprised that others worked differently, and the Walmart visit was his wake-up call. He believes companies in Arkansas and India deserve the same methods as Silicon Valley.
SVPG has five people, is booked almost a year ahead, and runs free sessions for independent coaches in London and New York.
He wrote three books, each answering the question the last one raised. Inspired came out in 2008 after 25 years in product, with a second edition ten years later. Empowered covered product leadership, and Transformed covers how to change a company.
SVPG only promotes a technique if several companies that consistently innovate use it. Cagan says they invent none of it.
Feature teams ship a roadmap of output; empowered teams solve problems. A feature team gets a dated list of features from executives, big customers or sales. An empowered team gets one or two hard customer or business problems a quarter and is judged on whether they are solved.
"You just don't get points for shipping, you get points for delivering the value."
He pitches outcomes to executives as time to money. CEOs and CFOs respond when outcome work is framed as time to money rather than time to market. Getting to market is well understood; getting to money is the hard part.
The PM is a creator who owns value and viability. Engineers own feasibility and designers own usability. The PM owns whether it works for the customer and whether the business can sell, market, service and legally run it.
At Airbnb, getting people to sign up was easy; making listings legal in San Francisco was the hard part.
He rejects 'asking why' and backlog administration as the PM job. The why comes from product strategy. A CSPO or PSPO class teaches Jira backlog management, which he compares to learning to operate Google Docs.
To a PM who says the job is to ask why: "what do you do for the rest of the week besides the 10 minutes it takes you to say why?" He calls having both a PM and a product owner a huge anti-pattern.
Founders should hold the PM job until after product-market fit. Early on, value and viability are the founder's job, and a real PM causes too many cooks. His heuristic is to hire one after fit, at roughly 20 to 25 engineers.
Hiring a PM mainly for project management is overpaying.
Leaders set the bets; teams figure out how to win them. Letting teams pick their own work would mean 50 teams doing 50 things. Handing teams a feature list is what is truly top-down.
He points to Meta, with strong leadership on strategy and strong cross-functional teams on hard problems.
Optimization captures value; only discovery creates it. After founders leave, scared teams fall back to small A/B tests on main flows. Cagan says those are worth doing but are not discovery, and stopping real discovery is the beginning of the end.
Good teams release small changes many times a day. Most teams at good companies release about 20 times a day with CI/CD and instrument everything. Inspired sets a floor of every two weeks.
"Good companies, by the time they message it, it's live."
Start with a volunteer pilot team for a quarter or two. One team asks its manager to work the new way, with a fallback to the old way if it fails. Changing one team is cheap; switching whole business units is risky.
Pick people open to change and limit dependence on teams still working the old way.
He refuses to let product people see themselves as victims. Someone stuck on a feature team should self-assess and build real PM skills instead of quitting. He says he has seen companies promote those people countless times.
"Too many people in our industry view themselves as a victim of their company."
The product operating model rests on principles and four real roles. Transformed lays out 20 principles across strategy, discovery and delivery, and four missing competencies: product manager, designer, tech lead and product leader. Companies have the titles but not the jobs.
He chose the name "product operating model" because "product-led" sounds like a power grab to the rest of the company.
His case studies come from outside Silicon Valley on purpose. Trainline in the UK did innovation he rates alongside Amazon, and Saudi travel agency Almosafer holds over 80 percent of its market after changing how it works.
Product ops works only as a small research and data group. In good companies it combines user research and data analysts under one leader. If it focuses on process and governance, his advice is "run."
He urges people to vet advice and their future manager. He estimates about 90% of online PM content comes from the feature team world or worse. Before taking a job, research the manager who will coach you.
"Probably the most important skill for product people is really learning how to think critically."
He reversed his advice to start with ChatGPT. People trusted the output too much and optimized a wrong direction. Now he says write your own argument first, then use the tool to challenge and tighten it.
AI will absorb admin PM work and make viability harder. Backlog administration and feature team project work are easiest to automate. Probabilistic software raises legal and ethical questions that land on the PM.
"If you are fundamentally a backlog administrator, good luck protecting that."
The nature of product | Marty Cagan, Silicon Valley Product Group
Explains how real product teams differ from feature teams, why companies lose their product mojo as they grow, and what a team or PM can do this quarter to start working like the best. The result worth hearing is a practical playbook, including the three access rights every PM must protect, drawn from practices seen at the best product companies.
A manager pushed him to care about what gets built, not only how. As a new tech lead, his manager told him he had to care as much about what is built as how it is built. That sent him toward customers and gave him his first taste of discovery.
He says most good product people learned the same way, from a manager who cared about their career.
He had to visit 30 customers before he could make product decisions. Before taking the PM role he was required to visit 30 customers on a three week trip, 15 in the US and 15 in Europe. It changed how he saw customers.
"I thought I knew our customers and I really didn't."
A visit to Walmart's headquarters led him to start Silicon Valley Product Group. Having spent most of his career inside good product companies, he was surprised that others worked differently, and the Walmart visit was his wake-up call. He believes companies in Arkansas and India deserve the same methods as Silicon Valley.
SVPG has five people, is booked almost a year ahead, and runs free sessions for independent coaches in London and New York.
He wrote three books, each answering the question the last one raised. Inspired came out in 2008 after 25 years in product, with a second edition ten years later. Empowered covered product leadership, and Transformed covers how to change a company.
SVPG only promotes a technique if several companies that consistently innovate use it. Cagan says they invent none of it.
Feature teams ship a roadmap of output; empowered teams solve problems. A feature team gets a dated list of features from executives, big customers or sales. An empowered team gets one or two hard customer or business problems a quarter and is judged on whether they are solved.
"You just don't get points for shipping, you get points for delivering the value."
He calls the old requirements model obsolete, not just old. In it, the PM writes requirements, the designer makes it pretty and engineers first see the work at sprint planning. On a real team, designers and engineers are peers who help find the solution.
He thinks feature team PMs and real product team PMs should not even share the title.
Decisions go to the people closest to the problem. Engineers work with the enabling technology daily and product teams with users weekly, so they are best placed to solve problems. Cagan calls this the Netflix principle.
The PM is a creator who owns value and viability. Engineers own feasibility and designers own usability. The PM owns whether it works for the customer and whether the business can sell, market, service and legally run it.
At Airbnb, getting people to sign up was easy; making listings legal in San Francisco was the hard part.
PMs earn decision rights through four kinds of knowledge. They must know customers, product data, the business and its stakeholders, and the market. An unprepared PM is the biggest reason empowered teams fail.
Learning these skills usually takes two to three months. He also recommends an intro programming course and an intro accounting or finance course.
Three kinds of access are sacred and never delegated. A PM must keep direct access to customers, engineers and stakeholders. QA, project management, product marketing and production operations can be handed off.
Product owners, project managers or product ops sitting in between cut that access, and companies that do it "don't understand why they haven't innovated for years."
Plan as if at least half your ideas will fail. Ideas fail on value, usability, feasibility or viability, and the best teams assume at least three quarters will not perform as hoped. Only about 20% of executive-prioritized features generate any positive return.
Value failure is the most common. Even good ideas need several iterations.
Spend little time on the problem and most on the solution. The founder usually already knows the problem, and weeks re-validating it burn time needed to beat rivals. Products rarely fail for lack of demand; they fail because someone ships a better solution.
"People don't buy the problem, they buy your solution."
User research should hunt for reasons people won't use it. Most value from prototype testing is evaluative: finding why users would reject it, not collecting enough likes to build. If the PM and designer can't attend a test, he says cancel it.
He credits Elon Musk with the idea of looking for all the reasons users won't use the product.
Turn a requested feature back into a problem by asking about success. When a stakeholder asks for buy now, pay later, ask which KPI should move. The answer is usually conversion rate or average cart value.
Scale with leaders, not with process. Process is the easy path and appeals to old-school CIOs, which is why frameworks like SAFe spread. He calls them repackaged waterfall and warns that process people will destroy your company.
He leans on Steve Jobs's 1995 diagnosis of how companies decline. In the Lost Interview, Jobs said that as companies grow, sales, marketing and finance get promoted and good product people leave. Cagan thinks this beats his own theory that people have never seen good work.
Jobs also named the disease of stakeholders who think the idea is 90% of the work. Cagan calls an idea only "the very sparkle in the eye."
Optimization captures value; only discovery creates it. After founders leave, scared teams fall back to small A/B tests on main flows. Cagan says those are worth doing but are not discovery, and stopping real discovery is the beginning of the end.
Start with a volunteer pilot team for a quarter or two. One team asks its manager to work the new way, with a fallback to the old way if it fails. Changing one team is cheap; switching whole business units is risky.
Pick people open to change and limit dependence on teams still working the old way.
Product ops works only as a small research and data group. In good companies it combines user research and data analysts under one leader. If it focuses on process and governance, his advice is "run."
Inspired: How to Create Tech Products Customers Love
Strong tech product teams separate good ideas from bad in fast, cheap product discovery, then deliver production quality only for ideas with evidence behind them. The book gives a large toolkit for empowered teams to tackle value, usability, feasibility and viability risk, and it shows how to replace feature roadmaps with outcomes and keep innovating at scale.
Cagan learned on a well-built HP product that nobody bought. In the mid-1980s he was a young software engineer on an HP team that spent over a year of nights and weekends putting AI tools on a low-cost workstation. It earned patents and excellent reviews, and no one bought it.
The team met HP's strict quality bar, localized the product and trained the sales force. At HP, a product manager sitting in marketing defined products, and Cagan says HP was not good at product management.
Most companies run a waterfall and call it Agile. Inspired traces the chain from ideas to business cases to roadmaps, requirements, sprints, QA and deploy, with all risk sitting at the end. Engineers used only to code give about half their value, and Agile confined to delivery yields maybe 20 percent of its value.
"Projects are output and product is all about outcome."
Teams should be durable, co-located and cross-functional. A team is a product manager, a designer and two to about 10 to 12 engineers, kept together long term and owning a meaningful piece of the product, including bugs and performance. Co-located means close enough to see each other's screens.
He borrows John Doerr's line: "We need teams of missionaries, not teams of mercenaries."
He pitches outcomes to executives as time to money. CEOs and CFOs respond when outcome work is framed as time to money rather than time to market. Getting to market is well understood; getting to money is the hard part.
PMs earn decision rights through four kinds of knowledge. They must know customers, product data, the business and its stakeholders, and the market. An unprepared PM is the biggest reason empowered teams fail.
Learning these skills usually takes two to three months. He also recommends an intro programming course and an intro accounting or finance course.
Cagan's PMs spend 30 minutes every morning in the analytics. They review the last 24 hours of sales and usage data and check A/B results themselves. An analyst can help, but understanding the data cannot be delegated.
The engineer relationship matters more than any other. The PM shares customer pain, data and constraints, talks with engineers every workday, and leaves how to build to them. Bluffing fails with skeptical engineers; saying "I don't know" and following up works.
Plan as if at least half your ideas will fail. Ideas fail on value, usability, feasibility or viability, and the best teams assume at least three quarters will not perform as hoped. Only about 20% of executive-prioritized features generate any positive return.
Value failure is the most common. Even good ideas need several iterations.
Test cheap prototypes 10 to 20 times a week before building. Each discovery test should cost at least ten times less than a real release. The MVP should be a prototype, not a product.
"If the first time your developers see an idea is at sprint planning, you have failed."
Six paying reference customers in one market prove fit. Recruit six to eight desperate prospects from a single market and do not turn on sales until six are live, paying and willing to vouch. For consumer products, over 40 percent saying "very disappointed" suggests fit.
Struggling to recruit even four or five is an early sign the problem may not matter enough.
Make test users pay with money, reputation, time or access. People are polite, so praise means little. Ask for a credit card, a letter of intent, a referral to their boss or real working time.
Fake door tests and Wizard of Oz prototypes let teams learn demand before building.
Be dramatically better than rivals, not at parity. Most customers switch from something and migration hurts, so matching a competitor, even cheaper, won't move them. He now calls product a full contact blood sport.
Calling a list of ideas a roadmap turns guesses into promises. Leaders rightly want the most valuable work first and dates to plan around. Inspired keeps those goals but gives teams vision, strategy and prioritized objectives with measurable key results instead.
One team was asked to cut new customer onboarding from 30 days to under three hours, with the solution left to the team.
Dates come from rare high-integrity commitments made after discovery. Teams ask for a short discovery window, validate the four risks, and only then commit to a date and expected result. Those commitments are scored delivered or not.
OKRs belong to product teams and measure business results. Use one to three objectives with key results that measure outcomes, not tasks, and aim for a 0.7 score. Functional departments should not issue separate OKRs to people on product teams.
Wean stakeholders by tying every roadmap item to its metric. Keep the old process for six to 12 months, show the current and target metric for each item, and report the real impact after launch. A team adding PayPal did this with conversion rate.
"While you did ship the feature, the result was not successful."
One vision and a focused strategy give every team the same destination. The vision looks two to five years out, and strategy is a sequence of product/market fits, one market at a time. Product principles settle recurring tradeoffs, like eBay's buyer first rule.
"Customers rarely leave us for our competitors. They leave us because we stop taking care of them."
Good teams release small changes many times a day. Most teams at good companies release about 20 times a day with CI/CD and instrument everything. Inspired sets a floor of every two weeks.
"Good companies, by the time they message it, it's live."
Start with a volunteer pilot team for a quarter or two. One team asks its manager to work the new way, with a fallback to the old way if it fails. Changing one team is cheap; switching whole business units is risky.
Pick people open to change and limit dependence on teams still working the old way.