Inspired

The bottom line

Products customers love come from empowered, cross-functional teams that are given problems to solve and test ideas cheaply before building, not from teams handed feature roadmaps. At least half of ideas fail, so the speed of that testing decides how much a builder wastes.

Key takeaways

• Fine engineering cannot rescue a product nobody needs. Patents, quality and good press say nothing about whether customers want it. PART I: Lessons from Top Tech Companies
  • At HP in the mid-1980s, a strong team spent more than a year of nights and weekends putting AI tools on a low-cost workstation, replacing setups that cost over $100,000 per user. It earned patents and excellent reviews, and no one bought it.
• Give teams business problems with measurable results, not lists of features with dates. At least half of ideas fail, so a promised feature often ships without solving anything. Ch. 23 · The Alternative to Roadmaps
  • A product took 30 days to onboard a new customer. The team got one objective, cut the time to go live, with one key result: average onboarding under three hours. The team picked the solution.
• Test each idea for value, usability, feasibility and business viability before writing production code. Prototypes cost far less than a real build, so many ideas can be tried and most bad ones dropped early. Ch. 33 · Principles of Product Discovery
  • Good teams try out roughly 10 to 20 product ideas each week. Each test costs at least ten times less time and work than building and shipping a real release.
• Treat each stakeholder objection as a design constraint to solve, not a fight to win. A product customers love still fails if sales, legal or engineering can block it. Ch. 15 · Profile: Jane Manning of Google
  • In 2000, Google sales feared AdWords would eat into its top-of-results ads, and engineers feared ads would hurt search. Jane Manning met each objector, put self-service ads on the side, and ranked them by price per impression times click-through rate. At 16 years old, AdWords earned well over $60B in a year.
• Prove product/market fit with six paying reference customers in one market before turning on sales. Buyers want to see companies like them already succeeding with the product. Ch. 39 · Customer Discovery Program Technique
  • Teams recruit six to eight desperate prospects from a single market so that six remain. Struggling to recruit even four or five is an early sign the problem may not matter enough to sell.
  • For consumer products, fit is likely when more than 40 percent of qualified users say they would be very disappointed to lose the product.
• Large companies keep innovating only by disrupting their own revenue before others do. Profitable firms defend what they have, so change needs one vision of the new whole and constant persuasion. Ch. 21 · Profile: Lea Hickman of Adobe
  • In 2011 Adobe's Creative Suite earned about $2 billion a year, roughly half of company revenue. Lea Hickman moved it to subscriptions. Creative Cloud passed $1 billion in recurring revenue faster than anyone had, and Adobe's market cap more than tripled to roughly $60 billion.

Care deeply about the problem, not about the answer.

Marty Cagan, Principles of Product Vision

1Feature roadmaps fail because most ideas don't work

Feature roadmaps fail because they lock teams into ideas that mostly won't work, inside a waterfall chain that tests nothing until the end.

• Engineering quality says nothing about whether anyone wants the product. PART I: Lessons from Top Tech Companies
  • The questions that matter come first: who decides what to build, how they decide, and how they know it will be useful.
  • At HP, a product manager sitting in marketing defined the products, and HP was not good at product management.
  • The HP AI workstation team checked every box of a good launch. It met HP's strict quality standards, internationalized and localized the product, and trained the sales force. Cagan was a young software engineer on that team.
  • The gap between the state of the art and the state of the practice is wide. Academia, top business schools included, and industry bodies still teach the failed models of the past.
• Most companies run a waterfall and call it Agile. Ch. 6 · The Root Causes of Failed Product Efforts
  • The chain runs: ideas, business case, quarterly or annual planning into a roadmap, requirements, design, one to three Scrum sprints, QA, deploy.
  • Business cases rank ideas on numbers nobody can know yet. Value depends on how good the solution turns out, and cost depends on a solution that doesn't exist. This is the business case game.
  • Engineers pushed to estimate anyway fall back on t-shirt sizing.
  • The chain creates ten problems. Sales-driven specials leave teams as mercenaries. Product management shrinks to gathering requirements. Design arrives too late and can only put lipstick on the pig.
  • Engineers used only to code give about half their value, though they are usually the best single source of innovation. Agile confined to delivery yields maybe 20 percent of its value.
  • Funding projects creates orphaned projects that ship and miss their goals: Projects are output and product is all about outcome. All risk sits at the end, and the biggest loss is opportunity cost, which can't be recovered.
  • Business cases are not bad in themselves. They fit ideas that need a larger investment. The flaw is using them this early to rank a roadmap.
• Ideas fail in four distinct ways, and even the good ones need several iterations. Ch. 22 · The Problems with Product Roadmaps
  • Value: customers aren't excited and don't buy. This is the most common failure.
  • Usability: customers try it and find it too complicated to bother with. Feasibility: it costs far more to build than expected. Viability: legal, financial or business limits block launch.
  • The lag before a working idea pays off is called time to money.
  • The best teams assume at least three quarters of ideas will not perform as hoped. That is stricter than the baseline.
  • A/B tests show many ideas earn literally nothing.
  • Weak teams grind through the assigned roadmap. They blame the requesting stakeholder when a feature fails, then schedule a redesign. They succeed only if time, money and management patience last.
• Management's reasons for roadmaps are sound, but the label turns ideas into promises. Ch. 22 · The Problems with Product Roadmaps
  • Leaders want the highest-value work done first. They also want dates to time marketing programs, sales hiring and partner dependencies.
  • Stakeholder-driven roadmaps arise because the product organization can't staff every demand, so management referees.
  • A list of ideas harms nothing. Calling it a roadmap is what turns each item into a commitment, and disclaimers don't stop that reading.
  • Roadmaps run quarterly, on a rolling three months, or yearly. They skip bugs and optimizations but carry features, projects and multi-team initiatives with dates. All of it is output.
• Lean and Agile are real progress, but they are not silver bullets. Ch. 7 · Beyond Lean and Agile
  • Some self-described Lean teams spend months on an "MVP" before learning whether it sells. Others try to validate everything and get nowhere.
  • The strongest teams tackle risks up front, design together rather than in sequence, and solve problems instead of shipping features.
  • Disappointment with results has made criticizing Lean and Agile fashionable. Yet their core principles are lasting progress, and going backward would be a mistake.
  • In the sequential model, each role lives within the constraints set by the one before. Strong teams replace that with give and take among product, design and engineering.
  • No prescriptive recipe exists. Results come from the right culture plus a broad toolkit of discovery and delivery techniques, each matched to the problem.

2Give a durable cross-functional team a problem, not a feature list

Products get built well when a stable team of product, design and engineering owns a problem and its results, and the product manager leads through knowledge rather than authority.

• Strong product companies run on durable, co-located, cross-functional teams that each own a slice of the product and its results. Ch. 9 · Principles of Strong Product Teams
  • A team is a product manager, a product designer and two to about 10 to 12 engineers. Critical mass is one PM, one designer and two engineers.
  • Each team owns a meaningful piece. At eBay that might be fraud prevention or tools for high-volume sellers. At Facebook it might be the newsfeed or the iOS app.
  • Teams get objectives, choose how to meet them, and answer for the results. The PM is the boss of no one, and members keep reporting to their functional managers.
  • Shared roles round out the team: a product marketing manager, a user researcher, a data analyst and test automation engineers.
  • The aim comes from John Doerr: We need teams of missionaries, not teams of mercenaries. A team formed for a few months and then disbanded can hardly get there.
  • Co-located means close enough to see each other's screens. The same building or floor is not enough. All else equal, a co-located team substantially outperforms a dispersed one. Employees are preferred to contractors because they stay on the team longer.
  • Autonomy means solving the assigned problem the team's own way. It does not mean picking whatever looks fun. The team owns every kind of work in its area, including bugs, performance and content changes, and it is not done at launch.
  • Missing shared roles still have owners. The designer takes on user research, the PM digs into the data, and engineers write the automated tests. A setup where only the PM checks quality is unacceptable, because acceptance testing cannot support a confident release.
