We can't find the internet
Attempting to reconnect
Something went wrong!
Hang in there while we get back on track
Big Ideas
PRDs are moving from permission slips to decision records. The old flow was Idea → PRD → Design → Build → QA → Ship; the proposed AI-era flow is five prototypes, evaluate, kill four, then write the PRD for the survivor. Cheap prototypes move documentation later, and the PRD’s job changes: capture opportunity, boundaries, success measurement, a behavior contract, rollout, and risks—what the prototype cannot communicate, including why, measurement, and rollback. The note cautions against copying zero-PRD teams when regulation or many stakeholders make explicit alignment necessary.
AI-era PMF is perishable. Andrew Chen argues that improving models make older products obsolete; fit depends on comparison with alternatives across the ecosystem and “follows the frontier.” Treat model progress as a recurring competitive review: re-test the product against current alternatives and make the next innovation a roadmap requirement, rather than treating an initial PMF result as a durable moat.
Tactical Playbook
Turn states into contracts before polishing screens. A founder’s redesign rework began with decisions that never specified the trigger, user action, system action, or next destination. Writing those four items beside each important state reduced design back-and-forth; the unresolved question is where decisions live as the product changes. Make the four questions required in the PRD or decision log and link that canonical record from design and engineering, so a changed screen does not silently reopen the underlying decision.
Do not count enterprise meetings as traction. Paul Graham’s warning is blunt: a big company may spend months in meetings without saying no, and meetings are not commitment. Use each meeting to secure evidence—a named problem owner, budget and timeline, a bounded pilot, and an agreed success/stop condition—before forecasting demand.
Case Studies & Lessons
Pylon automates investigation, not accountability. Pylon says its new agentic-support product serves B2B companies and about 1,600 customers. Its thesis is that full-resolution bots handle the easier slice of tickets; in one roughly 5,000-person example, a bot deflected about 50% of tickets without reducing headcount. Pylon’s alternative pre-investigates each ticket across past issues, logs, code, documentation, account context, and Slack, then lets the rep interrogate the result, create a Linear issue, or draft a reply while retaining responsibility for the outcome. In beta, Pylon reports one customer cut escalations 70% in about a month and another improved time to first response by 64.5%. The product lesson is to automate context gathering and repeatable actions while keeping judgment and guardrails human.
Career Corner
Keep management reversible. Lenny’s Whatnot discussion asks why VPs of Product are becoming ICs again. Its accompanying takeaways say four or five PM managers spend at least 90% of their time on IC work, while the CPO spends about half his time as an IC. Preserve hands-on reps in data, decisions, and product work; a title change should not end craft development.
Tools & Resources
A lightweight AI build workflow. Patrick Collison’s economics-of-AI survey was built locally in two prompts and deployed in one: a single instruction asked Claude to push to Vercel, create the Stripe account, and store state safely; Claude chose Upstash as the datastore. Use this pattern for low-risk prototypes while keeping scope, data, and rollback decisions explicit.
Practice discovery, don’t just read it. Teresa Torres’ 2026 group read pairs one section per month with discussion questions, exercises, teammate videos, and quarterly live sessions; the current Chapter 9 focuses on story mapping, pre-mortems, and assumption testing.
- Physical vs digital AI. Building AI for the physical world differs from digital AI across four gaps: cost of error (lives, not tokens; no undo/retry), latency (a car at freeway speed moves ~100 ft/second, so inference must run onboard), data (no digitized "internet" for the physical world), and validation (you cannot ship good-enough and iterate; high safety and confidence are required on day one) . The operating principle is "move fast and ship safely," not "move fast and break things" .
- Demo-to-product gap. At Whimo a working demo was "1% at best" of the work: a ~12-engineer team reached a capability-complete autonomous demo in ~18 months (2009-2010, before deep-learning breakthroughs), but it took ~10 more years to begin offering a service and ~15 years to reach scale . Reliability climbs an exponential "ladder of nines" — each additional nine costs ~10x more effort — and at fleet scale the long tail is the entire problem space: a once-per-million-miles event becomes daily reality .
- Define required "nines" upfront. Product leaders must know how many nines their product demands before building: a demo needs ~one nine, an assist/co-pilot "a few," and a fully autonomous agent engaging the public "a whole stack" . Every hype cycle produces spectacular demos and few real products because teams spend on the demo what they should save for the long tail; the advice: "count your nines before you count your demo views" .
- Choose technology by required performance, not early ramp. Every technology's performance-vs-effort curve flattens; the common failure mode is riding a steep early curve that plateaus below the product's required nines, so be honest about whether you are building a demo, learning, or a product . Whimo's example: vision-only sensing may suffice to match human performance, but superhuman full autonomy required multi-modal sensing (cameras, lidar, radar) with redundancy, since weak sensing flattens the safety curve too early .
- Ride tech waves while unifying the stack. Whimo rebuilt its driver around each AI wave (convnets ~2013, transformers ~2017, VLMs/frontier world models today), running tiger teams but requiring a predefined success path — a successful project that ends in a dead end is wasteful — and demanding that new tech deliver both breakthrough performance and simplification/unification rather than fragmentation .
- Eval and metrics before building. "Build your eval and your metrics before you build your product" — eval, not the model, is the strategic asset and steers the whole tech stack . "If you can't quantitatively define what good enough means, you're not really building a product. You're just iterating on your demo" . For physical AI, validation must go beyond model-level evaluation to every component — physical to behavioral, onboard and offboard, plus operational processes — via a "safety and readiness framework" .
- Trust as the ultimate moat. In the physical world "trust is everything," earned by relentlessly proving safety in the field and openly publishing safety data; it becomes the definitive business advantage because models and algorithms can be replicated, but hundreds of millions of miles of real-world operation backed by evidence-grade evaluation and publicly audited proof are much harder to copy .
- Agent-simulator-critic flywheel. A production-grade closed-loop simulator is itself a major AI, "just as hard as building the agent itself" . Whimo runs three AI systems on one shared foundation model — the agent, the simulator, and a critic that judges performance — powering a flywheel: real-world deployment generates data, data grounds the simulator, the simulator generates harder edge cases, and the critic tells the agent how to improve .
- Results. The playbook's outcomes: 20M+ fully autonomous trips and 200M+ autonomous miles, rider-only vehicles in 15 US cities with 4M+ autonomous miles per week ; it took 8 years to reach the first four cities, then four cities launched in a single day this year . Latest published safety data (220M+ miles) puts the Whimo driver ~17x better than human drivers on crashes causing serious injury — one serious injury prevented every eight days at current scale .
Lenny Rachitsky's takeaways from Tom Verrilli (CPO at Whatnot) :
AI's biggest unlock for PMs is now in data science, not prototyping: cohort retention pulls, analyzing user logs, and sensitivity/regression models on a Hex thread that took an Amazon L7 data scientist a week or two in 2017 now take minutes; Verrilli spends 10x more time in data and less time talking to data scientists than ever.
Verrilli 'regrets that product management exists' — PM is a trade, not a qualification, built by reps; defaulting to many PMs takes reps away from engineers and designers and infantilizes people who could make good decisions.
AI is exposing rampant 'product theater': stakeholder management, alignment, and storytelling are real work but not product work, yet are what the industry has rewarded PMs for the past five years; theater only survives where real work is expensive to verify, and it isn't anymore. At Whatnot, every hire is given a problem and a dataset and must defend a POV out loud.
The PM skill trending up fastest is systems thinking: in every product review, ask 'What do we do if the experiment is green? What do we do if it's red?' If the answer is 'I don't know,' the mental work hasn't been done.
Stop promoting A-players out of the work they're great at; at Whatnot, the four or five PM managers each spend at least 90% of their time on IC work, and Verrilli spends about half his time as CPO as an IC.
'It's really complex' is usually code for weak leadership: Twitter ran working groups on lifting the 140-character limit for Verrilli's entire tenure even though Japanese users tweeted six times as often because kanji packs more meaning per character; it shipped almost two years after he left and nothing bad happened. Ask whether something is actually complicated or leadership just won't decide.
Map PMs to problems, not teams: every six months, Verrilli, the CEO, and senior leads define strategy and key pillars, then assign DRIs by skill set; some engineering teams go a year without a PM, and PMs build reps across buyer, seller, and trust problems instead of spending years on one surface.
Averages mean nothing to the individual: a feature only 3% of users touch can be 100% of the use case for some users, so ask what distribution hides under the average and trust the anecdote when it conflicts with the data.
True PMF is felt before it's seen in the data: Twitter had nine heads of product in two years and survived because network effects held — even after the name, brand, team, and culture changed. Career lesson: work somewhere with true PMF early.
End turf wars by giving one person both sides of the tradeoff: at Twitch, discovery and ads fought over impressions until ads sat inside discovery under a single PM accountable for total GMV from the feed, organic and paid; tradeoffs get made naturally, cutting months of back-and-forth and politics.
An episode featuring Whatnot CPO and former Twitch/Twitter product leader Tom Verrilli , billed as "The CPO who regrets that product management exists" , discusses how AI is exposing rampant "product theater", names systems thinking as the PM skill trending up fastest, and says AI's biggest unlock for PMs is now in data science, not prototyping . It also urges PMs to stop promoting A-players out of the work they're great at and argues "hire great people and get out of their way" is wrong . On careers, Verrilli explains why so many VPs of product are becoming ICs again: becoming a VP sounds like the dream until you actually get there .
Pylon (B2B customer support platform, ~1,600 customers, ~3 yrs old) launched "agentic customer support," where support reps orchestrate AI agents instead of doing manual ticket work; positioning is human+AI augmentation rather than full-resolution bots, arguing agents like Fin/Sierra only automate easy tickets — e.g., a 5,000-person company with a 1,000-person support team deflected 50% of tickets with no headcount change.
In the demo, a background agent automatically investigates every ticket across past issues, logs, codebase, docs, account context, and Slack tribal knowledge, returning an investigation and suggested next steps; the rep remains accountable, can ask follow-ups, and run skills (e.g., create Linear issue, draft reply in the rep's tone) that package the context.
Against DIY Claude skills, Pylon pre-computes account context (setup, goals, use cases, interactions, sentiment, related tickets/knowledge sources), claiming 3–6x cheaper inference, better quality, faster speed, and team control, with tickets arriving pre-investigated.
Beta outcomes: one customer saw ~70% fewer escalations in about a month; another 64.5% faster time to first response; teams scale without headcount; the Slack agent lets sales/product/engineering self-serve customer and product answers; expert workflows encoded as skills raise the floor and improve onboarding.
Agents learn from each rep's interactions and get better over time, enabling parallel work on pre-investigated tickets; customers who built in-house on Claude face rising costs; teams are hiring more junior and technical people plus a dedicated "builder" persona to maintain agents.
Roadmap: expand from support into "customer work" — mirrors Salesforce/HubSpot data, gives account/sales overviews (timeline, blockers, contacts), and plans upsell signals → suggested next steps → user-approved auto-actions; positions as post-sales, CRM-agnostic.
Implementation guidance: non-technical reps influence agents just by doing their job plus no-code tooling; give agents as much context as comfortable with human-in-the-loop guardrails; channels include SMS, WhatsApp, and Telegram.
Market signal: in AI spend per department, only AI coding has taken off so far, indicating agentic support remains early.
- Treat distribution as a learning process, not marketing: before reaching thousands, hold enough conversations to understand who has the problem, how they solve it today, and why they'd switch; this clarifies messaging. A concrete variant for introverts: pick 10 people with the problem and ask how they handle it today to learn who buys, what language they use, and where they hang out; then run low-volume outreach and warm intros — consistency beats reach.
- Distribution difficulty correlates directly with product-market fit strength: talk to people and pivot on feedback, and only start broad marketing once people in your niche want what you have.
- Build-in-public playbook for first distribution: commit to one platform (X, LinkedIn, Instagram, or Threads), post one learning daily, share product updates, engage followers and ICPs, and message people likely interested.
- For introvert-friendly acquisition, answer questions in founder/niche communities under your own name (no links or pitching); this brought first users and outperformed launch posts. To scale past the ~2-hour/day writing ceiling, repurpose best comments into blog/LinkedIn posts, and track which threads/questions actually drive interest so you can target similar ones.
- Validate demand before building: start with distribution to demand, frame an ICP, and test assumptions quantitatively (e.g., hypothesize "4 out of 10 businesses like this have this problem"; call or walk into 20 and if 8 have it, the assumption has evidence).
- Instead of searching for "early adopters," find people already complaining about the problem in Reddit threads, niche Slack groups, bad G2 reviews, and competitor comments; ask about their workaround before showing anything.
An r/ProductManagement poster described their org introducing a 'Directly Responsible Individual' (DRI) hat that would own estimates, architecture, project definition, interaction with product management, long-term product health, and short-term project outcomes — making their product development role (not reporting to PM) feel redundant and prompting them to ask how to proceed . Several commenters say DRI is not a new creation: it's derived from RACI, and 'PM = DRI' at most places, with one user calling it 'just an extra responsibility' rather than a designation . One commenter's company instead uses a 'quad' (PM, eng lead, product design, TPM), which they note is 'literally not how DRI works' .
A common critique frames DRI as the newest label for 'PM is the CEO of the product' and 'single throat to choke': concentrating accountability for messy shared responsibilities on one person undermines cross-functional team ownership and creates a convenient scapegoat, with process often built around it to avoid the root, often political, issue . Defenders describe DRI as 'almost always the PM' and 'the lead for the project... make sure it's done,' one speculates it originates from Microsoft, another recalls Apple culture before Steve Jobs returned in 1997; one commenter argues DRI is orthogonal to role type — 'You could have a DRI plumber' — and that the poster missed the basic concept .
Teresa Torres is hosting a year-long group read of Continuous Discovery Habits throughout 2026, one section per month, with reflection questions, practical exercises, and resources — framed around not just reading but building the habits . Each month includes reading guides, short shareable videos for teammates, and quarterly live discussion sessions . The current month covers Chapter 9: deconstructing product ideas into underlying assumptions via story mapping, pre-mortems, and assumption testing . The book turns five this year; the program aims for participants to be practicing continuous discovery, not just understanding it, by December .
Lenny Rachitsky's podcast with Tom Verrilli (CPO at Whatnot, former product leader at Twitch and Twitter) discusses how AI is exposing rampant "product theater," systems thinking as the PM skill trending up fastest, AI's biggest unlock for PMs now being in data science rather than prototyping, why you should stop promoting A-players out of the work they're great at, and why "hire great people and get out of their way" is wrong . Verrilli contends: "It's often optimal to not have a product manager" .
A solutions engineer who moved to PM warns that AI fervour persists in product roles — market expectations are shifting toward PM-generated prototypes and wireframes .
PM suits those who want to lead, build strategy, and sell, but it may disappoint those who value IC technical problem-solving; the commenter found the transition hardest despite a top-school math background because PMs act as "mini CEOs" who must influence, be decisive, and be accountable .
A SWE considering the pivot appreciates AI for prototyping but worries about over-reliance on AI in production ("slopified"); the appeal is leading build strategy and selling, and past side projects that helped developers are seen as transferable to PM .
Selecting a primary KPI for a strategic initiative — practical advice from PMs:
- Start with the outcome you're trying to change, not the metric; the KPI follows once the desired outcome is clear (e.g., adoption when built features aren't delivering value, support requests to surface friction).
- Business priorities usually decide it: "the goal essentially defines what KPI to track."
- Ask what the CEO would ask about first; every business has 1–2 primary problems (growth, retention, revenue, margin), and an initiative should address one directly or carry a compelling justification.
- Choose the KPI you'd act on — if a number moving the wrong way wouldn't change the plan, it's a reporting metric, not a KPI. Write down the decision rule (what result would pause/redirect the initiative) before starting; this also helps when the KPI is swapped mid-project.
- Use a KPI tree: the right primary KPI is the furthest-upstream metric the initiative genuinely influences; anything higher is an unsteerable lagging outcome, anything lower is a detail. Keep KPIs separate from diagnostic metrics that explain KPI movement.
- If the main KPI changes midway, ensure work in progress still achieves it; where there's a gap, create a "get it back on track" backlog.
Andrew Chen (@andrewchen) argues that product/market fit is fragile in the AI era: the race of improving AI models makes prior models obsolete, so fit depends not just on a product's features but on how it compares to alternatives across the ecosystem . PMF follows the frontier — a product that seemed powerful one week can be ignored the next; he notes that months ago he thought Opus 4.5 was amazing, but can no longer imagine using it now that Opus 5 is available . Therefore a product's moat depends on the ability to keep delivering the next innovation .
- A physical-product PM (automotive/trucking liftgates) reports the current job market is roughly 90% software-focused: most PM postings are software roles, and they face competition from laid-off software PMs and ATS filtering for non-software backgrounds.
- A hardware/industrial PM notes that despite slower physical product cycles, the work still involves software-like urgency and fast-paced requests: "Weirdly for a hardware product that is physically a slower pace, still lots of drama and fast requests like we’re making software."
An SDE with 7 years at one fintech company is pursuing an external SDE-to-PM transition after internal management said the product team is 'mostly process-oriented' and there's no scope for the move . To strengthen external chances, they are tailoring the resume to highlight product ownership, cross-functional collaboration, stakeholder management, and business impact rather than coding, and deliberately not claiming official PM experience — asking whether recruiters accept this positioning . They currently earn 22 LPA and want a first PM role without a pay cut (ideally a hike) while avoiding expensive MBA or PM courses, and ask whether a hike is realistic or whether to enter product first and negotiate later . They also ask about transition paths, profile focus, companies/job portals with the most PM openings for technical backgrounds, free learning resources, and whether certifications or projects/interview prep matter more .
Hiten Shah says he and Sam Asante have been working on a next desktop app drop since last year, with three pivots already; the pivots have been driven by local AI model progress and feedback from early access cohorts of users, with new cohorts planned soon .
Hiten Shah (@hnshah) posted: 'AI is forcing companies to admit they never really owned their data.'
- B2B GTM = the set of processes that get a product to market: for software, build → test → deploy → onboard; for hardware, design → prototype → test → manufacturing → build → package → warehouse → ship → activate; plus support, pricing, purchase channels, marketing pages, ad campaigns, sales/success training, and customization .
- Distribution ("getting product into customers' hands") is distinct from marketing ("making your value proposition visible to key markets") — both are part of GTM, and "distribution" is often misused .
- Example from a cybersecurity SaaS seller: target CISOs/CTOs via LinkedIn influencer content and sponsored advertorials from industry reporting agencies (endorsement marketing), driving to micro sites with a clear value prop and trial CTA; distribution is the online web portal .
- Hardware example: a water bottle marketed via Instagram influencers and celebrity endorsement for FOMO, distributed via Shopify orders fulfilled by a drop shipper warehouse near the buyer for ~24-hour delivery .
- Match GTM breadth to segment size: ≤200 companies → direct sales and relationship building plus PR for brand trust; ~10k SMEs → broader marketing approaches .
- Find where buyers already complain about the problem and show up there .
- For structurally change-averse institutional buyers, one seller stopped optimizing the pitch and redesigned the offer so the safe choice and the offered choice were identical: remove every ask (no installation, no hardware, no capital cost, no risk to the protected asset) and attach desired upside (a new revenue line and data they couldn't collect before). The conversations changed because saying no meant declining free upside with no downside; the lesson is to optimize the incentive, not the persuasion.
- For enterprise/risk-averse customers, removing cost only addresses price risk; implementation effort, security review, and career risk if the launch fails still block adoption. Make the first step small and reversible: one workflow, a fixed timeline, named success measures, and an agreed stop condition, and predefine what expands and who approves if measures are met — turning free into controlled, internally defensible proof.
- For consumer products, free removes the price objection but not setup effort or habit change: watch where users drop off before the first useful moment, count the steps/taps to reach it, and cutting two steps usually beats another round of messaging.
In a saturated market, "the issue isn't attention, it's your pitch": if you need time to explain what makes you different, you have a feature list, not a position yet. For an on-device meeting transcription app, pick the one use case where on-device is undeniably better — privacy for legal/medical meetings that can never touch a cloud server — and sell only that; a one-sentence pitch beats a ten-minute demo . Similarly, buyers reward the product that's easiest to understand: if someone needs a ten-minute explanation before seeing value, it's a positioning problem more than a product problem .
Lead with the single most important feature where you're 2-5x better to hook the customer, then lead them sequentially through the experience — don't shotgun every reason why you're better .
Contrarian positioning: in a highly competitive space, pivot into something contrarian solved via first principles; the answer "sounds dumb at first" but emerges from working with customers. The "dumb at first" phase is where most quit — that's your moat, and the real money lives where the dumb idea becomes the obvious one .
Don't fight the "like X but worse at Y" framing: defending the incumbent's axis concedes that Y matters. Flip it — "yeah, we skip Y on purpose, here's what we do instead"; often nobody actually used Y, they just saw it on a comparison page . Position as the "rebel" option more honest about its flaws than bloated cloud giants — "people don't want perfect, they want something that actually works" .
Niche dominance: pick the niche where you're getting traction and double down (e.g., become "meeting transcription for auto dealerships"); don't go so narrow it's meaningless, but create a category and dominate it rather than competing in an existing one (citing Positioning: The Battle for Your Mind). In practice, the more specific the niche, the easier the sale and the less cost concern .
Validate PMF and ICP before scaling: "You're trying to scale before you've even sincerely validated your PMF and ICP. You need to burn more money nailing that down before you keep burning money on sales hours and marketing spin" .
Enterprise reality check for GTM: corporate software procurement spans 1-3 years including an initial request for funds; companies only seek vendors once budget is allocated, making unsolicited outreach to buyers without budget futile .
Buyer psychology: most buyers don't want "better" — "I don't need better, I need it to work" . The real challenge in breaking into a market: buyers need to trust your name, yet won't give you any time to establish it .
Building-in-public playbook on LinkedIn for an early product: 1) define your ideal customer profile and ideal follower profile; 2) post personal lessons, growth stories, and product updates; 3) engage with both profiles regularly; 4) outreach to potential leads offering a free trial — this builds the trust that drives conversion and generates leads .
The PRD has shifted from a permission document to a decision record. The old flow was slow — Idea → PRD → Design → Build → QA → Ship — because engineering time was considered the most valuable resource and building required buy-in. The new flow is fast: Idea → 5 prototypes → Evaluate → Kill 4 → PRD for the survivor → Ship; prototyping is now cheap because it's just an MCP connection to the code base, a configured design system, and a prompt away .
Modern PRDs contain what a prototype can't communicate: (1) opportunity framing, (2) scope and boundaries, (3) success measurement, (4) behavior contract, (5) rollout plan, (6) risk management. The prototype shows "what"; the PRD shows why, how to measure, and when to roll back .
Some teams have dropped the PRD entirely. Anthropic's Claude Code team writes zero PRDs, aligning through conversation and working software. Most teams won't go that lean — because they don't build for themselves, operate in regulated industries, or have many stakeholders to align — and that's fine, but everyone should embrace new ways of working . "PRDs aren't dead. They've just grown up."
In a thread on PM workload at large tech companies (e.g., Amazon, Google, Meta, Airbnb) , a commenter notes that zero-to-one work is much less common on established mature products, where PMs end up mostly working on optimizations .