The innovation graveyard is full of ideas that were “obviously dumb” right up until they weren’t. Some were mocked as fleeting fads; others stumbled out of the gate and looked like write‑offs. Then reality happened. Below are ten products that went from punchline to juggernaut—with research, receipts, and a little playful shade for the early naysayers.

1) Post‑it® Notes — the “failed glue” that stuck around

3M set out to make a super‑strong adhesive in 1968 and accidentally created the opposite: a low‑tack, re‑stickable glue. Useful? Not obviously. The first product—Press ’n Peel—hit four test markets in 1977 with “mixed results,” which is corporate for “meh.” Only after a 1978 sampling blitz in Boise (“the Boise Blitz”) did the lightbulb go on; in 1980, the product launched nationally as Post‑it Notes. (Post-it, Minnesota Historical Society)

3M’s own history admits the beginnings were “far from certain.” (Post-it)

The outcome: A canonical office staple born of a “failure”—and a masterclass in changing context (samples + use cases) instead of changing chemistry. (Post-it)

2) Sony Walkman — launched without market research, sold ~385 million

If you’d asked a focus group in 1979 whether they wanted to wear headphones in public, you’d have likely gotten polite laughter. Sony co‑founder Akio Morita didn’t ask. As The Guardian put it: “Neither market research nor focus groups featured anywhere in the Walkman story.” The bet paid off: Sony’s official history tallies 385 million Walkman units shipped across formats. (The Guardian, Sony)

The outcome: When you create a new behavior (“private, portable sound”), people can’t describe it in a survey—but they can buy it by the tens of millions. (Sony)

3) Apple iPhone — from “no chance” to Apple’s biggest business

Microsoft’s Steve Ballmer famously scoffed in 2007: “There’s no chance that the iPhone is going to get any significant market share.” (He also dinged it for lacking a keyboard.) Reality disagreed. Apple sold one million iPhones in 74 days, and by fiscal 2024 the iPhone generated $201.2 billion in revenue—Apple’s largest line item. (WIRED, Q4 Capital)

The outcome: The device Ballmer dismissed became the center of Apple’s financial universe. (And yes, it still doesn’t have a physical keyboard.) (Q4 Capital)

4) AirPods — “toothbrush heads” to $100B‑class franchise

When Apple unveiled AirPods in 2016, the internet’s verdict was savage: “roundly mocked” and meme‑ified as easy‑to‑lose ear‑dangles. Then… they took over. Counterpoint expects cumulative AirPods revenue to cross $100 billion by 2026, and Apple has led the true‑wireless earbuds market for years even as competitors pile in. (The Guardian, Counterpoint Research)

The outcome: From punchline to category synonym. Moral: never bet against frictionless pairing. (Counterpoint Research)

5) Crocs — the “ugly shoe” that became a $4B+ powerhouse

For a while, Crocs were the footwear you wore privately to take out the trash. Fashion writers sneered; thinkpieces called them the “ugliest shoes ever.” And yet the company’s financials tell a happier tale: $4.1 billion in 2024 revenue—a record—after a years‑long resurgence powered by comfort trends and savvy collabs. (Business Insider, investors.crocs.com)

The outcome: From meme to money machine. (Beauty may be subjective; gross margin is not.) (investors.crocs.com)

6) Bubble Wrap — a failed wallpaper that cushioned the world

Two engineers laminated plastic sheets to make textured wallpaper in 1957. The décor idea bombed. They then pitched it as greenhouse insulation… also not the hit. The big break came when Sealed Air repurposed it for protective packaging, with IBM among the early adopters. As Smithsonian summarizes, it was a “failed experiment” that revolutionized shipping—and stress relief. (Sealed Air, Wikipedia, Smithsonian Magazine)

The outcome: From interior‑design miss to indispensable packaging—and the world’s most satisfying office toy. (Smithsonian Magazine)

7) Tupperware — retail flop → living‑room rocket ship

Earl Tupper’s airtight plastic bowls were impressive, but store shelves weren’t moving them in the late 1940s and early 1950s. Enter Brownie Wise, who built the now‑legendary Tupperware Party model: in‑home demos where hosts showed (and sealed) the value. The Smithsonian notes the product simply “was not selling well in stores” until Wise’s direct‑sales approach turned it into a cultural and commercial force. (National Women’s History Museum, Smithsonian Magazine)

The outcome: Distribution innovation mattered more than product innovation. Sometimes the channel is the product. (Smithsonian Magazine)

8) Dyson Vacuums — 5,127 “failures” before a global hit

James Dyson’s bagless cyclone concept was rejected by major manufacturers (that vacuum‑bag cash cow didn’t want disrupting). He built 5,127 prototypes anyway, then launched the DC01 himself in 1993. Within 18 months the DC01 topped the UK market; the brand later expanded into fans, hair dryers, and air purifiers. As Dyson himself put it: “It took 5,127 prototypes and 15 years to get it right.” (WIRED, Dyson, Wikipedia)

The outcome: A lesson in stubbornness as a strategy. (And in transparent dust bins as surprisingly persuasive UX.) (Wikipedia)

9) Microwave Ovens — from restaurant behemoths to 96% of U.S. homes

The first commercial microwaves (late 1940s–1950s) were enormous, water‑cooled, and cost the equivalent of a used car. Adoption was slow; by 1986 only 25% of U.S. households had one. Fast‑forward: by 2015, roughly 96% of U.S. homes had a microwave, according to the Energy Information Administration’s RECS survey. (WIRED, Bureau of Labor Statistics, U.S. Energy Information Administration)

The outcome: Shrink the box, cut the price, and one day it’s the most‑used “chef” in the house. (U.S. Energy Information Administration)

10) The Hula Hoop — the fad that wouldn’t quit

Wham‑O’s plastic hoop exploded in 1958, selling an estimated 25 million in the first four months and ~100 millionwithin two years. Yes, it was the definition of a “craze,” but the hoop kept rolling—revivals, fitness versions, competitions. As History.com puts it, the Hula‑Hoop became a “huge fad”—and a permanent icon. (HISTORY, Encyclopedia Britannica)

The outcome: Some fads don’t disappear; they just stop apologizing for being fun. (Smithsonian Magazine)

Bonus round: “But were they really flops?”

A quick framing:

• Flop → hit: The product underperformed or was dismissed, then scaled (Post‑it, Dyson, Tupperware, Bubble Wrap).

• Fad → franchise: The product was laughed off as a novelty but sold at wild scale—and in some cases built durable businesses (AirPods, Crocs, Hula Hoop).

• Skepticism → dominance: Experts called it misguided; it became a platform (Walkman, iPhone).

In all three lanes, the pivot wasn’t just marketing spin. It was fit found through sampling, channel design, or a new behavior people hadn’t imagined yet. (Post-it, Smithsonian Magazine, The Guardian)

What these “resurrections” have in common

1) They changed the context, not (always) the concept.
Samples (Post‑it’s Boise Blitz), in‑home demos (Tupperware), and re‑framing (Bubble Wrap as packaging) turned idle curiosities into obvious purchases. (Post-it, Smithsonian Magazine, Sealed Air)

2) They hacked time‑to‑value.
AirPods erased pairing pain. The Walkman gave instant private music. Microwave ovens slashed reheat time. In each case, the first five minutes were magic. (The Guardian, Bureau of Labor Statistics)

3) They ignored (or outgrew) early “this will never work” takes.
From Ballmer’s iPhone quip to fashion’s Crocs disdain, confident contrarians won by shipping—and measuring—real usage. (WIRED, Business Insider)

4) They paired product with distribution genius.
New channels matter: Tupperware parties; Sony’s global branding of “Walkman”; Apple’s retail + ecosystem lock‑in for AirPods and iPhone. (Smithsonian Magazine, Sony, Counterpoint Research)

Quick receipts (so your inner skeptic can rest)

• Post‑it Notes: Press ’n Peel test had “mixed results”; 1978’s Boise Blitz sampling flipped sentiment; national launch in 1980. (Post-it, Minnesota Historical Society)

• Walkman: “No focus groups” origin story; ~385M units sold. (The Guardian, Sony)

• iPhone: “No chance” quote; 1M units in 74 days; $201.2B iPhone revenue in FY2024. (WIRED, Q4 Capital)

• AirPods: “Roundly mocked” at launch; Counterpoint sees $100B+ cumulative revenue by 2026. (The Guardian, Counterpoint Research)

• Crocs: From meme to $4.1B 2024 revenue. (investors.crocs.com)

• Bubble Wrap: Wallpaper → insulation → packaging; IBM among early users. (Sealed Air, Wikipedia)

• Tupperware: “Not selling well in stores” until Brownie Wise’s party plan. (National Women’s History Museum, Smithsonian Magazine)

• Dyson: 5,127 prototypes; market‑leading DC01. (WIRED, Wikipedia)

• Microwave: 25% U.S. homes by 1986; ~96% by 2015. (Bureau of Labor Statistics, U.S. Energy Information Administration)

• Hula Hoop: 25M in four months; ~100M within two years. (HISTORY, Encyclopedia Britannica)

The (slightly snarky) playbook for your next “flop”

1. Don’t ask, show. Surveys are great, but the Walkman‑style “ship it and watch” approach has a track record when you’re birthing a new behavior. (The Guardian)

2. Put the product where belief happens. A sampling blitz (Post‑it), a living‑room demo (Tupperware), or a dead‑simple setup (AirPods) beats another press release. (Post-it, Smithsonian Magazine, The Guardian)

3. Instrument the first five minutes. Microwaves, Walkman, AirPods, iPhone—winners deliver velocity to value. Measure that moment like it’s your NPS, because it kind of is. (Bureau of Labor Statistics)

4. Be stubborn (and specific). Dyson’s 5,127 tries weren’t random; they were tight feedback loops. If your “flop” is on the right problem, double down. (WIRED)

5. Let fads fund franchises. Hula Hoop was a craze—then a category. Crocs was a meme—then a margin machine. Sometimes fashionably “uncool” is a moat. (Encyclopedia Britannica, investors.crocs.com)

Final thought

Every great product has an awkward teenage phase. If yours is being mocked as a fad or dismissed as a flop, take heart: you might be one sampling program, one channel innovation, or one prototype #5,128 away from the list above. Just remember—history is written by the winners…and the people who kept a straight face while gluing office paper with a “failed” adhesive. (Post-it)

1) The Social Network (2010) - Drama

Why PMs: Vision, velocity, and the cost of moving fast without enough UX tape. Great case study in positioning, PRDs (Petty Relationship Documents), and stakeholder… disputes.
Quote: “You don’t get to 500 million friends without making a few enemies.”
Stars: Jesse Eisenberg, Andrew Garfield, Justin Timberlake
Trailer: YouTube • IMDb • Rotten Tomatoes

2) Moneyball (2011) - Sports/Drama

Why PMs: Data > gut. This is OKRs, experiments, and ruthless prioritization-before A/B testing was cool.
Quote: “Adapt or die.”
Stars: Brad Pitt, Jonah Hill, Philip Seymour Hoffman
Trailer: YouTube • IMDb • Rotten Tomatoes

3) Apollo 13 (1995) - Drama/Thriller

Why PMs: Crisis management, cross‑functional war rooms, and heroic scope cuts. Also: duct‑tape prototyping.
Quote: “Houston, we have a problem.”
Stars: Tom Hanks, Ed Harris, Kevin Bacon
Trailer: YouTube • IMDb • Rotten Tomatoes

4) The Martian (2015) - Sci‑Fi/Adventure

Why PMs: Resource constraints meet radical creativity. Standups where your only teammate is a potato.
Quote: “I’m gonna have to science the **** out of this.”
Stars: Matt Damon, Jessica Chastain, Chiwetel Ejiofor
Trailer: YouTube • IMDb • Rotten Tomatoes

5) Steve Jobs (2015) - Biopic/Drama

Why PMs: Product launches as opera. Narrative, taste, and ruthless focus on the demo.
Quote: “Musicians play their instruments. I play the orchestra.”
Stars: Michael Fassbender, Kate Winslet, Seth Rogen
Trailer: YouTube • IMDb • Rotten Tomatoes

6) Chef (2014) - Comedy/Drama

Why PMs: Build an MVP, ship a food truck, iterate from user feedback (and Twitter meltdowns).
Quote: “I may not do everything great in my life, but I’m good at this.”
Stars: Jon Favreau, Sofía Vergara, Scarlett Johansson
Trailer: YouTube • IMDb • Rotten Tomatoes

7) Hidden Figures (2016) - Drama/History

Why PMs: Diverse teams outperform. Remove blockers (even literal bathroom blockers) and watch velocity soar.
Quote: “We get to the peak together, or we don’t get there at all.”
Stars: Taraji P. Henson, Octavia Spencer, Janelle Monáe, Kevin Costner
Trailer: YouTube • IMDb • Rotten Tomatoes

8) The Godfather (1972) - Crime/Drama

Why PMs: Negotiation, influence without authority, and… stakeholder management.
Quote: “I’m gonna make him an offer he can’t refuse.”
Stars: Marlon Brando, Al Pacino, Diane Keaton
Trailer: YouTube • IMDb • Rotten Tomatoes

9) Ocean’s Eleven (2001) - Heist/Comedy

Why PMs: Assemble your cross‑functional A‑team, align on a mission, and run the playbook.
Quote: “Because the house always wins.”
Stars: George Clooney, Brad Pitt, Julia Roberts, Don Cheadle
Trailer: YouTube • IMDb • Rotten Tomatoes

10) Inception (2010) - Sci‑Fi/Heist

Why PMs: Multi‑layer roadmaps, stakeholder dream‑alignment, and the art of planting ideas.
Quote: “You mustn’t be afraid to dream a little bigger, darling.”
Stars: Leonardo DiCaprio, Joseph Gordon‑Levitt, Tom Hardy
Trailer: YouTube • IMDb • Rotten Tomatoes

11) The Matrix (1999) - Sci‑Fi/Action

Why PMs: Change management. Choosing the red pill = shipping the uncomfortable truth.
Quote: “There is no spoon.”
Stars: Keanu Reeves, Carrie‑Anne Moss, Laurence Fishburne
Trailer: YouTube • IMDb • Rotten Tomatoes

12) Edge of Tomorrow (2014) - Sci‑Fi/Action

Why PMs: Iterate, learn, repeat. A masterclass in fast feedback cycles…and unit tests that shoot back.
Quote: “Live. Die. Repeat.”
Stars: Tom Cruise, Emily Blunt, Bill Paxton
Trailer: YouTube • IMDb • Rotten Tomatoes

13) Mad Max: Fury Road (2015) - Action

Why PMs: Ruthless prioritization on a flaming gantt chart. Constraints force brilliant design.
Quote: “What a lovely day!”
Stars: Charlize Theron, Tom Hardy, Nicholas Hoult
Trailer: YouTube • IMDb • Rotten Tomatoes

14) Minority Report (2002) - Sci‑Fi/Thriller

Why PMs: When data predicts behavior, ethics must be part of your roadmap.
Quote: “Everybody runs.”
Stars: Tom Cruise, Colin Farrell, Samantha Morton
Trailer: YouTube • IMDb • Rotten Tomatoes

15) Groundhog Day (1993) - Comedy/Fantasy

Why PMs: Endless iteration until you finally get the user journey right.
Quote: “What if there is no tomorrow? There wasn’t one today.”
Stars: Bill Murray, Andie MacDowell, Chris Elliott
Trailer: YouTube • IMDb • Rotten Tomatoes

16) The Devil Wears Prada (2006) - Comedy/Drama

Why PMs: Stakeholder management, taste, and the peril of vague acceptance criteria. That’s all.
Quote: “Florals? For spring? Groundbreaking.”
Stars: Meryl Streep, Anne Hathaway, Emily Blunt
Trailer: YouTube • IMDb • Rotten Tomatoes

17) The Big Short (2015) - Drama/Comedy

Why PMs: Systems thinking. Incentives matter. Assumptions matter more.
Quote: “Truth is like poetry. And most people ****ing hate poetry.”
Stars: Christian Bale, Steve Carell, Ryan Gosling, Margot Robbie (in a bubble bath, explaining CDOs)
Trailer: YouTube • IMDb • Rotten Tomatoes

18) The Dark Knight (2008) - Action/Crime

Why PMs: Trade‑offs, reputation risk, and the long arc from product darling to villain (if you don’t keep delivering).
Quote: “You either die a hero, or live long enough to see yourself become the villain.”
Stars: Christian Bale, Heath Ledger, Aaron Eckhart
Trailer: YouTube • IMDb • Rotten Tomatoes

19) Jerry Maguire (1996) - Comedy/Drama

Why PMs: Customer obsession, retention over acquisition, and writing a memo nobody asked for.
Quote: “Show me the money!”
Stars: Tom Cruise, Renée Zellweger, Cuba Gooding Jr.
Trailer: YouTube • IMDb • Rotten Tomatoes

20) WALL‑E (2008) - Animation/Sci‑Fi

Why PMs: Design ethics and long‑term user impact. Make products that help humans stand up-literally.
Quote: “I don’t want to survive. I want to live!”
Stars (voices): Ben Burtt, Elissa Knight, Jeff Garlin
Trailer: YouTube • IMDb • Rotten Tomatoes

Bonus viewing prompts (a PM’s stream‑of‑consciousness)

• Backlog grooming: Groundhog Day until you stop shipping the same bug twice.

• Retro energy: Apollo 13 on mute while you build the post‑mortem template.

• Stakeholder sync: The Godfather-but resist using the exact negotiation style.

• Roadmap workshop: Inception (bring a totem; i.e., a realistic delivery date).

Data debate:Moneyball-and yes, vanity metrics still don’t win games.

Each pick includes a moment (what to use it for), a tiny rationale, and a Spotify link so you can cue it instantly.

1) P1 War Room

Track: “Under Pressure” — Queen & David Bowie
Why: Because nothing says “sev‑zero with execs watching” like that bassline. The title alone is your incident severity taxonomy. When the PagerDuty symphony kicks off, this is your overture.
Spotify: link. (Spotify)

2) The Fix (a.k.a. Redeploy, Retry, Rejoice)

Track: “Fix You” — Coldplay
Why: The hymn for post‑mortem redemption arcs. You’ll swear you hear “lights will guide you home” when the health checks finally turn green.
Spotify: link. (Spotify)

3) Release Countdown (T‑10 to T‑0)

Track: “The Final Countdown” — Europe
Why: During change‑freeze you need an anthem that literally narrates the moment. Bonus: the synths go great with Jenkins build lights.
Spotify: link. (Spotify)

4) Keynote Reveal / Big Feature Unveil

Track: “Also sprach Zarathustra: Sunrise” — Richard Strauss
Why: The most dramatic “we have… one more thing” in music history. Fade your slides in on that sun‑dawn brass and watch adoption double out of sheer intimidation.
Spotify: link. (Spotify)

5) Pre‑Launch Pep Talk

Track: “Lose Yourself” — Eminem
Why: For the stand‑up where you admit you’re nervous, then ship anyway. Palms sweaty, code spaghetti, but CI is steady.
Spotify: link. (Spotify)

6) Fundraising / PMF Faith Maintenance

Track: “Don’t Stop Believin’” — Journey
Why: For when an investor calls your total addressable market “aspirational.” Belt the chorus, update the deck, chase that small‑town ARR.
Spotify: link. (Spotify)

7) Performance‑Tuning & Refactors

Track: “Harder, Better, Faster, Stronger” — Daft Punk
Why: Put this on loop while shaving 300ms off p95. You’ll rename half your variables “Robot,” but the throughput graphs will forgive you.
Spotify: link. (Spotify)

8) Competitive Showdown / Sales Sprint

Track: “Eye of the Tiger” — Survivor
Why: The canonical montage music for turning SE feedback into demo wizardry. Add tiger emojis to Slack until legal sends a tasteful reminder.
Spotify: link. (Spotify)

9) GA Party (We Actually Shipped!)

Track: “Ode to Joy” — Beethoven, Symphony No. 9 (finale)
Why: The triumphant chorus that makes release notes feel like liberation literature. This is your production‑safe confetti.
Spotify: link. (Spotify)

10) The Morning After (Stability Returns)

Track: “Here Comes the Sun” — The Beatles
Why: For that first calm stand‑up after a storm. Coffee’s hotter, graphs are flatter, life is good.
Spotify: link. (Spotify)

11) On‑Call at 3:07 a.m.

Track: “Stayin’ Alive” — Bee Gees
Why: Pager goes off; you go full falsetto. Not because you can, but because your nerves forgot other registers exist.
Spotify: link. (Spotify)

12) Load Tests & Traffic Spikes

Track: “Thunderstruck” — AC/DC
Why: The riff is exactly how your Grafana alerts sound in your skull. If the chorus hits and your CPU stays under 70%, you’re winning.
Spotify: link. (Spotify)

13) Gradual Rollout / Feature Flag Ramp

Track: “Boléro” — Maurice Ravel
Why: A single idea, quietly repeated, scaling until the room notices. Perfect for going from 1% to 100% without anyone rage‑tweeting.
Spotify: link. (Spotify)

14) Postmortem (The Honest Kind)

Track: “Bitter Sweet Symphony” — The Verve
Why: For the ceremony where you acknowledge trade‑offs, document the learning, and resist the urge to blame the interns or Mercury in retrograde.
Spotify: link. (Spotify)

15) User Feedback Storms

Track: “Shake It Off (Taylor’s Version)” — Taylor Swift
Why: One‑star reviews happen. Play this, triage the themes, and upgrade your backlog from “feelings” to “fixings.”
Spotify: link. (Spotify)

16) The Victory Slide (OKRs: Met. CFO: Surprised.)

Track: “We Are the Champions” — Queen
Why: Use responsibly; product karma is real. But when you close the whale or crush NPS, it’s legally required to play this.
Spotify: link. (Spotify)

17) Security Incident / DDoS Counter‑Charge

Track: “Ride of the Valkyries” — Wagner
Why: The sound of cavalry arriving. Rotate keys, block IPs, and shout “to the logs!” in your most operatic voice.
Spotify: link. (Spotify)

18) Sprint Review, But Make It Cinematic

Track: “William Tell Overture — Finale” — Rossini
Why: For demos at a gallop and the last‑minute bug fix that slides in at 4:59 p.m. like the Lone Ranger.
Spotify: link. (Spotify)

19) The All‑Nighter That Actually Worked

Track: “Nessun Dorma” — Puccini (Pavarotti)
Why: Transl. “None shall sleep.” The final “Vincerò!” is exactly how sunrise tastes after your migration finally cuts over.
Spotify: link. (Spotify)

20) Metrics Dashboard in Full Green

Track: “All I Do Is Win” — DJ Khaled (feat. T‑Pain, Ludacris, Snoop Dogg & Rick Ross)
Why: Play once for conversion up, twice for churn down, thrice if your cohort chart looks like a ski slope. Hands go up; retention does not go down.
Spotify: link. (Spotify)

How to Use This Playlist Without Getting Fired

• Tie songs to rituals. Cue Under Pressure on a Slack incident channel join, and Fix You on the resolved message. Make it muscle memory.

• Keep it inclusive. Rotate picks for different musical tastes (and ages). Beethoven slaps in all time zones.

• Let the music set pace. Boléro for slow ramps; Thunderstruck for stress tests; William Tell for sprint reviews you want to actually end on time.

• Mind the quotes. Resist dramatic lyric‑slack after 2 a.m.; your future self will thank you during the postmortem.

Products are built in sprints, but remembered in scenes. Give your team the sound cues that tell them what kind of story they’re in—and that the ending (eventually) is joyful, stable, and deployable. Now dim the lights, open the console, and press play.

1) Airbnb - “Let strangers sleep in your living room.”