• The product manager earns the right to decide what gets built through deep knowledge, not through title. Ch. 10 · The Product Manager
  • That knowledge comes in four kinds: customers, data, the business and its stakeholders, and the market and industry.
  • Knowing the data means about 30 minutes each morning in the analytics.
  • Three models fail. The backlog administrator escalates everything to the CEO. The roadmap administrator lets stakeholders fight it out. The third is the project manager or business analyst renamed during an Agile rollout.
  • The morning review covers the last 24 hours of sales and usage analytics, plus A/B test results. A data analyst can help, but the PM cannot hand off the understanding.
  • The six featured PMs, from Google, Adobe, the BBC, Microsoft, Netflix and Apple, hold no MBAs. Their winning solutions came from working with design and engineering. Users had no idea those solutions were possible.
  • Success belongs to the whole team, and failure belongs to the PM. Few people do the job well in under 60 hours a week. The PM must also be the product owner, because splitting the two roles costs the team its ability to innovate.
  • A new PM needs two to three months to ramp up, with access to customers, data, tool training and stakeholders. Two courses matter: intro programming in any language except HTML, and intro business accounting or finance.
• A trained product designer is a full partner in discovery, judged on product success, not a service that decorates specs. Ch. 11 · The Product Designer
  • In strong teams, design shapes the functionality at least as much as the functionality shapes the design.
  • Design is table stakes for consumer products and a differentiator in B2B. Most business products long got away with poor design because the user is often not the buyer.
  • Companies that hire designers and run them as an internal agency get no more than an outside agency would give.
  • User experience covers every touch point over time. That includes email, marketing, sales and support, and offline service such as the ride booked through Uber or the house found through Airbnb.
  • Designers test with real users every week, and they check value as well as usability. They need some skill in both interaction and visual design. This matters most on mobile, where the two are intertwined.
  • The PM has five habits to keep. Seat the designer next to you. Include them from the start of every idea. Bring them to customer contact. Hold back your own design ideas. Do not nitpick early versions.
  • Without a designer, two failures are common. The PM draws wireframes and engineers improvise the visuals. Or engineers invent the design from bare user stories. In small business products the user is usually the buyer, so the design bar there matches consumer products.
• The relationship with the engineers matters more than any other the product manager has. Ch. 12 · The Engineers
  • The PM shares customer pain, data and business constraints openly, then works out solutions with the team.
  • How to build belongs to the engineers. They dislike being told how as much as PMs dislike stakeholders dictating what to build.
  • The PM talks with engineers every workday and works closest with a tech lead who joins discovery.
  • Daily talks come in two kinds. One asks for ideas on discovery items. The other answers clarifying questions on delivery items.
  • Engineers are skeptical, so bluffing fails. Saying "I don't know" and following up works. A PM without an engineering background should take a programming class, to collaborate better and not to direct the code.
  • Engineers deserve latitude on solutions because they get the call in the middle of the night when things break. Shielding them from customer and business problems lowers their morale. It does not protect them.
  • Not every engineer needs to do discovery, even senior ones. A team where no engineer wants to is not acceptable.
• If the company is not organized this way, fixing that comes first, and a volunteer pilot team is the way in. Ch. 59 · Pilot Team Technique
  • Everything else depends on the team model.
  • One team volunteers to work the new way for a quarter or two. It is judged on business outcomes, against other teams or against its own past results.
  • A pilot that succeeds pulls other teams in. A mandate pushed on everyone at once invites resistance.
  • People inside a company accept change at different speeds, just as customers adopt products at different speeds. Some love change and some wait to see others succeed. A few change only when forced, and they may sabotage a company-wide rollout.
  • Set the pilot up to win. Pick people open to change. Keep key members co-located. Limit the team's dependence on teams still working the old way.
  • The comparison will be qualitative rather than a controlled test, yet it can still persuade. If the pilot fails, drop the technique or adjust it and try again.

3Steer teams with vision, strategy and outcome objectives instead of roadmaps

Empowered teams make good decisions only when leaders give them business context: one shared vision, a focused strategy and measurable objectives, in place of a feature list.

• Leaders still set priorities, but they rank business results instead of product ideas. Ch. 23 · The Alternative to Roadmaps
  • Any replacement must serve the two reasons roadmaps exist: work on the most valuable things first, and dates the business can plan around.
  • Each team gets the vision and strategy plus its own prioritized objectives with measurable key results. The team picks and iterates on the solution.
  • Shipping is not the finish line. If a feature does not move the key results, the team tries another approach.
  • Dates come from rare high-integrity commitments that the rest of the company can fully rely on.
  • Steps for a high-integrity commitment: ask stakeholders for a short discovery window. Validate value and usability with customers, feasibility with engineers and viability with stakeholders. Only then commit to a date and the expected business results.
  • Delivery managers set the date, not engineer estimates alone, because a team may be busy for a month before it can start. They also track the commitments and dependencies through to delivery.
  • Commitments cause grief because they come too early. Teams promise before knowing whether they can deliver or whether the result will solve the customer's problem.
  • Outcome-based roadmaps, which list problems instead of features, are roughly equal to an OKR system. Their risk is a deadline on every item, which hurts motivation. Put dates only where a real constraint exists.
• One inspiring vision and one focused strategy give every team the same destination. Ch. 24 · Product Vision and Product Strategy
  • The vision describes the future two to five years out, or five to 10 for hardware. It is a storyboard, narrative or visiontype meant to persuade, not a spec.
  • Teams do not get their own visions. The organization has one, and every team contributes to it.
  • Strategy is a sequence of product/market fits, one target market at a time, split by vertical, persona, geography or milestone.
  • Product principles settle recurring tradeoffs ahead of time, so teams stop reopening the same debates.
  • A vision that fits in six months to a year is too small to inspire. Disrupt your own business before a rival does. Dropping the vision itself usually signals a weak product organization. Changing the route to it is normal.
  • Markets are ranked by TAM, GTM and TTM. A smaller market that fits existing sales channels, or can be reached sooner, can beat a bigger one. The heads of product, technology and product marketing decide together.
  • Most of eBay's revenue came from sellers. Yet sellers loved eBay because it brought them buyers. So the principle became buyer first when needs conflict, and it resolved many design questions on its own.
  • Companies facing a serious competitor often panic and chase the rival's moves. Strategy should stay on customers: Customers rarely leave us for our competitors. They leave us because we stop taking care of them.
• OKRs work when cross-functional teams own them and they measure business results. Ch. 28 · The OKR Technique
  • Managing by objectives instead of by control runs from HP through Intel to Google.
  • Objectives are qualitative. Key results measure business results, not output or tasks. Use one to three of each.
  • Normal key results aim for a 0.7 score. High-integrity commitments are scored binary: delivered or not.
  • Functional departments should not issue separate OKRs to people who sit on product teams.
  • Dave Packard said no tool did more for HP than MBO. Andy Grove refined it at Intel. John Doerr took it to a young Google, and Larry Page later credited OKRs for Google's success.
  • Common scale: 0 for no progress, 0.3 for the bare minimum, 0.7 for what the team hoped, 1.0 for exceptional. Organization OKRs are typically annual and team OKRs quarterly. Teams propose their key results, track them weekly, and hold a retrospective after a substantial miss.
  • When engineers must re-platform, designers go responsive and QA retools, the same people also owe the team's goal of cutting acquisition cost. The business problem goes unsolved. Leadership should rank such goals against business objectives and fold the chosen ones into a specific team's objectives.
  • Picture two company objectives, customer lifetime value and global expansion, across about 25 teams. The heads of product, technology and design assign teams to each, coordinate platform teams, then reconcile proposed key results and cover gaps by adding teams or reprioritizing.
• Context only steers teams if it is sold over and over. Ch. 31 · Product Evangelism
  • PMs aim evangelism mostly at their own team. They use prototypes instead of piles of user stories, take engineers on customer visits, and share learnings and credit.
  • In a growing company, the head of product reports big discovery learnings at the all-hands every week or two.
  • Evidence from small experiments lets even an individual contributor sell a new vision.
  • A roadmap-dependent organization can be shifted slowly by tying each item to its outcome.
  • A demo is a persuasive tool, not training and not a test. A PM who is not excited should change projects or roles. A PM with a remote team should visit it at least every couple of months.
  • The all-hands update runs 15 to 30 minutes and is given by the VP product, not by each PM. It covers what worked, what failed and what comes next. Failures matter most, since listeners sometimes explain them.
  • At the BBC in 2003, Alex Pressland saw that city-center video billboards were showing home TV programming. She ran tailored-content experiments, measured reach and engagement, and worked through editorial and legal licensing resistance. Then she pitched "BBC Out of Home." It became the base for BBC mobile, now used by more than 50 million people weekly.
  • Keep the roadmap for six to 12 months. For an item like adding PayPal, show the current conversion rate and the target, then report the actual impact after launch. Celebrate wins. Call a miss a shipped feature that failed, with the lessons learned and the next ideas to try.

