We can't find the internet
Attempting to reconnect
Something went wrong!
Hang in there while we get back on track
The Summit's verdict: no playbook, but judgment wins
Lenny Rachitsky posted a recap of the Lenny & Friends Summit. Speakers took both sides on software factories, roadmaps, and whether PMs should ship to production. The one point of agreement was that there's no single right way. Ami Vora of Anthropic said "We don't know the answer. We don't think anyone knows the answer" . A second theme was that it has "never been easier to build something nobody wants." Robby Stein of Google Search said PM value now comes from "judging… taste," and Karri Saarinen of Linear put it as "The output is not the product" . Speakers also described the PM role as growing, not collapsing into a generic "builder." Ramp's Geoff Charles predicted that PMs "will become GMs" who own business outcomes .
The talks themselves give specific practices:
- Anthropic: the PM role still matters. Mike Krieger thought Claude could cover the work on a project close to launch. Once a PM joined, they handled the tasks that were about to be dropped: preparing customer success, looping in safeguards, and keeping enterprise users in mind. His view is that faster building makes this role "increasingly important" and requires more operational excellence than before .
- Park ideas the models can't handle yet, and keep an eval. Anthropic's first computer-use product in 2024 was "so bad." The team parked it and re-ran it in an eval harness with each new model until results jumped. Krieger counts turning a failed project into an eval as a win .
- OpenAI: plan 2–3 months ahead. Tara Sesha's launch bar is whether a product adds user value, retains internal users, and targets where the models will be in 2–3 months . She says predictions years out are "almost always wrong." A panelist added that slower markets like payments can still support annual plans . Nan Yu (OpenAI) named the other limit: "people's ability to absorb what you're giving them" .
- Linear: automate without losing what the work teaches. Saarinen warns that automating work separates teams from what they learn by doing it. Linear uses an agent to investigate bugs and draft fixes, which engineers verify. The time saved goes to customer contact . He also has an agent send him a daily briefing on what customers say about their AI workflows . To keep quality standards shared, everyone finds and fixes one defect every week ("Quality Wednesday"). Optional "feature roasts" collect blunt critique, on the view that if colleagues are confused, users probably will be too .
Writing is thinking: the case against AI-drafted docs
Aakash Gupta highlights Clay's new AI writing policy and predicts other companies will follow. His argument: PRDs were how PMs committed to a hypothesis and checked edge cases, so outsourcing the writing outsources the thinking . If you use AI, label it ("I used Claude for this. wdyt?"). Disguised AI writing is the worst case. Teams should put collective productivity ahead of individual speed . Shreyas Doshi agrees: if you have real clarity on a topic, writing a strategy doc yourself "takes way less time" and reads more clearly .
AI PM interviews are changing
Gupta lists recent changes in AI PM interviews:
- Timed prototype rounds, where you build in 45 minutes in Cursor, Bolt, or Lovable. He names Google India, Figma, Perplexity, Netflix, and Stripe.
- Google dropped its standalone technical interview. OpenAI made AI product sense a required round.
- Behavioral questions now probe technical trade-offs, such as model accuracy versus serving latency.
- Safety is tested: Anthropic has a dedicated round, and OpenAI works it into every round .
Getting promoted
In a new video, Shreyas Doshi says recognition depends on four things: scope, outcomes, outputs, and visibility. Companies weight them differently. He advises against joining companies that reward only visibility . To avoid surprises from a promotion committee, draft a plan covering those four areas and refine it with your manager ahead of the cycle. The same approach works if you're aiming for a higher rating rather than a promotion .
Practitioner threads
- Shipping cadence vs. announcement cadence. One B2B PM says fixes now ship as soon as they're ready, but customer release notes stay monthly. How often you ship and how often you tell customers are separate decisions. Admins filter out weekly bug notes, but they do want a direct message when a bug they reported is fixed . Another PM says the team now builds faster than customers can absorb updates, which means more release management and enablement work .
- Naming an in-product AI chat. One commenter argues that "Intelligence" promises judgment and raises expectations, while "Chat" or "Assistant" promises less and holds up better. The real risk is the first wrong figure, so show the source rows behind each answer .
- Switching AI providers. Changing the API is the easy part. What breaks is subtle behavior: a tool call skipped in edge cases, or valid JSON in an order a downstream step doesn't expect. One team mirrored real traffic to the new provider for two weeks and compared outputs daily before switching .
- Innovation isn't the goal. Teresa Torres and Petra Wille argue that chasing novelty leads to complex solutions. Simplifying and removing steps count as innovation too, and every new pattern costs users effort to learn .
- For fast-moving AI products, favor an imperfect but workflow-safe launch that produces real user evidence over prolonged theorizing; the example was a toggle used to put an agentic harness in front of ChatGPT’s billion-plus users without disrupting developer workflows. When evolving or replacing early solutions, give users a coherent story and transparency so they can follow the change.
- Set a product bar around added user value, internal uptake and retention, delight or novel use cases, and whether the product fits model capabilities roughly two to three months ahead.
- For agent products, many separate agents can overwhelm users, so group them into manageable bundles; choose a unified or specialized agent design based on the use case and practical requirements such as permissions, memory boundaries, and whose credentials the agent uses.
- Pair user empathy and systems thinking with relentless iteration. When working with research, bring specific user goals, use cases, and sample sessions; write evals to establish a feedback loop and demonstrate desired behavior for possible post-training.
- In a rapidly changing AI market, plan roughly two to three months ahead rather than relying on years-out forecasts; set the planning cadence to the market, since more stable markets may support longer-range plans.
- As model capabilities outpace users’ ability to absorb them, onboarding matters more. For semi-autonomous products, make privacy and data use understandable and behavior predictable; direct user relationships and follow-up questions can reveal context behind subtle failures.
- Structure platform capabilities in layers: expose hooks for integrations and provide computer use as a fallback when other tools are unavailable. Judge the experience by whether it completes the task; a near-complete failure can feel worse than a clear non-starter.
- Recognition reflects scope, outcomes, outputs, and visibility, but companies weight these factors differently; learn what your organization actually rewards rather than assuming one universal model.
- For an internal move, weigh both the initiative’s importance and the manager. Career inflection points more commonly come from changing function or company, or taking on new responsibility, than from a new manager.
- For experienced, high-performing PMs, evaluate whether a prospective manager makes it easier to get work done, can take on work you delegate upward, recognizes your performance, has organizational credibility, and will advocate for you; manager choice matters especially in an internal transfer, where the company stays fixed.
- To reduce promotion or rating surprises, draft a working-backwards plan with your manager for the next performance cycle, covering scope, shipped outputs, outcomes, and visibility; surface gaps before a promotion committee meets. The same approach can support a higher performance rating, not just a promotion.
- AI speed does not remove the need for PMs: as one project neared launch, adding a PM surfaced connective work that otherwise risked being dropped, including keeping end-user needs in view, coordinating customer-success readiness and safeguards, and keeping people aligned. Faster execution makes operational excellence in this role more important.
- Keep solving human problems while continually relearning what the technology can do; as building gets faster, replace some upfront debate over interaction details with making and testing multiple versions. Adaptability, judgment under ambiguity, and persistence are increasingly important.
- For agent-native products, build shared primitives and plumbing that let agents perform tasks users can perform, rather than treating AI only as a disconnected add-on. Those foundations can support gradual evolution from a sidebar toward interfaces that adapt to a project or user; retrofitting older applications can be difficult.
- When product direction is uncertain, explore parallel bets where teams have real conviction, support them with shared foundations, and use user value and repeat use to identify what is working; then consolidate experiments into a coherent experience rather than overloading users with choices. If an idea depends on model capabilities that are not ready, park it and keep an evaluation to revisit as models improve; an early failure is not proof that the capability will remain out of reach.
Behavior-change insight: Nir Eyal argues that knowing what action to take and what benefit it brings is not enough to sustain motivation; people also need belief, including belief in their ability to act. For PMs building behavior-change products, this suggests addressing users’ confidence alongside instructions and value. Eyal describes how trying an action with a more enabling belief and seeing a perceptible result can provide evidence to continue the behavior.
- Don’t optimize product teams solely for output: automate repeatable work that teaches little—such as AI-assisted bug investigation and draft fixes for engineers to verify—while preserving execution-to-learning loops. Use the time saved for customer contact, exploration, and better-quality work.
- Keep customer and product context available to both people and agents: collect feedback from sales calls, meetings, support emails, and internal discussions, then use an agent to surface salient themes in a brief daily update; the example tracks customers’ AI workflows.
- Use recurring peer critique to build shared product judgment: “Quality Wednesday” asks everyone to find and fix one defect each week, however small, and share findings; optional feature roasts invite raw feedback from across the company, which the feature lead turns into actionable issues. Treat internal confusion as a possible signal that users will also be confused.
When you have clarity on a topic grounded in authentic experience and understanding, writing a strategy document, important email, or blog post yourself can take less time than having AI write it—and may produce clearer writing for the reader.
- Lenny’s Summit takeaways: there is no settled, universal playbook for AI-era product work—choices such as building software factories, maintaining roadmaps, or having PMs ship to production depend on the product and its stage; speakers said the best practices are still being written.
- As building gets easier, product teams need stronger judgment about what to build and what “good” looks like: prioritize solving customer problems and useful, well-executed details over novelty or code output alone.
- The PM role is expanding rather than simply disappearing into a generalist builder role: one speaker forecast PMs taking broader responsibility across marketing, sales, growth, and operations, with ownership of business outcomes; a Lovable example described one PM doing pricing-page changes, prototyping, production deployment, research, analysis, and optimization.
- Use AI to raise ambition, not only speed up existing work: one proposed measure is running experiments in weeks that previously took a year, while accounting for people’s ability to absorb what teams create.
An in-depth video titled “How to Get Promoted” was published, with a YouTube link.
- As building gets easier, teams risk shipping products nobody wants; PM value shifts toward choosing the right problem, exercising judgment and taste, and delivering quality. Customers value solutions to their problems and thoughtful details—not code output or novelty alone.
- AI should raise ambition, not just accelerate existing work: Summit speakers said teams could run experiments in weeks that previously took a year, while users’ ability to absorb what teams build can be a constraint.
- PM roles are expanding rather than disappearing: responsibilities may extend into marketing, sales, growth, and operations, with PMs owning business outcomes; overlapping roles also enable people to do more, including prototyping, user research, analysis, and production deployment.
- There is no settled best practice for questions such as software factories, roadmaps, or PMs shipping to production; the right approach depends on the product and its stage, and teams are still discovering what works.
A reviewer who has taken both of Shreyas Doshi’s courses says they offer clarity on becoming a better product leader and recommends either to founders; the reviewer describes Advanced Product Taste as the shorter entry point and says they revisit the recordings regularly.
- The essay’s career-management model is that strengths such as curiosity, helpfulness, and questioning can become traps; identify and rehearse a personal “saveable moment” before the situation escalates.
- Volunteering for an orphaned problem without clear ownership or backing can make you the figurehead for work others cannot explain. A warning sign is that you see and care about the problem, but nobody else is willing to own or support it.
- In workplace discussions, expressing uncertainty or showing unfinished reasoning can be mistaken for perfectionism or lack of conviction. Notice when people critique how you ask rather than answer the question, or react more to the shape of your thinking than its substance. Raising a weak signal repeatedly after people have heard it and taken no action is another point to pause rather than keep pushing.
- The discussion argues that consumer agents should target painful life-admin and cost savings rather than marginal efficiency gains: examples include filing HSA reimbursements, claiming airline credits when fares drop, and weather-linked sprinklers reportedly cutting a user's water bill by 50%. One user also reports ChatGPT Voice categorizing and replying to email and sending calendar invites during a 30-minute bike commute.
- Treat autonomy as a consequence-based permission boundary: the guest contrasts actions like drafting an email or obtaining a flight credit with consequential changes such as switching insurance, which should require user permission; crossing that line once may destroy trust.
- The speakers suggest that configurable personality is a weak moat; proactive execution and specialized agents grounded in distinctive taste or proprietary knowledge may differentiate products more effectively.
- Assistant Benchmark evaluates assistants with identical consumer-use-case prompts, comparing actual outcomes, follow-up behavior, and performance across 16 dimensions to help users choose an assistant—not to measure technical internals.
- Teresa Torres and Petra Wille argue product teams should optimize for solving customer problems, not novelty for its own sake: chasing novelty can produce complex solutions, while simplification and reduction can themselves be innovative.
- Novel solutions impose a cognitive cost because users must learn them; valuable innovation can emerge from cross-functional discovery when a newly feasible approach addresses a real customer struggle, even if the solution feels ordinary to users.
- For frontier PM roles with no established job profile, stay flexible about candidate backgrounds and build the role template during the search; assess potential to solve analogous problems rather than requiring proof of having solved the exact one. The author’s early Twitter platform-PM example combined distributed-systems knowledge, startup-style action, and cross-functional diplomacy.
- When competing with stronger brands or compensation, differentiate the role and candidate segment rather than competing on the same terms. At Twitter, the author found that AWS PMs valued product-line ownership, cutting-edge technology, and commercialization—advantages that made Twitter’s legacy-system work harder to pitch.
- Use a “talent magnet” as a domino hire: verify their claimed ability to attract colleagues through named candidates and references, test whether they can diagnose hiring-pipeline bottlenecks, and explicitly make pipeline-building, interviewing, and closing part of the role.
- As AI makes building easier, PM advantage shifts toward choosing the right problem and applying judgment and taste: distinguish useful from merely new, solve customer problems, and sweat details; output or code alone is not the product.
- PM roles are expanding, not disappearing: they can extend across prototyping, shipping, research, analysis, optimization, and commercial functions, with greater ownership of business outcomes.
- There is no universal product-building playbook: whether to use software factories, change roadmaps, or have PMs ship to production depends on the product and its stage.
- AI can enable more ambitious experiments—work that once took a year may be testable in weeks—but teams should also account for users’ ability to absorb what they deliver.
Andrew Chen argues that open-weight AI products should favor customer-controlled guardrails over black-box rules, highlighting configurability as a product principle . The quoted vendor says customers from startups to Fortune 500 companies found centralized guardrails prevented them from doing their jobs, and presents user-defined guardrails as its alternative .
AI workflows can produce uneven results even when employees use the same models, because the useful context, examples, corrections, and quality bar are scattered—and may leave with the employee. Saving prompts alone does not transfer the full way of working. A product-management opportunity is to make recurring corrections, context, methods, and quality checks reusable so others can build on what colleagues have learned; the author says how much of this can be made reusable is still an open question.
As a feature moves from customer need and business goal through requirements, specifications, acceptance criteria, engineering stories, QA, and delivery, context can erode—leading to requirement drift, vague stories, missing edge cases, conflicting assumptions, and process overhead. One proposed multi-agent PM workflow uses stateful orchestration to carry an idea through a validated brief, specification, and delivery-ready stories, with traceability and governance; its design separates structural validation from product judgment review and tracks workflow state through snapshots, staleness detection, reconciliation, and reverse derivation. The author’s central takeaway is that AI generation is less challenging than preserving alignment and intent as requirements evolve across teams, artifacts, and delivery phases.
- A PM handling four clients reported exhaustion and difficulty keeping track of each client's context amid constant switching .
- One recommended approach is a dashboard for each client covering priorities, blockers, risks, decisions, and next steps, plus a decision log, batched meetings/messages, and protected focus time .
- An AI-assisted approach is to keep standardized Markdown files for strategy, architecture, personas, and OKRs and reuse them in Claude Code spec and ticket skills; one commenter said this worked across three different products and businesses . Separately, a PM described auto-transcribing meetings to SharePoint and using Claude with those transcripts and records in Confluence, Jira, and Slack; they estimated transcripts provide 80% or more of Claude's context, with details available for retrieval when needed .
- A team building a chatbot for querying its platform data was considering calling it “[company] Intelligence” instead of “AI chatbot,” hoping to avoid AI-brand fatigue and distrust and set lower expectations.
- Naming can shape both discoverability and trust: one commenter said users mistook a sidebar labeled “Chat” for an internal chat tool, while another cautioned that business-software users may treat answers as authoritative, making incorrect figures damaging; showing the source rows behind answers was suggested as a verification aid. The latter commenter also argued that “Intelligence” may raise expectations by implying judgment, rather than lowering them.
Context is now the product: Product leadership when software can build itself | Karri Saarinen
- Don’t optimize product teams solely for output: automate repeatable work that teaches little—such as AI-assisted bug investigation and draft fixes for engineers to verify—while preserving execution-to-learning loops. Use the time saved for customer contact, exploration, and better-quality work.
- Keep customer and product context available to both people and agents: collect feedback from sales calls, meetings, support emails, and internal discussions, then use an agent to surface salient themes in a brief daily update; the example tracks customers’ AI workflows.
- Use recurring peer critique to build shared product judgment: “Quality Wednesday” asks everyone to find and fix one defect each week, however small, and share findings; optional feature roasts invite raw feedback from across the company, which the feature lead turns into actionable issues. Treat internal confusion as a possible signal that users will also be confused.