Why it sounded crazy: Hospitality experts assumed trust would be the fatal bug. Investors wondered who would type their credit card into a website and then… hand their keys to a stranger? In 2008 the founders literally kept the lights on by selling limited‑edition political cereal boxes, “Obama O’s” and “Cap’n McCain’s.” (WIRED)

What worked: Airbnb didn’t just build listings; it productized trust (reviews, identity, payments). By IPO day in 2020, the company’s valuation briefly exceeded the combined market caps of Marriott, Hilton, and IHG-an unthinkable outcome when the idea was “airbeds on floors.” (Business Insider)

A little internet color:

“Before Airbnb, the idea was crazy that you’d let strangers into your home.” - Hacker News user (Hacker News)

Nugget: In 2021, analysts estimated Airbnb’s share of U.S. lodging revenue jumped to 18% in 2020 (up from 11.5% in 2019)-evidence that “crazy” can scale fast when the market shifts. (Reuters)

2) Post‑it® Notes - “A glue that barely sticks.”

Why it sounded crazy: In the late 1960s 3M chemist Spencer Silver accidentally invented a very weak adhesive. Inside 3M it was dismissed as a “solution without a problem” for years. Art Fry’s hymnal bookmarks finally gave it purpose, and after early field tests as Press ’n Peel (1977), the product launched nationally in 1980. Also: the now‑iconic Canary Yellow happened because the lab next door had scrap yellow paper. (Skeptical Inquirer)

A little internet color:

“For five years, Silver promoted his ‘solution without a problem’ within 3M…” - Reddit /r/AskEngineers(Reddit)

Nugget: Post‑its are a masterclass in customer education: when 3M sampled them broadly (“try it, then you tell us what it’s for”), adoption exploded. If you’ve ever learned to peel them sideways so they don’t curl-there’s literally a Reddit Life Pro Tip for that. (Reddit)

3) FedEx - “Build a private air fleet for guaranteed overnight delivery.”

Why it sounded crazy: In the 1960s, shipping piggybacked on passenger planes; owning a dedicated network felt financially bonkers. A famous (and debated) legend says founder Fred Smith only got a “C” on the Yale term paper outlining the idea. What’s not debated: on April 17, 1973, Federal Express launched with 14 aircraft, 389 employees, and 186 packages delivered to 25 U.S. cities-and an industry was born. (Quote Investigator)

A little internet color:

“FedEx may have the worst and least secure digital platform for a major company.” - Hacker News user, grumbling half a century later (Hacker News)

Nugget: The hub‑and‑spoke system Smith envisioned as a student ultimately helped power modern e‑commerce. When he passed away in June 2025, obituaries noted FedEx had grown to ~17 million daily deliveries with ~500,000 employees. Crazy… worked. (The Washington Post)

4) Spanx - “A 21st‑century girdle. Also, I have $5,000 and no experience.”

Why it sounded crazy: Mills kept saying no; shapewear sounded dusty. Sara Blakely persisted, got Neiman Marcus to try it, and then Oprah raved-cue hockey‑stick demand. Forbes later named Blakely the world’s youngest self‑made female billionaire. (Allure)

Nugget: The lesson isn’t just persistence; it’s product storytelling. With nothing but a prototype and a pitch, Blakely reframed shapewear from “grandma’s garment” into a confidence device.

5) The Pet Rock - “It’s a rock. In a box.”

Why it sounded crazy: Because it is crazy. Yet Gary Dahl’s satirical “pet care” manual turned a gag into the ultimate case study in packaging and narrative. In late 1975 the fad went nuclear, selling about 1.5 million rocks at $3.95. (The Washington Post)

A little internet color (from the manual itself):

“It takes most PET ROCKS exactly three days to acclimate themselves to their new surroundings.”

Nugget: The product was a rock; the experience was comedy. Dahl’s manual offered deadpan commands like SIT, STAY, and ATTACK-earning a permanent spot in marketing lore.

6) Twitter (now X) - “Micro‑blogging, but only 140 characters.”

Why it sounded crazy: “Who cares what you had for lunch?” The 140‑character limit-born from SMS’s 160‑character cap-seemed laughably restrictive. Then constraints made the medium: real‑time news, citizen journalism, and culture in bite‑size bursts. (Fast Company)

What changed: In 2017 the limit doubled to 280 (and later ballooned for paid tiers). A year in, data showed the average tweet was still just ~33 characters-brevity persisted. (TechCrunch)

A little internet color:

“It is also incredibly bloated considering they only need to display 140 characters and some media.” - Hacker News user, 2016 (Hacker News)

Nugget: Product constraints can birth culture. Hashtags, threads, and @‑replies were user hacks before features-proof that “toy” platforms can become public squares. (WIRED)

7) The Slinky - “An industrial spring… as a toy?”

Why it sounded crazy: In 1943, naval engineer Richard James knocked a torsion spring off a shelf and watched it “walk.” Who would buy a bare spring? In 1945, he demoed it at Gimbels-400 units sold out in 90 minutes. Lifetime sales later topped 300 million. (Lemelson MIT)

Nugget: Slinky is proof that physics can be a product. No lore, no specs-just mesmerizing behavior powered by gravity and momentum.

8) Amazon - “Books… on the internet.”

Why it sounded crazy: In 1995, typing a credit card into a browser felt edgy. The “Earth’s biggest bookstore” was derided as a passing dot‑com. Jeff Bezos’ now‑famous 1997 shareholder letter counter‑programmed Wall Street: “It’s all about the long term.” (Wikipedia)

Nugget: The bet paid off: by 1997, Amazon had served 1.5 million customers and grown revenue 838% to $147.8M-still just the prologue to “the everything store.” (SEC)

9) Crocs - “Foam clogs with holes. In neon.”

Why it sounded crazy: Fashion critics recoiled; the public shrugged. But chefs, nurses, gardeners, and kids discovered the shoes were absurdly practical and comfortable. Crocs leaned into the weird.

Receipts (literally): $4.1 billion in 2024 revenue, a record for the company. Also, the Financial Times noted the brand’s comeback and collaborations helped sustain growth post‑pandemic. (Crocs Investors)

A little internet color:

“Love them, give zero effs about them being ugly. They are so comfy…” - Reddit user (Reddit)

Nugget: When your product’s core value is comfort, you can even win weddings. (Yes, there are Crocs‑at‑the‑altar stories. Internet, never change.) (People.com)

10) The GUI and the Mouse - “Click little pictures instead of typing commands.”

Why it sounded crazy: Early power users scoffed-why point when you can type faster? But Xerox PARC’s Alto (mouse + bitmapped GUI) showed a friendlier way; Doug Engelbart had demoed the mouse and hypertext as early as 1968. Apple’s Lisa (1983) and then the Macintosh (1984) brought the GUI to consumers. (CHM)

A little internet color:

“Keeping your hands on the keyboard… seems like it must be faster.” - Hacker News user (skepticism lives on) (Hacker News)

Nugget: Interfaces are adoption. The mouse + GUI didn’t just make computers nicer-they made them usable for non‑experts, transforming computers from lab tools into household appliances. (Wikipedia)

The pattern behind the “crazy”

1. Trust is the product. Airbnb didn’t invent spare bedrooms; it engineered reviews, identity, and payments so the risk felt tractable. (And they told a great cereal‑box story on the way.) (WIRED)

2. Constraints create culture. Twitter’s 140‑character leash birthed a new rhetoric; even at 280, average tweets stayed short. Slinky is literally a constraint (a coiled spring) turned delight. (Axios)

3. Packaging > parts. Pet Rock sold humor in a cardboard carrier with air holes; Post‑it sold a workflow, not a square of paper. (The Washington Post)

4. Distribution as a superpower. FedEx’s hub‑and‑spoke system made “tomorrow” a logistics default; Amazon’s early letters telegraphed an everything‑store ambition, then fulfilled it. (FedEx)

5. Own your weird. Crocs doubled down on ugly-and found identity (and billions). Spanx reframed an unfashionable category. (Crocs Investors)

Bonus bites: short quotes from the hive mind

“Using long threads is an abuse of Twitter format.” - HN user, 2025 (Hacker News)

“I used Airbnb when it first launched… floored that people would actually want to spend the night(s) in a random stranger’s house.” - HN user (Hacker News)

“Post‑it notes were a ‘solution without a problem’-until they weren’t.” - Reddit summary of 3M lore(Reddit)

What should you steal from these stories (legally)?

• If people laugh, ask why. Is the laughter about you, or about a broken assumption you can exploit? (Pet Rock literally monetized the punchline.) (The Washington Post)

• Prototype the trust system. Reviews, guarantees, defaults, rituals. Your “product” might be the scaffolding that lets customers try the risky thing once. (WIRED)

• Tell a legend customers want to repeat. Cereal boxes. Hymnals. A spring that walks. When your story sells the product, CAC gets a lot friendlier. (WIRED)

And if anyone on Reddit or Hacker News calls your idea ridiculous… take heart. Today’s “are you kidding me?” can be tomorrow’s default setting. (Just maybe don’t ship a literal boulder as a subscription service. That has been done.)

This post offers a practical way to decide when to rebuild, when to modernize in place, and when to leave well enough alone. It also compiles real case studies and data points-successes and cautionary tales-to ground the decision in reality rather than dogma.

First principle: avoid the false binary

Rewriting from scratch is seductive. As Joel Spolsky put it, “the single worst strategic mistake that any software company can make” is committing to a full rewrite. (Joel on Software) He overstates to make a point, but the core warning stands: a rewrite throws away hard‑won bug fixes and institutional knowledge, and pauses feature delivery for months or years.

Equally risky is doing nothing. The “don’t touch it” approach accrues security, compliance, and staffing risk until a minor incident becomes an existential problem. Southwest Airlines learned this the hard way in December 2022: outdated crew‑scheduling software helped turn a winter storm into nearly 17,000 canceled flights, over $1B in losses, and a $140M federal penalty. (AP News)

Between those poles lies a spectrum of options. Gartner’s commonly referenced “7 Rs” of modernization-encapsulate, rehost, replatform, refactor, re‑architect, rebuild, replace-remind us there are many ways to change a system besides a big‑bang rewrite. (vFunction)

A pragmatic scorecard for your product

Use these questions to guide the decision and to make trade‑offs explicit with executives:

1. Security posture

   • Are you stuck on memory‑unsafe components where critical bugs keep recurring? Google and Microsoft have reported that ~70% of serious security bugs stem from memory safety issues in C/C++-a strong argument for moving critical components to memory‑safe languages when feasible. (Google Online Security Blog)

   • Android’s shift toward Rust correlates with memory‑safety vulnerabilities dropping from 76% to 24% over six years-evidence that architectural language shifts can materially lower risk. (Google Online Security Blog)

2. Tech‑debt drag (financial)

   • McKinsey reports CIOs estimate 10–20% of budgets intended for new products are siphoned to tech‑debt remediation, and that tech debt equates to 20–40% of the value of the technology estate. If your numbers rhyme with these, modernization is already “taxed in.” (McKinsey & Company)

3. Delivery performance (DORA metrics)

   • Track deployment frequency, lead time for changes, change‑failure rate, and time to restore. Persistent “low performer” status signals architectural friction that incremental fixes aren’t solving. (Google Cloud)

4. Cost of delay vs. time to value

   • Use Weighted Shortest Job First (WSJF): prioritize the work with the highest Cost of Delay / Duration. This helps weigh a rewrite (long duration) against incremental refactors (shorter duration) and pure feature work. (Scaled Agile Framework)

5. Talent risk

   • If only a handful of retirees can maintain the core and hiring is impractical, you’re carrying operational risk. Many banks still run COBOL for core systems; an estimated 43% of banking systems and 95% of ATM swipes still rely on COBOL code. (BMC)

6. Regulatory/compliance isolation

   • Can you isolate regulated components (PCI, HIPAA) from the rest so they can evolve at different speeds? Etsy famously separated its PCI‑DSS environment to keep deploying 25–50 times a day elsewhere. (Thoughtworks)

7. Customer impact

   • What measurable user pain (latency, crashes, compatibility) results from the legacy stack? If the pain is systemic and user‑visible, refactoring or re‑architecture may pay back quickly.

When you should not rewrite: lessons from Netscape and Digg

• Netscape (1998–2000): Netscape paused new development to rewrite its browser (Mozilla). The market didn’t pause: IE surged, and Netscape’s share collapsed. Spolsky’s canonical post blames the rewrite for surrendering the lead-“They decided to rewrite the code from scratch.” The rest is history. (Joel on Software)

• Digg v4 (2010): A sweeping redesign/rebuild shipped with removed features and instability. U.S. traffic dropped 26–30% in a single month and kept falling. Users left. The migration strategy-not just the product decisions-amplified the damage. (Yahoo)

Takeaway: Big‑bang rewrites that freeze feature delivery and alienate users are strategically perilous unless you have runway and a clear, compelling payoff.

When incremental modernization wins

The Strangler‑Fig approach (wrap the legacy system, route some requests to new services, and gradually replace) is a proven pattern. Martin Fowler describes it as “the gradual replacement of a legacy system.” (martinfowler.com)

• Shopify: Rather than fracturing early into microservices, Shopify invested in a modular monolith (Rails) and tooling like Packwerk to enforce boundaries. This sustained developer productivity at scale without the operational overhead of premature microservices. (Shopify)

• Etsy: Known for 50+ deploys/day, Etsy demonstrates that a well‑tended monolith, CI/CD, and strong observability can deliver velocity and safety-no rewrite required. (InfoQ)

• Amazon (API mandate): As recounted by engineer Steve Yegge, Jeff Bezos mandated service interfaces between teams-forcing an internal SOA that set the stage for AWS-without stopping the world for a rewrite. (Courses at Washington)

• eBay (2000s): eBay evolved its platform to Java and built a DAL to scale horizontally, supporting billions of daily page views-a multi‑year re‑architecture rather than a “burn it down” rewrite. (Cornell CS)

Tactics that make incremental change work

• Strangler Fig at the edges (HTTP façade/proxy). (Microsoft Learn)

• Branch by Abstraction deep inside the codebase to swap implementations while shipping. (martinfowler.com)

• Monolith‑first discipline: start or stay monolithic until boundaries are proven. (martinfowler.com)

When a targeted rebuild pays off

Sometimes the architecture is the product. When core non‑functionals (speed, memory, offline, platform compatibility) determine user value, rebuilding parts-carefully-can transform outcomes.

• Slack (2019): Slack rebuilt its desktop app internals to improve performance: 33% faster launch and up to 50% less memory, while improving multi‑workspace stability. Users noticed; the app felt snappier across the board. (Slack)

• Snapchat Android (2019): Snap shipped a re‑engineered Android build (20% faster, 25% smaller) that reversed stagnating growth; DAUs ticked up after rollout. (TechCrunch)

• Firefox Quantum (2017): Mozilla overhauled core engine components (some in Rust), yielding ~2× speedups and ~30% less memory than Chrome at the time. A strategic rewrite of hot paths, not the whole browser. (Mozilla Blog)

• Microsoft Edge (2018): Microsoft re‑based Edge on Chromium to fix extension compatibility and web‑compat issues-trading engine purity for user and developer value. (Windows Blog)

• Facebook (2012): Mark Zuckerberg admitted, “The biggest mistake we made as a company was betting too much on HTML5 instead of native… We burned two years.” Migrating to native mobile clients improved performance and UX. (The Verge)

• PayPal (2013–2014): Rebuilt a critical app in Node.js: built twice as fast, 33% fewer lines, 40% fewer files, with 2× requests/sec and 35% lower response time vs. the Java version. (Medium)

Takeaway: Rebuilds shine when you have: (a) a contained surface area, (b) direct, measurable user‑visible gains, and (c) the ability to ship incrementally or swap in the new engine behind a façade.

When it’s rational to leave it alone (for now)

Some legacy systems are stable, deeply integrated, and mission‑critical. Killing them introduces more risk than reward-at least in the short term.

• COBOL cores in banking: Despite the age, COBOL systems power a large chunk of global banking, including 43% of banking systems and 95% of ATM swipes. During COVID‑19, states even sought COBOL talent to stabilize unemployment systems. The rational path for many is encapsulation and API exposure, not wholesale replacement. (BMC)

• Encapsulate mainframe logic with APIs: Tools like IBM z/OS Connect expose COBOL/CICS transactions as REST APIs-letting you build new experiences without rewriting the core. This is the Strangler in practice for mainframes. (IBM)

Leave it alone when:

• It’s stable, audited, and compliant.

• You can wrap, monitor, and limit blast radius.

• The Cost of Delay for new revenue features dwarfs the modernization benefits. (Use WSJF to make that explicit.) (Scaled Agile Framework)

When doing nothing becomes an unacceptable risk

• Security and patch hygiene: Equifax’s 2017 breach resulted from an unpatched Apache Struts flaw; total liabilities exceeded $1.3B and the reputational hit was massive. Legacy or not, inability to patch quickly is a red flag. (Oversight Committee)

• Operational fragility: Southwest’s “legacy” scheduling stack failed under stress, triggering cascading cancellations and federal penalties. If your incident postmortems repeatedly identify architectural bottlenecks or manual workarounds, waiting is expensive. (Wikipedia)

A step‑by‑step playbook

1) Measure and baseline.
Adopt DORA metrics; instrument change‑failure rate and MTTR. Quantify tech‑debt spend vs. feature spend. This gives you a before/after and supports executive alignment. (Google Cloud)

2) Identify “kill switches.”
Create explicit triggers for modernization (e.g., vendor EOL; inability to patch within 7 days; CFR/MTTR thresholds; critical talent attrition).

3) Prototype modernization safely.

• At the edges: Strangler Fig with a routing façade. (Microsoft Learn)

• In the core: Branch by Abstraction to swap internal implementations while shipping. (martinfowler.com)

4) Run a 6–12 week spike.
Build a small, production‑bound slice of the new approach. Compare outcomes (latency, error budget, dev time) to the legacy path. Use WSJF to prioritize next slices. (Scaled Agile Framework)

5) Choose your path:

• Rebuild when:

  • Security posture demands a language/runtime shift (e.g., moving to memory‑safe components). (Microsoft Security Response Center)

  • User‑visible performance or compatibility is blocked by current architecture (Slack, Firefox, Edge). (The Verge)

  • Talent risk is existential.

• Modernize in place when:

  • You can isolate and replace components iteratively (Shopify/Etsy/Amazon). (Shopify)

  • The core domain is stable, but supporting tech (build, deploy, observability) lags-invest in platform engineering first.

• Leave it (for now) when:

  • The system is reliable, contained, and easily wrapped with APIs (typical mainframe cores). Plan for data replication, event streams, and strangled replacements over time. (IBM)

6) Communicate with quotes and numbers.
Executives respond to crisp statements like Zuckerberg’s candid admission about HTML5-“We burned two years”-and to concrete deltas (Slack’s 33% faster). Anchor your plan in numbers, not vibes. (The Verge)

Case‑study quick hits (for your deck)

• Do not freeze features for years unless the payoff is existential. Netscape’s rewrite helped forfeit the browser war. (Joel on Software)

• Small, surgical rebuilds can delight users. Slack desktop, Snapchat Android, Firefox Quantum each earned material performance wins that users felt. (The Verge)

• You can scale a monolith (for a long time). Etsy and Shopify prove it with disciplined modularity and tooling. (Etsy)

• APIs keep legacy valuable. Amazon’s internal SOA, and mainframe API layers, let old cores power new businesses. (Courses at Washington)

• Neglect is costly. Southwest’s meltdown and Equifax’s patch failure are reminders that “leave it alone” is not “ignore it.” (Department of Transportation)

Final thought

Martin Fowler’s advice to start monolith‑first and evolve boundaries is still wise. Microservices, rewrites, and new languages are means, not ends. Choose the option that maximizes time‑to‑value and risk reduction for your context, measure it with DORA and WSJF, and ship it incrementally via Strangler and Branch by Abstraction.

If your product’s core is stable and compliant, encapsulate and invest around it. If architecture blocks your users or your security team, rebuild specific parts with clear ROI. And if your instincts say “rewrite everything,” remember Spolsky’s warning-and make sure your runway, and your users, won’t run out before you land. (martinfowler.com)

1) “Product management is responsible for discovering a product that is valuable, usable, and feasible.” — Marty Cagan

Who said it (short bio): Marty Cagan is a founding partner at Silicon Valley Product Group, former product leader at eBay and Netscape, and the author of Inspired and Empowered.

Why product managers repeat it: This definition crisply captures the PM’s real job: discovery, not just delivery. “Valuable” centers the customer and the business; “usable” anchors UX; “feasible” respects engineering realities. If your idea doesn’t satisfy all three, it isn’t ready.

2) “Innovation is saying no to 1,000 things.” — Steve Jobs

Who said it (short bio): Steve Jobs co‑founded Apple and led the creation of the Mac, iPod, iPhone, and iPad—products that reshaped consumer technology.

Why product managers repeat it: Focus is the most under‑appreciated superpower in product. This line reminds PMs that strategy is subtraction: every “no” preserves the time and attention needed to make the right “yes” excellent.

3) “We are stubborn on vision. We are flexible on details.” — Jeff Bezos

Who said it (short bio): Jeff Bezos founded Amazon and popularized a culture of long‑term thinking, customer obsession, and working backward from the desired customer experience.

Why product managers repeat it: A good product strategy is a strong “north star” paired with tactical adaptability. This quote legitimizes iteration and pivots without losing sight of the end state you’re building toward.

4) “If you’re not embarrassed by the first version of your product, you’ve launched too late.” — Reid Hoffman

Who said it (short bio): Reid Hoffman co‑founded LinkedIn, is a partner at Greylock, and hosts the Masters of Scalepodcast.

Why product managers repeat it: Perfect is the enemy of learning. Early releases—warts and all—let teams validate demand, discover edge cases, and focus effort where it matters. Shipping creates clarity.

5) “The minimum viable product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.” — Eric Ries

Who said it (short bio): Eric Ries is an entrepreneur and the author of The Lean Startup, a playbook that brought scientific experimentation to product development.

Why product managers repeat it: MVPs aren’t under‑baked products; they’re tightly scoped experiments. This quote reframes MVP as a learning vehicle, not a cheap release—use it to protect your MVPs from bloat.

6) “People don’t buy products; they hire them to do a job.” — Clayton M. Christensen

Who said it (short bio): Harvard Business School professor Clayton Christensen wrote The Innovator’s Dilemma and helped popularize Jobs‑to‑Be‑Done theory.

Why product managers repeat it: Switching perspective from features to “jobs” illuminates unmet needs and competing alternatives. It keeps you from optimizing the wrong thing and helps your product win in the context of the customer’s life.

7) “We must design for the way people behave, not for how we would like them to behave.” — Don Norman

Who said it (short bio): Don Norman is a cognitive scientist and author of The Design of Everyday Things, and was once Apple’s VP of Advanced Technology.

Why product managers repeat it: Real users are busy, distracted, and imperfect. This line urges PMs to ground decisions in observation and evidence, not wishful thinking about “ideal users.”

8) “The aim of marketing is to know and understand the customer so well the product or service fits him and sells itself.” — Peter F. Drucker

Who said it (short bio): Peter Drucker is often called the father of modern management; his ideas have shaped how organizations run and innovate.

Why product managers repeat it: Product and marketing share the same goal: fit. When you deeply understand segments, pains, and contexts, your product narrative writes itself—and acquisition gets far easier.

9) “The essence of strategy is choosing what not to do.” — Michael E. Porter

Who said it (short bio): Michael Porter is a Harvard professor known for the Five Forces framework and foundational work on competitive strategy.

Why product managers repeat it: Roadmaps often fail from over‑commitment, not bad ideas. Porter’s line makes trade‑offs explicit: choosing not to pursue certain segments, platforms, or features is how you achieve differentiation and momentum.

10) “Good design is as little design as possible.” — Dieter Rams