4Discover before you deliver: test the four risks with cheap prototypes

Strong teams run discovery and delivery side by side, using the cheapest prototype that fits each risk, so production engineering is spent only on ideas with evidence behind them.

• Discovery and delivery are two parallel tracks, and each keeps its own high bar. Product Discovery
  • Discovery produces a validated product backlog. Delivery builds a true product: scalable, tested, instrumented, localized where needed, maintainable, on brand and releasable with confidence.
  • Product managers and designers spend most of their time in discovery. They still give engineers 30 to 60 minutes a day for delivery questions.
  • Customers and executives can't say what to build. They don't know what technology makes possible, so the team owns solving the underlying problem.
  • Cagan has pushed one team to reach customers faster. Minutes later he pushed the same team never to cut corners on secure, fault-tolerant, high-performance software. Fast learning and confident release are both required, not traded.
  • Engineers belong in discovery from the start. If the first time your developers see an idea is at sprint planning, you have failed.
  • Ethics is sometimes a fifth risk: should we build it? The harm is rarely illegal. It shows up as a side effect of chasing engagement, growth or monetization. Learn how the business makes money first, then raise the concern with possible fixes, not as the company's police.
  • Early startups with no customers don't face this tension. Production-quality work is likely premature for them.
• An MVP should be a prototype, and product means far more than features. Ch. 8 · Key Concepts
  • Most teams that worked hard on an MVP could have learned the same thing in days or hours, not months.
  • Product includes technology, design, monetization, acquisition and offline experiences. For a store it is everything except the merchandise. For a media company it is everything except the content.
  • Sales and marketing leaders were often confused and embarrassed by what those teams asked customers to buy. The P in MVP suggests a product, and that causes the waste.
  • Frank Robinson coined the term in 2001. Cagan covered it in the 2008 first edition, and Eric Ries popularized it in The Lean Startup in 2011.
  • A discovery iteration means trying at least one new idea or approach. Many never leave the product manager, designer and tech lead, because building a prototype exposes problems by itself. The weekly benchmark assumes a team already skilled at modern techniques.
• Each prototype type answers a different risk, and using the wrong one misleads. Ch. 47 · User Prototype Technique
  • Feasibility prototypes are throwaway engineer code with no UI or error handling. They usually take a day or two.
  • User prototypes are pure façade, from interactive wireframes to near-real screens. They cannot prove value or sales.
  • Live-data prototypes cost about 5 to 10 percent of productization. They send limited real traffic to a few use cases.
  • Hybrids borrow parts. A Wizard of Oz pairs a realistic front end with a person doing the work.
  • In a prototype bike store, every mountain bike search returns the same fixed bikes. That rules out testing relevance, but it serves well for shaping the shopping flow. When 10 or 15 people say they love a high-fidelity prototype, nothing is validated, because people act differently than they talk.
  • A live-data prototype is not shippable. The product manager must never tell engineers it is good enough. Brief executives on its limits and budget full delivery if it succeeds.
  • For 24-hour chat help, the team first learned common questions from service staff. Then a teammate secretly typed replies behind a simple chat window. Automated responses came in later. A search relevance team used live data with no live traffic and learned by watching users react.
  • A prototype can serve as the spec. Remote engineers or complex products also need use cases, business rules and acceptance criteria.
• Validate only the risks an idea actually carries, and give engineers time to judge feasibility. Ch. 55 · Testing Feasibility
  • Many ideas carry little risk, or risk in one area such as a legal privacy concern. Engineers own feasibility tests and designers own usability tests.
  • Demanding estimates on the spot in planning gets a conservative answer meant partly to end the conversation. Ask instead what the best way is and how long it would take.
  • Hardware cannot be patched cheaply, so the confidence bar rises before manufacturing.
  • Ideas that need investigation are often the best ones. Many teams are now evaluating machine learning, weighing build versus buy and fit. That can take far longer than a day or two.
  • Engineers estimate the prototype time. The product manager decides whether the idea is worth it or a lower-risk approach wins.
  • Gross delivery underestimates come from inexperienced estimators, shallow shared understanding, or too little time to investigate.
  • Hardware teams analyze parts, manufacturing cost and forecasts in depth. 3D printing has made device prototypes much easier.

5Frame the problem and source ideas from customers, not requests

Discovery starts by framing the problem and its real risks, then draws ideas from direct contact with customers rather than from requests stacked on a roadmap.

• Framing aligns the team on the problem and exposes the risks it would rather avoid. Discovery Framing Techniques
  • The team agrees on four things: the business objective, the customer problem, who has it, and how success is measured. Each ties to the team's OKRs.
  • Teams drift toward comfortable risks, such as performance, scale or complex workflows. Value and business risk are harder and matter more.
  • If the product manager, designer and tech lead see no significant risk, the work goes straight to delivery.
  • Founders often spend months or years on one solution before they find the money and nerve to pursue it. They end up attached to that solution. Yet first solutions rarely solve the problem in a way that can power a business.
  • Each roadmap item is someone's guess at a solution. A legitimate problem probably sits behind it. The team's job is to dig that problem out and make sure what ships solves it.
  • Business risk has six parts. Can the company afford it? Does it work for partners and fit the brand? Can sales sell it? Is it legal? Should the company do it at all? Most efforts raise none of these, but any that does gets tackled hard.
  • Skipping validation means the team will sometimes be wrong. That costs less than testing every assumption. Discovery time goes where risk is significant or where team members disagree.
• Most work needs four short written answers, while big multi-goal efforts need an imagined happy customer. Ch. 35 · Opportunity Assessment Technique
  • An opportunity assessment names the business objective, the key results that define success, the customer problem and the target market.
  • The product manager writes it in a few minutes. It goes to the team and key stakeholders before discovery begins.
  • A redesign with several objectives gets a pretend press release or a customer letter instead. Either one is written as if the product had already launched.
  • Success has to be defined up front. A 1 percent drop in churn could be excellent or a waste of time, depending on what was expected.
  • The target can be a persona, a market or a job to be done. So much product work fails because it tries to please everyone and ends up pleasing no one. Work for internal users is labelled as such and linked back to end customers.
  • Amazon's working-backward press release describes customer benefits and includes a customer quote. If the team and leadership don't see the value, the PM has more work to do. It only tests colleagues, so it counts as framing, not demand validation.
  • Walker Lockhart, a long-time Amazonian, brought a variation refined at Nordstrom. A well-defined persona writes a grateful letter to the CEO, and the CEO writes back to the team about the business impact. Cagan prefers the letter for two reasons. Fewer people know the press release format now, and the letter builds empathy for the customer's current pain.
• A new business lists its risks on a startup canvas, then attacks value risk before anything else. Ch. 37 · Startup Canvas Technique
  • The canvas replaces the thick business plan. It covers value proposition, monetization, distribution, costs, metrics and market size.
  • People chase the risks they feel they control. So teams polish the canvas and keep postponing the real work of finding a solution people will buy.
  • Customers switch only to something substantially better. Feature parity is not enough.
  • A typical founder with an MBA fixates on value proposition, pricing, channels and costs. Cagan often has to tell such founders that at this stage these concerns are largely academic. Startups mostly fail because they never find a solution customers want.
  • Canvases leave the solution out on purpose, to avoid early lock-in. The side effect is that teams start treating the solution as the engineers' job.
  • Market risk is real but rarely the biggest one. Most teams tackle old problems in proven markets with newly possible technology. If a market truly is new, demand tests are cheap, so skipping them is inexcusable.
  • For an existing product, the canvas mostly repeats what is already known. It still helps a new product manager see the whole business her product touches.
