Lenny's Podcast · Jun 14, 2026
Mark Pincus presents "Proven Better New" — a product development framework that systematically de-risks innovation by separating what must be copied from what can be improved from what needs to be original. The throughline is that instincts about problem spaces are almost always right, but specific product ideas are almost always wrong, so the job is to test many ideas fast rather than commit to one heroically.
A structured method for building products that maximizes your chances by copying what already works, adding clear improvement, and testing one new idea — in that order.
Most failed products die because they innovate on the wrong layer — they break proven UX to ship a new idea nobody validates. This framework gives your team a shared language to separate what's in scope for innovation from what must be copied. In regulated enterprise contexts where user trust is hard to earn, getting the proven layer right before touching anything else is especially high-leverage.
It's like a new restaurant: nail the service and cleanliness first (proven), make the food genuinely better than the place next door (better), then add one signature dish nobody else has (new).
Your sense that "there should be a product here" is almost always correct; the specific form you imagine that product taking is almost always wrong.
In enterprise product work, teams frequently conflate conviction about a problem with conviction about a solution. This distinction gives you a principled reason to kill a specific feature or approach without abandoning the whole discovery track. It also reframes discovery velocity — the goal is to test more ideas per week against a stable instinct, not to protect any one idea.
It's the difference between a doctor's intuition that something is wrong with a patient (almost always right) and the first diagnosis they write down (often revised).
Because founders are taught that copying is cheating, those willing to do it well have access to a less crowded, higher-probability path to product success.
In B2B and enterprise product work, competitive analysis is already standard — but most teams use it as inspiration, not as a precise execution checklist. Treating "proven" as a mandatory first deliverable, not a reference point, is a different operating posture. It also helps with stakeholder alignment: "we are deliberately copying the best interaction pattern for this workflow" is a stronger argument than "we designed this from first principles."
It's like being the first restaurant in town to copy a format that's already proven wildly popular in another city — the idea isn't new, but the market gap is real.
The path to building something huge runs through an embarrassingly small starting point, and past success makes this harder, not easier, to accept.
In corporate product contexts, this is the anti-pattern behind most "pilot graveyard" failures — the scope is set at the level that sounds impressive to a steering committee, not at the level where signal can actually be found. For discovery work specifically, this suggests the MVP scope should be set by what can generate a clear yes/no answer, not by what the roadmap requires.
It's like drilling for oil — you start with the smallest, cheapest hole that can confirm there's something underground, not with the full production rig.
Hope is confidence without evidence; the discipline is to identify which of your current product bets are running on hope and cut them before they cut you.
Enterprise product teams are especially vulnerable to hope-sustained projects because killing them requires navigating organizational politics. Making the hope/belief distinction explicit gives you a neutral, principled framing to de-escalate those conversations: it's not about the team failing, it's about removing hope from the decision-making loop.
It's the difference between a navigator who checks the instruments and one who just feels like they're going the right direction.
There are two valid reasons to ship something: to learn, or because you already know it will win — and knowing which one you're doing changes every decision you make.
In enterprise contexts, the pressure to "launch" is high — stakeholders want a product, not a learning artifact. Making this distinction explicit in your team's language helps you defend low-fidelity experiments without looking like you're shipping garbage. It also reframes what AI-assisted development should be used for: running 100 tests in a week, not building one polished product in three months.
A scientist uses a prototype to confirm a hypothesis before building the real instrument — and never confuses the two.
AI should let you test 100 ideas in a week, but most teams are using it to build one idea in three months slightly faster.
For enterprise product teams, this reframes the AI tooling conversation. The question isn't "how do we use AI to build faster?" — it's "how do we use AI to invalidate more assumptions per sprint?" This is directly relevant to discovery practice and to making the case for experimentation infrastructure as a product investment.
A drug company uses combinatorial chemistry to test thousands of compounds at once — not to build one drug faster.
Building for day-365 retention forces a fundamentally different product philosophy — and the teams that do it outperform those optimizing for short-term engagement.
Most enterprise product teams track activation and sometimes D30. Framing long-term retention as the north star rather than an output metric changes prioritization: features that drive one-time use get deprioritized in favor of features that create recurring value loops. This is particularly important when pitching product investment to finance/business stakeholders who want to see stickiness, not just adoption.
It's the difference between measuring how many people enter a gym and measuring how many still come a year later — only the second number tells you if the gym is actually good.
ASN measures how many genuine two-way social exchanges a user has inside your product — and it turns out to be one of the strongest predictors of whether they'll still be using it next month.
For any product with a social or collaborative dimension — which increasingly includes enterprise tools — this is a more precise framing of "network effects" at the individual user level. Instead of tracking aggregate network size, you track whether each user has a reciprocal relationship inside the product. It's directly applicable to collaboration tools, internal platforms, or any product where value comes from interaction with others.
It's like measuring not how many contacts someone has in their phone, but how many people actually called them back.
The best opportunities are categories that don't exist yet but where the underlying human need is obvious once you look for it.
In discovery work, most teams look for validation by finding existing traction. Latent demand flips this: you're looking for strong desire combined with high friction or inaccessibility. In regulated enterprise contexts, this often shows up as "everyone does this manually in Excel" — which is a classic latent demand signal.
It's water pressure behind a dam — the demand is there, you just need to open the right gate.
Every successful social platform has been a cocktail party that created productive social leads; the next wave of social will be built around AI agents hosting or brokering those parties.
If you're building any product with a social or community dimension — including enterprise collaboration tools — this framework asks the right question: what is the "lead" your users are getting from interacting with each other inside your product? If you can't answer that, you have engagement without value, which is what kills social products long-term.
Every great social platform is really a very efficient matchmaker — the cocktail party metaphor just makes it easier to feel when the matching is working.
Instead of managing people, give each person a specific hill to take, full freedom to take it their way, and a budget — then get out of their way.
In large organizations, the frustrated expert witness is common — smart individual contributors who know the answer but never get the authority. This framing gives you a hiring and delegation model that converts that frustration into output. It's also a useful structure for product teams working within complex stakeholder environments where PMs need air cover to execute without constant approval loops.
It's like sending a special forces unit with a mission objective and letting them choose their route — versus sending them with step-by-step instructions.
The higher you go in an organization, the more deliberately you need to stay involved in the smallest product decisions — because those are where quality is won or lost.
For senior PMs in large organizations, this is a direct argument against the common pattern of becoming a "strategy layer" that never touches product details. Staying close to the metal is how you maintain the instinct calibration that makes your instincts trustworthy. It also makes you harder to marginalize — you're the person who actually knows what's in the product.
It's the difference between a head chef who tastes every dish before it goes out and one who only reviews the menu.
Hitting rock bottom in a product cycle strips away ego and forces the radical clarity of focus that success makes it easy to avoid.
This is a reframe on the sunk-cost conversations that dominate enterprise product discussions. The abyss isn't a failure state to be avoided — it's a forcing function that removes the organizational inertia keeping teams on B+ ideas. If you can manufacture the intellectual honesty of the abyss without actually running out of money ("we will act as if this is our last chance to get it right"), you get the product clarity without the existential risk.
It's like how composers who lose everything write their most honest work — constraint and desperation remove the noise that success adds.
Design your consumer AI product for the token economics of two years from now — the infrastructure cost will catch up to your product vision faster than you think.
For product strategy in AI-adjacent categories, this is a useful lens for roadmap prioritization: what would you build if inference were free? If the answer is different from what you're building now, you may be letting current cost constraints distort your product vision. This is directly applicable to enterprise AI product decisions where per-query cost often drives scope decisions.
It's like designing a streaming video service in 2005 — the bandwidth wasn't cheap yet, but you built for the world where it would be.
Your product is probably running on hope, not belief.
Pincus draws a hard line between evidence-based belief and hope-sustained product bets. If you're asking whether your product is working, it's not. This is a directly actionable test for any current initiative in your portfolio.
The Proven Better New framework is the most operational take on 'copy smart, innovate small' that exists.
It gives you a shared team language for separating what must be copied exactly, what must be improved measurably, and what single new idea you're actually betting on — directly applicable to how you run discovery and roadmap prioritization.
AI is changing which product bets make sense — but most teams are using it to go faster, not smarter.
Pincus argues AI's real value is enabling 100 hypothesis tests per week instead of one per quarter. For enterprise product teams where experiments are expensive and slow, this reframes what AI tooling investment should be optimized for.