Who said it (short bio): Dieter Rams led design at Braun and formulated the “Ten Principles of Good Design,” influencing generations of product designers.

Why product managers repeat it: Simplicity increases adoption. This quote is a lens for pruning: remove the marginal feature, reduce the configuration, and build defaults that feel obvious.

11) “Your most unhappy customers are your greatest source of learning.” — Bill Gates

Who said it (short bio): Bill Gates co‑founded Microsoft and later the Bill & Melinda Gates Foundation, shaping both software and global health.

Why product managers repeat it: Complaints, cancellations, and churn interviews spotlight the gaps your dashboards gloss over. Lean in—those sharp edges are often your fastest path to retention and growth.

12) “In God we trust; all others must bring data.” — W. Edwards Deming(attributed)

Who said it (short bio): Deming was a statistician and quality pioneer whose ideas fueled modern manufacturing and continuous improvement.

Why product managers repeat it: Opinions (even yours) are cheap; evidence is precious. This line keeps stakeholder debates honest and pushes teams to instrument, experiment, and measure outcomes—not outputs.

13) “Make something people want.” — Paul Graham

Who said it (short bio): Paul Graham co‑founded Y Combinator and is known for essays on startups and product.

Why product managers repeat it: It’s deceptively simple. When you stay close to real user demand, you beat feature anxiety and vanity roadmap items. Demand pulls product; it can’t be pushed.

14) “The only thing that matters is getting to product/market fit.” — Marc Andreessen

Who said it (short bio): Marc Andreessen co‑founded Netscape and investment firm Andreessen Horowitz; he coined “product/market fit” in a seminal essay.

Why product managers repeat it: Before PMF, nothing scales; after PMF, almost everything does. This quote keeps teams focused on the signals that actually matter early: retention, love, organic pull.

15) “People don’t want to buy a quarter‑inch drill; they want a quarter‑inch hole.” — Theodore Levitt

Who said it (short bio): Theodore Levitt was a Harvard marketing professor best known for the classic essay “Marketing Myopia.”

Why product managers repeat it: Outcomes over outputs. It’s a reminder to frame value in the result customers seek—not in the tool you’re proud of building.

16) “The best way to predict the future is to invent it.” — Alan Kay

Who said it (short bio): Alan Kay is a computer scientist who helped pioneer object‑oriented programming and the graphical user interface.

Why product managers repeat it: Vision matters. This line gives PMs permission to lead with a compelling future state and then work backward, instead of waiting for consensus or precedent.

17) “Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.” — Antoine de Saint‑Exupéry

Who said it (short bio): Saint‑Exupéry was a French aviator and author of The Little Prince.

Why product managers repeat it: Scope creep is relentless. This quote is your shield: tighten the core use case, reduce mode switches, trim preferences, and make the path to value obvious.

18) “Don’t make me think.” — Steve Krug

Who said it (short bio): Steve Krug is a usability consultant; his book Don’t Make Me Think is the go‑to primer on web usability.

Why product managers repeat it: Cognitive load kills conversion. Every extra decision, field, or label invites drop‑off. This reminder keeps flows intuitive and documentation thin because the product itself explains itself.

19) “Customers will never love a company until the employees love it first.” — Simon Sinek

Who said it (short bio): Simon Sinek is a leadership author and speaker best known for Start With Why.

Why product managers repeat it: Culture shows up in the product. If teams feel rushed, ignored, or misaligned, customers will feel it too. PMs who nurture trust and purpose end up shipping more thoughtful experiences.

20) “Fall in love with the problem, not the solution.” — Uri Levine

Who said it (short bio): Uri Levine co‑founded Waze and authored Fall in Love with the Problem, Not the Solution.

Why product managers repeat it: Attachment to a solution blinds teams to superior options. Anchoring on the problem keeps discovery alive, ideas diverse, and pivots emotionally easier when the evidence points elsewhere.

How to use these quotes in practice

• Kick off discovery: Start workshops by reading #6 (Christensen) and #20 (Levine). They reset the room around customer progress, not features.

• Prioritize ruthlessly: Use #2 (Jobs) and #9 (Porter) to justify trimming your roadmap and aligning around a sharp strategy.

• Accelerate learning: Pair #4 (Hoffman) and #5 (Ries) to frame early releases as experiments and protect MVP scope.

• Elevate quality without bloat: #10 (Rams), #17 (Saint‑Exupéry), and #18 (Krug) are your guardrails against complexity.

• Align the org: #3 (Bezos) and #19 (Sinek) help you connect mission, culture, and execution—so you can move fast and together.

• Stay evidence‑driven: #12 (Deming, attributed) reminds stakeholders that data is a common language when opinions diverge.

Closing thought

Product management lives at the intersection of vision, empathy, and evidence. The lines above endure because they translate complex ideas into navigational beacons you can carry into any stand‑up, review, or board meeting. Pick three or four that address your team’s current challenges—pin them to the top of your docs, put them in your onboarding materials, and revisit them in retros. Over time, they won’t just be quotes; they’ll be part of how your team thinks.

1) Start with the “five constant factors”

“The art of war…is governed by five constant factors… (1) Moral Law; (2) Heaven; (3) Earth; (4) The Commander; (5) Method and discipline.” (Internet Classics Archive)

Product translation.
Before you commit to a roadmap, assess your environment along five analogous dimensions:

• Moral law → Mission/strategy fit. Do we have a shared, credible product strategy customers and executives can rally around?

• Heaven → Timing. Seasonality, regulatory windows, technology waves—are we launching at a favorable moment?

• Earth → Terrain. Platform constraints, app store policies, partner ecosystems, distribution channels.

• Commander → Leadership. Do product, design, and engineering leaders exhibit clarity and courage, and make decisions quickly?

• Method/discipline → Process & economics. Do we have the operating model (cadence, budgeting, release process, analytics) to sustain momentum?

Treat this as your pre‑mortem checklist. It’s a fast way to surface hidden dependencies before you promise dates. (Marxists Internet Archive)

2) Know your market and yourself—or be surprised later

“If you know the enemy and know yourself, you need not fear the result of a hundred battles.” (gutenberg.org)

Product translation.
Run two loops continuously:

• Know the market: competitor teardowns, win/loss interviews, pricing scans, and usage telemetry.

• Know yourself: are you actually at or near product/market fit?

A simple, research‑backed test is the Sean Ellis PMF survey. Across ~100 startups, teams with strong traction consistently had ≥40% of users who would be “very disappointed” if the product went away; those who struggled were typically <40%. This gives you a crisp, comparable signal to prioritize retention and fit before chasing scale. (First Round)

Practice: instrument the PMF survey for your active users quarterly; pair it with cohort retention and a short “top three reasons why” prompt.

3) Win without fighting: design for uncontested space

“Supreme excellence consists in breaking the enemy’s resistance without fighting.” (Internet Sacred Text Archive)

Product translation.
Competing feature‑for‑feature is trench warfare. Applying Blue Ocean Strategy means reframing the basis of competition and creating fresh demand (e.g., Cirque du Soleil’s hybrid of theatre and circus). Summaries of the research note that a minority of “new market” moves generated a disproportionate share of revenues and profits in studied portfolios—evidence that reframing the game can beat incrementalism. (moodle.najah.edu)

Practice: build a simple strategy canvas around the key factors customers weigh today, then deliberately change the curve—eliminate/raise/reduce/create.

4) Know when not to build

“He will win who knows when to fight and when not to fight.” (gutenberg.org)

Product translation.
Saying “no” is a strategic act. Use RICE scoring (Reach × Impact × Confidence ÷ Effort) to force clear trade‑offs and explain them to stakeholders. RICE originated at Intercom and is now widely used to neutralize bias in prioritization debates. (Intercom)

Complement RICE with Cost of Delay (CoD): if you quantify only one thing, quantify how much money (or mission impact) you lose each week you don’t ship a given capability. CoD reframes prioritization from opinion to economics. (Project Management Institute)

5) Avoid protracted projects

“There is no instance of a nation benefiting from prolonged warfare.” (en.wikiquote.org)

Product translation.
Long, monolithic projects destroy optionality and raise risk. The Project Management Institute reports that organizations still waste a measurable share of investment due to poor project performance—~11.4% in 2020, improving to ~9.4% in 2021. Time‑boxing and incremental delivery help you escape this gravity well. (Project Management Institute)

Practice: plan in 6–8 week “bets” with explicit kill or continue criteria. Decompose epics until each slice changes a KPI, not just code.

6) Speed is a weapon—if you keep quality

“Rapidity is the essence of war.” (gutenberg.org)

Product translation.
Fast feedback loops—not heroics—let you learn and adapt. The DORA/Accelerate research program provides an evidence‑based way to measure software delivery: deployment frequency, lead time for changes, change failure rate, and time to restore service. High performers on these “Four Keys” correlate with better organizational outcomes across industries. (Dora)

Practice: baseline your Four Keys, set targets, and invest in CI/CD to raise deployment frequency while lowering failure rates (the research shows speed and stability can improve together). (Google Services)

7) Use “deception” ethically: experiment in the open, launch in the dark

“All warfare is based on deception.” (University of Alberta)

Product translation.
In product, “deception” isn’t about misleading customers; it’s about controlling blast radius. Ship behind feature flagsand do progressive delivery so customers only encounter changes when they’re ready—and you can turn things off instantly. Martin Fowler’s seminal write‑up explains the technique and its trade‑offs; modern trunk‑based workflows reduce merge pain and risk. (martinfowler.com)

Practice: default to short‑lived release toggles; require a removal plan for every flag to prevent “flag debt.”

8) Concentrate force where it matters: reallocate aggressively

Sun Tzu emphasizes massing strength at decisive points and avoiding the enemy’s strongholds. In corporate terms: don’t starve your best opportunities.

Independent research shows dynamic resource reallocation—shifting capital, talent, and attention to high‑return areas—correlates with superior shareholder returns and resilience. If you allocate in straight lines year after year, value suffers. (McKinsey & Company)

Practice: at least quarterly, move people and budget toward the top two opportunities on your strategy canvas—even if it means pruning pet projects.

9) Keep supply lines short: instrument discovery and delivery

“By method and discipline are to be understood…the maintenance of roads by which supplies may reach the army.” (Marxists Internet Archive)

Product translation.
Your “roads” are customer insight and deployment pipelines. Teresa Torres defines continuous discovery as weekly touchpoints with customers by the team that’s building the product. Pair that with rapid prototyping and small‑batch delivery to sustain flow from insight to impact. (Product Talk)

When you need quick usability signals, don’t over‑engineer research: the Nielsen Norman Group has long shown that small qualitative tests (≈5–9 users) uncover most usability issues for a specific flow—cheaply and fast. (Nielsen Norman Group)

10) Align morale and mindset

“He will win whose army is animated by the same spirit throughout all its ranks.” (Marxists Internet Archive)

Product translation.
The best practices in the world won’t overcome a fearful culture. Google’s Project Aristotle found that psychological safety—people feeling safe to take interpersonal risks—is the top factor in effective teams. Create space to speak up, surface bad news early, and run blameless postmortems. (Rework)

11) Strike where competitors are weak

Sun Tzu advises attacking the opponent’s plans and weak points rather than their strengths. For products, that means: don’t reflexively chase parity on their best features.

Use Opportunity Solution Trees to reveal better routes to your outcome than a head‑to‑head fight; they help teams compare opportunities and solutions in one visual map and avoid “build the thing” tunnel vision. (Product Talk)

Practice: for each major OKR, map the opportunity space (jobs, pains, desires) and test multiple solution spikes in parallel.

12) Convert speed into learning—safely

Speed without learning is thrash; learning without safety is chaos. The DORA research shows that elite delivery isn’t about recklessness: improving lead time, deployment frequency, reliability, and recovery together predicts better organizational performance. That gives product leaders an empirical argument for investing in engineering excellence as a growth lever, not just a cost center. (Dora)

Practice: track your Four Keys alongside product outcomes (activation, retention, expansion). Tie “engineering bets” to leading indicators (e.g., faster “lead time for changes” → more experiments/month → higher win rate on experiments).

Playbook: a one‑quarter “Art of War” plan for PMs

1. Week 1: Environmental scan (the five factors).
   Create a single slide per factor (mission fit, timing, terrain, leadership, process) listing risks and opportunities. Use this to align execs before revising the roadmap. (Internet Classics Archive)

2. Week 2: Know yourself & the market.
   Run the PMF 40% survey with active users; analyze by segment. In parallel, compile a teardown of the top two competitors’ strengths and gaps. (First Round)

3. Week 3: Opportunity Solution Tree + RICE + CoD.
   Map the opportunity space for your top outcome, brainstorm solutions, then score with RICE and Cost of Delay to decide what not to do. (Product Talk)

4. Weeks 4–8: Two discovery sprints; ship in the dark.
   Prototype & test 2–3 solution spikes (5–9 users each, per flow). Ship the leading candidate behind feature flags to a small cohort; watch leading metrics; iterate weekly. (Nielsen Norman Group)

5. Weeks 9–12: Expand, measure, reallocate.
   If the flag cohort clears your guardrails (conversion, retention, CFR/MTTR), begin progressive rollout. Move people and budget toward what’s clearly working; kill one stalled initiative to pay for it. Track your Four Keys to keep speed and stability in balance. (Dora)

Closing thought

Sun Tzu’s lines are compact, but their modern product meaning is clear:

• Diagnose the landscape before you move (five factors).

• Learn faster than rivals (PMF signals, usability sprints, Four Keys).

• Pick your battles (RICE + CoD) and avoid protracted campaigns (time‑box and ship small).

• Shape markets rather than chase them (blue oceans).

• Build teams that can tell you the truth quickly (psychological safety).

Do these, and you’ll “win” the only battles that matter in product: faster learning, happier customers, and compounding business impact.

A well‑crafted PRD is a leverage point against those odds. As product veteran Marty Cagan put it, “If the PRD is not done well, it is nearly impossible for a good product to result.” (CIMIT MAIN) But “good” today doesn’t mean a 50‑page tome. It means a crisp, collaborative, testable artifact that enables engineering to ship the right thing with minimal ambiguity.

Below is a practical playbook—best practices, structure, and examples—to help you write PRDs that do exactly that.

First principles: Start with customers and outcomes

Amazon’s first leadership principle states, “Leaders start with the customer and work backwards.” (amazon.jobs) Their Working Backwards process operationalizes this principle with a press release + FAQ (“PR/FAQ”) that forces clarity on value before solution details. You don’t need to adopt the PR/FAQ wholesale to borrow the mindset: your PRD should begin with the user problem and the business outcome, not with interface details or database fields. (Working Backwards)

To make this concrete, open your PRD with:

• Problem statement: Who’s struggling? What job-to-be-done isn’t met?

• Success metrics: The measurable outcomes that define “done” (activation lift, NPS improvement, support ticket reduction, etc.).

• Hypothesis: Why this change will move those metrics.

This framing keeps teams oriented toward outcomes rather than output.

The anatomy of a modern PRD (plus a reusable template)

There’s no single “right” format, but strong PRDs tend to share common sections. Atlassian’s widely used templates emphasize basics (context), objectives and success metrics, and assumptions—good scaffolding for most teams. (Atlassian)

Recommended sections

1. Overview & context

   • One paragraph: What we’re doing and why now. Link to discovery notes, research plans, and any PR/FAQ or pitch.

2. Goals & success metrics

   • The outcomes you expect and how you’ll measure them (leading and lagging indicators). Tie to company/product goals.

3. Users & use cases

   • Audience, personas, or jobs-to-be-done. Include primary scenarios.

   • Express behaviors as user stories: “As a <user>, I want <goal> so that <benefit>.” The Agile Alliance popularized this simple template to keep requirements human‑centered. (Agile Alliance)

4. Scope

   • In scope: The smallest set of capabilities to achieve the goals.

   • Out of scope / later: Equally important to prevent scope creep and protect timelines.

5. Functional requirements

   • Bullet the behaviors the system must support. Favor plain language.

6. Acceptance criteria (make requirements testable)

Write Given / When / Then scenarios so QA and dev can automate against them. Example:
Scenario: Reset password via email

Given an existing user with a verified email

When they request a password reset

Then they receive a reset link that expires in 15 minutes

• This Gherkin style aligns product/QA/dev and reduces interpretation gaps. (cucumber.io)

7. Non‑functional requirements (NFRs)

   • Performance, security, reliability, usability, maintainability, etc. ISO/IEC 25010 groups these quality attributes into eight categories—use them as a checklist to avoid “forgotten” requirements. (ISO 25000)

8. Design & UX

   • Link to wireframes/prototypes. (As Marty Cagan argues, “the majority of the product spec should be the high‑fidelity prototype.”) (Silicon Valley Product Group)

9. Analytics & telemetry

   • What events are tracked, where, and why. Define funnels, properties, and retention of data (plus privacy/compliance notes).

10. Dependencies & constraints

    • APIs, platform limits, legal/compliance, localization, releases, training.

11. Risks & assumptions

    • Call out the four big risks: value, usability, feasibility, and business viability. State how you’ll mitigate each. (Silicon Valley Product Group)

12. Rollout & ops

    • Phasing, guardrails, feature flags, support readiness, migration/backfill plans.

13. Open questions & decisions

    • Capture what’s unresolved and record decisions with owners and dates.

14. Changelog

    • Keep the doc living and searchable.

Copy‑paste PRD template (Markdown)

# Title: <Feature / Project Name>

**Doc owner:** <name> • **Last updated:** <YYYY-MM-DD> • **Status:** Draft/Review/Final

## 1) Overview & Context

One paragraph on the problem, why now, and links to discovery/PRFAQ/pitch.

## 2) Goals & Success Metrics

- Primary metric(s): <metric, target, time window>

- Secondary metric(s):

- Guardrails (what must not regress):

## 3) Users & Use Cases

- Audience/persona/JTBD:

- Key use cases:

- As a <user>, I want <goal> so that <benefit>.

## 4) Scope

- **In scope:** …

- **Out of scope / later:** …

## 5) Functional Requirements

- FR-1: …

- FR-2: …

## 6) Acceptance Criteria (Gherkin)

- Scenario: …

Given …

When …

Then …

## 7) Non-Functional Requirements (ISO 25010 cues)

- Performance: …

- Reliability/Availability: …

- Security/Privacy: …

- Usability/Accessibility: …

- Maintainability/Portability/Compatibility: …

## 8) Design & UX

- Links to prototypes, UI specs, content strings, empty states.

## 9) Analytics & Telemetry

- Events and properties, dashboards, alert thresholds.

## 10) Dependencies & Constraints

- External systems/APIs, legal/compliance/localization, platform limits.

## 11) Risks & Assumptions

- Value risk: …

- Usability risk: …

- Feasibility risk: …

- Business viability risk: …

- Assumptions: …

## 12) Rollout & Ops

- Phases/flags, migration/backfill, support/SOPs, training.

## 13) Open Questions

- Q1: … (owner, due)

- Q2: …

## 14) Decisions (Rationale)

- D1: … (date, approvers)

## 15) Changelog

- <YYYY-MM-DD>: <what changed> (owner)

Use this template “as‑is” for features, or scale it down to a one‑pager for small improvements.

Make requirements testable (and automation‑friendly)

Ambiguity is your enemy. User stories articulate why; acceptance criteria make the what verifiable. Gherkin’s Given/When/Then syntax forces you to specify context, action, and observable outcome—ideal for both manual and automated tests. (cucumber.io)

A few tips:

• Write criteria that a non‑developer can check.

• Prefer specific thresholds (“p95 response time < 500 ms”) over adjectives (“fast”).

• Cover happy path and edge cases (error states, timeouts, permissions).

• Tie each criterion to a test case or automated spec to enable traceability later.

Don’t forget the “ilities” (NFRs)

Many PRDs list functional requirements yet bury (or omit) non‑functional ones. That’s a recipe for rework. Use ISO/IEC 25010’s quality attributes—performance efficiency, reliability, usability, security, compatibility, maintainability, portability, and functional suitability—as a checklist. Even one line per attribute dramatically improves alignment between product, design, and architecture. (ISO 25000)

Examples:

• Performance: p95 search latency < 200 ms at 2× current traffic.

• Security: all PII encrypted at rest (AES‑256) and in transit (TLS 1.3).

• Reliability: 99.9% monthly availability; SLOs with alerts to on‑call.

• Accessibility: WCAG 2.2 AA for new UI.

Prioritize what makes the PRD (and what waits)

A PRD should constrain, not collect. Intercom’s RICE framework—Reach × Impact × Confidence ÷ Effort—is a simple way to stack‑rank candidate scope and keep the document focused on what moves the needle. Add the RICE score next to each functional requirement or open question so trade‑offs are visible. (Intercom)

Pair the PRD with prototypes (not paragraphs)

Length is not clarity. Cagan’s guidance is blunt: “the majority of the product spec should be the high‑fidelity prototype.” Screens + flows often resolve questions that pages of prose cannot. Embed links to click‑through prototypes and annotate the tricky interactions; then keep the body text short and decisive. (Silicon Valley Product Group)

Tooling and templates you can borrow

• Atlassian: battle‑tested Confluence PRD templates and a broader collection for product managers. Great for teams already in Jira/Confluence. (Atlassian)

• Notion: flexible PRD templates if your org prefers docs + databases; easy to keep “living” with comments and status properties. (Notion)

• GitLab: built‑in requirements management can connect requirements to issues and tests, giving you traceability from PRD to validation. (GitLab Docs)

Pick the platform your engineering partners already live in; the best PRD is the one people actually read and update.

Alternative formats you should know (and when to use them)

Amazon PR/FAQ (Working Backwards). If your biggest risk is value (will anyone care?) use a narrative PR/FAQ or “press release from the future” first. It forces customer impact and positioning clarity before you dive into mechanics. Use a PR/FAQ as a precursor to the PRD; once leadership aligns, translate its promises into testable requirements. (Working Backwards)

Basecamp’s Shape Up “Pitch.” If you operate in fixed cycles, the pitch is a lean alternative: problem, appetite (time budget), core solution, rabbit holes, and no‑gos. It’s ideal for teams that want to bet on outcomes within strict time boxes; you can still attach acceptance criteria and NFRs to raise the spec’s fidelity. (Basecamp)

Lean PRD one‑pager. For minor enhancements, compress the template to: Problem → Goal metric → Scope (in/out) → 3–5 acceptance criteria → NFRs (only those at risk). The point is to preserve decisiveness without ceremony.

Importantly, beware the anti‑pattern of using documents instead of discovery. Cagan cautions against a “reversion to heavy artifacts such as PRDs” as a substitute for product discovery work. Your PRD should capture validated decisions, not replace validation. (Silicon Valley Product Group)

Review cadence: Treat the PRD as a living contract

Think of the PRD as a living agreement among product, design, engineering, data, and go‑to‑market:

• Kickoff review: Walk the team through context, scope, and risks.

• Design review: Validate UX specs and empty states against acceptance criteria.

• Pre‑build review: Confirm NFRs, analytics, and dependencies.

• Changelog discipline: Every material change gets dated and owned so nobody is working from stale assumptions.

For teams that need traceability (regulated industries), link each requirement to tests or issues so you can show proof of verification later—something platforms like GitLab support out of the box. (GitLab Docs)

Common PRD pitfalls (and how to avoid them)

1. Jumping to solutions. If your PRD starts with UI, you’re probably skipping “why.” Force yourself to write the problem and the target metric first. Borrow Working Backwards language if it helps. (Working Backwards)

2. Vague acceptance criteria. “It should be fast” invites arguments; “p95 < 500 ms” ends them. Use Given/When/Then to codify behavior. (cucumber.io)

3. Ignoring NFRs. Bugs get fixed; missing security or reliability requirements can become headlines. Use ISO 25010 as a checklist. (ISO 25000)