• Teams that are handed problems and meet users every week rarely run short of good ideas. Ch. 41 · Customer Interviews
  • Feature requests from big customers, prospects, stakeholders and executives are rarely high-quality ideas.
  • Interviews take at least two to three hours every week, with the PM present. They answer four questions. Are customers who you think they are? Do they have the problem? How do they solve it today? What would make them switch?
  • In a concierge test, the team does the customer's job by hand.
  • Unplanned uses by customers and developers point to new opportunities. Directed hack days pull engineers into ideation.
  • Each interview asks for about an hour, ideally where the customer works. Video is worse but beats skipping it. The designer leads, the PM takes notes and a rotating engineer observes. Questions focus on what people do today, not what they wish for. Afterward the team debriefs together and keeps any promises made.
  • A concierge test works like a hotel concierge who gets theater tickets for a guest. The customer may need to train the team first. Shadowing customer service is a different thing, because that work starts only after a problem is reported.
  • Concert tickets, fine art and cars all ended up in "Everything Else," the general category on eBay. Only once the demand was clear did eBay add real support for cars. It now ranks among the biggest used car companies on the planet. Facebook went the developer way instead. It used its platform to open up its social graph.
  • A directed hack day starts from a given problem, such as churn or customer lifetime value. People form their own groups, and each group builds a prototype that can be evaluated. Where it makes sense, the groups test those prototypes on real users.
• A one-week discovery sprint gives teams new to discovery a proven recipe. Ch. 58 · Discovery Sprint Technique
  • The sprint targets one big problem and explores dozens of ideas. It always ends with a high-fidelity prototype in front of real target users.
  • It fits when the problem is big, when the team is learning discovery, or when work moves too slowly.
  • A discovery coach with real PM or design experience can guide it. Most Agile coaches know only delivery.
  • A story map lays user activities across the top and tasks and stories below. Release lines are drawn across it.
  • GV's design team spent about a week with each startup GV invested in. Startups valued that help more than the money. After more than 100 teams, the team wrote Sprint, by Jake Knapp, John Zeratsky and Braden Kowitz.
  • The sprint runs in six steps. Map the problem space. Pick the problem and the target customer. Pursue several approaches. Narrow them and flesh them out. Build a high-fidelity prototype. Watch real users react to it.
  • It is called a discovery sprint, not a design sprint, because the work goes well beyond design. It also helps companies that struggle to get value from the MVP concept.
  • Jeff Patton built story maps out of frustration with flat backlogs that had no context. Critical tasks sit above optional ones. The map changes with each round of prototype feedback. When delivery starts, its stories move into the backlog.

6Prove value with real behavior and six reference customers

Value is the hardest risk to retire, so teams spend most of their testing time on it and trust what users do over what they say.

• Test value first, because nothing else matters if customers will not choose the product. Ch. 51 · Testing Value
  • Teams test value and usability together, with the same users in the same sessions. Feasibility goes to engineers next, and viability goes to the business last.
  • Customers are almost always switching from something, even a homegrown tool. Matching competitors feature for feature does not win them, even at a lower price.
  • The product must look substantially better, enough to justify the purchase and a painful migration.
  • Usability often has to be solved inside the session first. Users cannot see value in something they cannot work out.
  • Legal, sales and the CEO see an idea last, so the organization is not stirred up over ideas that may not survive. This order is a common logic, not a rule.
  • Value has three testable parts: demand, qualitative reaction and quantitative efficacy. Efficacy is objective in ad tech, where a team can compare revenue against rival ad tools. In games it is much harder to measure.
  • In existing markets demand is usually already proven. The real question there is whether the solution clearly beats the alternatives.
• A value test works only after users learn the product, and only when their praise costs them something. Ch. 53 · Qualitative Value Testing Techniques
  • Each session runs a short interview, then a usability test on a high-fidelity prototype, then the value test. Without the usability step it becomes a focus group about an imagined product.
  • Usability work covers primary tasks, such as setting an alarm and hitting snooze in an alarm app. Users stay in use mode, not critique mode.
  • People are polite, so users pay with money, reputation, time or access.
  • Teams run at least two or three of these a week.
  • Money: ask whether they would pay, and watch for a credit card offered on the spot, but never take the details. For expensive business products, ask for a signed non-binding letter of intent.
  • Reputation: ask for a 0 to 10 recommendation score, or a boss's email that is never saved. Access: ask for login credentials to the old product for a supposed migration utility, then discard them. Time: ask for significant working sessions.
  • Tests often happen at a small coffee shop table, known as Starbucks testing. The tester stays silent and acts like a parrot, reflecting questions back instead of helping or praising. The prototype gets fixed mid-round as soon as a problem shows.
  • Sharply different reactions between two users get investigated. Shelving an idea that cannot win interest is a valid outcome. As product manager, you need to make sure you are at every single qualitative value test. Do not delegate this.
• Demand tests check interest before a costly build, though demand is rarely what sinks a product. Ch. 52 · Demand Testing Techniques
  • A fake door puts a real-looking button where the feature would live. A click leads to a page asking volunteers to talk.
  • A landing page test does the same for a whole product, pitched as if it were launching.
  • Most products get trial signups. They fail because users are not excited enough to switch.
  • A typical trigger: a large customer, a competitor or the CEO wants a feature that engineers call substantial. A fake door measures real interest first, and its click rate is compared with expectations or with other features.
  • No sign of the test may appear before the click, or the data is invalid. The volunteers become recruits for follow-up discovery.
  • Innovation should not go to a protected lab, because existing teams resist what it learns. At Apple, Amazon, Google, Facebook and Netflix, every product team owns it.
  • Large firms protect revenue and brand with limited exposure, invite-only tests or customers under NDA. They protect staff and customers with gentle deployment, customer impact assessment and continuous deployment.
• Quantitative tests supply evidence of behavior, and no feature should ship without analytics. Ch. 54 · Quantitative Value Testing Techniques
  • The technique depends on traffic, time and risk tolerance.
  • A discovery A/B test shows a live-data prototype to 1 percent of users or less. Users cannot tell which version they see.
  • Low traffic or a risk-averse company calls for invite-only tests. Numbers show what happens, never why, so a qualitative test follows.
  • Discovery A/B tests need closer watching than optimization tests of button colors, which usually split 50:50.
  • Invite-only data predicts less well, because opt-in users lean toward early adopters. For business products, discovery program customers are the main usage source, compared against the wider base.
  • Behavior data is not new. Desktop and server software called home a full decade before the web, and even firewalled customers can send approved periodic reports.
  • Data should be anonymized and aggregated. Without it, decisions go to the most senior opinion, and removing dead features becomes painful.
• Business products reach fit by building reference customers alongside the product, before sales turns on. Ch. 39 · Customer Discovery Program Technique
  • Startups race to fit before the money runs out, so until then the product is all that matters.
  • A reference customer is real, runs the product in production, paid for it, and freely says they love it.
  • Members pay nothing up front, only after they love the product. The program caps at eight, and other eager customers go into an early release program.
  • Members hear that the company is building a general product, not a custom one. The team seeks one solution for all six instead of merging their requests, and it screens out technologists. Cash-poor startups may use escrow.
  • Markets come in sequence: six references in financial services, then manufacturing. Or the United States, then Germany, then Brazil.
  • API products aim for reference applications. An internal agent dashboard uses well-respected agents who later tell colleagues they love it.
  • Consumer products work with 10 to 50 users, plus broad testing on newcomers. The Sean Ellis survey asks recent users who reached the core value how they would feel if they lost the product.

7Treat every stakeholder objection as a design constraint

A product customers love still fails if it breaks a business constraint, so the product manager learns every constraint early and designs a solution that satisfies it.

• Being CEO of the product means knowing every business constraint before anything is built, and a blocked launch is the product manager's failure. Ch. 56 · Testing Business Viability
  • Viability means four things. Costs to make, market and sell sit well below revenue. The product is legal in every country of sale. It honors partner deals. It fits the brand promise.
  • The areas to check are marketing, sales, customer success, finance, legal, business development and security, plus any stakeholder unique to the company.
  • The CEO, COO or GM already worries about all of these. They quickly spot a product manager who skipped the homework.
  • Sales channels limit what can succeed. A costly direct sales force needs a high-value, high-price product. It may also reject a product that needs skills it lacks.
  • Finance work means modeling costs with someone in finance, so leadership can see the approach is viable. Legal gets an early meeting on privacy, compliance, IP and competitive issues. For security, the product manager brings the tech lead to meet security leadership.
  • Partner contracts can cripple competitiveness or turn into a big win, so the product manager reads them. A product must also match the customer success model, high touch or low touch.
