We can't find the internet
Attempting to reconnect
Something went wrong!
Hang in there while we get back on track
AI-First PMs Are Being Asked to Show Working Software—and Defend the Core
•
3 min read
•
364 docs
The period’s clearest signal is a split: AI is pushing PMs closer to working software and agent-mediated distribution, while behavioral validation, core-product discipline, and auditable product knowledge become more important—not less.
Big Ideas
Agent access is becoming a distribution battleground. Scott Belsky’s current framing is that owning the UI remains a moat “for now” even as the UI comes under attack. He describes a new negotiation over “favored agent” status and a “headless services war,” and speculates that restricting consumer-agent access may be part of the transition.
For consumer and service products, map not only the human user flow but also where an agent discovers, authorizes, and completes the job. Treat agent compatibility and access terms as product-strategy assumptions, not integration plumbing to solve after launch.
Tactical Playbook
Turn AI prototypes into behavioral tests, not prettier demos. Sachin Rekhi’s method is unusually concrete: make the prototype functional with real data, a database, login, and—where useful—LLM integrations; add PostHog analytics, session replays, and heatmaps; let customers drive it during 1:1 sessions; then send it to dozens of customers with an embedded survey and compare stated feedback with observed behavior.
Use the sequence as a discovery loop:
- Build the smallest realistic workflow.
- Instrument it before recruiting users.
- Observe customers attempting the job rather than presenting the concept.
- Define success criteria before the test and plan for false positives and false negatives, as Teresa Torres recommends.
Front-load decisions before AI-assisted development starts. One B2B practitioner recommends aligning with design and lead engineering first, labeling decisions by confidence, and asking the coding agent to expose gaps before the spec is finalized. The point is to prevent the agent from silently making product decisions while the team is already building.
Case Studies & Lessons
Snap and Discord: strengthen the core before chasing side quests. Lenny Rachitsky’s summary of Peter Ellis points to Snap’s response to its 2018 redesign: after DAU flattened, the team focused on performance for existing users—especially on Android—and then saw a multi-year growth renaissance. Discord likewise focused on becoming the best place for intentional multiplayer gaming with friends rather than chasing Midjourney’s moment.
The reusable tool is a Core Product Value: one memorable user promise paired with operating metrics. Snap’s promise—“the fastest way to share a moment with the people you care about”—was translated into load time, camera-open-to-share rate, and best-friends engagement; the phrase without metrics is a slogan, while metrics without it are only a dashboard. Use that pairing to test whether a growth initiative improves the product’s central behavior or merely adds activity around it.
Career Corner
“Full Stack PM” is a capability stack, not a replacement for product craft. Aakash Gupta’s model keeps designers and engineers in place but adds AI prototyping and small PRs to the PM toolkit, so the PM can bring working software rather than only a spec. He explicitly says the fundamentals remain: know users deeply, exercise taste about what to add, and direct the build/ship/measure loop toward strategy.
Build one small prototype end to end, but make the career evidence the judgment it enabled: what behavior changed your view, what you stopped, and why the product should ship.
Tools & Resources
Use a Raw → Wiki → Schema research stack. Aakash Gupta’s lightweight knowledge system preserves unedited transcripts, threads, and PDFs as the Raw layer; records conclusions once in a linked Wiki; and adds a Schema so the team can query its evidence instead of rereading it. Skipping the raw layer makes later conclusions unauditable.
For every discovery program, preserve the source material, link decisions to it, and only then structure recurring fields such as segment, problem, evidence, confidence, and outcome.
AI-First PMs Are Being Asked to Show Working Software—and Defend the Core
Lenny Rachitsky
AI-assisted execution can outpace product understanding: a quoted engineer at a large company reported that Claude Code was producing specs, code, tests, PRDs, tickets, ticket resolutions, and reports, while management pushed shipping volume because code output was not viewed as the bottleneck; they described 12–13-hour days spent “just to press enter,” with little reading, bug resolution, or independent thinking. For PMs, this is a caution to distinguish artifact throughput from product progress and preserve explicit time for human review, validation, and bug resolution—the engineer said AI use would be acceptable if people had time to inspect what the code was doing before shipping. Lenny’s response was: “Hug your engineer.”
Shreyas Doshi
Profile
- Set up the negotiation: During the offer process, identify who will advocate for your compensation internally—typically the hiring manager, or the recruiter when the hiring manager is inexperienced—and build an open, honest working relationship with that person. Doshi also says candidates whose current compensation is high relative to peers can disclose that at the appropriate stage rather than in the first recruiter call.
- Optimize one priority: Before negotiating, choose the single compensation factor that matters most—such as cash, equity, benefits, or flexibility—state it clearly, and focus the negotiation on that factor instead of trying to maximize every term. The priority should reflect the candidate’s current life stage; Doshi argues that this clarity makes the candidate appear more reasonable and gives the negotiation direction.
- Use leverage with integrity: Transparently share competing offers and indicate which ranks highest on the chosen factor, giving the internal advocate a specific basis to seek a better outcome. Negotiate firmly, but with kindness and honesty; never misrepresent facts or make the process unpleasant for the prospective employer.
Lenny Rachitsky
- Prioritize the core product over side quests when seeking growth. After Snap’s 2018 redesign caused DAU to flatten, refocusing on performance for existing users—especially on Android—helped spark a multi-year growth renaissance; Discord likewise focused on becoming the best place for intentional multiplayer gaming with friends rather than chasing Midjourney’s momentum, producing rapid growth.
- Define a “Core Product Value” as both a memorable user promise and the metrics that operationalize it. Snap’s promise—“the fastest way to share a moment with the people you care about”—mapped to load time, camera-open-to-share rate, and best-friends engagement; Discord paired its gaming-and-friends promise with L7 and Lness metrics. The phrase without metrics is only a slogan, while metrics without the phrase are only a dashboard.
- Design teams for speed through a shared ideology and an explicit map of decision ownership. Clear DRIs should be trusted to make founder-quality decisions, because broad coordination can make an organization move at the speed of its slowest node.
- For consumer products, optimize for daily active use: DAU/MAU is presented as a proxy for next-day retention, and improving the ratio can be more valuable than acquiring weak monthly actives.
- Strong PMs are expected to combine apparently opposing capabilities: confidence with humility, organizational discipline with comfort in ambiguity, and long-term vision with a bias for day-to-day action.
- Managers should invest disproportionate time and responsibility in their strongest performers, continuing to increase their ownership until their capacity limit, rather than focusing primarily on employees who appear to be struggling.
Hiten Shah
- Use “orientation” as a lightweight product/company decision loop: establish the current reality before debating actions by asking: Where are we? What is actually happening? What matters now? What changed? What did we learn? What should we do next? What can safely be ignored? Run the questions before important decisions, after launches, during planning, or when the team feels stuck; keep the questions stable while continually updating the answers.
- Ground prioritization in observed behavior, not summaries: combine metrics with customer workarounds, repeated sales objections, internal workarounds, and actual feature usage, reconstructing what happened until the company’s behavior matches its narrative. After identifying the constraint limiting the system, keep reassessing because solving one constraint can expose another and make an earlier framework obsolete.
- Make learning and updating explicit: count learning only when evidence changes the team’s model of the world; favor actions that both advance the product and test an assumption, such as a narrow launch or pricing change. Shah defines “update speed” as the gap between new evidence arriving and the company changing its mind, and recommends making it safe to surface mistakes early so teams do not hide evidence or defend outdated strategies.
Lenny Rachitsky
Lenny Rachitsky promotes a Peters Ellis conversation featuring two product heuristics: growth “almost always comes from the core” and great product taste includes knowing when to stop. The discussion also covers PM quality and team design.
Aakash Gupta
- Full Stack PM: In AI-first teams, the company still hires designers and engineers, while the PM adds AI prototyping and small PRs to the toolkit to bring working software—not only a spec—and become a stronger partner to engineering and design. The model does not replace core PM: it still depends on knowing users well, applying product taste, and directing the build/ship/measure loop toward strategic goals.
- Flywheel strategy: Amazon’s e-commerce example uses two reinforcing loops: lower costs → lower prices → more scale → lower costs, and greater selection → better customer experience → more traffic → more sellers → greater selection. The practical lesson is to sketch the main flywheel and concentrate effort on increasing its momentum rather than repeatedly launching initiatives that never reach breakthrough velocity.
- Trust-building framework: Build workplace trust bottom-up: avoid mistakes and maintain timely communication, including not sending AI-generated slop; then do excellent work in the areas visible to the target stakeholder; next, ask stakeholders about improvement, partnership direction, and core needs; finally, deliver work they cannot see themselves producing. The stated career outcomes are greater independence, impact, and larger roles.
- Product knowledge system: Preserve product research in order: Raw—unedited transcripts, threads, and PDFs; Wiki—conclusions written once and linked back to the raw material; Schema—structure that makes the knowledge queryable instead of requiring rereading. Keeping the raw layer enables later auditing; skipping it can leave conclusions unauditable when the underlying material is gone.
Teresa Torres
- Teresa Torres is organizing a 2026 Continuous Discovery Habits reading program with one section per month, reflection questions, practical exercises, teammate-shareable videos, and quarterly live discussions to help practitioners turn the concepts into working habits.
- The current methodology focus is testing the assumptions behind product ideas: design tests well, define success criteria before running them, and account for false positives and false negatives by applying mitigation strategies.
Hiten Shah
- Orientation framework: Maintain a current picture of reality so the team can decide what deserves attention as conditions change. Use seven questions: where are we, what is actually happening, what matters now, what changed, what did we learn, what should we do next, and what can safely be ignored.
- Implementation: First establish the current state using the measures that matter for the company—such as revenue, retention, runway, or product quality—and separate that state from the story built around it. Then validate the picture against customer workarounds, repeated sales objections, internal workarounds, and actual feature usage rather than relying only on dashboards or summarized requests. Identify the constraint currently limiting the system, but reassess after solving it because a new constraint may emerge.
- Keep strategy current: Ask what is true today that was not true six months ago—and what stopped being true—because market or capability changes can invalidate product assumptions and strategy. Treat learning as evidence that changes the team’s model of the world, and favor actions that both address a problem and test an assumption, such as a narrow launch or pricing change.
- Operating cadence: Run the questions before important decisions, after launches, during planning, or when the company feels stuck; keep the process lightweight and repeat it often. Improve “update speed,” defined as the gap between new evidence arriving and the company changing its mind, by making it safe to acknowledge misunderstood customers, ineffective features, or wrong positioning.
Lenny Rachitsky
TypeSafe’s Jev is described as a product for reliable decisions inside software rather than chat, with the discussion emphasizing that the right task and data can matter more than brute-force compute; it also examines how System One Models could affect coding agents and software.
Hiten Shah
- Orientation as a product decision framework: Maintain a useful, current picture of reality while it changes so the team knows what deserves attention. Use seven questions—where are we, what is actually happening, what matters now, what changed, what did we learn, what should we do next, and what can safely be ignored—before important decisions, after launches, during planning, or when the team feels stuck.
- Implementation: Establish the current state before debating strategy, separating measurements from the story built around them; then inspect customer workarounds, repeated sales objections, internal spreadsheets, and actual feature usage instead of relying only on dashboard summaries. Identify the constraint putting disproportionate pressure on the system, but reassess after solving it because the next constraint may emerge and yesterday’s framework can become inertia.
- Make learning and action reinforce each other: Count learning only when evidence changes the company’s model of the world, and favor actions that both advance the business and test an assumption—for example, a narrow launch or a pricing change. Improve “update speed,” the gap between new evidence and changing course, by making it safe to acknowledge incorrect assumptions, ineffective features, or faulty positioning early; blame causes teams to hide evidence and learn slowly.
Lenny Rachitsky
Peter Ellis’s concise definition of systems thinking is to ask “why” five times—a lightweight questioning framework for applying systems thinking to product problems.
Hiten Shah
- Orientation framework: Hiten Shah defines “orientation” as maintaining a useful, current picture of reality so a company can decide what deserves attention. The framework asks: Where are we? What is actually happening? What matters right now? What changed? What did we learn? What should we do next? What can safely be ignored?
- How to apply it: Start by agreeing on the current state using the measures that matter for the company’s moment, while separating facts from the story built around them. Then inspect the work behind the metrics—customer workarounds, repeated sales objections, internal spreadsheets, and features that are praised but unused—to reconstruct what is actually happening. Prioritize the constraint putting disproportionate pressure on the system, but reassess after solving it because conditions and the relevant constraint can change. Regularly ask what is true now that was not true six months ago, what stopped being true, and whether new evidence changed the team’s model of the world.
- Execution and operating cadence: Choose the next action from the current evidence and favor actions that both advance the product and generate learning; Shah gives a narrow launch and a pricing change as examples. Keep the questions lightweight enough to use before important decisions, after launches, during planning, or when the company feels stuck, and improve “update speed” by making it safe to admit that an assumption, feature, or positioning choice was wrong.
Lenny Rachitsky
Peter Ellis describes managing Nikita Bier as directing rather than conventionally managing: Bier has “a very special set of skills” suited to high-stakes problems, but may be poorly matched to routine tasks. The product-leadership lesson is to channel exceptional specialists toward their strongest work rather than assume they will perform uniformly across responsibilities.
Product Management
- Decision propagation failure: In the thread’s scenario, a decision changed after the team aligned, but Jira was not updated; two weeks later, someone worked from the obsolete requirement. The unresolved process questions are who owns propagating changes across Jira, PRDs, and designs, and where to preserve the rationale for later “why did we change this?” questions.
- Decision logs are not a substitute for collaboration: Commenters attributed stale requirements to poor meeting facilitation, multitasking and partial attention, weak accountability, and teams changing their minds—not simply to people forgetting decisions. They cautioned that a decision-log or backlog tool may address the surface problem without fixing collaboration and focus.
- Remote-work tactic: One commenter recommended increasing communication and facilitation effort for remote work by “maybe 30% or more”; another suggested aiming small and getting fast feedback so mistakes are cheap, easy, fast, and safe to fix.
Kevin Weil 🇺🇸
OpenAI is working with an independent advisory group of mathematicians to guide the responsible sharing of AI and mathematical advances. The group will advise on evaluating and communicating results, maintaining academic and professional standards, and building tools for mathematical research and learning—an example of incorporating domain experts into AI product governance.
Product Management
- Use a T-shaped, context-driven learning model. Maintain broad working knowledge across product, data, technology, business, and communication, with deeper expertise in one or more valuable areas; PMs need enough familiarity to understand trade-offs and ask productive questions, not mastery of every function. When a gap blocks current work, learn the minimum needed to make progress and deepen when the product requires it, using specialists for expert depth. Smaller companies generally require broader individual scope, while larger companies place more value on knowing where to find answers and bringing the right experts together.
- Prioritize four durable craft capabilities. Data literacy means interpreting numbers and distinguishing correlation from causation; metrics should measure what matters rather than simply produce activity measures. Business fundamentals include navigating company politics and influencing without authority, while stakeholder communication requires tailoring messages to internal and external audiences and explaining delays without exposing irrelevant internal detail.
- Clarify technical-PM scope before accepting a role. Technical PM jobs can range from developer experience, APIs, search, personalization, and analytics systems to infrastructure-layer work, and some roles are mislabeled or combine business, UX, and deep technical expectations. In a technical PM role, the PM should define requirements, assess risk and viability, and understand implementation trade-offs without directing developers on how to code.
- Build capability through situated practice and mentorship. Product management is difficult to learn from books alone; observing experienced PMs, pursuing internships, and working with mentors provide practical exposure. Cross-functional mentoring, including with engineering leadership, can improve understanding of technical work and how to communicate with engineers versus senior leaders. In interviews, be candid about areas not yet owned and explain how you would approach learning them.
Product Management
- The poster reports moving from a marketing coordinator role into an associate PM position after two years of self-directed product work, then using a 12-week Google PM interview plan: 30% product sense, 25% analytics, 20% strategy, 15% behavioral, and 10% estimation.
- The product-sense practice loop was: choose and justify a user segment, map its pain points, prioritize one, propose solutions, define success metrics, and state trade-offs. Analytical preparation covered metric trees—goal, supporting, and counter-metrics—and diagnosis drills for metric declines. Strategy preparation used market context and sizing, competitive landscape, company right-to-win, options, a recommendation, and explicit risks.
- For behavioral interviews, the poster prepared five stories covering shipping against engineering objections, resolving cross-team conflict, killing a feature based on data, handling ambiguity, and influencing a skeptical stakeholder; they also ran mock interviews every other week.
- The reported hiring process was recruiter screen, virtual onsite, committee review, and team match, taking eight weeks from start to offer.
Product Management
- Calibrate spec depth to feature risk and audience. A tight spec covering the user story, edge cases, and acceptance criteria can make implementation more predictable, but may be excessive for small features; skipping detail can create rework when gaps emerge, particularly with AI coding tools. One practitioner adjusts documentation based on whether the work is customer-facing and its assessed potential for translation issues.
- Front-load decisions for AI-assisted development. One B2B practitioner recommends aligning with the designer and lead engineer before writing the spec, providing as much detail as possible, labeling sections by high/medium/low confidence, and asking the AI agent to identify gaps before the final spec is written; the goal is to prevent the agent from silently filling in missing product decisions while development is already underway.
- Treat documentation as a shared team artifact. Another response recommends building artifacts with designers and developers and agreeing on the required documentation level, while a separate reply suggests keeping the spec tight, using AI to surface details, and sharing the outputs with engineering.
Product Management - The place for all things product
- Decision drift can create direct execution risk: the post describes a team changing an agreed decision without updating Jira, after which someone built the outdated version two weeks later; the unresolved process question is how changes should propagate across Jira, PRDs, designs, and later rationale retrieval.
- A discussion participant recommends that PMs update tickets when requirements change and surface the change during grooming, sprint planning, and daily scrum, treating omissions across those checkpoints as broken execution.
- Use decision logs selectively for major feature or architectural changes—especially when stakeholders are affected—while keeping routine governance lightweight; commenters argue that the backlog can itself function as the decision record and that added process should justify its noise and overhead.
Product Management
- The thread identifies a process mismatch: PM discovery and requirements work involve unknowns, dependencies, and organizational red tape, but are being judged by two-week sprint rollover expectations more suited to scoped development work.
-
A proposed operating model is to separate discovery from delivery, define explicit
readycriteria for requirements and dependencies, and allow work into a development sprint only after it meets those criteria; frame escalation around the gap between readiness and the requested commitment. - An alternative is to track PM work in sprint planning when useful, but break broad activities such as “gather requirements” into small, estimable outcomes such as scheduling stakeholder interviews, holding requirements meetings, or unblocking a dependency.
- One perspective recommends preparing requirements at least a quarter before development and managing PM work against broader deadlines and timelines, while another suggests PM work should shape engineering direction one to two months ahead rather than target the immediately following sprint.