4. Spec bloat. If a requirement can’t be tied to a goal or a RICE score, it doesn’t belong (yet). (Intercom)

5. Documents replacing discovery. Keep doing customer interviews, prototypes, and tests; then let the PRD memorialize what you learned. (Silicon Valley Product Group)

A 15‑minute PRD checklist

• Problem statement grounded in customer evidence (or PR/FAQ link). (Working Backwards)

• Clear goals and measurable success metrics.

• User stories for key scenarios. (Agile Alliance)

• In‑scope vs out‑of‑scope explicitly listed.

• Functional requirements listed as behaviors, not solutions.

• Acceptance criteria in Given/When/Then for each requirement. (cucumber.io)

• NFRs checked against ISO 25010 categories. (ISO 25000)

• Prototype links embedded; copy and empty states included. (Silicon Valley Product Group)

• Dependencies, analytics events, and rollout plan documented.

• Risks (value, usability, feasibility, viability) and mitigations recorded. (Silicon Valley Product Group)

• Decisions and open questions tracked with owners and due dates.

• Changelog entries for every material update.

Pulling it together

A good PRD is not bureaucracy—it’s clarity on paper. It starts with the customer’s problem, codifies success, makes behavior testable, and surfaces risks early. Done well, it becomes the shared compass that lets engineering and design move fast without breaking context. That’s how teams escape the trap McKinsey describes—overruns and under‑delivered value—and ship products that do what they promised. (McKinsey & Company)

If you adopt just three practices from this guide, make them these:

1. Lead with outcomes and users (Amazon’s “work backwards” in spirit). (amazon.jobs)

2. Write testable acceptance criteria (Given/When/Then for every requirement). (cucumber.io)

3. Enumerate NFRs explicitly (use ISO 25010 as your checklist). (ISO 25000)

Do that consistently, and your PRD becomes a force multiplier: fewer meetings, fewer surprises, and a much higher chance that what ships is what matters.

Cue the HiPPO-Highest Paid Person’s Opinion-lumbering majestically across your product strategy. The HiPPO was coined and popularized by experimentation leaders like Ronny Kohavi (who even printed HiPPO stress toys to remind teams to test ideas instead of obey them). The lesson: decisions should be informed by users and experiments, not (just) the org chart. (ExP Platform)

This isn’t a “down with CEOs” screed. Great CEOs set vision, unblock, and raise the bar. But the CEO is not your user, and when you build for the corner office instead of the customer, you pay a tuition you didn’t budget for.

Let’s unpack why the HiPPO is so tempting, what the data says about our intuition, a few real‑world “ouch” stories, and a playbook to keep you (and your roadmap) user‑centered-with a bit of humor to keep the hippos at bay.

Why we keep listening to the HiPPO (and why that’s risky)

1) Authority bias is real. Humans overweight the opinions of authority figures-bosses, experts, charismatic founders-even when evidence is thin. Psychologists call this authority bias. It’s a diagnostic, not a character flaw. Recognize it so you can design around it. (The Decision Lab)

2) Our “gut feel” is less accurate than we think. In large‑scale online experiments at Microsoft and elsewhere, only about one‑third of ideas move the intended metric, another third are neutral, and a third make things worse. Translation: treating a leader’s idea as a sure thing is a great way to collect unplanned learnings-and red dashboards. Controlled experiments convert opinions (including the CEO’s) into testable bets. (Harvard Business Review)

3) We don’t spend enough time with customers to resist the HiPPO. A Pendo survey found 74% of product pros spend fewer than five hours per month with customers-far below the “at least weekly touchpoints” standard many discovery coaches recommend. If the loudest voice is internal, of course it wins. (Pendo.io)

The receipts: cautionary tales of building for the wrong audience

Quibi: “We’ll reinvent TV for phones.”
Founded by Jeffrey Katzenberg and led by Meg Whitman, Quibi raised $1.75B to deliver Hollywood‑grade, mobile‑only “quick bites.” Six months after its April 2020 launch, the service shut down. Critics cited misjudged user habits (mobile video ≠ mobile‑only paid content), limited sharing, and a wobbly feature set for the actual market. It’s a case study in betting on executive instinct over observable behavior (say, what people already did on TikTok and YouTube). (Wikipedia)

Juicero: “Wi‑Fi, but for juice.”
A $400 connected press… for proprietary pouches you could squeeze by hand. Juicero raised around $120M before a 2017 Bloomberg demo torpedoed the premise; the company offered refunds and shut down. When reality (squeezing) beats your value prop (machine), your product was built for a boardroom pitch, not a kitchen counter. (Bloomberg.com)

New Coke: “People prefer sweeter in blind tests.”
In 1985, Coca‑Cola reformulated its flagship after nearly 200,000 consumer taste tests suggested a preference for a sweeter formula. The backlash was instant. Turns out, people weren’t just buying taste; they were buying identity and ritual. A hard lesson in context: test environments can’t capture brand attachment. (To Coke’s credit, they listened and reversed course.) (Coca-Cola Company)

Snap Spectacles: “We’re a camera company now.”
After hype and vending‑machine lines, Snap wrote down ~$40M in unsold Spectacles inventory; media reported hundreds of thousands of units sitting in warehouses, and fewer than half of buyers used them after a month. Early sizzle ≠ product‑market fit. Don’t let launch buzz substitute for sustained use. (The Verge)

If those feel a bit “celebrity fail,” here’s a data‑first counterexample:

Netflix’s thumbs beat stars (by a lot).
In 2017, Netflix A/B‑tested its 5‑star rating against a simple thumbs up/down. Result: 200%+ more ratings activity, which improved recommendations. That wasn’t someone’s opinion; it was a controlled test. (Business Insider)

Friendly reminder: craft matters (and pays off)

Think “customer‑obsessed” is just a slogan? McKinsey’s multi‑year study of 300+ public companies found those in the top quartile of its Business Value of Design index grew revenues 32 percentage points and total returns to shareholders 56 percentage points faster than peers over five years. Great design and user focus don’t just feel good; they show up in P&L. (McKinsey & Company)

Or, as Jeff Bezos wrote: “There are many ways to center a business… obsessive customer focus is by far the most protective of Day 1 vitality.” He also reminds us that many decisions are two‑way doors-reversible-so you can move fast and correct with data. Don’t turn reversible bets into board‑level epics. (About Amazon)

The tell‑tale signs you’re building for the CEO (not the user)

• Roadmap items begin as quotes, not problems. “ ‘Make it pop’ by Q3” is not a user need.

• Discovery is “that thing we do after the press release.” (You can hear your research lead sobbing in Figma.)

• Success criteria are… vibes. “We’ll know it when we see it” works for latte art, not product bets.

• You cite one Very Important Person as “the persona.” Congrats, your target market is the executive floor.

If any of the above stung, don’t worry. We’ve all been there. Let’s fix it.

The playbook: user‑centric, data‑driven, CEO‑friendly

1) Make weekly customer touchpoints non‑negotiable.
Book a recurring hour to watch people use your product, interview recent sign‑ups or churns, or shadow support. Bring your designer and lead engineer. Teresa Torres calls weekly touchpoints the minimal standard for continuous discovery. It’s how teams keep their instincts calibrated to reality. (Product Talk)

2) Translate executive ideas into testable hypotheses.
When a leader says “ship the holographic carousel,” reply with:

Hypothesis: Onboarding completion will rise from 62% → 70% because the carousel surfaces key actions sooner.
Test: In‑product A/B with a 10% holdout; success = +8pp completion; guardrail = no drop in 7‑day retention.
This reframes opinion as a bet, which is where the Microsoft/HBR “one‑third improve, one‑third hurt” reality forces healthy humility. (Harvard Business Review)

3) Use two‑way doors to go fast (safely).
Label decisions Type 1 (consequential, hard to undo) vs. Type 2 (reversible). For Type 2, default to shipping the smallest viable test and measuring, not debating. Your CEO likely already believes this; Bezos literally wrote it down. (Q4 Investor Relations)

4) Prioritize with a bias‑reducing framework (and show your math).
RICE (Reach × Impact × Confidence ÷ Effort) came out of Intercom’s attempts to compare unlike ideas fairly. The magic is less the score and more the conversation it forces about user reach and confidence (a perfect place to inject research). Bonus: share the sheet with leadership; sunlight is the best disinfectant for pet projects. (Intercom)

5) Anchor the roadmap to a North Star (so “no” is a service).
Define one North Star Metric that captures customer value (plus 3–5 input metrics you can actually move). When a HiPPO request lands, assess whether it moves an input. If not, you can say “yes-if we drop X, because our NSM is Y.” It’s not insubordination; it’s alignment. Amplitude’s North Star Playbook is a practical primer. (Amplitude)

6) Instrument before you build.
A shocking number of teams bolt on analytics after launch, then wonder why “success” is a mood. For every bet, define leading indicators and guardrails up front. If Netflix can test ratings systems and roll with the results, you can test that onboarding tour. (Business Insider)

7) Tell the story in writing, not just in slides.
A short narrative memo (context → options → trade‑offs → recommendation) calms rooms, aligns stakeholders, and makes HiPPOs read. Amazon normalized this because writing is thinking; it works outside Seattle, too. (About Amazon)

“But my CEO is a power user…”

Lucky you-but that still doesn’t make them the user. They represent N=1, with edge‑case access, enterprise‑grade laptops, perfect Wi‑Fi, and a personal Slack channel called “everyone.” Treat their input as a valuable data point, then triangulate with (a) observed user behavior, (b) market signals, and (c) experiment results. When those align, you’ve got a bet worth escalating.

If you need a polite deflection, try:

• The “Yes, if”: “Yes-if we can prototype and test with 50 new users next week; if we see +8pp activation, we’ll scale.”

• The “Compare, don’t decide”: “We’ll test your idea alongside two alternatives; we’ll bring back evidence in two sprints.”

• The “Door type”: “This is a Type 2 decision; we can ship and measure by Friday. If it’s a miss, we’ll roll back.” (Q4 Investor Relations)

A short, sharp checklist (print this; tape it above the roadmap)

To avoid building for the HiPPO:

1. Users weekly: At least one real customer touchpoint, every week, with your product trio. (Product Talk)

2. Hypotheses before handoffs: Every initiative has a user problem, a causal hypothesis, a success metric, and guardrails. (Harvard Business Review)

3. Two‑way door by default: If reversible, prototype and test; don’t convene the Grand Council. (Q4 Investor Relations)

4. RICE the backlog: Publish the scoring; force the conversation about reach and confidence. (Intercom)

5. North Star or it waits: If it doesn’t move the NSM or its inputs, it’s not on this quarter’s plan. (Amplitude)

Real‑world script: defusing a HiPPO in three moves

Scenario: CEO wants to replace onboarding with a 3‑minute sizzle reel because “our story is emotional.”

1. Reframe as a user problem: “New users don’t reach first value in 24 hours; activation is 62%.”

2. Offer options: “We can test (A) your sizzle reel, (B) a 3‑step checklist, (C) contextual tips. We’ll A/B/C test 10% of traffic.”

3. Pre‑commit metrics: “Success = activation +8pp; guardrails = 7‑day retention, support contacts flat.”

4. Invoke the two‑way door: “Reversible change; if it misses, roll back by end of week.”

5. Bonus: share a case: “Netflix saw 200%+ more ratings with thumbs vs. stars after testing-simple wins when the data says so. Let’s let the data pick our winner.” (Business Insider)

The CEO still gets to lead; the user gets to vote; and you get to sleep.

Closing thought

A great CEO wants the same thing you do: products people love that drive the business. The fastest way there is to treat opinions-especially powerful ones-as hypotheses and let real customers and experiments decide. Remember:

• Authority bias is human; build guardrails against it. (The Decision Lab)

• Most ideas don’t work as imagined; design learning loops. (Harvard Business Review)

• Customer‑obsessed, well‑designed products outperform over time. (McKinsey & Company)

And if the HiPPO still charges? Offer it a prototype to chew on. They’re surprisingly docile when fed a steady diet of evidence.

Because the CEO can lead the company-but only your users can lead your product.

This post unpacks the behaviors and mindsets that separate “good” from “top‑1% great.” It includes a shareable comparison chart, practical habits, and, yes, research and quotes—because your VP will ask “Source?”

The data (and a few quotable north stars)

• Most ideas don’t work as intended. Microsoft’s experimentation leaders reported that, across thousands of online experiments, about one‑third of ideas improved key metrics, one‑third were neutral, and one‑third made things worse. Translation: great PMs build learning loops, not legend stories. (Harvard Business Review)

• Customer time is shockingly rare. A Pendo survey found 74% of product pros spend fewer than five hours per month with customers—far below Pragmatic Institute’s recommendation of eight hours per week. Great PMs buck the norm. (Pendo.io)

• Weekly customer touchpoints are the bar for discovery. Teresa Torres defines continuous discovery as “at a minimum, weekly touchpoints with customers by the team building the product.” If you’re not hearing from customers weekly, your intuition’s warranty expires fast. (Product Talk)

• Design quality correlates with business results. McKinsey’s multi‑year “Business Value of Design” study showed companies in the top quartile outperformed peers on revenue growth and TSR—evidence that taste and craft are not “nice‑to‑haves.” (McKinsey & Company)

• Team climate matters more than team résumés. Google’s Project Aristotle found psychological safety was the most important dynamic of effective teams. Great PMs create it; good PMs unknowingly drain it. (Rework)

• Writing clarifies thinking. Amazon institutionalized six‑page narrative memos; “We don’t do PowerPoint… Instead, we write narratively structured six‑page memos,” wrote Jeff Bezos. Great PMs write to think, not just to update. (About Amazon)

• The job, simply stated. Marty Cagan: the PM’s job is to discover a product that’s valuable, usable, feasible (and viable)—and to involve engineers early or you’re “only getting about half their value.” (Silicon Valley Product Group)

“People think focus means saying yes… It means saying no to the hundred other good ideas… Innovation is saying no to 1,000 things.” —Steve Jobs. When in doubt, practice “no‑fu.” (Goodreads)

The shareable comparison chart: Good PM vs. Great PM (Top 1%)

Pro tip: Drop this in your team wiki, laminate it for your standup, or “accidentally” leave it open when your favorite stakeholder walks by.

Dimension

Good PM

Great PM (Top 1%)

North Star

Measures success by shipped features and velocity.

Anchors work to a North Star Metric that captures customer value and ties inputs to outcomes. Can explain how today’s task moves the NSM—without needing an espresso first. (Amplitude)

Customer Contact

Schedules interviews… when it’s time to write a PRD.

Weekly touchpoints with users (min.), co‑observes with design & engineering; discovers surprises in context. (Product Talk)

Discovery

Runs a survey; calls it a day.

Treats discovery as a habit. Uses Opportunity Solution Trees, rough prototypes, and cheap tests to reduce value/usability/feasibility/viabilityrisks early. (Silicon Valley Product Group)

Experimentation

Prefers “strong opinions, strongly defended in meetings.”

Builds fast, trustworthy experiments because “only ~1/3 of ideas help.” Learns in weeks, not quarters. (Harvard Business Review)

Design & Craft

Ships “MVPish” and moves on.

Sweats first‑mile/last‑mile details; knows quality compounds financially (MDI). Makes empty states and error states lovable. (McKinsey & Company)

Team Dynamics

Treats engineers like code vending machines.

Works as a Product Trio (PM + Design + Eng) from day 0; engineers co‑create and innovate. Psychological safety isn’t a poster; it’s the meeting norm. (Product Talk)

Strategy

“Our strategy is… roadmap Tetris.”

Can draw the market map, wedge, and bet—in Sharpie. Explains what would falsify the bet.

Saying “No”

Says yes to keep the peace; inherits chaos.

Practices “disagree and commit” and uses no‑if‑yes framing (“Yes—if we drop X and hit Y outcome”). (amazon.jobs)

Writing

Slides with 8‑point font and 32 arrows.

Clear, narrative docs that survive the meeting. Channels Amazon’s memo ethos to force clarity. (About Amazon)

Metrics

Adds analytics after GA says “404.”

Instruments events before build; defines leading indicators and guardrails (e.g., activation, change‑failure rate proxies).

Prioritization

Argues frameworks by acronym.

Uses any framework (RICE, cost of delay) pragmatically—but chooses based on causal logic and constraints.

Stakeholders

Runs status theatre.

Co‑authors decisions: “Here’s the problem, options, trade‑offs, and the bet.” Leaves a paper trail of decisions and rationale.

Meetings

10 people, 0 owners, 90 minutes.

Fewer, smaller, written pre‑reads. Meetings are for decisions; Slack is for updates.

Time Use

Calendar Tetris grandmaster.

Guards maker time for deep work and customer time; automates status. (Also knows when to cancel a meeting—heroic act.)

Roadmaps

Output‑heavy, feature‑dense.

Outcome‑driven, time‑boxed themes with space to learn; OKRs are outcomes, not task lists. (What Matters)

Risk

Treats risk as a slide.

Names the four risks explicitly and designs tests for each. (Bonus: sleeps better.) (Silicon Valley Product Group)

Technical Depth

Avoids the engine room.

Gets curious about architecture, latency, data models. Doesn’t overrule engineers—asks better questions.

Go‑to‑Market

Tosses over the wall.

Partners early with marketing, success, sales enablement; drafts the API and the one‑pager.

Backlog

Graveyard of unloved tickets.

Ruthless pruning; closes JIRA with the same joy others close rings on an Apple Watch.

Learning Loops

Postmortems as blame sessions.

Blameless postmortems; metrics + narrative + action items. Turns surprises into system improvements.

Ethics & Privacy

“Legal will catch it.”

Designs for consent, minimization, and explainability from the start. (Future‑you says thanks.)

Accessibility

“We’ll add alt text later.”

Targets WCAG compliance by default; tests with real users.

Humor

“Our funnel is a slide.”

“Our funnel is a hole if we don’t instrument it.” (Then fixes it.)

Outcome

Ships a lot of stuff.

Changes customer behavior and moves business metrics—reliably.

Five moves to go from good → great this quarter

1. Block weekly customer time—non‑negotiable.
   Pencil it in like a dentist appointment you can’t wiggle out of. Invite your designer and your tech lead; aim for weekly touchpoints (Torres). Keep it scrappy: 30‑minute calls, short field observations, or live support ride‑alongs. You’ll find problems you “wouldn’t even know to ask about” and your ideas will get sharper. (Product Talk)

2. Adopt a North Star + inputs (and use it to say no).
   Commit to one metric that represents value to users; list 3–5 input metrics your team can actually move. If a request doesn’t obviously influence an input → it waits. (Amplitude’s playbook is a great starter.) (Amplitude)

3. Write narratives, not decks.
   Try the Amazon move for your next big decision: a 1–3 page narrative with context, options, trade‑offs, and the recommendation. Start the meeting with a quiet read. It’s eerie how much this raises the IQ of the conversation. (“We don’t do PowerPoint… we write narratively structured six‑page memos.”) (About Amazon)

4. Turn opinions into experiments.
   Remember the 1/3‑1/3‑1/3 rule. For any medium bet, outline: hypothesis → success metric → guardrail metric → smallest test. Pre‑commit to what triggers a rollback. Your future postmortem self will send you cookies. (Harvard Business Review)

5. Include engineers in discovery.
   The little secret in product: engineers are often your best single source of innovation—if they see the problem early. Invite them to interviews, whiteboard the constraints, and ask “What would be easy but high‑leverage?” (Cagan’s point, repeatedly.) (Silicon Valley Product Group)

Behaviors of the top 1% you can spot from the hallway

• They make trade‑offs legible. The great PM doesn’t just decide—they expose the decision calculus in plain language so others can challenge assumptions before code is written. (Your legal counsel will clap silently.)

• They cultivate psychological safety. They thank dissenters; they model “I don’t know.” Teams share half‑baked prototypes without fear—which is how the best ideas show up early. (Google’s Project Aristotle made this painfully clear.) (Rework)

• They manage upwards with outcomes. Exec says “We need Feature X.” Great PM replies, “We can achieve Outcome Y two faster ways—trade‑offs inside.” (Cue the CFO smiling.) (What Matters)

• They remove ambiguity with writing. Even a two‑paragraph pre‑read turns stakeholder chaos into a solvable math problem. Amazon didn’t ban slides for aesthetics—they did it because writing is thinking. (About Amazon)

• They’re calm in the chaos. Andy Grove’s famous mantra—“Let chaos reign, then rein in chaos”—is their posture. They invite exploration, then converge decisively. (Wikiquote)

• They care about craft because dollars care about craft. The MDI findings aren’t just design‑team folklore; better design practices correlate with stronger growth and TSR. Great PMs budget time for polish (and for removing features). (McKinsey & Company)

• They say “no” as an act of love. Jobs’s line about saying no to a thousand things is not bravado; it’s resourcing. Every yes spends your team’s attention. Every no buys clarity. (Goodreads)

A quick self‑assessment (printable, merciless, effective)

Score yourself 0–2 on each item (0 = “not me,” 2 = “obviously me”). If you hit 30+, you’re trending great.

1. I had four or more user touchpoints this month, with an engineer present in at least two. (Product Talk)

2. My roadmap is outcome‑driven and laddered to a North Star; I can defend every theme’s causal chain. (Amplitude)

3. I ran at least one experiment that could have rolled back something we believed. (The humility rep.) (Harvard Business Review)

4. I shipped at least one decision via narrative memo instead of a deck. (About Amazon)

5. Our product trio co‑created a solution this month; engineers weren’t “surprised” in sprint planning. (Product Talk)

6. I explicitly listed value/usability/feasibility/viability risks for the top initiative and how we’re testing them. (Silicon Valley Product Group)

7. I said no (or “yes‑if”) to at least one misaligned request and documented why. (amazon.jobs)

8. We improved one UX detail (first mile/empty state) that reduced friction and measurably helped a metric. (McKinsey & Company)

9. I created psychological safety on my team by thanking a dissenter and adopting their suggestion. (Rework)

10. I pruned backlog items that didn’t move inputs (RIP, dear tickets). (Amplitude)

11. I instrumented at least one funnel before building the feature.

12. I wrote down one assumption that would falsify our strategy and shared it with leadership.

If your score is low, congrats—you found your growth edges. That’s a gift, not an indictment. Product is a long game; we level up by systems, not sprints.

“But my company is a feature factory…”

Many are. John Cutler’s classic “feature factory” essay struck a nerve for a reason. If your org celebrates output and forgets outcomes, start small: define a North Star, run one honest experiment, and narrate the learning. You can’t flip a factory overnight, but you can start a lab next to it. (Medium)

Closing thought

Great PMs aren’t clairvoyant; they’re compounded learners. They start with the customer, translate strategy into outcomes, use writing to sharpen thinking, pull engineers into discovery, and run experiments because they know most ideas are innocent until proven useful. If you adopt just three practices from this piece, make them these:

1. Weekly customer touchpoints with your trio. (Product Talk)

2. A North Star + inputs to say no with confidence. (Amplitude)

3. Narrative decisions and cheap experiments—because the data says humility wins. (About Amazon)

Now, go forth and rein in some chaos. (Innovation requires saying no to a few things today—like that “urgent” 10‑person status meeting.) (Goodreads).

And because good hiring teams try to separate judgment from vibe, they increasingly use structure: decades of research show structured interviews are markedly more predictive than unstructured chats-often roughly twice the validity. So when you answer with clear structure, you’re making it easier for them to evaluate you well. (Wiley Online Library)

What follows is the ultimate, candid field guide to the pet peeves product leaders see most often-including a special section of seven “silent dealbreakers” that senior PM leaders say will cost you the job.

The Silent Dealbreakers: 7 Product Leader Pet Peeves That Will Cost You the Job