• Stakeholders allow unfamiliar solutions only when they trust the product manager's competence and see the real thing early and in private. Ch. 61 · Managing Stakeholders
  • A stakeholder is someone who can veto the work or block its launch. Everyone else is community input.
  • Spend about half an hour one on one with each key stakeholder, two to three hours a week in total. Listen, ask questions, and share what you learn.
  • Preview a high-fidelity prototype privately during discovery, before the work reaches the backlog. Slides are too vague for a lawyer or a marketer to judge, and group reviews turn into design by committee.
  • Executives who approve a slide deck are often shocked and visibly angry when they later see the actual product. A sign-off on anything less than a high-fidelity prototype is not a real sign-off.
  • When it comes down to the product manager's opinion against a senior stakeholder's, the stakeholder usually wins. A quick discovery test turns the argument into one about data, and sometimes neither opinion holds up.
  • Name the mode before showing a prototype. In a user test, users drive. In a demo, the presenter drives to sell. In a walkthrough, the stakeholder sees everything and nothing is hidden. Rookie errors include running a walkthrough when a demo was needed, and demoing during a user test and then asking for opinions.
  • Some stakeholders do not understand the product role or feel threatened by it. The product manager may first have to explain how a technology product company works.
• Top-level backing does not move a stalled product, but resolving each group's specific concern does. Ch. 15 · Profile: Jane Manning of Google
  • AdWords had Larry Page behind the core idea, yet sales and engineering still resisted.
  • Manning sorted the objections into types: discomfort with advertising, cannibalization of ads sales already sold, and harm to users.
  • Winning over Georges Harik, a respected early engineer, brought other engineers along.
  • Manning was a young engineering manager asked to act as product manager. Sales was led by Omid Kordestani.
  • The engineers' concern for relevance was treated as legitimate. Ranking by performance meant poor ads rarely or never showed, even when they paid more.
  • She led discovery, wrote the first spec, and built and launched the product alongside the engineers. There are always so many good reasons for products not to get built.
• When a business model appeals to customers but breaks the economics, product technology can make it viable. Ch. 57 · Profile: Kate Arnold of Netflix
  • In 1999 Netflix was stuck at about 300,000 customers. Rentals by mail were not better enough than a trip to Blockbuster.
  • A monthly unlimited subscription tested well. But everyone wanted expensive new releases, and stocking them would drain cash.
  • Kate Arnold's team built the queue, ratings and recommendations to steer demand toward a mix of costly and cheap titles.
  • Netflix had fewer than 20 employees in Los Gatos. The team redesigned the site and rewrote billing in about three months, coordinated through daily standups that included nearly the whole company.
  • The subscription launched before the new billing system was ready. The 30-day free trial meant no one had to be billed right away, which bought the needed time.
  • That service powered the business for seven more years, until Netflix disrupted itself with streaming. Earlier, short of cash, Netflix had offered itself to Blockbuster for $50 million and was turned down. Netflix is now worth more than $40 billion.
  • Arnold credits the team, strong engineers and the founders. Cagan's own judgement is that without her push for technology-based solutions, Netflix as known today might not exist.
• Internal efficiency goals and partner deals count only if the customer experience survives them. Ch. 40 · Profile: Martina Lauchengco of Microsoft
  • In 1993 Microsoft converged the Windows, DOS and Mac code for Word 6.0. On regular Macs, the release took two minutes just to start.
  • Martina Lauchengco's 6.1 fix targeted what Mac users felt: speed, native keyboard shortcuts and a fast word count.
  • At Apple, Camille Hearst hid trending and popular iTunes charts for American Idol, because song sales would likely predict the vote (Ch. 63).
  • The Mac market was $60 million, against more than $1 billion for Windows. The team developed on fast new PowerMacs, unlike most customers. Bill Gates forwarded hate mail with a note that the problem was depressing the stock price.
  • Mac users had many more fonts, so font loading was reworked. The press checked word count about 10 times a day as its speed yardstick. Version 6.1 ended up faster than Windows. Within a couple of months it went to every registered user with a signed apology and a discount coupon.
  • Microsoft later diverged the code again and gave the Mac team its own buildings and business units. Today more than 1 billion Macs and PCs run Office.
  • In 2008 American Idol drew more than 25 million viewers twice a week. Eddy Cue made the deal, and Hearst owned the integrations. Her team aimed at one persona and made iTunes easy to reach for fans without the app. The work fed a business of roughly $20 billion in 2014.

8Scale without losing innovation: leaders, structure and culture

Companies keep innovating as they grow only when senior people hold the whole product together, teams are shaped around architecture, and culture is guarded against protective process and imported habits.

• Growth strains every part of a company, and an enterprise that only optimizes what it has drifts into a slow death spiral. Ch. 5 · Enterprise Companies: Consistent Product Innovation
  • Growth-stage firms have about 25 to several hundred engineers. Their teams lose the big picture, the first product's go-to-market misfits new products, and engineers talk about technical debt everywhere.
  • In enterprises, stakeholders protecting the core block new ventures. The symptoms are low morale, slow delivery and design by committee.
  • Tweaking existing products is value capture, not innovation. The decline is slow and unintended. A big company can stay afloat for years before a nearly certain end.
  • Frustrated leaders reach for acquisitions or separate innovation centers, which rarely deliver. Adobe, Amazon, Apple, Facebook, Google and Netflix escaped the spiral, but only through big changes, not small fixes.
  • At Adobe each function had a valid fear. Finance feared the dip from licenses to subscriptions. Engineering faced a jump from a two-year release train to continuous deployment. Sales feared leaving a reseller channel that would not forgive failure.
  • Lea Hickman built prototypes with then-CTO Kevin Lynch to rally executives, then kept feeding stakeholders new ones. To her, over-communication did not exist. The shift covered 15 major apps across desktop, tablet and mobile, and now has more than 9 million subscribers.
• Someone senior must own the whole product in business, experience and technology, or it fragments across teams. Ch. 16 · The Role of Leadership
  • A head of product or principal product manager owns the business view. A design leader or principal designer owns experience. The CTO and architects own technology.
  • The head of product's top duty is developing PMs and designers. The role must complement the CEO, not mirror her.
  • The CTO has six ranked duties, from building the organization down to evangelism. Technology reporting to a CIO is a warning sign.
  • Delivery managers, who clear impediments, matter more once there are roughly 5 to 10 teams.
  • Symptoms point to the gap. A product that looks built by half a dozen outside agencies lacks a design lead. PMs asking engineers to read code lack a principal PM. Spaghetti code means weak technical oversight. Documentation never replaces these people.
  • When a CEO with big ideas hires another person with big ideas, the two fight and people keep leaving. When a CEO without big ideas hires someone just like herself, everyone gets along but no one sets a direction. The hiring process should include a long dinner with at least the CEO and the CTO.
  • A marketplace with about 10 teams split them into platform, buyer and seller groups under one VP product and three group product managers. The buyer-side GPM ran one team and coached the PMs of the other two, keeping the buyer side seamless.
  • A delivery manager's day: chasing a marketing approval, getting another team's delivery manager to prioritize a dependency, and persuading a designer to make assets a front-end developer needs.
• No team structure is right for every company, so leaders weigh principles and accept tradeoffs. Ch. 20 · Principles of Structuring Product Teams
  • Architecture is often the main principle, since it drives technologies, which drive skill sets. Ignoring it leaves teams fighting the architecture.
  • Fewer dependencies mean faster teams, so map them and keep cutting them. Review the structure about once a year.
  • The central tension is team autonomy against the leverage of a shared foundation.
  • If engineering has standardized on GitHub, one team's preference for another tool loses. The total cost to the organization would far outweigh the benefit.
  • Marketplaces give some teams buyers and others sellers so each learns one customer deeply. Platform teams, staffed by highly technical PMs, still provide the shared foundation.
  • The balance depends on whether teams are A, B or C teams, how much speed and integration matter, and how mature the technology is. Standardizing on an immature foundation builds a house of cards.
  • When teams keep making poor autonomy tradeoffs, the likely cause is missing business context, not inexperience.
• Process and hires brought in to protect assets are what usually stall innovation at scale. Process @ Scale
  • Formal process on expense reports only annoys. Formal process on how products are made can halt innovation, as 'Agile at Scale' frameworks do.
  • Leaders hired from companies weak at product bring their old practices, then hire people who like them.
  • Empowering teams moves power away from management, so the change is cultural and meets resistance.
  • A young company hires a head of product, engineering or marketing from Oracle, and the board is pleased. The leader assumes they were hired for their process and imports it. Strong people Oracle acquires rarely like its ways of building product.
  • New hires at Netflix, Airbnb and Facebook sense within days that they joined a different kind of company. That is deliberate protection.
  • When Cagan advises on such hires, he asks openly why the candidate's former company has not shipped a successful product in years. He stresses that their talent is wanted, not their old process. Candidates often say this is why they are leaving.
  • The slide from good to bad takes years and reaches every level from engineer to CEO. It is easy to prevent once leaders see it.
