We can't find the internet
Attempting to reconnect
Something went wrong!
Hang in there while we get back on track
Big Ideas
Generation is abundant; judgment is becoming the scarce product capability. Andrew Chen contrasts unlimited proofs, code, videos, and lawsuits with the limited people who can verify, review, watch, or adjudicate them; he argues that when creation becomes nearly free, the cost moves elsewhere. Shreyas Doshi labels that bottleneck “Taste.” Hiten Shah gives the quality risk a name—“AI slop debt”—and says it extends beyond code. The product implication is close to Scott Belsky’s prediction that the best software in many industries will be proprietary, built around a versatile data layer, specialized models, routers, and homegrown workflows and interfaces. PMs should therefore design the review standard and workflow/data advantage alongside the feature itself.
Organizational coherence is an AI capability. The Beautiful Mess argues that when strategy, structure, technology, and incentives line up, teams can infer context across maps and spend less energy reorienting; that benefit applies to humans and humans using AI. AI can surface and compare conflicting maps, but it cannot reconcile incompatible goals, incentives, or definitions—and may create the appearance of alignment instead. The practical test is to find the consequential gaps and bring them back into alignment, rather than adding another layer of documentation or orchestration.
Tactical Playbook
Govern agent work as artifacts, not conversations. A practitioner’s experience with coding agents is that the hard part is no longer coding or model access; it is preserving intent, specs, ownership, review, and knowledge across people and agents. Chats become a temporary layer. Use this operating sequence:
- Let chat explore and negotiate, but make the durable unit an artifact with an owner, version, and acceptance test.
- Have the agent investigate and report first; approve the plan; then permit one change at a time and inspect the diff before commit.
- Link the artifact to the code or files it governs and define the test that can invalidate it. When a later change crosses that boundary, mark the decision stale; let the agent retrieve the current decision, while old conversations remain supporting context.
Make AI-assisted feedback timely but auditable. A proposed alternative to shallow forms is a conversational prompt triggered by a dropped checkout, adoption event, or cancellation, followed by questions about the user’s intent and what went wrong. Treat that as a design hypothesis, not a license to interrupt: users may need a snooze control and may reject a lengthy exchange. For summaries, require timestamped transcript links, explicit “I don’t know” behavior, and manual review of early outputs before trusting aggregate claims. For consequential decisions, pair the summary with observation, direct calls, or recurring support evidence; one practitioner specifically rates skilled observation and repeated support tickets above feature suggestions, warning that AI can amplify bad input.
Case Studies & Lessons
Use the cheapest reversible surface to validate behavior. In a community example, a builder created an education-aid web POC with Supabase and a landing page, then deliberately held back further building while trying to get prospects to use it for free. The builder chose direct outreach because usage might reveal an entirely different product, and later chose to delay a native app because the web version was easier to iterate and deploy. The lesson is not “always build web”; it is to make the first product an instrument for learning and earn platform complexity with evidence of demand.
Career Corner
Build cross-functional capability instead of chasing a mythical AI-PM résumé. One founder says companies want forward-deployed AI PMs but describes the supposedly ideal CS–consulting–startup profile as mythical; the stated answer is intentional training. That fits the broader signal that everyone is becoming a part-time engineer and marketer while organizational boundaries thin. Build proof that you can frame problems, use technical tools, work with users, and move decisions through an organization—not just a PM title.
A separate community account describes automotive PM assignments lasting one vehicle cycle—roughly three to five years—after which managers returned to their prior disciplines, and predicts more rotation as PM, engineering, sales, and design blur. The author is treating the stint as a rotation after burnout, so this is an anecdotal career design option, not a universal prescription.
Matthew Dicks will teach a hands-on workshop on storytelling at the Lenny & Friends Summit . Dicks is a columnist, playwright, school teacher, 60-time Moth StorySLAM champion, 9-time GrandSLAM champion, and internationally bestselling author of nine books, including Storyworthy — which Lenny Rachitsky calls his all-time favorite book on the skill of storytelling . Karri Saarinen is also announced as a speaker at the Summit; the full lineup is at lennyssummit.com .
Career decision framework from a r/startups thread on leaving FAANG for a post-Series A fintech startup ($100M valuation, higher base, equity, "positive view" on work-life balance, acquisition planned): evaluate the move as a 3–5 year growth decision, not a comp or lifestyle play. If you're stalled at big tech — no promotion path, layoffs/contractor replacement expected — and the startup has product-market traction, strong leadership, and a clear path to Series B, it can be a better move than waiting for a promotion that may never come.
Expect worse work-life balance, not better: a Series A with a "positive view of work-life balance" is "likely an exercise in futility" — for WLB, join a large, already-successful company. Experience report: more 80-hour weeks than <45-hour weeks (~60 average), a claimed profitability that turned out to be a lie, and two near-fatal cash crunches; "profitability is a mirage at an early stage company."
Don't count post-Series A equity: joining too late makes it near-worthless, and further dilution will reduce its value — treat it as no bonus. In fintech specifically, valuations track AUM/transaction volume rather than SaaS multiples, causing headwinds at Series B/C/D raises; failure to raise leads to staff trims, heavier workloads, shutdown, or fire sale. Example: a fintech valued at $400M in 2019 peaked at $2B in 2022 and sold for ~$20M.
Total comp at big tech usually wins: higher salaries and liquid RSUs vs. illiquid startup equity ("RSUs are golden handcuff"). The upside of a startup is culture — "the best part about being at startups, but don't get drunk on it."
An r/ProductManagement post by vaultech0, "3 Unpopular PM Opinions", argued: (1) The PM's job is to make money — priorities, roadmap debates, and career growth get easier when work maps directly to revenue/profit, and building the thing celebrated at the board meeting/earnings call outweighs mediocre tickets ; (2) Industry knowledge matters more than PM skills — PM craft (PRDs, user interviews, data analysis) is learnable beyond basic competence, but deep customer and industry understanding (why they buy, conventions, regulations, competitors) is the real differentiator, so PMs should find and stick with one industry ; (3) Expectations for the median engineer are too low — engineers who know and care about the product deliver dramatically better output, should break down their own work, and should spend time on planning/design/research, reducing the need for product owners/scrum masters .
Commenters pushed back on #2: some said the worst PMs they worked with were hired for industry expertise but lacked PM fundamentals like scoping and engineering collaboration , and SME-turned-PMs often can't translate customer knowledge into business outcomes . Others argued experienced PMs from outside an industry bring fresh perspective and challenge norms, while same-industry PMs can over-rely on stale conventions ; a middle view held that industry knowledge and PM skills are both necessary but neither sufficient alone .
On #1, commenters widened "profit" to "business value": internal platform PMs (support AI, data engineering, observability) have no direct profit link but create tangible value such as freeing capacity, reducing risk, and avoiding costs . Another commenter argued strong PM skills transfer across industries (finance→ecommerce→publishing), and that prioritizing being "a star" over writing decent tickets fails the engineers who actually build .
The author later said the post was "100% meat generated" (AI-generated) .
PM as a temporary/rotation career — A former automotive engineer argues PM was never meant to be permanent: at his old OEM, PMs were assigned from the manager pool (mostly engineering managers) for each 3–5 year vehicle launch, then returned to their original roles; the company knew the role was too hard to sustain indefinitely, and low attrition plus 10+ year tenures made it feasible . He observes that junior/grad PMs aren't really doing PM work and should build core skills first, most PMs burn out and struggle to exit into other roles, PM identity hinders good decisions, and external PMs have trouble building rapport with eng/design; he expects PM rotation to become more popular as role boundaries blur , and is personally rotating back to engineering after burnout .
Career path debate — A commenter sees PM as a leadership track because it develops decision-making and stakeholder management skills . Another counters that most Fortune 100 CEOs come from operations, the next-biggest source is technical leadership (engineers who stayed on the eng-management path), and product produces few top leaders; any management role is a path to leadership .
Off-ramps — Some commenters say PMs can become surprisingly good engineering managers if given a shot, though one strongly disagrees, saying PMs make terrible EMs and lack engineering-management skills . A PM in his 40s at an automotive supplier, burned out, sees no viable off-ramp but likes the rotation idea .
AI shifting PM scope — In SaaS, the usual design/eng/PM trio is less needed; startups are replacing it with a few people covering all three . AI is also raising expectations: PMs are being asked to do everything except the core job of coming up with solutions and aligning people around them .
Practitioners debating in-product feedback surveys emphasize timing and context: asking in the moment captures what just went wrong, and the open-ended follow-up is where users explain the problem — "right place and right time" decides whether the survey works . Critics counter that most survey systems are mediocre because collecting/processing data is hard (Conway's Law) and direct conversations beat anonymous clicks — 100–1,000 customer meetings over 200,000 clicks — while replays/custom data plus interviews outperform forced surveys, which often trigger only after good experiences and can bias responses positive . One commenter recommends talking to 100–200 customers first to "true up" measurements before broad validation, noting Goodhart's/Campbell's laws apply if done right . Others call NPS and the Single Ease Question weak — "only exist to tell you if someone chose less than 7, 7, or more than 7" — and argue CSAT/NPS give product little insight compared with observed behavior; true feedback comes from SUS/SUMI surveys, observations, heat maps, and direct user contact . NPS is also described as antiquated . An operator of a feedback tool reports that after implementing such a survey, written feedback volume exceeded everything else, it became a regular pulse, and it repeatedly revealed wrongly held assumptions; right questions, UX, and timing are required for the spend to pay off .
@dvasishtha writes that every founder they know wants 'forward deployed AI PMs,' with the assumed best background being a CS undergrad who spent two years at McKinsey then two years in product/biz ops at a Series A startup — a 'mythical' profile; the reality is that teams must be intentional in training up this talent .
An r/prodmgmt post proposes proactive conversational feedback collection instead of passive forms: the system appears at a specific moment (dropped checkout, feature adoption, cancelled plan) and asks follow-up questions a PM would ask ('Why did you do that, what were you trying to do, how bad was it'). The poster asks whether this is just a nicer survey, whether a founder-named avatar builds trust or feels creepy, and notes they have already built the tool.
A commenter says this is established customer research and 'no decent PM should be making decisions based solely on written customer reviews.'
Another commenter, citing Google's similar proactive feedback, wants a snooze option when they're mid-task and does not want a lengthy back-and-forth.
Lenny Rachitsky (@lennysan) highlights that AI is making everyone a part-time engineer and marketer . He amplifies @emollick's finding from a Procter & Gamble study — which OpenAI reports too — that AI blurred the lines between jobs, thinning organizational boundaries and forcing companies to rethink how they divide labor .
PMs are debating how to handle customer feedback that appears AI-generated or AI-polished; one thread asks how to 'lose the AI-slop without losing the AI-sloppy customer' and whether to ignore, play along, joke, or confront it . Advice from commenters: skip written intake — talk directly with users in person (if travel is funded) or via web conference because you learn more ; skilled interviewers watching users are the best problem-identification source, support tickets reported by multiple users/orgs are a good source, feature suggestions are much less useful, and AI-managed feedback risks 'garbage in/garbage out' . One commenter notes junior IC PMs are often denied customer access or could face career risk reaching out without internal stakeholder diplomacy, raising the problem of starting such conversations without making the customer lose face . Suggested workaround: run AI-generated responses back through AI to extract key points while treating the original intent as real feedback , though a reply warns AI extraction can itself introduce bias or miss points, leading to an AI-checking-AI loop .
Shreyas Doshi highlights "Taste" as the scarce quality in response to Andrew Chen's observation that when creation of things like code, videos, or lawsuits becomes unlimited and near-free, cost moves elsewhere — to the limited people capable of verifying, judging, or paying attention (skilled mathematicians, programmers, judges, attention) . The implication is that judgment and curation, not creation, become the bottleneck and differentiator.
Andrew Chen observes that users now prefer asking an LLM for the exact right answer over clicking through multiple blue links filled with popups, ads, and flashing text, calling the spammy blue-links paradigm outdated — especially in travel, tech support, and movie reviews .
When what you are mapping is incoherent, don't fall in love with the map—use it to refactor what you see . In coherent organizations, strategy, structure, technology, and incentives align, so a team and its mission become reliable shorthand for goals, ownership, work, funding, and intended path to impact . In incoherent organizations, what you learn from one map stops being useful when you switch to another, requiring constant reorientation and translation . Coherence lowers the energy required to make sense of context—for humans and for AI . Insiders may navigate an incoherent org perfectly well, but that simply means navigation has become a specialized skill, not that the place is coherent . Organizations often build sophisticated documentation, cross-functional forums, and fixers to navigate incoherence, but these can lower the immediate pain enough that the underlying incoherence never gets addressed . AI can surface and compare the maps, but it cannot make conflicting structures, incentives, goals, and definitions line up; by smoothing over contradictions, it may exacerbate underlying tensions while producing the appearance of alignment . The goal is not perfect coherence but to notice where maps have stopped lining up, decide which gaps matter, and continually bring the most consequential ones back into alignment .
A PM building an AI tool that turns interview transcripts into insight reports asks what would make PMs trust an AI claim like "5 customers said X" enough to act on it — source links, confidence scores, or other mechanisms — noting that AI summarizers overstate confidence.
Verification approach from a commenter: have the AI link claims to timestamped transcript moments so reviewers can read the relevant passages, and treat LLMs like "fresh graduates" — give clear instructions, restate and add detail, verify their work, but don't do it for them.
Prompting tips for reliable AI summaries: use the Anthropic prompting guide to teach the model to source claims and say "don't know" when unsure; build a prompt, manually review a few outputs to build confidence, and optionally advance to an LLM-as-judge setup.
An inventor with working prototypes of a heavy-duty portable fire pit weighs three brand directions — tactical/overlanding ("BullPup"), sturdy-but-comforting ("Chonk"), and anti-establishment ("Iconoclast") — concerned that the tactical angle limits the audience while "Chonk" may lose the tactical community . Commenters recommend the broad "Chonk" positioning: tactical branding locks into an audience with existing brand loyalties and invites "knockoff" perceptions, whereas a cozy-but-sturdy angle allows content for both decks and truck beds and can still be shot in rugged/overlanding settings to keep credibility . A third view advises avoiding name preference polling alone: put each name behind product pages and test the promise with segmented audiences (overlanders vs. deck users), since purchase is likely driven by portability/cleanup proof, with the name reinforcing it .
Hiten Shah introduces the mental model that "AI slop debt is the new tech debt," warning that low-quality AI-generated output accumulates as a form of debt for teams; in reply he clarifies it "goes beyond code," i.e., applies to AI-generated content and artifacts broadly, not just software .
Founder of a SaaS side-business at $40K ARR (growing ~20% net-of-churn per year for the last 3 years, investing ~$25K/year in new features, estimated $1M ARR ceiling based on TAM/competition) asks for a framework to decide whether to shut down, sell, or keep running the product . Commenters advise: if profitable, sell rather than shut down ; at 20% annual growth, reaching $1M takes over a decade, so decide based on whether ~10 more years at current scale works for you ; and $40K ARR shows traction/PMF — assess net profit, TAM, and what's limiting growth, and consider investor funding for marketing to accelerate .
A startup founder validated demand for an education-aid app by building a web app POC with Supabase and a landing page, deliberately avoiding further building until demand is confirmed. They chose cold-calling potential users over The Mom Test, reasoning that The Mom Test suits larger-scale investments and people with existing access to users; mature startups they consulted advised "just get people using it" because usage feedback is the clearest validation signal. The same founder recommended validating with a web app before a native app, because web apps are easier to iterate and deploy changes to during the validation stage; they planned to build native only after market validation. Early-stage founders were warned that success odds for a social mobile app are "basically zero," urged not to obsess over idea protection, and told to come back with a concrete plan: deadlines, budgets, operating costs, business plan, expected user counts, and go-to-market strategy, instead of open-ended questions. Another commenter argued that in the AI era, a founder who cannot build a fully functioning proof of concept and get users is in the wrong business ("My mum can make an app"); the advice was to research, build it, see how it performs, and gather feedback, expecting the first app to be imperfect.
On r/startups, a first-time founder in India with a working AI agent authorization product asked about turning it into a company — whether to validate with design partners/pilots first, when to incorporate (India vs US), whether to raise before pilots/revenue, and what skills a co-founder should bring .
A responder advises: first have conversations with potential clients to validate the need, product fit, and pricing; incorporate only once you start getting traction so the first sale is made as a business . On co-founders, they caution that trust and equity splits are hard, and recommend a complementary partner with go-to-market or marketing skills if the founder is technical .
A r/startups discussion argues chat is a poor durable UI for AI-assisted software engineering: engineering is preserving intent, reviewing decisions, tracking work, sharing knowledge, and coordinating people/agents, so chats become a temporary layer and the bottleneck shifts to keeping intent/specs and knowing which agent did what . Commenters propose concrete patterns: make the durable unit an artifact with an owner, version, and acceptance test — chat creates or challenges the artifact, then disappears, so the next agent doesn't inherit a transcript and have to guess which sentence became the decision . One builder fixed it with process rules rather than tooling: discovery first where the agent only investigates and reports back, human approval, then one change at a time with the diff shown before anything commits — intent lives in the approval step, not the chat . Another pattern: the artifact should point to the code it governs and define what invalidates it (e.g., an auth decision names the service/files plus the test that proves the implementation still matches); when a later change touches that boundary, mark the decision stale until someone reviews it, letting the agent retrieve the current decision and show when the implementation has drifted, with old conversations as supporting context rather than source of truth . Projects need a source of truth that outlives the conversation once multiple people or agents are involved; otherwise discussions repeat and decisions lack context .
Scott Belsky shares five things builders must love:
- Love constructive feedback and having deep convictions doubted; obsess over criticism for what isn't working, but be wary of cynicism and gain confidence from doubt .
- Love vigorous team debate, which signals navigating new territory effectively; debate exposes the surface area of possibility for the best decision, keeps the team engaged, and fights apathy ruthlessly .
- Love merchandising — always selling or sharing the narrative of what you're building and why, especially with customers and when hiring/retaining a team; it's the most important thing and not taught in business school .
- Love building a team and culture as much as product; team potential compounds with commitment and alignment, culture should strengthen from volatility, and the real competitive advantage is a great team sticking together long enough to figure it out .
- Love time with customers/users; best products come from empathy for those suffering a problem, not passion for a solution — you need to be shoulder to shoulder identifying pain and testing solutions .