You polished the résumé, networked on LinkedIn, and can recite CIRCLES backward. You even wore your lucky socks. Still-rejection. What went wrong? Often it’s not skills; it’s subtle missteps that scream not ready to a hiring manager. Here are the seven that come up again and again.

1) The Solution in Search of a Problem

The peeve: Asked “How would you improve Spotify for podcast listeners?”, you launch into a feature confetti cannon: “AI clip generator! Comments! Magic transcripts!”

Why it’s a red flag: Great PMs fall in love with the problem, not the feature list. Marty Cagan contrasts empowered product teams (given problems/outcomes) with feature teams (handed solution requests). If you jump to features before understanding who and why, you signal “feature factory” thinking. (Silicon Valley Product Group)

The fix:

• Start with user & outcome (“Are we increasing weekly listening among casuals, or depth among power listeners?”).

• Map the problem space (discovery, find moments in long shows, sharing friction).

• Propose solutions tied to pain points and outline how you’d test them. (Remember: in large-scale experiments, only about one‑third of ideas help; humility and testing win.) (Harvard Business Review)

2) The Hand‑Waving Generalist

The peeve: “I’m a strong communicator; I over-communicated and we aligned.” That’s… not a story.

Why it’s a red flag: PMs trade in specifics. Vague answers suggest you either lack the experience or can’t articulate it.

The fix: Use STAR (Situation–Task–Action–Result) and quantify. Laszlo Bock’s résumé formula works in interviews too: “Accomplished [X] as measured by [Y] by doing [Z].” (“I paused build for five 30‑min interviews, then prioritized a checklist that raised activation from 22%→30%.”) (LinkedIn)

3) The Uncurious Candidate

The peeve: “No questions from me, thanks!” at the end.

Why it’s a red flag: Curiosity is the engine of product. A former Meta recruiting leader calls not asking questions a clear red flag-it reads as disinterest and shallow thinking. (Business Insider)

The fix: Arrive with tiers of questions:

• Role: “What does success in the first 90 days look like?”

• Team: “How do you resolve disagreement between PM and Design?”

• Strategy: “What’s the biggest bet the team is making this year, and what would falsify it?”

4) The Victim

The peeve: On a failed project: “Eng couldn’t deliver; marketing botched the launch; PMM changed everything…”

Why it’s a red flag: Product is leadership through influence. Blame‑shifting screams “low ownership.”

The fix: Start with your contribution: “I failed to get early PMM buy‑in.” Then share the learning and process change going forward.

5) The Rambler

The peeve: You talk for five minutes and still haven’t said what problem you’re solving.

Why it’s a red flag: PMs must make complexity legible. Interview science is on your side: structured approaches lead to better decisions and fairer assessments. Signal that discipline by taking a beat to structure your answer. (Wiley Online Library)

The fix: Ask for 30 seconds to outline. Then preview: “I’ll clarify the goal, segment users, propose three solution shapes, and pick a test.”

6) The Unprepared Guest

The peeve: It’s obvious you haven’t used the product (or you mix it up with a competitor).

Why it’s a red flag: It reads as apathy. Also, you can’t credibly propose outcomes without touching the experience.

The fix: Use it. Break onboarding. Read the last release notes. Ken Norton literally wrote: it drives me crazy when candidates name one of my products as the greatest thing they’ve seen-bring fresh POV. (Bring the Donuts)

7) The Know‑It‑All

The peeve: Confidence curdles into arrogance; you present opinions as facts and dismiss trade‑offs.

Why it’s a red flag: Product is a team sport. The healthy stance is “strong opinions, weakly held” (Paul Saffo’s classic formulation widely echoed by product leaders). Have a POV-then invite disconfirming evidence. (SKMurphy, Inc.)

The fix: Use collaborative language: “My initial hypothesis is… One risk is… If data shows X, I’d pivot to Y.”

Bottom line: These seven aren’t about what’s on your résumé; they’re about how you show up. Avoid them and you’ll look less like a candidate and more like a soon‑to‑be teammate.

More Pet Peeves Hiring Managers See Every Week (and how to avoid them)

Think of these as the “greatest hits” beyond the seven dealbreakers.

8) Vague, impact‑free bullets

“Owned roadmap. Improved engagement.” Improve what? By how much? With which lever? Use the X‑Y‑Z formula and you become instantly scannable in those first 7.4 seconds. (LinkedIn)

9) Frameworks without thinking

Dropping acronyms is not strategy. Tie your answer to a causal chain (“Reduce sign‑up time → more first‑session success → +D7 retention”) and show how you’d test it-because the experiment literature says many “great ideas” backfire. (Harvard Business Review)

10) Badmouthing past teams

Hiring managers screen for people who make teams safer and smarter. Google’s Project Aristotle found psychological safety was the most important factor in effective teams. If you torch your last team, you telegraph risk. (Think with Google)

11) No numbers-ever

You don’t have to remember every decimal, but you should know ballparks and how you measured success. “Activation rose from low‑20s to ~30% after we added a 3‑step checklist; p95 time‑to‑value fell from 3 days to ~1.”

12) Not testing your opinions

When you present an absolute view in product cases, expect a follow‑up like, “How would you de‑risk that?” Keep an experiment pattern handy (hypothesis → success metric → guardrails → smallest viable test). Again: only ~1/3 of ideas help. (Harvard Business Review)

13) AI overuse (or dishonesty)

Recruiters are seeing an avalanche of AI‑generated applications; some surveys show a sizable share of managers view fully AI‑written résumés and cover letters as a red flag. Use AI as an assistant, not a mask-and never claim AI’s ideas as your own. (TopResume)

14) Lying or “airbrushing” your past

Don’t. A CareerBuilder survey found 75% of HR managers have caught a lie on a résumé. Trust is the easiest knockout. (PR Newswire)

15) Generic questions

“Tell me about the culture” signals minimal prep. Ask specifics that reveal how the team really operates (decision cadence, North Star inputs, how trade‑offs are made). A former Meta recruiter calls “no questions” a red flag. (Business Insider)

16) Mixing up company names or products

Yes, it happens. Proofread. And-pro tip-don’t tell Ken Norton your favorite product is the one he built. He has receipts. (Bring the Donuts)

17) Over‑indexing on tenure

Ten years of experience isn’t the same as ten 1‑year loops. Show how you think: structure, trade‑offs, experiments, and outcomes.

18) Treating people as obstacles rather than partners

Great PMs elevate their trio (Design + Eng + PM). Your stories should make your teammates co‑authors, not NPCs. It’s one way managers sniff out whether you’ll increase psychological safety-or drain it. (Rework)

19) Ignoring the product’s business model

You can be brilliant at funnels and still miss the P&L. Before the loop, sketch a mini market map (competitors, switching costs, acquisition channels) and come with one thoughtful hypothesis about the company’s wedge.

20) Ghosting or poor follow‑through

Candidates are ghosted too (surveys show 61–67% have experienced it), but that’s not your cue to vanish. The rare candidate who communicates promptly stands out. (Greenhouse)

21) Ignoring the product before interview day

Download it. Break it. Write a 2‑minute teardown (problem → evidence → options → metric). This alone puts you in the top quartile of preparedness.

Real‑life mini‑moments hiring managers remember

• “We ran three options, not one.” A candidate walked a panel through A/B/C onboarding experiments, pre‑declaring success and guardrails. No heroics-just measured thinking, backed by the HBR truth that experiments beat opinions. Offer extended. (Harvard Business Review)

• “Don’t name our product.” A senior hiring manager still laughs about the candidate who named the company’s own app as the “best product in the world.” Ken Norton warned you. Bring fresh examples and why they’re great. (Bring the Donuts)

• “I blew it-here’s what I changed.” The best failure story we heard this quarter began with ownership, not blame, and ended with a new cross‑functional kickoff ritual. That’s leadership.

A printable prep checklist (steal this)

• Résumé uses X‑Y‑Z bullets; scannable in <8 seconds. (LinkedIn)

• Company homework: I’ve used the product, noted friction points, and have a 2‑minute teardown.

• Stories are STAR‑structured and quantified; I can show trade‑offs and test plans. (Wiley Online Library)

• Questions: I have role, team, and strategy questions that reveal how work actually gets done. (Business Insider)

• Ethics & accuracy: No embellishment; no AI‑written boilerplate. (Hiring managers notice.) (PR Newswire)

• Follow‑through: I’ll send a crisp thank‑you with one clarified insight and one next‑step I’m excited about.

Closing thought

Great hiring teams aren’t searching for perfection. They’re looking for evidence that you’ll make good decisions with incomplete information, raise the team’s psychological safety, and learn fast when your first idea is wrong (because many will be). Show curiosity, own outcomes, structure your thinking-and keep your opinions strong but weakly held. That combination is catnip to product hiring managers. (Think with Google)

That sounds like intuition-and in many ways it is. But the best people will also tell you it’s not magic. Marty Cagan argues that strong product sense is really deep product knowledge earned by immersing yourself in a domain, customers, and the competitive set. In other words, instincts get trained. (Silicon Valley Product Group)

This article unpacks what product sense is, the ingredients that make it work, and practical ways to develop and demonstrate it.

A working definition

A useful way to define product sense is as a repeatable decision‑making skill that blends:

1. Empathy (for users’ contexts, constraints, and motivations).

2. Causal reasoning (clear hypotheses about how a change will create value).

3. Market awareness (the competitive and business realities your product operates in).

4. Taste and craft (the ability to recognize and shape high‑quality experiences).

5. Evidence discipline (knowing when to lean on data, when to run an experiment, and when to ship a well‑reasoned bet).

Put differently: product sense is the judgment to choose the right problem, the right solution shape, and the right next learning step.

It is fundamentally customer‑first. Steve Jobs captured the mindset: “You’ve got to start with the customer experience and work backwards to the technology.” (All About Steve Jobs)

And it is anchored in markets. Marc Andreessen’s concise definition of product/market fit-“being in a good market with a product that can satisfy that market”-reminds us that taste without market truth is just opinion. (Pmarchive)

Why product sense matters (and is measurable)

Good product sense correlates with business results because it improves what you choose to build and how you validate it. Consider two data points:

• McKinsey’s multi‑year study found companies in the top quartile of their McKinsey Design Index grew revenues 32 percentage points and total returns to shareholders 56 percentage points faster than peers-evidence that superior product quality and customer experience compound. (McKinsey & Company)

• At Microsoft and elsewhere, large‑scale experimentation shows how often our instincts are wrong. In one HBR summary: roughly a third of ideas improve metrics, a third are neutral, and a third make things worse-a humbling reminder that product sense shines when it guides what to test next, not when it claims infallibility. (Harvard Business Review)

Together, these suggest a practical definition: product sense = user‑centric hypotheses + disciplined learning loops.

The five building blocks of product sense

1) Empathy rooted in real contexts

You can’t intuit great products from a conference room. Field studies and contextual inquiry expose the constraints and workarounds that users rarely articulate. NN/g summarizes the value: observing people in their natural environment reveals problems “you wouldn’t know to ask about,” and often changes what you design in the first place. (Nielsen Norman Group)

How to practice

• Shadow customer support calls, watch screen‑share sessions, or do short field visits.

• Capture moments of struggle (where, when, who’s nearby, what else is on screen).

• Write one‑sentence “jobs” that describe the progress the user is trying to make.

2) Causal mental models

Product sense is not just “what users say”; it’s why the world behaves as it does. A robust approach is Jobs to Be Done: identify the job customers are “hiring” your product to do, then design around it. Christensen’s HBR piece makes the case that focusing on jobs-rather than personas or raw demographics-improves innovation hit rates. (Harvard Business Review)

How to practice

• Translate observations into causal statements: If we reduce X friction in moment Y, Z adoption metric should move.

• Distill hypotheses into plain, testable language.

3) Market and business literacy

Taste without market fluency is a liability. Product sense requires understanding the ecosystem your product lives in (competitors, switching costs, channel constraints) and what winning looks like (business model mechanics, unit economics). Andreessen’s PMF framing is a helpful north star for prioritization and timing. (Pmarchive)

How to practice

• Keep a “market map” one‑pager: substitutes, complements, entry points, lock‑ins.

• During prioritization, explicitly state the market bet you’re making and the disconfirming evidence that would change your mind.

4) Taste & craft (the quality bar)

“Quality” is not subjective hand‑waving; it’s the ability to recognize when an experience is clean, obvious, and complete. The business case is strong: better design correlates with materially better growth and shareholder returns. (McKinsey & Company)

How to practice

• Build a reference library of flows you admire; do teardown notes on why they work.

• Sweat “first mile, last mile” details (onboarding clarity, error states, edge cases).

• Borrow constraints from the best: mobile‑first content limits, progressive disclosure, accessible defaults.

5) Evidence discipline (experiments over arguments)

Strong product sense knows when to seek fast feedback. Large‑scale A/B testing research shows many “great ideas” don’t move the needle-and some harm key metrics. That’s not an indictment of intuition; it’s a roadmap for how to learn: run small, trustworthy experiments and iterate. (Harvard Business Review)

How to practice

• Decide before launch which outcomes would count as success or a rollback.

• Instrument minimally but meaningfully; define leading indicators and guardrails.

• Treat inconclusive results as signal about your hypothesis quality, not just sample size.

A helpful backdrop here is the Kahneman–Klein joint paper on intuition: expert “gut feel” is reliable when the environment is sufficiently regular and feedback is rapid-exactly what disciplined product teams create with continuous discovery and experimentation. (PubMed)

Concrete routines to build product sense

You don’t need a decade at a FAANG to develop product sense. You need reps and feedback loops. A practical weekly cadence might include:

1. Customer hours
   Block two hours every week for direct contact: interviews, field observations, or watching support tickets get resolved. Field studies are especially useful in discovery because they often change what you’d build by revealing unspoken constraints. (Nielsen Norman Group)

2. Opportunity Solution Trees (OSTs)
   Borrow Teresa Torres’s OST to map from an outcome → opportunities (user needs) → candidate solutions → experiments. OSTs visualize assumptions and keep the team aligned on learning paths, not just feature lists. (Product Talk)

3. North Star + inputs
   Use Amplitude’s North Star Framework to anchor your product’s value in a single North Star Metric (NSM) and a small set of input metrics you can move. This gives your bets a quantitative backbone and reduces thrash. (Amplitude)

4. Write the press release (or narrative) first
   Before spec’ing, write the customer‑facing story: who is this for, what changes in their life, why now? It forces clarity on value and trade‑offs-then your PRD or spec can translate promises into testable requirements.

5. Run more small experiments
   Heavyweight tests aren’t necessary. Even simple A/Bs or smoke tests can deliver the rapid feedback conditions where intuition sharpens. Kohavi and Thomke’s work summarizes the power of small, frequent experiments in improving decision quality. (web-docs.stern.nyu.edu)

How to demonstrate product sense (at work and in interviews)

1) Start with the problem and the outcome.
When presented with a request (from a stakeholder or an interviewer), restate the user problem, name the North Staryou’ll move, and surface the constraints. This signals that you can separate what matters from implementation details. (Amplitude)

2) Reveal your causal chain.
Draw the simplest link from intervention → behavior change → metric movement. Then list the top assumptions that could break the chain and how you’d test them (OST language helps). (Product Talk)

3) Make trade‑offs explicit.
Great product sense is often visible in what you don’t do. State what’s out of scope for v1 and why (risk, complexity, opportunity cost). Tie those choices to your metric guardrails.

4) Show your taste with specifics.
Do a three‑minute teardown of a comparable flow (e.g., “first‑time activation”). Talk through why a particular microcopy, progressive disclosure, or error state reduces cognitive load and increases completion.

5) Close the loop with an experiment plan.
Describe how you’d instrument the experience, what constitutes success or rollback, and how quickly you’ll learn. Cite the reality that many ideas don’t work-and that your plan accounts for that with cheap, trustworthy tests. (Harvard Business Review)

Common misconceptions

• “Product sense is innate.”
  Cagan’s point is the antidote: it’s mostly deep product knowledge and context you can acquire with immersion and practice. (Silicon Valley Product Group)

• “If you talk to users, you don’t need to test.”
  User research reduces unknowns, but large‑scale online experiments repeatedly show that teams overestimateimpact. Both are essential: research to choose what to build, experiments to verify that it works. (Harvard Business Review)

• “Taste is subjective; metrics are objective.”
  Taste without metrics can drift; metrics without taste can optimize for the wrong thing (e.g., clicks over value). The North Star framework exists precisely to align craft and measurement. (Amplitude)

• “The market will figure itself out.”
  Product sense requires market truth. PMF is about a good market and a product that satisfies it; ignoring either side undermines judgment. (Pmarchive)

A simple self‑assessment you can run this month

1. Evidence: Did you talk to at least five users in context about the problem you’re addressing? What did you learn that changed your plan? (If nothing changed, you likely didn’t go deep enough.) (Nielsen Norman Group)

2. Model: Can you write your causal hypothesis in one sentence? (If X at moment Y, then Z.)

3. Market: Could you explain your market map on a whiteboard in under two minutes? Where is the wedge?

4. Taste: Do you have a gallery of best‑in‑class flows you review with your team? What principles do they illustrate?

5. Learning: Do you have one experiment running (or queued) at all times? What would cause you to roll back?

If you can answer “yes” to most of these, you’re practicing product sense-not as a buzzword, but as a daily habit.

Closing thought

Strong product sense doesn’t mean you’re always right. It means you start with the customer, think clearly about cause and effect, respect the market, sweat quality, and learn fast. Jobs’s mantra-customer experience first, technology second-keeps you grounded in value. Andreessen’s PMF definition keeps you honest about markets. McKinsey’s data reminds you that craft and results are linked. And the experimentation literature keeps you humble enough to test your best ideas quickly. Put together, that’s not mysticism. It’s a practice you can build-one outcome‑oriented week at a time. (All About Steve Jobs)

And because good hiring teams try to separate judgment from vibe, they increasingly use structure: decades of research show structured interviews are markedly more predictive than unstructured chats-often roughly twice the validity. So when you answer with clear structure, you’re making it easier for them to evaluate you well. (Wiley Online Library)

What follows is the ultimate, candid field guide to the pet peeves product leaders see most often-including a special section of seven “silent dealbreakers” that senior PM leaders say will cost you the job.

The Silent Dealbreakers: 7 Product Leader Pet Peeves That Will Cost You the Job

You polished the résumé, networked on LinkedIn, and can recite CIRCLES backward. You even wore your lucky socks. Still-rejection. What went wrong? Often it’s not skills; it’s subtle missteps that scream not ready to a hiring manager. Here are the seven that come up again and again.

1) The Solution in Search of a Problem

The peeve: Asked “How would you improve Spotify for podcast listeners?”, you launch into a feature confetti cannon: “AI clip generator! Comments! Magic transcripts!”

Why it’s a red flag: Great PMs fall in love with the problem, not the feature list. Marty Cagan contrasts empowered product teams (given problems/outcomes) with feature teams (handed solution requests). If you jump to features before understanding who and why, you signal “feature factory” thinking. (Silicon Valley Product Group)

The fix:

• Start with user & outcome (“Are we increasing weekly listening among casuals, or depth among power listeners?”).

• Map the problem space (discovery, find moments in long shows, sharing friction).

• Propose solutions tied to pain points and outline how you’d test them. (Remember: in large-scale experiments, only about one‑third of ideas help; humility and testing win.) (Harvard Business Review)

2) The Hand‑Waving Generalist

The peeve: “I’m a strong communicator; I over-communicated and we aligned.” That’s… not a story.

Why it’s a red flag: PMs trade in specifics. Vague answers suggest you either lack the experience or can’t articulate it.

The fix: Use STAR (Situation–Task–Action–Result) and quantify. Laszlo Bock’s résumé formula works in interviews too: “Accomplished [X] as measured by [Y] by doing [Z].” (“I paused build for five 30‑min interviews, then prioritized a checklist that raised activation from 22%→30%.”) (LinkedIn)

3) The Uncurious Candidate

The peeve: “No questions from me, thanks!” at the end.

Why it’s a red flag: Curiosity is the engine of product. A former Meta recruiting leader calls not asking questions a clear red flag-it reads as disinterest and shallow thinking. (Business Insider)

The fix: Arrive with tiers of questions:

• Role: “What does success in the first 90 days look like?”

• Team: “How do you resolve disagreement between PM and Design?”

• Strategy: “What’s the biggest bet the team is making this year, and what would falsify it?”

4) The Victim

The peeve: On a failed project: “Eng couldn’t deliver; marketing botched the launch; PMM changed everything…”

Why it’s a red flag: Product is leadership through influence. Blame‑shifting screams “low ownership.”

The fix: Start with your contribution: “I failed to get early PMM buy‑in.” Then share the learning and process change going forward.

5) The Rambler

The peeve: You talk for five minutes and still haven’t said what problem you’re solving.

Why it’s a red flag: PMs must make complexity legible. Interview science is on your side: structured approaches lead to better decisions and fairer assessments. Signal that discipline by taking a beat to structure your answer. (Wiley Online Library)

The fix: Ask for 30 seconds to outline. Then preview: “I’ll clarify the goal, segment users, propose three solution shapes, and pick a test.”

6) The Unprepared Guest

The peeve: It’s obvious you haven’t used the product (or you mix it up with a competitor).

Why it’s a red flag: It reads as apathy. Also, you can’t credibly propose outcomes without touching the experience.

The fix: Use it. Break onboarding. Read the last release notes. Ken Norton literally wrote: it drives me crazy when candidates name one of my products as the greatest thing they’ve seen-bring fresh POV. (Bring the Donuts)

7) The Know‑It‑All

The peeve: Confidence curdles into arrogance; you present opinions as facts and dismiss trade‑offs.

Why it’s a red flag: Product is a team sport. The healthy stance is “strong opinions, weakly held” (Paul Saffo’s classic formulation widely echoed by product leaders). Have a POV-then invite disconfirming evidence. (SKMurphy, Inc.)

The fix: Use collaborative language: “My initial hypothesis is… One risk is… If data shows X, I’d pivot to Y.”

Bottom line: These seven aren’t about what’s on your résumé; they’re about how you show up. Avoid them and you’ll look less like a candidate and more like a soon‑to‑be teammate.

More Pet Peeves Hiring Managers See Every Week (and how to avoid them)

Think of these as the “greatest hits” beyond the seven dealbreakers.

8) Vague, impact‑free bullets

“Owned roadmap. Improved engagement.” Improve what? By how much? With which lever? Use the X‑Y‑Z formula and you become instantly scannable in those first 7.4 seconds. (LinkedIn)

9) Frameworks without thinking

Dropping acronyms is not strategy. Tie your answer to a causal chain (“Reduce sign‑up time → more first‑session success → +D7 retention”) and show how you’d test it-because the experiment literature says many “great ideas” backfire. (Harvard Business Review)

10) Badmouthing past teams

Hiring managers screen for people who make teams safer and smarter. Google’s Project Aristotle found psychological safety was the most important factor in effective teams. If you torch your last team, you telegraph risk. (Think with Google)

11) No numbers-ever

You don’t have to remember every decimal, but you should know ballparks and how you measured success. “Activation rose from low‑20s to ~30% after we added a 3‑step checklist; p95 time‑to‑value fell from 3 days to ~1.”

12) Not testing your opinions

When you present an absolute view in product cases, expect a follow‑up like, “How would you de‑risk that?” Keep an experiment pattern handy (hypothesis → success metric → guardrails → smallest viable test). Again: only ~1/3 of ideas help. (Harvard Business Review)

13) AI overuse (or dishonesty)

Recruiters are seeing an avalanche of AI‑generated applications; some surveys show a sizable share of managers view fully AI‑written résumés and cover letters as a red flag. Use AI as an assistant, not a mask-and never claim AI’s ideas as your own. (TopResume)

14) Lying or “airbrushing” your past