• When innovation or speed fades, check a short list of cultural causes before blaming people. Ch. 65 · Top Reasons for Loss of Innovation
  • Ten missing attributes explain lost innovation, from customer contact and corporate courage to a product mindset and time beyond keep-the-lights-on work.
  • Lost velocity usually traces to technical debt, weak PMs, no delivery management, rare releases, shifting priorities or a consensus culture.
  • Rate the company separately on innovation and on execution. Few are strong at both.
  • Jeff Bezos holds that customers stay dissatisfied even when happy, which drives a company to invent for them. Growing firms turn risk averse, yet The riskiest strategy of all is to stop taking risks.
  • Teams should release at least every two weeks, and very good teams release several times a day. Outsourcing firms that add a coordination layer usually make communication worse.
  • Amazon is strong at both innovation and execution, but strong execution makes a tough workplace. Many older firms are poor at both and survive on brand and customer base.
  • In a strong execution culture, missed commitments cost mainly reputation among peers. Firing is reserved for extreme, repeated cases.

9Put it to work

Teams stop accepting feature lists on faith and instead tie each item to a business result, talk to customers every week, and test risky ideas on prototypes before engineers build them.

1. Set up one durable, cross-functional team Seat a product manager, a product designer and two to about 10 to 12 engineers side by side. Keep them together long after any single project ends. Ch. 9 · Principles of Strong Product Teams
   • The product manager is the boss of no one on the team. Members keep reporting to their functional managers.
   • Teams formed for a few months and then disbanded rarely become missionaries.
2. Tie every roadmap item to the result it should move Keep the current roadmap running for six to 12 months. Each time an item comes up, show today's metric and the target. After launch, show the actual impact. Ch. 60 · Weaning an Organization Off Roadmaps
   • A team adding PayPal to raise conversion shows the current conversion rate and its goal. If the number doesn't move, it reports that the feature shipped but the result failed, and it names the next idea to try.
3. Write an opportunity assessment before any discovery Answer four questions: the business objective, the key results that mean success, the customer problem, and the target market. The product manager writes it in minutes and shares it with the team and key stakeholders. Ch. 35 · Opportunity Assessment Technique
   • Set the size of a win up front. A 1 percent drop in churn can be excellent or a waste of time, depending on what was expected.
   • Pick one primary beneficiary. Work aimed at everyone tends to please no one.
4. Book customer interviews every week Two to three hours a week is the floor. Bring the product manager, the designer and a rotating engineer. Learn who the customers are, what problem they have, how they solve it today, and what would make them switch. Ch. 41 · Customer Interviews
   • Interviews held without the product manager produce lessons nobody feels firsthand, so they get taken less seriously.
   • The designer usually leads, the product manager takes notes, and the engineer watches. All three debrief together right after.
5. Test value on a prototype before engineers build Run a short usability test on a high-fidelity prototype, then a value test right after it. Aim for at least two or three of these sessions every week. Ch. 53 · Qualitative Value Testing Techniques
   • People are polite, so praise proves little. Ask users to pay in money, reputation, time or access. For an expensive business product, that can mean a signed non-binding letter of intent.
   • If the team can't create interest or make the product usable enough, shelving the idea saves the build cost and the engineering time.
6. Walk each stakeholder through the prototype privately Find the people who can block a launch and learn their constraints. Show each of them a high-fidelity prototype one on one, during discovery, before the work reaches the backlog. Ch. 61 · Managing Stakeholders
   • Executives who approve from slides are often shocked and angry when they later see the real product.
   • When your opinion meets a more senior one, run a quick test and move the argument to data.
7. Commit to dates only after discovery Ask for a short stretch of discovery first. Validate the solution with customers, engineers and stakeholders, then promise a date and the business result. Keep these promises rare, and keep every one. Ch. 23 · The Alternative to Roadmaps
   • Commitments cause grief because they get made too early, before anyone knows whether the solution can be built or will work.
   • Delivery managers set the date. They count team availability and dependencies, not just build time.

10The book's words

A few terms carry most of these ideas: what teams test, how they think of themselves, and what they promise.

• Product discovery The work of separating good ideas from bad ones with cheap, fast experiments before any production code gets written.
  • It runs in parallel with delivery, and its output is a validated product backlog.
• The four risks Value, usability, feasibility and business viability: will customers buy it, can they use it, can the team build it, does it work for the business.
  • Value is the hardest risk and gets most discovery time. Ethics is sometimes a fifth risk: should we build it at all?
• Missionaries vs. mercenaries Missionaries believe in the vision and own the customer problem. Mercenaries build whatever they are told.
  • The phrase comes from venture capitalist John Doerr.
• Outcome vs. output Outcome is the business result a team achieves. Output is the features and projects it ships.
  • Typical roadmaps track output, which leads to orphaned projects that ship and still miss their objectives.
• High-integrity commitment A date or deliverable promised only after discovery has shown the solution works, so the rest of the company can rely on it.
  • In OKR scoring it counts as delivered or not, while ordinary key results aim for about 0.7.
• Minimum viable product (MVP) The smallest thing that yields the needed learning. It should be a prototype, never a product.
  • Frank Robinson coined the term in 2001. Eric Ries popularized it in The Lean Startup in 2011.
• Product/market fit The most basic real product that serves what one defined group of customers needs.
  • Marc Andreessen popularized it. A product strategy is a sequence of these fits, one target market at a time.
• Reference customer A real, paying customer who runs the product in production and sincerely tells others they love it.
  • Friends, family and trial users don't count.
• Fake door demand test A real-looking button for an unbuilt feature, placed where the feature would live, that measures how many people click.
  • The click leads to a page saying the feature is under study and inviting the user to leave contact details for a conversation.
• Feature parity Matching what competitors already offer.
  • Parity doesn't win customers, even at a lower price. Switching is painful, so a product must be substantially better.

11Chapter by chapter

Where each idea is in the book.