Don’t. A CareerBuilder survey found 75% of HR managers have caught a lie on a résumé. Trust is the easiest knockout. (PR Newswire)

15) Generic questions

“Tell me about the culture” signals minimal prep. Ask specifics that reveal how the team really operates (decision cadence, North Star inputs, how trade‑offs are made). A former Meta recruiter calls “no questions” a red flag. (Business Insider)

16) Mixing up company names or products

Yes, it happens. Proofread. And-pro tip-don’t tell Ken Norton your favorite product is the one he built. He has receipts. (Bring the Donuts)

17) Over‑indexing on tenure

Ten years of experience isn’t the same as ten 1‑year loops. Show how you think: structure, trade‑offs, experiments, and outcomes.

18) Treating people as obstacles rather than partners

Great PMs elevate their trio (Design + Eng + PM). Your stories should make your teammates co‑authors, not NPCs. It’s one way managers sniff out whether you’ll increase psychological safety-or drain it. (Rework)

19) Ignoring the product’s business model

You can be brilliant at funnels and still miss the P&L. Before the loop, sketch a mini market map (competitors, switching costs, acquisition channels) and come with one thoughtful hypothesis about the company’s wedge.

20) Ghosting or poor follow‑through

Candidates are ghosted too (surveys show 61–67% have experienced it), but that’s not your cue to vanish. The rare candidate who communicates promptly stands out. (Greenhouse)

21) Ignoring the product before interview day

Download it. Break it. Write a 2‑minute teardown (problem → evidence → options → metric). This alone puts you in the top quartile of preparedness.

Real‑life mini‑moments hiring managers remember

• “We ran three options, not one.” A candidate walked a panel through A/B/C onboarding experiments, pre‑declaring success and guardrails. No heroics-just measured thinking, backed by the HBR truth that experiments beat opinions. Offer extended. (Harvard Business Review)

• “Don’t name our product.” A senior hiring manager still laughs about the candidate who named the company’s own app as the “best product in the world.” Ken Norton warned you. Bring fresh examples and why they’re great. (Bring the Donuts)

• “I blew it-here’s what I changed.” The best failure story we heard this quarter began with ownership, not blame, and ended with a new cross‑functional kickoff ritual. That’s leadership.

A printable prep checklist (steal this)

• Résumé uses X‑Y‑Z bullets; scannable in <8 seconds. (LinkedIn)

• Company homework: I’ve used the product, noted friction points, and have a 2‑minute teardown.

• Stories are STAR‑structured and quantified; I can show trade‑offs and test plans. (Wiley Online Library)

• Questions: I have role, team, and strategy questions that reveal how work actually gets done. (Business Insider)

• Ethics & accuracy: No embellishment; no AI‑written boilerplate. (Hiring managers notice.) (PR Newswire)

• Follow‑through: I’ll send a crisp thank‑you with one clarified insight and one next‑step I’m excited about.

Closing thought

Great hiring teams aren’t searching for perfection. They’re looking for evidence that you’ll make good decisions with incomplete information, raise the team’s psychological safety, and learn fast when your first idea is wrong (because many will be). Show curiosity, own outcomes, structure your thinking-and keep your opinions strong but weakly held. That combination is catnip to product hiring managers. (Think with Google)

There’s a line that gets every new product manager in trouble: “You’re the CEO of the product.” Ben Horowitz actually wrote that in his classic memo-then immediately reminded readers that this was a training device, not a literal job description. You don’t have a CEO’s org chart, budget, or hiring power. You have… meetings, a backlog, and a stubborn belief that a better future is just one decision away. The job isn’t to bark orders; it’s to build trust, communicate a compelling vision, and use data to align smart people who don’t report to you. (Andreessen Horowitz)

Below is a practical playbook-backed by research, sprinkled with quotes from the trenches, and spiced with a dash of humor-for leading when the only thing you can command is your calendar invite.

1) Why “authority” is a mirage in product work

Social psychologists John French and Bertram Raven defined power over 60 years ago as a set of bases: coercive, reward, legitimate, referent, expert (and later informational). Product managers rarely control the first three. That leaves referent (trust/relationships), expert (credibility), and informational (clarity). Translation: your levers are influence, not enforcement. (Massachusetts Institute of Technology)

Even Hacker News-the internet’s toughest product panel-draws the distinction cleanly:

“A large difference between being a PM and an actual CEO is that both lead via influence but the CEO has final authority.” (Hacker News)

And the reality check can sting:

“Many PMs are lame ducks… because they have to ‘lead without influence,’ which is extremely challenging in many large companies.” (Hacker News)

The antidote isn’t to grab a bigger stick. It’s to earn more voluntary followership. That starts with trust.

2) Trust is your operating system

In the gold‑standard Integrative Model of Organizational Trust, Mayer, Davis, and Schoorman argue that people trust leaders who demonstrate three things: Ability, Benevolence, and Integrity (ABI). Ability = competence; Benevolence = “you’re in it for us, not just you”; Integrity = “your words and actions match.” When ABI rises, people accept risk; when it falls, they protect themselves. Influence lives or dies here. (Making Good)

Trust isn’t just academic. The 2024 Edelman Trust at Work report found that “my employer” remains the most trusted institution for employees globally (79%). In a noisy world, the employer is still the most believable source of information-so PMs who act as trustworthy guides can cut through the static. (Edelman)

On the flip side, the 2025 Trust Barometer shows declining trust in CEOs and public leaders. People aren’t impressed by megaphones; they want credible, proximate leadership. That’s your cue. (Axios)

Actionable ABI upgrades:

• Ability: Spend real time in the weeds-system constraints, user journeys, and the numbers. Summarize the hard stuff in plain language.

• Benevolence: Share context early (including bad news). Credit others loudly. Protect the team from randomization.

• Integrity: Write decisions down. Stick to them-or explain clearly why they changed.

Reddit puts it more colorfully:

“You need to build trust. My engineers know I’m honest with them… I give them more business info than I have to… It’s building trust and two‑way communication.” (Reddit)

3) Make it safe to disagree (then people will align)

Google’s Project Aristotle sifted through data on hundreds of teams and identified five drivers of team effectiveness. Psychological safety-the belief that it’s safe to take interpersonal risks-was #1. Without it, even elite talent underperforms. Amy Edmondson’s foundational research shows the same: psych safety predicts learning behavior and better outcomes. In other words: if people fear looking foolish, they won’t tell you the truth you need. (Rework)

What this looks like in practice:

• Invite dissent explicitly: “What’s the strongest argument against this?”

• Normalize “I don’t know” with your own vulnerability.

• Reward risk‑taking (prototypes, experiments), not just perfect outcomes.

4) Vision beats volume: goals that rally people

A fuzzy rallying cry (“Let’s be world‑class!”) won’t move a cross‑functional team. Decades of research on goal‑setting theory (Locke & Latham) show that specific, challenging goals consistently drive higher performance than vague “do your best” exhortations, especially with feedback and commitment. Effect sizes in meta‑analyses are large. If you want influence, clarify the scoreboard. (Stanford Medicine)

McKinsey’s data on large transformations echoes this: programs are 5.8× more likely to succeed when leaders communicate a compelling change story, and 6.3× when senior leaders’ messages align. Vision doesn’t replace execution; it aims it. (McKinsey & Company)

Pro tip: Pair one business goal (e.g., gross retention) with two behavior goals (e.g., weekly active teams + setup completion). Now every argument can be tested against a shared definition of “winning.”

5) Use data as a social object-not a bludgeon

“Let the data speak for itself” is a romantic notion. In reality, data needs a narrator. HBR has argued for years that the gap isn’t in data collection-it’s in persuasion: telling a clear, credible story that changes minds. Great PMs don’t forward dashboards; they craft data narratives that show why a choice is better for users and the business. (Harvard Business Review)

Amazon institutionalized this idea. Meetings often start with 6‑page narratives (and silent reading) so discussion time is spent on decision‑quality Q&A rather than slide karaoke. Former leaders describe how that “reading culture” becomes a forcing function for clarity. Your org may never go full Bezos, but a tight PR/FAQ or memo will often beat a 40‑slide deck at earning alignment. (Andreessen Horowitz)

A simple data‑story template:

• Question: What decision are we making now?

• Evidence: What we learned (from users, logs, experiments).

• Implications: What it means for our goals.

• Risk & Reversal: What could go wrong and how we’d unwind it.

• Ask: The smallest commitment that moves us forward.

6) The ethics (and tactics) of persuasion

If influence is your toolkit, use it consciously. Robert Cialdini’s research points to seven durable persuasion levers: reciprocity, scarcity, authority, consistency/commitment, liking, social proof, and unity. Map these to honest product practices: give help before you ask (reciprocity), be transparent about constraints (scarcity), bring your staff engineer to the meeting (authority), capture explicit buy‑ins (commitment), invest in relationships (liking), reference evidence and peer teams (social proof), and rally around a shared identity (unity). (Influence at Work)

Hacker News, in its way, agrees: “Managers have power; they should exercise their influence to the betterment of their team… Good managers lead.” (Keep the title; ditch the power trip.) (Hacker News)

7) Rituals that scale influence in a matrix

a) Weekly customer touchpoints
Teresa Torres’s continuous discovery habit-weekly conversations with customers by the team building the product-creates a drumbeat of outside‑in evidence. When a decision references a fresh clip or test, it’s easier to align. (Product Talk)

b) Pre‑reads and decision logs
Short memos with a crisp “what/why/risks” let people engage on their own time. Then log the decision so it stays decided.(Amazon’s narrative culture is one way to enforce this.) (Andreessen Horowitz)

c) One‑on‑ones as influence multipliers
Most objections surface before the meeting-if you make the time. Book 15‑minute pre‑reads with key partners. Ask, “What would make this a ‘yes’ for you?”

d) Public measures, private feedback
Report progress against those specific goals. Offer corrective feedback 1:1. Praise publicly and specifically.

8) Scripts for common PM street fights (influence edition)

When engineering says, “That’s harder than you think.”

“Great-help me quantify which parts are hard. If we simplified X and dropped Y, what’s the earliest we could prove Z outcome for users? I’ll adjust the bet to protect the schedule.”

When a stakeholder wants a custom feature “just for this deal.”

“I hear the revenue. Our goal this quarter is activation rate, and this request adds integration debt that risks it. What’s the smallest concession that saves the deal and keeps activation healthy? Let’s test that first.”

When design and engineering disagree on an approach.

“Two strong options-let’s time‑box prototypes behind a toggle and ship the winner to 10% of traffic. Decision by data, not decibels.”

Reddit’s unvarnished summary of the job description is worth taping to your monitor:

“Product management is about talking to customers and identifying problems, then playing politics across the entire organisation to get everyone to actually build something that solves that problem.” (Correct, and also: hydrate.) (Reddit)

9) Communicate a vision people can repeat (not just nod at)

A compelling vision isn’t poetry-it’s a testable story that teammates can echo when you’re not in the room. Steal this structure:

• From → To: “From reactive feature factory → To outcome‑driven product bets.”

• Because: “Activation rate is stuck at 38%; competitors are 50%+.”

• So we will: “Prioritize first‑run experience, run weekly user sessions, and A/B test onboarding patterns.”

• We’ll know it worked when: “Activation hits 48% by Q4.”

That last line matters most. As McKinsey notes, clarity and consistent messaging dramatically improve the odds of change sticking. Write your vision so others can teach it. (McKinsey & Company)

10) Your influence scorecard (measures you control)

• Decision latency: Days from “proposal” to “committed.”

• Reversal rate: % of decisions reversed due to missing/late info (lower is better).

• Pre‑read open rate + comments: Are people engaging before the meeting?

• Cross‑functional ENPS for “trust in PM”: Quick, anonymous pulse (quarterly).

• Outcome health: Your two behavior metrics + the business metric they ladder to.

If these move in the right direction, your reputation compounds-door by door, quarter by quarter.

11) A few myths (gently) debunked

“If only I had authority…”
French & Raven would like a word. The kinds of power PMs can credibly deploy-referent, expert, informational-are earned, not granted. (Massachusetts Institute of Technology)

“Vision is vibes.”
Nope. It’s goals and evidence. Specific, challenging goals raise performance. The vibes are optional; the numbers aren’t. (Stanford Medicine)

“Data speaks for itself.”
Not in real companies. It needs a story, a memo, and a call to action. (Harvard Business Review)

“Psych safety is soft.”
It is hard infrastructure for candor and speed. Google and Edmondson already did the homework. (Michigan)

12) Closing: The quiet superpower of PMs

You won’t win every argument. You’ll still say “no” more than you wish (politely, with receipts). But when you lead through influence, teams ship smarter work with fewer scars. The magic isn’t charisma-it’s character plus craft: ABI‑level trust, a clear and testable vision, tidy data stories, and rituals that make good decisions easier than bad ones.

Or, in the wise words of Hacker News:

“The best product manager I worked with… understood the complexity and the business need… basically a value add to the company.” (Be that person.) (Hacker News)

Marc Andreessen’s famous line sets the tone: “The only thing that matters is getting to product/market fit.” He defined PMF as “being in a good market with a product that can satisfy that market,” and noted you can feel when it’s not happening-word of mouth stalls, usage crawls, sales cycles drag. Conversely, when it’s working, customers buy (or use) as fast as you can serve them. (Pmarchive)

This post distills how founders actually get there: the signals that PMF is near, the loops that push you through the fog, and the gritty stories (Slack, Airbnb, Dropbox, Superhuman) that show what it looks like in practice.

First principles: what PMF is (and isn’t)

• PMF is value × market, not hype. As Andreessen (and Andy Rachleff, who coined the term) argued: great teams can still fail in bad markets, and mediocre products can wiggle through in great ones-but the repeatable success path is pairing a real market with a product that truly satisfies it. (Andreessen Horowitz)

• PMF is felt in behavior, not vibes. Y Combinator’s motto-“Make something people want”-sounds simple; it’s also the best north star when everything is messy. Sam Altman and Paul Buchheit’s corollary: in the beginning, it’s better to have a small number of users who love you than many who kind of like you. (Paul Graham)

• PMF is not one metric. It’s a tapestry of leading and lagging indicators: how much users would miss you, whether cohorts stick, how fast people tell friends, and-especially in B2B-whether expansion outpaces churn.

The scoreboard: reliable signals that PMF is close

1. The “very disappointed” (40%) test
   Sean Ellis popularized a deceptively simple survey: ask active users, “How would you feel if you could no longer use this product?” If ≥40% say “very disappointed,” you likely have initial PMF. Rahul Vohra (Superhuman) operationalized this into a full system, and Hiten Shah’s 2015 open study of Slack users found 51% “very disappointed” at ~500k paying users-strong external proof of PMF. (Venture Hacks)

2. Retention curves that flatten (and don’t drop to zero)
   For nearly every software product, a cohort retention curve that levels off-instead of bleeding out-signals durable value. Amplitude calls retention the “ultimate product strategy,” and PostHog’s founder guide is blunt: “If your retention curve flattens… it’s a strong sign you have product-market fit.” (Amplitude)

3. Power usage and habit formation
   For consumer and prosumer apps, Andrew Chen’s “magic metrics” include cohort curves that flatten, DAU/MAU > 50% for daily-habit products, and a power-user curve with a visible engaged core. These are symptoms of PMF, not causes-but they’re consistent across winners. (LinkedIn)

4. B2B expansion and net revenue retention (NRR)
   In B2B, PMF shows up as teams adding seats and features without you begging. A useful rule-of-thumb from growth leaders aggregated by Lenny Rachitsky and Casey Winters: bottom‑up SaaS NRR ~100% is good; ~120% is great; enterprise NRR ~110% good; ~130% great. (Revenue.fyi)

5. Fast, compounding word‑of‑mouth
   Andreessen’s “you can feel it” list included press and customers pulling on you. Chen layers math on top: the viral factor matters (how many users each user brings) but is only one piece-still, channels like referrals and WOM comprising a big chunk of new users are common in PMF stories. (Andrew Chen)

War stories: what PMF looked like up close

Slack: a usage threshold that predicted near‑certain retention

Inside Slack’s early data, a “magic number” emerged: when a team had sent 2,000 messages in its history, 93% of those teams were still active. Stewart Butterfield: “After 2,000 messages, [they’ve] really tried Slack.” This wasn’t vanity; it told the team what activation to design for. (First Round)

Slack’s internal storytelling matched the metrics. In the now‑famous “We Don’t Sell Saddles Here” memo (2013), Butterfield reframed Slack around making work life simpler, more pleasant, more productive-a story the market could feel. (Medium)

Takeaway: instrument your own “activation threshold” and orient onboarding toward it. Slack optimized everything-from invites to notifications-to get teams to 2,000 messages fast. (GrowthHackers)

Airbnb: do things that don’t scale to unlock the must‑have

In 2009, with revenue stuck at $200/week, the founders grabbed a camera, flew to New York, and re‑shot listings. A week later, revenue doubled. That small, hands‑on fix clarified the value proposition and sparked a systematic professional photography program that improved bookings and trust at scale. (First Round)

Takeaway: PMF often hides behind an unscalable insight. Remove the biggest friction (in this case, poor photos) and the market’s real appetite surfaces. (First Round)

Dropbox: demonstrate the magic, then build

Before there was a working product, the team released a 3‑minute demo video, packed with in‑jokes for early adopters. The result: the waitlist jumped from 5,000 to 75,000 overnight. Demand was real; the product still had to catch up. (TechCrunch)

Takeaway: for deep tech, show the core value early to validate appetite-and then race to meet it.

Superhuman: turning a survey into a roadmap

Superhuman’s PMF system starts with the Ellis survey, then segments by persona to find the High‑Expectation Customer (HXC)-a term from Julie Supan’s brand work with Airbnb, Dropbox, and Thumbtack: “the most discerning person within your target demographic.” Superhuman focused on the HXCs’ words to prioritize the roadmap and systematically raised its PMF score. (First Round)

Takeaway: identify the small group who love you (or could), build for them, and let their language shape your positioning and features. (First Round)

A practical playbook: loops that push you toward PMF

1) Narrow the market (and name your HXC)

Write a crisp one‑liner for who you’re for and what pain you solve (not your feature list). Supan’s HXC definition is a great forcing function-this is the persona whose endorsement changes everyone else’s mind. If you can’t name yours, you’re not close. (First Round)

Tactic: Run 15–30 discovery calls with only prospective HXCs. Ask for stories about the last time the pain showed up. Ship a prototype or a workflow mock and listen for the “Where has this been all my life?” reaction-Steve Blank calls it the “pupil‑dilation” test. (Lenny’s Newsletter)

2) Define the activation moment that predicts habit

Find the behavioral milestone that separates dabblers from devoted users (Slack’s 2,000 messages; for your app it might be shared a doc with 3 teammates, took a ride in a new city, etc.). Instrument-then design onboarding to get people there fast. (First Round)

3) Measure the two PMF pillars: retention and love

• Retention: Plot cohort retention and keep iterating until the curve flattens-that is, a meaningful % of users still active months later. (For many consumer products, Andrew Chen’s heuristics-flattening cohorts, strong DAU/MAU-are practical guardrails.) (PostHog)

• Love: Run the 40% PMF survey on active users monthly. Segment results by persona and use verbatim feedback from “very disappointed” respondents to draft your next sprint. (It’s how Superhuman turned a metric into a roadmap.) (Venture Hacks)

4) Chase one distribution loop that amplifies pull

Don’t bolt on “growth hacks” before PMF; as Andrew Chen says, growth follows fit. That said, once users love you, lean into the loop that compounds-referrals, integrations, content SEO, or sales‑assisted pilots-so that more of your new users come from WOM and referrals over time. (Andrew Chen)

5) Keep your runway for iteration, not theatrics

YC’s “make something people want” pairs with another Graham-ism: stay cheap long enough to iterate. Most startups die before PMF because they run out of time. Keep cycles short, experiments honest, and your definition of done anchored in user behavior, not pitch‑deck milestones. (Paul Graham)

Benchmarks & heuristics (so you don’t optimize noise)

• Ellis/40% rule: ≥40% “very disappointed” ⇒ strong early PMF. Slack’s 51% at scale is a useful reality check-even beloved products rarely score 70–80%. (First Round)

• Consumer habit signals: DAU/MAU > 50% for daily‑use apps; cohorts flattening; power‑user curve with a heavy engaged tail. (LinkedIn)

• B2B health: NRR ~100% good / ~120% great (bottom‑up), ~110% / ~130% (enterprise). Pair with logo retention and seat expansion. (Revenue.fyi)

• WOM share: expect an increasing fraction of signups from referrals/WOM as fit improves (e.g., Chen’s marketplace case studies). (Lenny’s Newsletter)

Treat these as sanity checks, not dogma. For instance, during the pandemic, Hiten Shah’s survey found Zoom scored ~30% “very disappointed”-below the Ellis bar-despite obvious category growth. Surveys are snapshots; triangulate with retention and expansion. (Nira)

Common pitfalls on the road to PMF

• Counting signups, not sticking users. Until retention flattens for a meaningful cohort, you don’t have PMF-no matter how pretty the acquisition graph looks. (PostHog)

• Optimizing average feedback. Your HXC is not “average.” Build for the most discerning users who feel your product’s core benefit most strongly, then generalize. (First Round)

• Treating velocity as victory. Shipping fast without learning fast just burns runway. The Slack, Airbnb, and Dropbox stories all hinged on specific insights (messages sent; photography; a demo video) that unlocked the curve. (First Round)

• Buying growth before you’ve earned it. Chen’s admonition bears repeating: “Startups need product/market fit, not growth.” Paid acquisition can expose more people to a non‑fit-it can’t create one. (Andrew Chen)

A 30–60–90 day PMF plan you can actually run

Days 1–30: Define & discover

• Write your HXC spec (who, where they hang out, exact pain, current workaround). Steal their words from interviews to update your landing page and onboarding. (First Round)

• Instrument a candidate activation event (your equivalent of Slack’s 2,000 messages). Make sure you can seecohorts hitting it. (First Round)

Days 31–60: Prototype & prove

• Ship two changes per week that specifically move activation and early retention (e.g., pre‑filled templates, better default notifications, a single‑player “sandbox” to demo value).

• Launch your first PMF survey to active users; segment by persona; build the next sprint from the “very disappointed” group’s words. (Venture Hacks)

Days 61–90: Consolidate & concentrate

• Run a cohort analysis. Do later cohorts flatten higher? If yes, keep pushing the same loops. If not, decide: move upmarket/downmarket, or pivot the wedge. (PostHog)

• Pick one distribution loop to amplify genuine pull (referrals, integrations, or founder‑led sales to look‑alike accounts). Keep spending small until you see retention. (Andrew Chen)

Closing thought

You’ll know you’re close when two things happen at once: users come back on their own, and more new users come from existing ones. At that moment, all the slogans make sense: make something people want; make a few people love you; then broaden the circle. The stories are remarkably consistent-from Slack’s 2,000‑message threshold to Airbnb’s scrappy photography sprints, to Dropbox’s “show, don’t tell” video. Small, focused moves revealed a market that was already waiting. (First Round)

If you’ve ever watched a Zoomer juggle TikTok, Discord, and 47 photo edits while sending a Venmo request and shutting down a scam text faster than you can say “unsubscribe,” you’ve seen the future of your product. Gen Z isn’t just “the next generation of users”-they’re the cultural R&D lab for everyone else. As Satya Nadella famously put it, “the true scarce commodity is increasingly human attention.” (The Atlantic)

So how do you build for a generation that grew up in a world where the feed never ends, the store is in the app, and the line between creator and consumer is a smudge? Let’s turn research into a practical playbook-with a dash of humor, a few cautionary tales, and concrete product moves.

Meet Gen Z (and their context)

Definitions vary, but think late‑1990s to around 2010 for birth years. McKinsey calls them “digital natives” whose identity was shaped by the internet, climate anxiety, and COVID‑19-context that shows up in how they spend, learn, and demand meaning from products and brands. (McKinsey & Company)

Where they are (a lot): YouTube and TikTok. Pew’s latest teen fact sheet shows 90% of U.S. teens use YouTube; majorities also use TikTok (≈63%), Instagram (≈61%), and Snapchat (≈55%). (Pew Research Center) Among 18–29‑year‑olds (the older half of Gen Z), Instagram (78%), Snapchat (65%) and TikTok (62%) are standouts. Translation: video‑first, mobile‑first, creator‑led. (Pew Research Center)

How they discover and decide: Social is search. Sprout Social finds Gen Z treats social as their go‑to channel for information, discovery, and even customer care-often preferring it over traditional search engines-and nearly half plan to buy more through social commerce in 2025. (Sprout Social)

Where they hang out beyond feeds: Gaming platforms are social networks. Roblox reported 111.8 million DAUs in Q2 2025, with 64% of users now 13+ and heavy creator payouts-evidence that co‑creation isn’t a “feature,” it’s the platform.

What they value: Deloitte’s 2025 global Gen Z survey shows persistent cost‑of‑living stress and strong values: two‑thirds feel anxious about the environment and 65% say they’re willing to pay more for sustainable products-a huge signal for product positioning and roadmaps. (Deloitte) Identity matters, too: more than 1 in 5 Gen Z adults in the U.S. identify as LGBTQ+, which should inform inclusive defaults (names, pronouns, imagery) and safety features. (Gallup.com)

How they pay: Buy Now, Pay Later (BNPL) is mainstream for them. Reuters notes younger consumers over‑index on BNPL; LendingTree finds 33% of Gen Z BNPL users even used it for groceries in 2025-so plan conversion flows accordingly and build responsible guardrails. (Reuters, LendingTree)

Their media tolerance (or lack thereof): Churn is a lifestyle. Deloitte’s 2025 Digital Media Trends shows 54% of Gen Z canceled an SVOD service in the last six months; they lean ad‑supported, flexible, and low‑friction. If your onboarding or pricing feels like calculus, expect a rage‑quit. (Deloitte)

A mental‑health reality check: The U.S. Surgeon General warns that while social can have benefits, we cannot conclude it’s sufficiently safe for youth; nearly all teens use social media, and a sizeable share report heavy use. Product teams should internalize “safety by design,” not treat it as optics. (HHS.gov)

Practical playbook: product moves that resonate (and retain)

1) Make speed and clarity your superpowers

Attention isn’t “short”-it’s selective. Users will give you hours if you deliver value; they’ll give you seconds if you don’t. The usability rule of thumb still holds: after about 10 seconds of waiting, minds wander and tasks derail. Every tap, scroll, and paywall should feel instantaneous. (Nielsen Norman Group)

What to ship

• Performance budgets for core flows (home feed, search, checkout).

• Microcopy that explains, not performs. As Steve Krug put it, “Don’t make me think.” (It’s a cliché because it’s true.) (Goodreads)

• Smart defaults: auto‑save, resume states, undo. Reduce the “what now?” moments.

PM humor break: If your loading screen needs witty quips, your loading is too long. Save the jokes for the release notes.

2) Design for creation and community, not just consumption

Gen Z expects to remix, review, and react. Co‑creation grows usage and trust. Look at Roblox’s ecosystem: a thriving creator economy plus algorithmic discovery lifted new titles into the top‑spend experiences within weeks. That’s not luck-it’s platform design.

What to ship

• Low‑friction UGC tools: duet/reply formats, templates, easy rights requests.

• Native collab: group lists, blends, or shared boards (Spotify’s “Blend”‑style ideas win with young users). (Music Ally, Spotify)

• Creator rails: revenue splits, analytics, and in‑product promo surfaces so your best users become your best growth channel.

3) Be where discovery happens (social) and sell where the intent peaks (in‑app)

Gen Z discovers on social, checks the vibes in comments/UGC, and increasingly buys right there. Sprout Social reports 48% plan to make more purchases via social in 2025-especially on TikTok Shop. Build your catalog and support into social surfaces, but let users finish in your app without friction. (Sprout Social)

What to ship

• Social‑first product pages (short video, creator quotes, community Q&A).

• In‑app checkout that mirrors social carts (saved address, wallet, BNPL).

• Reply‑in‑comments customer care for visible trust (Gen Z often DMs brands first). (Sprout Social)

4) Personalize responsibly (and transparently)

Gen Z loves great recommendations and hates creepy ones. They’ll trade data for value, but only with control. Give them the knobs and make the trade‑offs legible.

What to ship

• Preference centers that are actually useful (topics, creators, ad frequency, notifications).

• Explainable recs (“Because you liked X…” with an option to tune or mute).

• Privacy presets freshmen can understand (location sharing off by default, easy “ghost” mode). The Surgeon General’s advisory underscores why this matters. (HHS.gov)

5) Offer flexible, ethical payments

BNPL boosts conversion; it also invites risk. Reuters’ BNPL charts show rapid growth and younger skew. LendingTree’s 2025 insight that a third of Gen Z BNPL users financed groceries should trigger design empathy-and proactive safeguards. (Reuters, LendingTree)

What to ship

• BNPL with friction where it counts: eligibility checks, reminders, snooze once, transparent schedules.

• Budget modes: set spend caps, surface “total cost” before commit.

• Student pricing and ad‑supported tiers to address subscription fatigue (Deloitte pegs Gen Z churn at 54% in 6 months). (Deloitte)

6) Build sustainability and inclusivity into the product, not just the brand book

Values are not a slide-they’re a backlog. Two‑thirds of Gen Z say they’ll pay more for sustainable choices, and over 20% identify as LGBTQ+. That means real features and defaults, not just seasonal campaigns. (Deloitte, Gallup.com)

What to ship

• Impact toggles: show carbon‑aware shipping or resale options by default; surfaces for “buy used” where relevant (the resale economy is booming). (thredUP newsroom)

• Identity controls: chosen names, pronouns, inclusive avatars, and safe‑reporting built into flows (not hidden in help centers).

• Accessible by design: alt text prompts, captions on by default, high‑contrast modes. (If your brand green fails WCAG, is it still green?)

7) Treat customer support like a product feature

Gen Z wants instant, conversational help-ideally without waiting for a human unless they need one. CX leaders are responding: 70% plan to integrate generative AI into many touchpoints in the next two years. Design self‑service that feels like a smart sidekick, and escalate gracefully. (Zendesk)

What to ship

• AI triage with receipts: cite the policy, link the log, summarize the path taken.

• Channel choice: chat, text, social DMs; email last. (Gen Z is least likely to prefer email.) (Smart Communications)

• Trust signals: verified agent badges, resolution timers, and one‑tap handoffs.

8) Mind well‑being; reduce harm by default

“Healthy engagement” beats “any engagement.” The U.S. Surgeon General urges action; product teams should ship safety as an MVP, not a patch. (HHS.gov)

What to ship

• Quiet hours and Do‑Not‑Disturb schedules that auto‑suggest based on behavior.

• Sensitive‑content thresholds the user can tune; panic untag/private buttons.

• “Why am I seeing this?” on algorithmic surfaces to reduce confusion and doomscroll triggers.

Case studies & signals

• Duolingo’s “be native to the platform” lesson. Its TikTok‑first approach grew followers dramatically and turned a mascot into a meme (and a growth engine), with CTRs well above benchmarks in TikTok case studies and a 2025 push into YouTube Shorts paying off. The lesson isn’t “be unhinged”-it’s “be fluent in the culture you’re entering.” (TikTok For Business, Adweek)

• Roblox as a co‑creation blueprint. AI‑driven discovery, constant live‑ops, and creator economics-plus a user base that’s now majority 13+-show how platform mechanics can foster rapid iteration and community flywheels.

• Resale as a core journey, not a partner tab. ThredUp’s 2025 report highlights younger shoppers driving secondhand and doing it via social. If you sell goods, consider “resale mode” and trade‑in flows early. (thredUP newsroom)

Metrics that matter (and how to move them)

• Time‑to‑value (TTV) and first action completion in under a few taps. If TTV climbs, your welcome mat is a welcome maze.

• Community health: creator activation rate, UGC contribution rate, “reply in < X hours” in public threads.

• Consentful personalization: % of users who set preferences (and keep them), opt‑out re‑engagement rather than more pop‑ups.

• Sustainable conversion: resale attach rate, eco‑shipping selection rate, BNPL repayment completion (paired with nudge efficacy).

• Churn early warning: cohort retention deltas after pricing or ad‑load changes; social sentiment shift when you tweak algorithms (Gen Z notices).

A quick Gen Z readiness checklist

• Mobile‑first, video‑first surfaces.

• One‑tap creation: remix, duet, stitch, collab.

• Social commerce done right: creator quotes + in‑app checkout + BNPL with guardrails. (Sprout Social, Reuters)

• Safety by default: sensitive‑content controls, quiet hours, explainable recs. (HHS.gov)

• Inclusive identity: pronouns, chosen names, accessible UI, diverse imagery (remember those Gallup numbers). (Gallup.com)

• Flexible pricing: ad‑supported tiers; student plans; clear, cancel‑friendly billing (they churn-design around it). (Deloitte)

• Fast paths to help: AI self‑service with humane escalation; DM support. (Zendesk)

Final thought (and a pep talk)

Gen Z is not a mystery to be solved; they’re a mirror. They show us what everyone will expect soon: clarity, control, and community-with speed. If you design for those, you won’t just win Zoomers; you’ll build a product that feels inevitable for the rest of us, too.

And if you need a mantra, borrow two: “Don’t make me think” (Krug), and “human attention is the scarce commodity” (Nadella). Build for both, and you’ll earn the one metric that matters most with Gen Z: the choice to come back tomorrow. (Goodreads, The Atlantic)

1) INSPIRED - Marty Cagan

What it is: A modern overview of the PM role in tech and how empowered product teams discover and deliver value.
Why it matters: Still the clearest “PM 101” for ICs-use it to align on responsibilities, discovery vs. delivery, and teaming with design/engineering. Many r/ProductManagement threads point new PMs here first. (Reddit)
Amazon. (Amazon)

2) Product Management’s Sacred Seven - Neel Mehta, Parth Detroja & Aditya Agashe

What it is: A comprehensive playbook spanning seven core domains PMs should master-product design, economics, psychology, UX, data, law & policy, and marketing/growth.
Why it matters: Functions like a desk reference you’ll return to for frameworks across disciplines; widely praised on Reddit for breadth and practicality. > “It’s… stuffed with useful knowledge… Best product book I’ve ever read, hands down.” (Reddit)
Amazon. (Amazon)

3) The Lean Startup - Eric Ries

What it is: The build‑measure‑learn loop, MVPs, and hypothesis‑driven development.
Why it matters: Gave teams a common language for validated learning-from startups to enterprises (e.g., GE’s FastWorks). (WIRED)
Amazon. (Amazon)

4) The Mom Test - Rob Fitzpatrick

What it is: A short, practical guide to asking customers non‑leading questions that expose truth and kill false positives.
Why it matters: Perfect antidote to vanity interviews. > “The Mom Test is one of those books that have a lot of good advice.” (Hacker News)
Amazon. (Amazon)

5) Continuous Discovery Habits - Teresa Torres

What it is: A sustainable weekly cadence for discovery-opportunity solution trees, assumption tests, and simple rituals teams can keep up.
Why it matters: The most actionable “how” for ongoing discovery; often cited by PMs as a habit‑forming upgrade to their practice. (Reddit)
Amazon. (Amazon)

6) Escaping the Build Trap - Melissa Perri

What it is: Why organizations ship features for their own sake-and how to pivot toward outcomes and value.
Why it matters: If your roadmap is a feature factory, this book gives you strategy and feedback loops to reset. (Melissa Perri)
Amazon. (Amazon)

7) Working Backwards - Colin Bryar & Bill Carr

What it is: Amazon’s mechanisms (PR/FAQ, six‑page narratives, Bar Raisers) and the principles behind them.
Why it matters: Even if you don’t adopt six‑pagers wholesale, the press‑release‑first mindset forces customer clarity. > “The essay will be read… quietly… typically for 30 minutes or more.” (Hacker News)
Amazon. (Amazon)

8) The Four Steps to the Epiphany - Steve Blank

What it is: The original customer development handbook that heavily influenced Lean Startup.
Why it matters: Structure for getting out of the building, de‑risking, and validating before scaling. (Amazon)
Amazon. (Amazon)

9) Crossing the Chasm (3rd ed.) - Geoffrey A. Moore

What it is: How disruptive products make the leap from early adopters to the mainstream, and how to pick a beachhead.
Why it matters: A marketing/positioning framework PMs still use to plan segmentation and adoption. > “Shaped my understanding of who buys what when.” (Hacker News)
Amazon. (Amazon)

10) The Innovator’s Dilemma - Clayton M. Christensen

What it is: Why great companies fail amid disruptive innovations from below; the theory behind “disruption.”
Why it matters: Helps PMs see when sustaining the core won’t win-and to look for new value networks. (Amazon)
Amazon. (Amazon)

11) Good Strategy/Bad Strategy - Richard Rumelt

What it is: A crisp definition of strategy (diagnosis → guiding policy → coherent actions) and what isn’t strategy.
Why it matters: Cuts through vision‑statement fog and forces hard choice‑making. > “Good definitions of what is or is not a strategy.” (Hacker News)
Amazon. (Amazon)

12) Measure What Matters - John Doerr

What it is: Case‑driven introduction to OKRs (Objectives & Key Results), popularized at Google and beyond.
Why it matters: Done well, OKRs align teams on outcomes (not output). Community discussions highlight pitfalls-e.g., don’t tie compensation to OKRs and avoid “metric gaming.” (Hacker News)
Amazon. (Amazon)

13) Thinking, Fast and Slow - Daniel Kahneman

What it is: System 1 (fast) vs. System 2 (slow), heuristics and biases, and how humans actually decide.
Why it matters: PMs interpret noisy data, price products, and design flows-Kahneman sharpens judgment under uncertainty. (He died in March 2024; obituaries recap his influence on behavioral economics.) (The Guardian)
Amazon. (Amazon)

14) Influence (New & Expanded) - Robert Cialdini

What it is: Six universal principles of persuasion with updated research and applications.
Why it matters: Ethical influence is central to activation, onboarding, and stakeholder alignment. Use as design constraints, not dark patterns. (Amazon)
Amazon. (Amazon)

15) Nudge (Final Edition) - Richard H. Thaler & Cass R. Sunstein

What it is: Behavioral economics applied to policy and product-how choice architecture shapes outcomes (updated in 2021).
Why it matters: PMs set defaults and craft flows that materially change behavior; this is a guide to doing it responsibly. (Penguin Random House)
Amazon. (Amazon)

16) The Design of Everyday Things (Revised & Expanded) - Don Norman

What it is: The classic on human‑centered design, mental models, affordances, and feedback.
Why it matters: Even data‑heavy B2B products are experienced by humans; this book helps you make interfaces that communicate effectively. (Amazon)
Amazon. (Amazon)

17) Thinking in Systems - Donella Meadows

What it is: A readable primer on feedback loops, stocks/flows, delays, and leverage points.
Why it matters: Products live inside complex org, market, and technical systems. Systems literacy reveals non‑obvious levers. > “It changed how I think about everything.” (Hacker News)
Amazon. (Amazon)

18) Hooked - Nir Eyal

What it is: The Hook model-Trigger → Action → Variable Reward → Investment-for habit‑forming products.
Why it matters: Offers a simple retention lens; apply ethically. WIRED’s explainer is a quick overview of the four‑step cycle. (WIRED)
Amazon. (Amazon)

19) Accelerate - Nicole Forsgren, Jez Humble & Gene Kim

What it is: Rigorous research into what makes high‑performing technology organizations-and four key software delivery metrics (a.k.a. DORA metrics).
Why it matters: Shipping speed and stability are product capabilities. DORA identifies four “Four Keys” metrics-Deployment Frequency, Lead Time, Change Failure Rate, Time to Restore-and finds that elite teams are twice as likely to meet or exceed org performance goals. (Dora)
Amazon. (Amazon)

20) High Output Management - Andrew S. Grove

What it is: Intel’s legendary CEO on managerial leverage, one‑on‑ones, task‑relevant maturity, and managing by outputs.
Why it matters: PMs lead through others; Grove’s playbook clarifies how to amplify a team’s output. > “A classic… good for the fundamentals.” (Hacker News)
Amazon. (Amazon)

Why these 20 (and how to use them)

• Core PM craft - INSPIRED; Product Management’s Sacred Seven; Continuous Discovery Habits; Escaping the Build Trap; Four Steps; Lean Startup; Working Backwards.
  These recur in “what should a new PM read?” threads and offer a solid base across role clarity, discovery cadence, and Amazon‑style writing mechanisms (PR/FAQ and narratives). (Reddit)

• Strategy & economics - Good Strategy/Bad Strategy; Crossing the Chasm; Innovator’s Dilemma; Measure What Matters; Nudge.
  Together they give you language for segmentation, disruption, and outcome‑based goal‑setting-tempered by community caveats about OKR misuse. (Hacker News)

• Psychology, design, systems - Thinking, Fast and Slow; Influence; The Design of Everyday Things; Thinking in Systems; Hooked.
  These sharpen product sense: how people decide, how interfaces communicate intent, how habits form, and how systems create (or thwart) leverage. (The Guardian)

• Execution engine - Accelerate; High Output Management.
  If you want to ship faster and safer, use DORA’s Four Keys as your scoreboard and adopt Grove’s principles for managerial leverage. (Dora)

A few “apply tomorrow” tips

1. Turn ideas into 1‑pagers. Create reusable templates: an Opportunity Solution Tree for discovery (Torres), a PR/FAQ outline for new bets (Amazon’s “working backwards”), and a Rumelt‑style strategy memo (diagnosis → guiding policy → coherent actions). (Amazon)

2. Instrument delivery as a product capability. Track the Four Keys-deployment frequency, lead time, change failure rate, time to restore-and review them alongside product metrics. Google Cloud’s summary is a handy reference. (Google Cloud)

Apply behavioral insights ethically. Use Influence, Nudge, and Hooked to reduce friction and create value-not to coerce. (WIRED’s overview of the Hook model is a quick refresher.) (WIRED)

There’s a certain myth about product management: a lone visionary PM strides onstage in a black turtleneck, unveils The Future™, and is carried out on the shoulders of grateful engineers. Cute story. In reality, most PM work is unglamorous glue-communication, alignment, trade‑offs, and a surprising amount of politely saying “no.” The good news? That glue is what holds real products together.

Below, I’ll cut through the hype with data, quotes, and a little humor to show what PMs actually do all day, why the boring bits matter, and how to thrive amid the chaos.

1) PMs are professional translators (with a minor in diplomacy)

When ProductPlan surveyed 1,400+ product professionals, they found that product strategy sits at the center of the job-yet it’s shaped by a swirl of internal and external pressures. In 2024 data, respondents said their strategy was primarily driven by senior leadership (31%) or customer requests (27%), with competitive/market signals close behind. Translation: you will spend a lot of time reconciling what customers ask for, what the market rewards, and what your executives want yesterday.

This is why the job is so communication‑heavy. If stakeholders don’t understand the strategy, they can’t align their work. The same ProductPlan report shows organizations consolidating tools and processes largely to standardize how product decisions are communicated-because misalignment is expensive.

“A good product manager is the CEO of the product.”
-Ben Horowitz, Good Product Manager/Bad Product Manager (nostalgically true in spirit, not in org charts). (Andreessen Horowitz)

It’s a punchy line-and a popular misread. You’re not actually the CEO of anyone. You don’t have hiring/firing authority over engineering, you can’t set comp, and your budget might live three reporting lines away. Your leverage is clarity: a shared narrative about what we’re doing and why. Your superpower is getting a dozen smart, skeptical people to agree to the same trade‑offs without hating each other.

2) Meetings: your natural habitat

Let’s talk calendars. Knowledge work has drifted into an “infinite workday,” where collaboration now spans time zones and-unfortunately-mealtimes. Microsoft’s 2025 Work Trend Index notes that 30% of meetings span multiple time zones, and after‑8‑p.m. meetings grew 16% year‑over‑year. That’s not just a vibe; it’s telemetry from Microsoft 365. (Microsoft)

Independent time‑tracking analyses tell a similar story. Reclaim’s 2024 study found professionals average 17.1 meetings per week, consuming ~14.8 hours. And not all of those are planned: roughly 27% of meetings are spontaneous (aka the “got‑a‑minute?” that steals your hour). If you ever wondered where your focus time went, it eloped with your calendar invite. (Reclaim)

What does that mean for PMs? It means the job is less “visionary keynote” and more facilitating alignment loops: design critiques, backlog grooming, roadmap reviews, customer calls, sales syncs, go‑to‑market huddles, “quick” exec check‑ins-each an opportunity to clarify, de‑risk, or de‑scope. The trick is designing your week so meetings serve decisions (not the other way around).

Practical tip: Give every recurring meeting a single decision to make (and cancel it when there isn’t one). You don’t get paid by the meeting; you get paid by the clarity per minute.

3) The discipline of “no” (and why it’s the kindest word in product)

Steve Jobs-who knew a thing or two about focus-famously said, “Innovation is saying no to 1,000 things.” That line comes from a 2004 BusinessWeek interview, and it endures because it’s operationally true. Focus compounds; scattered effort leaks value. (Bloomberg.com)

Saying no isn’t about being a gatekeeper; it’s about protecting outcomes. ProductPlan’s data shows teams are increasingly measuring success by outcomes over output-usage, adoption, retention-rather than “features shipped.” The more your measures emphasize behavior change and business impact, the easier it is to say no to random acts of roadmap.

No is also how you protect the team from death‑by‑miscellaneous. When everything is a priority, nothing is. (If “top priority” appears more than three times on the same slide, you don’t have a strategy; you have a wish list.)

4) Discovery: less epiphany, more reps

Marty Cagan distills product discovery succinctly: build solutions that are valuable, usable, feasible, and viable-and test those risks early. That’s the heart of the job, not the side quest. (Mind the Product)

Teresa Torres makes the cadence concrete: “At a minimum, weekly touchpoints with customers by the team building the product, doing small research in pursuit of a desired outcome.” Her point isn’t academic; it’s scheduleable. Discovery isn’t a sprint‑0 ritual; it’s a habit. (Product Talk)

Why does this matter? Because the number‑one failure pattern-across hundreds of post‑mortems-hasn’t changed: 42%of failed startups cite “no market need.” That’s CB Insights’ aggregation of 100+ post‑mortems, and while your company may not be a startup, the physics applies: build what people won’t use, and nothing else matters.

Here’s the kicker: PMs know they should talk to users more, but internal gravity is strong. In one (admittedly older) Alpha survey of 550 PMs, 86% said they didn’t spend enough time with users, and 60% said internal politics ate too much of their time. If that sounds familiar, you’re not broken-your calendar might be. (HubSpot)

Practical tip: Put a recurring, team‑owned customer session on the calendar-every week. Treat it like an outage if it gets bumped. Your backlog will get smarter, and “no” will get easier when it’s grounded in fresh evidence.

5) What a PM’s day actually looks like

On an average week, expect a mix like this:

• Translation ops: Turn executive intent into a crisp, testable strategy; turn research into prioritized bets; turn engineering constraints into honest timelines.

• Risk reduction: Run lean tests to de‑risk value/usability/feasibility/viability before you commit real scope. (Paper beats PowerPoint. Prototype beats paper.)

• Stakeholder therapy: Pre‑reads, 1:1s, and small group reviews to prevent “surprise” objections in big meetings.

• Backlog hygiene: Constant pruning so your roadmap reflects your strategy, not your Slack history.