• Preface to the Second Edition The second edition is a full rewrite aimed at technology product managers. It goes beyond Lean and Agile and adds how to do product well at scale. Great products come from the right culture and a toolkit of discovery and delivery techniques, not from a fixed recipe.
• PART I: Lessons from Top Tech Companies A strong engineering team is wasted if it is not given something worth building. Most companies decide what to build badly, and the best product companies work in a very different way.
• Ch. 1 · Behind Every Great Product Behind each great product stands a person, often out of sight, who guided the team. This person helped blend technology and design to fix real customer problems, while also meeting the needs of the business. In most cases, that person is the product manager. The role is demanding and takes all of one's time. It is also distinct from design, engineering, marketing, and project management.
• Ch. 2 · Technology‐Powered Products and Services The focus here is only on products, services and experiences powered by technology. Most products are turning into tech-powered ones, and companies that miss this are being disrupted.
• Ch. 3 · Startups: Getting to Product/Marketing Fit A startup is a new product company that has not yet reached product/market fit, and it is racing to find a product that can power a viable business before its money runs out. Until it gets there, the product is the only thing that really matters.
• Ch. 4 · Growth‐Stage Companies: Scaling to Success Startups that reach product/market fit face a new and equally hard problem: growing and scaling. Growth brings more people and more products, but it also brings organizational stress that forces leaders and teams to change how they work.
• Ch. 5 · Enterprise Companies: Consistent Product Innovation Large tech companies must keep creating new value for customers and the business, not just optimize what they already have. Without consistent product innovation, enterprise companies drift into a slow death spiral, but they can avoid it by making big changes.
• Ch. 6 · The Root Causes of Failed Product Efforts Most companies build products through a waterfall chain: ideas, business cases, a roadmap, requirements, design, then build, test and deploy. This chain is the root cause of most failed product efforts, and the best teams work nothing like it.
• Ch. 7 · Beyond Lean and Agile Lean and Agile principles are real progress and here to stay, but they are not silver bullets. The best teams go past common practice by tackling risks up front, defining and designing products collaboratively, and focusing on solving problems rather than shipping features.
• Ch. 8 · Key Concepts Modern product teams work on two parallel tracks: discovery, which uses cheap prototypes to separate good ideas from bad, and delivery, which builds production-quality products aimed at product/market fit and, over time, the product vision. Product is defined holistically, and an MVP should be a prototype, not a product.
• Ch. 9 · Principles of Strong Product Teams Strong product companies organize around durable, cross-functional, co-located teams that are given problems to solve, the autonomy to solve them, and accountability for results. If a company is not set up this way, this is the most important thing to fix, because everything else depends on it.
• Ch. 10 · The Product Manager Strong product managers do the job themselves rather than escalating to the CEO or refereeing stakeholders, and they earn the right to decide what gets built by bringing four kinds of deep knowledge: customer, data, business, and market. The role is closest to a CEO without authority, so it needs among the strongest talent in the company.
• Ch. 11 · The Product Designer Product teams need a trained product designer as a full partner in discovery, not a service that decorates finished requirements. In strong teams, design shapes the functionality at least as much as functionality shapes the design.
• Ch. 12 · The Engineers The product manager's relationship with the engineers matters more than any other. It is built by bringing real product knowledge, sharing customer pain and business context openly, leaving the how to the engineers, and working most closely with a tech lead who takes part in discovery.
• Ch. 13 · Product Marketing Managers Product marketing managers speak for the market inside the product team. They own positioning, messaging and the plan for going to market. They are key partners through discovery, delivery and launch, though they often support more than one team at the same time.
• Ch. 14 · The Supporting Roles Beyond the core product team, user researchers, data analysts and test automation engineers support several teams at once. Product managers should know why each role exists and use them well, while covering the work themselves or with the right teammate when the role is missing.
• Ch. 15 · Profile: Jane Manning of Google Products that succeed usually have someone behind the scenes who works through every objection, technical, business or otherwise. Google AdWords nearly never happened, and Jane Manning got it built by understanding each group's concerns and shaping a solution that answered them.
• People @ Scale Growing product companies know they must hire strong people as they scale, but they often miss the other changes that scaling demands, from leadership roles to team autonomy, accountability and dependencies.
• Ch. 16 · The Role of Leadership Leaders in a product company must recruit, develop and keep strong people, and they must also hold a holistic view of the product. That view has three parts, business, user experience and technology, and each needs a senior owner as the company grows.
• Ch. 17 · The Head of Product Role The head of product must be proven at four things: developing people, product vision that complements the CEO, execution, and building a strong product culture, plus the right technical background and personal chemistry with the CEO and CTO. In larger organizations, a group product manager role blends hands-on product work with coaching a few other PMs.
• Ch. 18 · The Head of Technology Role A strong head of technology makes technology a strategic enabler for the business rather than a barrier, and a product manager's working relationship with that leader largely decides how good the job is. The role has six responsibilities in priority order, each with its own measures.
• Ch. 19 · The Delivery Manager Role Growth-stage and enterprise companies need delivery managers, project managers whose job is to remove obstacles for product teams. This frees product managers to focus on making sure engineers have a product worth building.
• Ch. 20 · Principles of Structuring Product Teams There is no recipe for splitting a product across many teams. Leaders must weigh a set of principles, chiefly architecture, dependencies, ownership and leverage, and accept that every structure trades some goals for others, including the tension between team autonomy and a shared foundation.
• Ch. 21 · Profile: Lea Hickman of Adobe Large, profitable companies can make dramatic product changes only with strong product leadership. That means a compelling vision of the new whole and relentless communication with every stakeholder, as Lea Hickman showed in moving Adobe from Creative Suite to Creative Cloud.
• Product Roadmaps Typical product roadmaps are lists of output, features and projects with dates, while good teams are asked to deliver outcomes. Management wants roadmaps for sound reasons, yet these roadmaps cause most of the waste and failed efforts in product organizations.
• Ch. 22 · The Problems with Product Roadmaps Roadmaps fail because most ideas don't work and the good ones need several iterations, yet anything listed on a roadmap is read as a commitment. Strong teams answer with fast product discovery and commit to solving the underlying problem, not to shipping a feature.
• Ch. 23 · The Alternative to Roadmaps Roadmaps exist to ensure teams work on the highest-value things and to track date commitments. Both needs are better met by giving empowered teams a product vision, strategy and prioritized business objectives, plus a few high-integrity commitments made only after product discovery.
• Ch. 24 · Product Vision and Product Strategy A product organization needs a product vision that inspires everyone toward a future two to five years out, and a product strategy that reaches it through a focused sequence of product/market fits, one target market at a time.
• Ch. 25 · Principles of Product Vision A product vision works when it states a purpose, centers on a customer problem, aims big enough to inspire, reads trends well, and is held firmly for years while the details stay flexible and the vision is sold constantly.
• Ch. 26 · Principles of Product Strategy Good product strategies share five principles. Serve one target market or persona per release, align with business and go-to-market strategy, obsess over customers instead of competitors, and communicate the strategy widely.
• Ch. 27 · Product Principles Product principles state what a company believes matters about the nature of the products it builds. They sit beside the product vision, which describes the future, and the product strategy, which describes the path there.
• Product Objectives Strong product organizations manage by business objectives, not by control. Teams get told what outcome to reach and are judged by results, and today the OKR system (objectives and key results) is the main tool for doing this.
• Ch. 28 · The OKR Technique OKRs are a tool for management, focus, and alignment. Product organizations should use them at the organization and product team level, with qualitative objectives, measurable business-result key results, a small number of each, consistent scoring, and clear ownership.
• Ch. 29 · Product Team Objectives In a product organization, OKRs should be set at the level of the cross-functional product team, not by functional department or individual. Department-level goals like technical debt or responsive design get prioritized by leadership and folded into the relevant product team's objectives.
• Product @ Scale Early startups can get by without product vision, strategy, and business objectives by serving early customers, but at scale teams cannot make good decisions without that context, and its absence shows up as low morale, little innovation, and slow velocity.
• Ch. 30 · Product Objectives @ Scale OKRs scale well, but in larger product organizations leadership and management must carry more of the work of alignment. That means assigning company objectives to the right teams, reconciling gaps, coordinating platform teams and tracking commitments so every team knows how it contributes.
• Ch. 31 · Product Evangelism Product evangelism means selling the dream: helping people picture the future and inspiring them to build it. Product managers carry most of this job, and without it their products tend to stall or die quietly.
• Ch. 32 · Profile: Alex Pressland of the BBC A strong product manager can push a large, traditional enterprise into a major strategic shift by seeing what an enabling technology makes possible, proving it with small experiments, and then proposing a vision. Alex Pressland did this at the BBC as an individual contributor.
• PART IV: The Right Process Product teams succeed through a mix of techniques, mindset and culture rather than one fixed process. Product managers should spend most of their time on discovery, while staying available to engineers during delivery.
• Product Discovery Product teams face two goals that look opposed: learn fast through cheap experiments with real customers, and release production-quality software with confidence. Product discovery exists to gather evidence before engineers spend the costly effort of building a real product, so neither goal has to be sacrificed.
• Ch. 33 · Principles of Product Discovery Product discovery exists to gather evidence, quickly and cheaply, that an idea is valuable, usable, feasible and viable for the business before anything gets built. A small set of principles drives how good teams do it, and ethics is sometimes a fifth risk to check.
• Ch. 34 · Discovery Techniques Overview Product discovery needs a toolkit of techniques grouped by purpose: framing, planning, ideation, prototyping, testing and transformation. Teams should validate only the risks that actually exist for an idea and pick the technique that fits the situation.
• Discovery Framing Techniques Most discovery work needs little framing, but big projects and multi-team initiatives need a short up-front framing that aligns the team on the problem and surfaces the real risks. Teams should fall in love with the problem, not the solution.
• Ch. 35 · Opportunity Assessment Technique Before starting discovery on any piece of work, the product team should answer four short questions: the business objective, the key results that define success, the customer problem being solved, and the target market. These answers take minutes to write and keep the whole team and its stakeholders aligned.
• Ch. 36 · Customer Letter Technique For larger efforts like a redesign, frame the work before building by imagining its successful outcome. Write either a pretend press release, as Amazon does, or a happy customer's letter to the CEO, as Nordstrom does, so the team focuses on customer benefits rather than features.
• Ch. 37 · Startup Canvas Technique When inventing an entirely new product or business, use a lightweight startup canvas to surface the full range of risks early. Still, attack the biggest risk first: value risk, meaning discovering a solution customers will choose to buy and use.
• Discovery Planning Techniques Complicated product efforts benefit from a way to scope and plan discovery work before diving into solutions. Two techniques do this well: story maps, which are simple, and the customer discovery program, which is demanding but is the strongest leading indicator of future success.
• Ch. 38 · Story Map Technique A story map is a simple two-dimensional layout of user activities and their stories. It gives every story context and serves framing, ideation, design, communication and work management across both discovery and delivery.
• Ch. 39 · Customer Discovery Program Technique Product teams should develop a set of real, paying, happy reference customers in one target market at the same time as they discover and build the product. For business products, six such references in a single market is a practical definition of product/market fit and the best leading indicator of product success.
• Ch. 40 · Profile: Martina Lauchengco of Microsoft A shared code base or internal efficiency goal is an empty win if the product it produces is bad for customers. Strong product managers find a way to do the right thing for the customer even under heavy pressure.
• Discovery Ideation Techniques The ideation question that matters is how to produce ideas that solve the hard business problems leaders have asked the team to focus on now. Teams that are given problems instead of solutions, and that talk to users often, rarely run short of good ideas.
• Ch. 41 · Customer Interviews Customer interviews are the most basic and one of the most powerful discovery skills a product manager has. They should happen every week, with the product manager present, to learn who customers are, what problems they really have, how they solve them today, and what would make them switch.
• Ch. 42 · Concierge Test Technique A concierge test means doing the customer's job for them, manually and personally, so the team learns how they really work. It produces strong product ideas fast and builds the customer empathy that motivates a team.
• Ch. 43 · The Power of Customer Misbehavior Beyond following the market or following the technology, a powerful and underused way to find product opportunities is to let, and even encourage, customers and developers to use your product for problems you never planned for. Then study what they do.
• Ch. 44 · Hack Days Hack days, especially directed ones aimed at a specific customer problem or business objective, quickly produce a range of promising, prototyped ideas. They also pull engineers into ideation and build a team of missionaries rather than mercenaries.
• Discovery Prototyping Techniques Prototypes come in several distinct types, each suited to testing a different risk. Teams should pick the cheapest, fastest type that fits the idea and be skilled at all of them.
• Ch. 45 · Principles of Prototypes Every kind of prototype exists to learn something far more cheaply than building the real product. Prototypes also sharpen thinking, align the team, should be only as realistic as the purpose needs, and can double as the spec for what gets built.
• Ch. 46 · Feasibility Prototype Technique When engineers flag a real feasibility risk, one or more of them should write a quick, throwaway feasibility prototype. It should be just enough code to show whether the approach can work before the team commits to delivery.
• Ch. 47 · User Prototype Technique A user prototype is a simulation with nothing real behind it, ranging from low to high fidelity. It is one of the most powerful discovery and communication tools, but it cannot prove that a product has value or will sell.
• Ch. 48 · Live‐Data Prototype Technique When a major discovery risk can only be settled with real usage data, teams build a live-data prototype. It is a tiny, unproductized implementation that real users use for real work, so the team can measure behavior before paying for a scalable, shippable product.
• Ch. 49 · Hybrid Prototype Technique Hybrid prototypes mix traits of user, feasibility and live-data prototypes. The Wizard of Oz version, a realistic front end with a human doing the work behind it, lets teams learn fast without building automation first.
• Discovery Testing Techniques Discovery testing separates good ideas from bad by answering four questions: value, usability, feasibility and business viability. Teams usually test value and usability first with customers, then feasibility with engineers, then viability with the business.
• Ch. 50 · Testing Usability Usability testing belongs in discovery, on prototypes, before anything is built. Product teams can run it themselves cheaply and still catch the serious friction points.
• Ch. 51 · Testing Value Customers and users only buy or adopt a product when they see real value, enough to make switching worth the pain. So product teams should spend most of their time creating value and testing it through demand, qualitative reaction, and quantitative efficacy.
• Ch. 52 · Demand Testing Techniques Before building a feature or product, test whether people want it at all, using fake doors or fake landing pages. Large companies must keep innovating the same way, but do it in ways that protect revenue, brand, employees and customers.
• Ch. 53 · Qualitative Value Testing Techniques Qualitative value testing with real users is likely the most important discovery activity a product team can do. It explains why users respond as they do, and its tests are built so people cannot just be polite.
• Ch. 54 · Quantitative Value Testing Techniques Quantitative value testing collects evidence of what users actually do with a new idea, chosen by traffic, time and risk tolerance. Analytics show what is happening but not why, so qualitative work must explain the numbers.
• Ch. 55 · Testing Feasibility Engineers need time, not on-the-spot demands, to judge whether an idea can be built, and ideas that need investigation are often the best ones. Hardware raises the stakes, so risks must be tackled harder and confidence raised before manufacturing.
• Ch. 56 · Testing Business Viability A product that customers love and engineers can build still fails if it does not work for the business. The product manager must test the solution against every stakeholder's constraints, early, before building, and that is what being the CEO of the product means.
• Ch. 57 · Profile: Kate Arnold of Netflix Netflix survived its 1999 crisis because its product manager, Kate Arnold, drove technology-based solutions (the queue, ratings and recommendations) that made a subscription business model workable and affordable.
• Transformation Techniques Knowing good product discovery techniques is not enough. Getting teams and companies to actually work this new way is hard because the change is mostly cultural, and specific transformation techniques can help an organization make that shift.
• Ch. 58 · Discovery Sprint Technique A discovery sprint is a focused, one-week block of discovery work that targets a major problem or risk. It ends when the team tests a prototype with real users. For teams that are new to modern discovery, it offers a clear, tested method to follow. A discovery coach who has hands-on product experience often leads it.
• Ch. 59 · Pilot Team Technique Change how a product organization works by first letting a volunteer pilot team try the new way for a quarter or two, then spreading it once it has shown results. This respects the fact that people adopt change at different speeds.
• Ch. 60 · Weaning an Organization Off Roadmaps Teams can move an outcome-blind organization off feature roadmaps gradually. They keep the roadmap for six to 12 months but tie every item to its business result, so attention shifts from features and dates to outcomes.
• Process @ Scale Growing companies tend to add formal, standardized process to protect what they have built, and when that process governs how products are made, it can kill innovation. It does not have to happen, and large companies can keep innovating if they scale with care.
• Ch. 61 · Managing Stakeholders Product managers win room to find the best solutions by understanding every stakeholder's constraints, earning their trust one on one, and previewing high-fidelity prototypes during discovery rather than showing finished work or slides. A separate warning: growing companies can lose their good product practices by hiring leaders from companies that are weak at product.
• Ch. 62 · Communicating Product Learnings As companies grow, product learnings stop spreading on their own. A short, regular update from the head of product at an all-hands meeting keeps the whole company informed of the big discovery learnings and reinforces a culture of experimentation and transparency.
• Ch. 63 · Profile: Camille Hearst of Apple Great product managers find creative solutions to hard problems that sit between product and business. Camille Hearst's work on the iTunes and American Idol integration at Apple is one example.
• PART V: The Right Culture Beyond the details of roles, process and techniques, success in tech product work depends on building the right product culture. That means knowing how strong product teams behave and how strong product companies give those teams an environment where they can flourish.
• Ch. 64 · Good Product Team/Bad Product Team The best product companies differ from the rest in almost everything: leadership behavior, team empowerment, how they fund and staff work, and how product, design and engineering collaborate. A set of good team versus bad team contrasts shows those differences so teams can see where to raise the bar.
• Ch. 65 · Top Reasons for Loss of Innovation Large companies do not have to lose their ability to innovate. When they do, it is because one or more of ten cultural attributes is missing, and the fix is mostly about culture rather than process.
• Ch. 66 · Top Reasons for Loss of Velocity Organizations often slow down as they grow, but they don't have to, and the best ones speed up. When velocity drops, a short list of common causes is where to look first.
• Ch. 67 · Establishing a Strong Product Culture Product culture has two dimensions: innovation, the ability to keep finding valuable solutions (product discovery), and execution, the ability to deliver shippable products (product delivery). Few companies are strong at both, and teams should assess where they stand and where they need to be.
• Learning More Silicon Valley Product Group offers further resources for product people: a free website with articles and examples, a reading list, public training workshops for aspiring product managers, and custom on-site engagements for companies needing deep change.