• Decision theater: Facilitate a decision, document it, and communicate it-so it stays decided.

• Saying “no” (nicely): To the feature that helps one prospect but hurts the product, to the “just this once” scope creep, to the executive pet rock.

And yes, docs-PRDs, bet canvases, decision logs, FAQs. They are not bureaucracy; they’re memory. If your team has ever re‑debated the same decision three sprints in a row, you don’t have too many docs-you have too few.

6) The CEO of the product myth-what’s useful, what’s not

Ben Horowitz’s classic memo was trying to teach ownership: be accountable for outcomes; don’t outsource hard calls; define the what clearly (and let engineering rock the how). All of that is still gold. But don’t let the metaphor trick you into acting like a mini‑autocrat. Real‑world PM authority is borrowed-granted by trust, clarity, and results. (Andreessen Horowitz)

If you want an identity that won’t get you side‑eyed, try this: You are the chief risk officer for a bet the company is making. Your goal is to reduce uncertainty quickly and ethically, then align the org behind the next best move.

7) Alignment is a product-ship it on purpose

The 2024 ProductPlan report hints at why large orgs consolidate product tools: alignment is fragile, and scattered artifacts breed siloed decisions. PMs who communicate strategy through consistent, accessible channels report better understanding across the org. That’s not magic; it’s deliberate information architecture for your product decisions.

Spend one hour fewer debating a feature and one hour more improving the legibility of your roadmap, assumptions, and measures of success. Your future self (and your support queue) will thank you.

8) Metrics: outcomes over outputs (and why revenue still shows up)

Most PMs will tell you to measure product success with product metrics (usage, adoption, retention)-because they’re actionable. Yet many organizations still hold PMs accountable to revenue growth first. That’s okay; revenue is the business scoreboard. Just be explicit about the causal chain from product behavior change to business impact, and report both.

Pro move: Pair every revenue goal with two product behavior metrics you believe will move it. If those don’t budge, the quarter won’t either.

9) Reality check-with love-for aspiring PMs

If you’re eyeing PM as a path to glory, here’s the sober (but good) news:

• You’ll be judged more by the decisions you prevent than the features you ship. (Quietly killing a bad idea saves more money than loudly launching a mediocre one.)

• You’ll say “no” a lot, but you’ll earn the right to say “yes” to the right things. As Jobs put it, “Innovation is saying no to 1,000 things.” (Bloomberg.com)

• You’ll spend serious time in meetings, and some will happen at unfriendly hours because your collaborators sit in four time zones. That’s the modern workplace; design for it. (Microsoft)

• Your calendar will try to eat your strategy. Guard your discovery cadence like a hawk (weekly if you can); it’s how you avoid building for a non‑existent need. (Product Talk)

And yet-it’s a fantastic job. PMs get a front‑row seat to how ideas become products that help real people. You won’t always get the credit, but you’ll always see the impact.

10) A sample script for your next “no”

Because we all need one:

“I hear why this feature matters to [stakeholder/customer]. Right now, our outcome is [specific behavior or KPI], and our data shows [evidence]. If we divert to this, we’ll delay [current bet] by [cost] without evidence it moves [outcome]. Let’s put it in the parking lot, keep listening for the signal, and revisit after [milestone]-unless we uncover new data that says it beats our current bet.”

It’s respectful, evidence‑first, and-crucially-reversible if the data changes.

11) The unsexy PM toolkit that actually works

• Decision logs. If it isn’t written down, it didn’t happen.

• Pre‑reads. Meetings are for decisions, not reading.

• Assumption tables. Make the invisible visible; test the riskiest first.

• Customer clips. Nothing punctures debate like a 90‑second user snippet.

• Roadmap narratives. Tie bets to outcomes; outcomes to strategy.

• Red team reviews. Ask a friendly critic to try to break your plan-before the market does.

Closing thought

“In discovery mode, we try to create solutions which are valuable, usable, feasible, and viable.” -Marty Cagan. That’s not poetry; it’s a checklist for your week. Run small tests, talk to customers, and align the org-again and again. Do that well, and no one will remember the meetings you canceled or the features you killed. They’ll remember that the product actually worked. (Mind the Product)

Product management has matured enormously in the past decade-new frameworks, better tooling, and a worldwide community that will happily debate whether a roadmap should be a slide, a memo, or a mood. Yet the hard parts persist. Below are ten chronic, still‑unsolved problems in PM, each with research, practitioner quotes, and pragmatic ways to chip away at them.

1) Escaping the “feature factory” and proving outcomes (not output)

Most PMs agree we should measure success by outcomes. ProductPlan’s 2024 report shows a marked shift toward outcomes (usage, retention, revenue) over counting features shipped. But it also admits many orgs still track output because it’s easier-and because executives ask for it. In short: belief outruns behavior. (ProductPlan)

The waste is real. Pendo’s analysis of anonymized product usage found ~80% of features are rarely or never used. Their 2024 benchmarking suggests the median feature adoption rate is just 6.4%-meaning a tiny slice of your surface area drives most of the value (and support requests). (Pendo.io)

Practitioners see it, too. A plain‑spoken Redditor defines a feature factory as a team that “continually pumps out new stuff at the request of management… with little autonomy.” And a Hacker News commenter adds the cost: “More features mean a more complex system… if you’re not measuring value, parts of your product can cost far more than they’re worth.” (Reddit)

What to try next: Pair every roadmap item with a measurable behavior change (your input metric) and its link to a business outcome; kill or iterate when the behavior doesn’t move. Make “adoption reviews” as routine as launch reviews.

2) Turning strategy into something teams can actually use

Even when companies have a strategy, it often dies on impact with reality. McKinsey’s multi‑year analysis of transformations found programs are 5.8× more likely to succeed when leaders communicate a compelling change story-and 6.3× when senior messages are aligned. Product work is no different: ambiguity is the silent killer of cycles. (McKinsey & Company)

What to try next: Write the “strategy as a memo” (two pages is fine): From → To, Because, So we will, We’ll know it worked when. Then make it easy to repeat. If a designer can’t paraphrase it in standup, it’s not strategy yet.

3) Sustaining continuous discovery (without breaking delivery)

Most teams intend to talk to users; calendar physics disagrees. Teresa Torres’s benchmark is simple but hard: “At a minimum, weekly touchpoints with customers by the team building the product,” doing small research toward a desired outcome. That cadence is the difference between opinion and evidence. (Product Talk)

What to try next: Block a team‑owned, recurring 45‑minute discovery session every week (interview, usability test, or log‑review). Treat skipped sessions like an outage: capture a reason, and fix the underlying cause (recruiting, incentives, or scheduling). Tools help-but the habit matters more. (videos.producttalk.org)

4) Establishing causality: proving a release actually helped

The humbling truth from controlled experiments: at Microsoft, only about one‑third of ideas improved their target metric; a third were flat; a third made things worse. Kohavi’s work (later echoed across Amazon/Airbnb) is widely cited because it collides with our intuition. As he summarizes: our intuition is poor; 60–90% of ideas don’t improve the metric(s). (Stanford AI Lab)

You can’t A/B test everything (sample sizes, ethics, latency). But you also can’t pretend dashboards prove causality when five things changed at once.

What to try next:

• Default to controlled experiments for high‑traffic decisions; use quasi‑experimental methods (switchback tests, diff‑in‑diff) where you can’t randomize.

• Pre‑register success metrics and guardrails to avoid p‑hacking.

• Keep a “reversal log” so you learn from ideas that hurt.

5) Prioritization under radical uncertainty (and the estimation trap)

You can RICE, WSJF, and stack‑rank all day. The problem is variance. Steve McConnell’s Cone of Uncertainty shows early estimates are inherently off by large factors-no matter how skilled the estimator-so early business cases are fragile. Using them as hard commitments turns product bets into calendar fiction. (Construx)

What to try next: Prioritize by risk retirement, not guess‑precision. Ask: “What’s the smallest, fastest test that changes our confidence the most?” Move funding from feature line items to options (bets unlocked by evidence). Teach leaders to buy information before scope.

6) Tool sprawl, data fragmentation, and the missing single source of truth

The average company now runs ~93–100+ SaaS apps; large enterprises average 231. That’s a lot of logins-and conflicting “sources of truth.” Okta’s Businesses at Work shows the number keeps creeping up, even as many firms try to consolidate. For PMs, this translates into scattered analytics, duplicate roadmaps, and painful reconciliation. (Okta)

Sprawl isn’t just annoying; it’s wasteful. Surveys peg material license waste and hidden costs from duplicate tools and shadow IT. (Tool vendors love this; your users don’t.) (TechRadar)

What to try next: Stand up lightweight product operations to own taxonomy, event instrumentation, and research repositories; federate dashboards into a few “golden” artifacts (e.g., NSM + inputs). Your goal isn’t one tool-it’s one story. (Pendo.io)

7) Shipping fast and sustainably (the debt dilemma)

Shipping is table stakes; sustainable shipping is the moat. DORA’s research ties the “four key metrics”-deployment frequency, lead time for changes, change failure rate, and time to restore-to better organizational outcomes and healthier cultures. But many orgs still treat these as “engineering stats,” not product levers. (DORA)

What to try next: Put one DORA metric on the product scorecard and discuss it in the same breath as activation/retention. Elite teams aren’t faster because they work later-they’re faster because they reduce batch size and recover quickly. (DORA)

8) Collaboration overload: alignment by meeting (and the cost of time zones)

Hybrid work made it easier to include everyone-and to schedule everyone. Microsoft’s 2025 Work Trend Index shows meetings after 8 p.m. are up 16% YoY, and ~30% of meetings now span multiple time zones. Reclaim’s tracking found professionals average 17.1 meetings/week (≈ 14.8 hours). Try strategizing with that calendar. (Microsoft)

Linked teams feel the pain; so do PMs’ families. As Lenny Rachitsky quipped on X/Twitter, “I don’t see product management work becoming faster at the same speed as engineering. I’m seeing this ratio shift.” Translation: PM “surface area” keeps expanding. (X (formerly Twitter))

What to try next: Give every recurring meeting a single decision; cancel when none exists. Push context into pre‑reads. Reserve two no‑meeting blocks per week for discovery and deep work. Treat meetings as tools, not lifestyle.

9) Designing for value without manipulation (and staying on the right side of the law)

The temptation to “optimize the funnel” can slide into dark patterns-a regulatory and reputational hazard. The U.S. FTC’s 2022 staff report catalogs common deceptive designs (hard‑to‑cancel flows, disguised ads, sneaky data sharing) and makes clear enforcement is rising. In the EU, the Digital Services Act explicitly prohibits certain dark patterns and mandates transparency reporting. PMs are now expected to build safety and fairness by design. (Federal Trade Commission)

What to try next: Add an “integrity review” (privacy, minors, accessibility, consent) to your definition of done. Keep screenshots of consent flows, cancellation steps, and pricing pages in a compliance appendix. If you’d be embarrassed to show it to a regulator-or your grandmother-don’t ship it. (FAS Project on Government Secrecy)

10) Measuring PM craft (not just product results)

There’s still no universally accepted, quantitative way to measure product managers. ProductPlan’s research shows orgs increasingly track outcomes (good!), but translating that into fair PM performance signals is thorny: results are shared, lagging, and often confounded. Cue the endless debate over KPIs vs. 360s vs. “trust me.” (ProductPlan)

The rise of product operations is one response: standardize rituals, data, and tooling so PMs can spend more time on strategy and discovery-and leaders can see the craft more clearly. (Also: fewer bespoke dashboards with eleven shades of teal.) (Pendo.io)

What to try next: Combine a team outcome score (behavior metrics + a business KPI) with a craft score (peer feedback on discovery habits, decision quality, and communication). Publish the rubric. Reward better bets, not louder slides.

Bonus problem: PM identity whiplash (and the internet’s opinions)

PMs live in the splash zone of hot takes. A popular HN comment: “The best product manager I worked with… was just an exceptionally bright person… basically a value add to the company.” A less charitable thread calls many PMs “gatekeepers.” Meanwhile on Reddit, a weary PM writes: “I learned this the hard way… my success depended on how others saw my job, not just how I did it.” None of that is data-but it is the reality of reputation in a role built on influence. (Hacker News)

A LinkedIn post, riffing on Pendo’s stat, sighed: “The saddest statistic I saw this week… 80% of features… rarely or never used.” The point isn’t doom; it’s a reminder that craft is choosing not to build most things. (LinkedIn)

Putting it all together: A battle‑tested, unsolved‑but‑improvable loop

1. Write a repeatable strategy. Two pages, tops. Test it in plain English. (McKinsey & Company)

2. Run weekly discovery. Keep it small, steady, and in the trio. (Product Talk)

3. Tie bets to behavior + business. Make adoption reviews routine. (Pendo.io)

4. Experiment where it counts. Expect to be wrong ~2/3 of the time; learn fast. (Stanford AI Lab)

5. Budget for uncertainty. Buy information before scope. (Construx)

6. Tame the stack. Fewer tools, clearer taxonomies. Product ops is your friend. (Okta)

7. Make flow a product goal. Put one DORA metric on your product dashboard. (DORA)

8. Optimize for decisions, not meetings. Use pre‑reads; cancel purposeless time. (Reclaim)

9. Ship with integrity. Pre‑empt dark patterns; document the choices. (Federal Trade Commission)

10. Measure PM craft fairly. Blend shared outcomes with behavioral evidence. (ProductPlan)

Why these remain “unsolved”

These challenges are systems problems. They involve incentives, uncertainty, and humans-none of which sit tidily in a JIRA filter. As one HN thread about “feature factories” put it, doing Scrum harder won’t save you if the org measures the wrong things. You can’t framework your way out of a misaligned system; you can only change the system-slowly, evidence first. (Hacker News)

If this all sounds a little daunting, good. PM is the craft of turning ambiguity into alignment without kidding yourself about what’s unknown. Keep the humor handy. Keep the receipts (data). And keep building teams that can argue, learn, and decide together.

“Good teams engage directly with end‑users and customers every week… Bad teams think they are the customer.” -Marty Cagan (still an aspirational norm in 2025). (Silicon Valley Product Group)

Stripe is the archetype of a developer‑first company: it turned docs, SDKs, and APIs into the product, then layered a decade of infrastructure decisions (versioning, idempotency, uptime discipline) on top. The result is a compounding advantage that looks nothing like short‑term growth hacking: businesses on Stripe processed $1.4 trillion in 2024 (up 38% YoY)-about 1.3% of global GDP-and Stripe says it’s now used by half of the Fortune 100, 80% of the Forbes Cloud 100, and 78% of the Forbes AI 50. (Stripe Assets)

Below is a deep dive into how Stripe builds product-grounded in public letters, docs, engineering posts, and the developer community’s commentary.

1) “Developer‑first” means docs are the product

If you ask developers on Hacker News about exemplary API docs, Stripe is the default answer: “Stripe API docs.”Another comment adds, “Stripe started really really well with its developer, library and documentation support… a very large part of their initial success.” Those threads repeat across years. (Hacker News)

What does “developer‑first docs” look like in practice?

• Interactive, multi‑language examples and try‑it flows right in the docs. Stripe’s documentation home exposes quickstarts, code in multiple languages, test cards (“4242 4242 4242 4242”), and a unified navigation that treats “API reference” and “how‑to” as first‑class neighbors. (Stripe Docs)

• CLI & Workbench tools that make integration and debugging part of the product surface, not an afterthought. The Stripe CLI tails logs, triggers webhooks, and exercises endpoints; Workbench offers an in‑browser shell, API explorer, and health alerts. Developers can also simulate time with Test Clocks to verify billing flows without waiting weeks. (GitHub)

• Authoring system as product: Stripe open‑sourced Markdoc, the framework behind its interactive docs. As the team put it, Markdoc “decouple[s] code and content while enforcing proper discipline at the boundaries,” keeping docs consistent and up‑to‑date. A Stripe engineer on HN summarized the practice: “documentation is part of the ‘definition of done.’” (Stripe)

• Machine‑readable backbone: Stripe publishes its OpenAPI spec and ships updates constantly; this backbone fuels code samples, SDKs, and consistency across languages. (GitHub)

None of this is glamorous. It’s the unsexy blocking and tackling that turns “read the docs” into “ship the integration.”The payoff shows up in adoption and in how the developer community talks about Stripe.

Balanced view: Not every developer thinks Stripe’s docs stayed perfect at scale; some HN voices argue they’ve grown more complex. That dissent is part of the truth of building at internet scale. (Hacker News)

2) API design as a product feature (not an implementation detail)

Stripe treats API quality as a user‑facing feature with three cornerstone practices.

a) Idempotency by design

Networks fail. Retries happen. Stripe’s API supports idempotency keys so clients can safely retry without double‑charging-formally documented and evangelized in blog posts that became canonical for API designers. (Stripe Docs)

“The API supports idempotency for safely retrying requests without accidentally performing the same operation twice.” - Stripe API Reference. (Stripe Docs)

This pattern isn’t just “nice to have”-it’s critical for money movement. You’ll see it referenced in countless developer discussions and Stripe SDKs. (Hacker News)

b) Versioning that protects integrators

Stripe’s versioning strategy is unusually explicit: frequent, backward‑compatible monthly releases and named major releases when breaking changes are unavoidable, with tools and docs to manage upgrades. Engineers have written publicly about why Stripe doesn’t auto‑upgrade users (to avoid breaking integrations), and how it defines deprecationswith a bias toward absorbing support costs instead of shifting them to customers. (Stripe Docs)

An HN commenter (self‑identified as Stripe) captured the ethos: once you publish a web API, you must treat backward‑incompatible changes with extreme caution-especially in payments. (Hacker News)

c) Evolving primitives without breaking merchants

When the EU’s Strong Customer Authentication (SCA) rules arrived, Stripe didn’t paper over the change; it introduced PaymentIntents and SetupIntents as new primitives that explicitly model asynchronous, multi‑step authentication-and provided migration tooling and guides from legacy flows. (Stripe Docs)

That choice-changing the model, not just the docs-embeds regulatory realities into the product so merchants can comply without bespoke hacks. It’s a template for PMs handling external shocks (policy, platform, or ecosystem changes).

3) Infrastructure as a product moat: reliability, scale, and money movement

Stripe’s annual letter and engineering blog make a simple case: reliability is part of the user experience. In 2023, Stripe processed $1 trillion while achieving 99.999% uptime for its document database layer-“DocDB,” a heavily customized extension of MongoDB that serves 5+ million queries/sec across 2,000+ shards-and built a Data Movement Platformto do zero‑downtime shard migrations. That’s not just an engineering flex; it’s why checkout “just works.” (Stripe)

At the business layer, Stripe’s 2024 letter reports $1.4T total payment volume and attributes growth in part to long‑running investments in machine learning and AI that improve authorization and fraud outcomes-again, infrastructure work surfacing as customer revenue. (Stripe Assets)

The product surface now spans a full financial stack: Connect for platforms and marketplaces, Issuing for programmatic cards (including charge cards), Treasury for embedded banking via partner banks, Terminal for in‑person payments, and Atlas to incorporate in the US for $500. Each is API‑first, deeply documented, and strategically adjacent to core payments. (Stripe)

Infrastructure bets also show up in Stripe’s public‑goods posture: it co‑founded Frontier, a $925M+ advance market commitment to permanent carbon removal (with Alphabet, Shopify, Meta, and McKinsey), and has continued to make multi‑year offtake deals-an unusual move for a private fintech, but consistent with a long‑term, systems‑building worldview. (Frontier)

4) Outcomes & community perception (and why HN cares)

• Scale and durability: 2024 TPV of $1.4T (+38% YoY), usage across major enterprise and startup cohorts, and continued profitability (per press coverage) without rushing an IPO. (Stripe Assets)

• Conversion impact mentality: Stripe regularly publishes data on checkout performance (e.g., “99% of top ecommerce checkouts make five or more basic errors”) and runs large‑scale experiments on payment methods and authorization optimizations-treating optimization as a platform responsibility, not just a merchant problem. (Stripe)

• Developer goodwill (with caveats): HN threads routinely cite Stripe as the docs/API benchmark-though some argue complexity has increased. That conversation-including the visible trade‑offs-is a hallmark of a mature platform. (Hacker News)

Perhaps the clearest statement of Stripe’s product lens is its mission to “increase the GDP of the internet.” The company repeats it in talks and letters-not as brand copy but as operating strategy: grow the pie by removing friction and expanding participation. (Haas News | Berkeley Haas)

5) What PMs can actually copy from Stripe

1) Treat docs and tooling like core features.
If your users are developers (or even just integrators at customer companies), invest in interactive docs, a CLI, and a sandbox that make doing the right thing the fastest thing. Make documentation part of your definition of done. If you can, generate docs from a single source of truth (e.g., OpenAPI) and ship language‑specific examples by default. (Stripe)

2) Design for failure modes.
Build idempotency into write endpoints; document retry semantics; model long‑running or multi‑step flows explicitly (like PaymentIntents). You’ll avoid entire classes of bugs and support tickets, and your customers won’t fear pressing “retry.” (Stripe Docs)

3) Version like an infrastructure company.
Adopt a compatibility contract. Cut breaking changes only on explicit major releases; make monthly releases backward compatible; and give teams time and tooling to upgrade. Publish precise changelogs and upgrade guidance. Your future developers (and customers) will thank you. (Stripe Docs)

4) Translate regulation into primitives.
Don’t fight the ecosystem; encode it. Stripe’s move from token/charge to intent‑based payments (to handle SCA and asynchronous auth) is a model: change your product’s objects to match reality, then ship migration paths. (Stripe Docs)

5) Make reliability a product requirement.
Publish SLOs internally; invest in the data platforms that let you migrate and evolve state without downtime; and surface reliability wins as customer value (higher auth rates, fewer support pings). Stripe’s 99.999% DocDB uptime isn’t just a graph-it’s fewer abandoned carts. (Stripe)

6) Think in decades, not quarters.
Stripe’s expansion-Connect, Issuing, Treasury, Terminal, Atlas-are multi‑year compounding bets that widen the platform’s surface area and defensibility. If your product has platform potential, identify adjacent capabilities that unlock new business models for users, then invest patiently. (Stripe)

6) A brief contrast with “growth‑hacked” product playbooks

Short‑term growth hacks often optimize around integration pain; Stripe optimizes integration itself. Consider three differences:

• Friction removal vs. friction camouflage. Test cards, interactive examples, Workbench, and Test Clocks reduce time‑to‑first‑value; hacks would hide failures or defer integration debt to customers. (Stripe Docs)

• Contracts over campaigns. Versioning, idempotency, and SCA‑ready primitives build trust and lower long‑term switching costs-for both sides. (Stripe Docs)

• Systems metrics over vanity metrics. Stripe’s letters discuss volume, auth improvements, and reliability-not just signups. That’s why HN treats Stripe like an infrastructure company, not a front‑end tweak machine. (Stripe Assets)

7) A note on reality: trade‑offs and critiques

At Stripe’s scope, complexity increases-new payment methods, geographies, compliance regimes, and ecosystem changes (like SCA) force API evolution. Some community members argue the docs and APIs are less simple than in 2014. That’s reasonable. The lesson for PMs isn’t to avoid complexity; it’s to contain it with explicit primitives, strong upgrade paths, and relentless tooling. (Hacker News)

Closing

Stripe’s product strategy isn’t magic. It’s a discipline:

• Make docs, APIs, and developer tools your product.

• Engineer for failure and change-by contract.

• Invest in reliability and compounding adjacencies.

• Align it all to a durable mission-increase the GDP of the internet-that rewards patience and systems thinking. (Haas News | Berkeley Haas)

For PMs building platforms or developer surfaces, that discipline is eminently copyable. Start by making your next feature’s documentation, CLI support, and upgrade path part of the spec-not a follow‑up task.