We can't find the internet
Attempting to reconnect
Something went wrong!
Hang in there while we get back on track
AI made building cheap, so deciding what to build is now the bottleneck
•
3 min read
•
219 docs
Practitioners and product leaders agree that AI coding speeds up individual work but doesn't speed up shipping on its own. The constraint has moved to decisions, alignment, QA and context. Also: what model-PM job postings ask for, and how teams are using AI in discovery.
Faster coding isn't faster shipping
A PM on an 8-person transportation team said Claude Code and Copilot made everyone faster individually, but "our overall delivery speed hasn't really changed." QA is backing up, and people still go back and forth over missing context and unclear requirements . Other PMs reported mixed results. One org of about 1,000 people says it ships roughly 2x what it did two years ago with flat headcount . Another PM said bug fixes are much faster, but the slowest steps are still alignment and stakeholder meetings: "AI isn't making it any faster to convince a team we should do something" .
Product leaders made the same point. Miro's CPTO said he has talked to over 200 customers in the past year. Most have "solved the execution," but it feels like chaos, and "building the right thing is the new bottleneck" . His prescription: PMs should make decisions faster and more often, take bigger bets, and spend the time they used to put into stakeholder artifacts on asking whether they're aiming high enough . Marty Cagan agrees that deciding what to build is the PM's job, and that it matters more as build costs fall. He separates "build to learn" (discovery prototypes) from "build to earn" (production-grade delivery) .
YouTube's Sunday Ticket launch is a pre-AI example of the same constraint. The team started with 129 P0 features but didn't own 80% of the engineering needed, so it had to win alignment and be strict about what truly blocked launch. Installment billing turned out to be a state-by-state regulatory problem. The team launched with pay-in-four only and later added 8- and 12-part plans and month-to-month plans .
PMs as builders, unevenly
Webflow moved from designers prototyping in code to "builder days" for PMs and EPD ops. Product staff then shipped real PRs to production, and that is now a weekly Wednesday habit . Lovable's growth lead says everyone there pushes changes to production, with AI-written code reviewed by humans. She argues that easy recovery from mistakes means less time spent debating the "right" decision . She spends 70% of her time talking to agents. She moved back to IC work but kept her seat on the exec team, her pay, and ownership of Lovable's monetization model . Not every company agrees. A PM at a large bank who used Copilot to ship code, build data pipelines and spin up services is losing access because they're not in the engineering org. Management said "hard no" .
AI in discovery: summarize, don't simulate
In r/ProductManagement, practitioners were skeptical of simulated personas. Prompts like "would a senior IT buyer buy this?" give "random results." One PM said it works better to have AI summarize raw data . Another found that letting AI take interview notes cost them the ability to synthesize across conversations. They now take notes themselves and use AI to pull quotes and challenge their bias . Gamma did discovery at scale for users whose usage had faded. It rebuilt the product over one summer , then had over 30 of its 120 employees join calls with more than 100 users. The calls showed that users share more by voice, so Gamma added a microphone button .
Also notable
- Model-PM hiring. Aakash Gupta read 46 open model-PM postings. The most common ask (76%) was "going from pixels to evals to hill climbing." Only 7 required production experience, and the median posted base salary is $345K. His advice is to turn a model's failure modes into evals and build a product that passes them .
- Defensibility tests. Hiten Shah suggests asking a coding agent to rebuild one of your valuable workflows, then trying to do the customer's job with an outside agent and the services they already have . For agent products, he says the metric that matters is cost per verified result, including human review and recovery .
AI made building cheap, so deciding what to build is now the bottleneck
Product School
- Product management should operate in “founder mode”: an owner mindset crosses functional boundaries to fix business problems instead of staying in swim lanes. Product managers should consider sales, marketing, engineering, pricing, packaging, finance, and accounting when building.
- Cisco describes moving from a holding-company model toward a platform company: it focuses managers on building features for the platform, rather than standalone products, because the platform is what it sells. New products should leverage established routes to market; pursuing routes the company cannot effectively reach can put it at a disadvantage.
- If consumers delegate shopping to agents, retailers could lose some direct customer relationship and influence over upselling and cross-selling. Product managers should use AI to strengthen their thinking—not delegate it blindly—and apply judgment about what not to build.
- Cisco says it launched agents and a personal concierge for every brand at its Webex event, with the aim of giving every customer access to concierge support, sales, and consulting—not just a small set of top accounts.
- Cisco’s stated M&A posture is build-first: define what to build in an important market, and acquire when a company can accelerate that clearly defined vision.
Hiten Shah
- Start product discovery with the recurring customer job: map what triggers product use, where judgment is needed, and who notices and fixes failures. Define automation as a bounded responsibility with clear evidence of success, and expand autonomy only as it proves accurate; authorized access is also part of the product boundary.
- Evaluate agent quality by cost per verified result, including human review and recovery—not just speed or cost per attempt. Track what work customers still have to do, and improve checks, verify source records, or hand off when the system cannot safely proceed.
- Test defensibility by asking a coding agent to reproduce a valuable workflow and an outside agent to complete the customer’s job using existing services. A product centered on a few reproducible screens is more exposed than one providing trusted records, transactions, or reliable end-to-end work; agent use can also reduce interface time while increasing use of underlying services. Align pricing with delivered value and cost, such as seats, transactions, or completed results.
Marty Cagan
Profile
- Marty Cagan distinguishes a feature-factory/project model, where teams execute preselected roadmap solutions, from empowered product teams given a problem and outcome to solve through discovery and delivery. A solution must be valuable, usable, feasible, and viable; product managers are responsible for customer value and business viability, designers for usability, and engineers for feasibility, while all contribute to the solution .
- As AI lowers the cost of building, deciding what to build—the product manager’s role—becomes more important; speeding up the project model can instead produce failed products faster. Use discovery prototypes to learn whether a solution is worth building, then shift to production-quality delivery .
- Engineers should engage with discovery rather than only productionize prototypes: Cagan recommends about half an hour a day with customers or the latest prototypes, so engineers can understand the proposal, assess feasibility, and suggest better approaches before sprint planning .
- AI tools can let smaller teams own broader scope and reduce coordination dependencies. Empowerment means being able to find the best solution; autonomy means being able to build it without relying on other teams, though platform and infrastructure dependencies remain .
- For engineers in project-oriented organizations, Cagan suggests asking to visit customers and access usage data, speaking with sales if there is no substantive product manager, and prototyping an idea to show users or leaders; teams can also propose a short trial of this way of working .
Elena Verna
Profile
- Lovable’s growth leader describes AI-native high-impact ICs as end-to-end owners: they identify problems, make decisions, execute across functions, ship to production, and own outcomes. AI can give an individual capabilities across product, design, engineering, and marketing, challenging the assumption that more direct reports necessarily mean more impact.
- At Lovable, she says most code is written by AI but reviewed by humans, with people across the company contributing technical changes. As building gets cheaper and mistakes are quicker to recover from, she argues product organizations should favor shipping and learning over extended debate, approvals, and coordination.
- She frames high-impact IC work as an organizational operating model, not a title: distribute company context, pair authority with accountability, and allow cross-functional ownership. She also argues that pay and status should not require moving into management, and cautions against combining management and IC work as a default.
Product School
- Set AI-era strategy by pairing customer-domain veterans with people tracking new model capabilities, then use product and customer signals to judge what customers will value . As tools automate peripheral data-gathering and coordination, PMs’ value shifts toward domain expertise, business understanding, judgment, and product taste; ground customer understanding in unified, quantified evidence rather than anecdotes .
- As shipping gets easier, give smaller teams explicit product-area ownership, metrics, shared context, and rituals . Shared goals and a north star matter more than dashboards or specs alone; cross-functional sprint reviews can bring in stakeholders such as customer support, executives, and pricing to make decisions as plans change .
- Guidance on PMs shipping code differed: one team has PMs prototype and hand work to engineers because PM decision-making is its bottleneck, while another stresses engineering trust and case-by-case decisions about which code PMs should touch . Distinguish build-to-learn experiments from build-to-scale production, where review, maintainability, and accountability matter .
- Make post-launch analysis a core PM capability: use qualitative and quantitative data and establish a clear way to measure each feature . Customer feedback and observed behavior can continuously improve evals, but invest selectively in rigorous evaluations because they are costly and may need reworking as models change .
- Design AI products from the intended interface backward rather than letting technology dictate the experience; avoid chasing every new model or over-optimizing for current-model limitations that may soon become stale .
The Product Compass
- Claude Desktop’s Code tab presents Claude Code through a user-friendly interface; the author recommends it for PMs prototyping, building agents, and automating work instead of using VS Code. Access to the Code tab requires a paid Pro, Max, Team, or Enterprise subscription.
- Cowork is less suited to project work: it cannot run or preview apps, create project-specific skills or MCP connections, define guardrails, or use the AGENTS.md standard. The author also reports that its 10GB virtual-machine limit quickly became restrictive in practice.
- Suggested PM workflows include comparing competitors’ pricing, positioning, and changes over the past three months, and grouping and counting Jira, Linear, or GitHub tickets to surface the five problems most aligned with product strategy. The built-in browser can run an app, let Claude check its changes, and accept visual feedback through annotations or component selection.
Product School
- Elena Vera, Lovable’s growth lead, argues that AI-native organizations can decouple impact from team size: AI-enabled ICs can produce impact previously associated with teams, so direct-report count should no longer be the career currency. Her “high-impact IC” model assigns one person the full loop—identify a problem, decide, execute across functions, ship to production, and own the outcome; Vera says Lovable’s technical and nontechnical employees push production changes subject to human review.
- She says this requires unfiltered company context for ICs, authority tied to accountability, and cross-functional scope; with build costs falling and decisions becoming more reversible, she argues shipping and learning should take precedence over approval chains and debating the “right” decision.
- Vera reports spending 70% of her time with agents and 30% with people at Lovable, and 90% of her week building, shipping, and thinking about what to build next, with less than 10% in meetings. She says moving to IC retained executive-team access, monetization ownership, and her previous pay; she also says Lovable sets no salary difference between IC and VP roles, separating pay from management status.
Product School
- Gamma Enterprise’s GM said fast-moving AI markets can require recapturing product-market fit about every three months; after deciding its previous AI presentation experience risked falling behind, Gamma rebuilt the product in one summer.
- To understand why users were fading, Gamma contacted them directly and automated much of the research workflow while keeping insight human: product, design, and engineering colleagues joined live calls, transcripts were processed with an LLM for candidate insights, and employees shared immediate reactions afterward.
- More than 100 users spoke with Gamma, with over 30 of its 120 employees participating; conversations surfaced that users shared more and were less filtered when speaking by voice, prompting Gamma to add a microphone button.
- A two-seat team customer who had canceled with months left said Gamma’s updated product could be a game changer after the company asked for feedback without pitching or offering a discount, and chose to try it again.
Product School
- Webflow CPO Ben Hafley says agentic development can reverse the software lifecycle: after an idea, generate working code, test and refine it, add intentional design, and codify requirements and documentation at the end. This lets stakeholders react to working software instead of imagining states and flows from specs or design artifacts.
- He argues that product practitioners’ work shifts from production mechanics toward design judgment, curation, and quality, with more effort spent building systems that help agents work effectively and evaluating their output to improve guardrails. He cautions that expectations about what is difficult must keep evolving as models and agent harnesses improve.
- Webflow’s adoption playbook moved from designers prototyping in code to enabling product managers and operations teams, then shipping real code changes; it established weekly Builder Wednesdays and set a quarterly goal for everyone across its EPD organization to ship to production, which it said reached 100% in July. The company also embedded AI fluency in career expectations, including a “PM as builder” competency.
- At Webflow’s September customer conference, the company paired customers reporting product friction with a PM, designer, engineer, and agents, and said it fixed 50 paper cuts live.
Teresa Torres
- Leaders should co-design challenging team experiences with participants, making room to surface abilities, disabilities, and comfort levels; stretch people within a “zone of proximity,” since pushing too far can alienate rather than help. Hierarchy, politics, and cultural norms also shape whether people feel safe struggling in front of colleagues.
- Learning a new sport is presented as practice in being a beginner and embracing continuous improvement; unfamiliar, immersive experiences may also offer new perspectives and energy for innovation, even when their relevance is not immediately obvious.
Product Growth
- James McAulay open-sourced a Growth OS for Claude Code, also compatible with Codex, Hermes, and OpenClaw. It combines API/CLI-connected tools, recurring skills such as PRD writing and SEO audits, and weekly routines that suggest improvements; it is designed for a full-stack growth hire but adapts onboarding for specialists.
- The OS builds experimentation discipline into the workflow: each experiment gets a file before shipping; an A/B-testing playbook prevents early result reads; standups and retros flag tests ready for review or gone stale; and templates capture baselines and confounders before a weekly loop records learnings.
- Its execution flow drafts a metric-focused PRD, uses specialist subagents to critique it and prioritize changes, then asks Claude Code to build—an approach intended to let growth teams run tests without waiting on engineers. The author cautions that agent autonomy is often overhyped and the system still needs human involvement.
Product School
- Anthropic’s FDE team moved Claude from creating an opportunity tracker and dashboard on request to owning ongoing updates: Claude pulled CRM data, asked clarifying questions, and updated the tracker and dashboard. The team later iterated an internal tracker’s requirements with go-to-market feedback, had Claude build the app and open PRs for Ryan to approve, then assigned Claude to triage user feedback and fix obvious bugs while humans decided which new features to design and build.
- As the team grew, coordination and information flow—not tooling—became the bottleneck; Claude gathered updates from leads, synthesized relevant Slack, call-note, and email context, resolved what it could, and prepared open questions for Monday meetings. After meetings, humans reviewed and confirmed transcript-derived action items before Claude handled follow-ups such as posting updates and updating the tracker.
- The team’s enabling elements were shared context, access to tools (including delegated user identity with an audit trail), individual/team/organizational memory, proactive triggers, and a feedback loop that updated memory and instructions.
Kevin Weil 🇺🇸
Arda launched publicly with a $160M Series A at a $1.5B valuation, after spending a year building with Anduril as its design partner. Its platform helps manufacturers design and operate manual assembly lines to get designs into production faster; the next planned product step is automated lines that can be reconfigured as quickly as human workers.
Product Management
- Use AI to assimilate and structure discovery material, summarize transcripts, and draft interview questions; keep decisions and assumptions with the PM, and treat AI output as a hypothesis or rough draft—not as research.
- Keep direct user contact and active note-taking: one PM reports that outsourcing interview notes to AI reduced their engagement and ability to synthesize across conversations; they instead recommend taking notes personally, then using AI to find illustrative quotes and challenge bias. Another PM emphasizes frequent user meetings to retain firsthand understanding of how users feel about the product.
- Treat simulated personas as weak evidence: commenters describe simulated users as generic and senior-IT-buyer purchase prompts as producing random results; one also notes that actual paying customers may differ from mapped personas. One practitioner recommends summarizing raw data instead of asking AI to predict a persona’s behavior.
- To improve LLM collaboration, one practitioner recommends supplying product context from 8–15 artifacts, specifying the desired output, and splitting work into single tasks (such as identifying assumptions separately from risks); they report that combining tasks performed poorly.
Casey Winters
Casey Winters argues that exceptional consumer-tech outcomes are not simply a matter of luck: a wrong decision or series of decisions can prevent a breakout. He says Foursquare had the chance to become such an outcome but did not, while cautioning against blaming those who were involved.
Product School
- The speaker’s AI-era PM model calls for technically self-sufficient individual contributors: technical does not necessarily mean writing code, but includes choosing models, engineering context, debugging AI-generated code, and understanding model-call economics. Hiring should test what candidates build through demos rather than strategy presentations.
- Leaders should do the work themselves before delegating or reviewing others’ work. The speaker describes a two-day leadership hackathon and argues that teams must unlock execution speed before judgment becomes the bottleneck.
- Replace long prioritization cycles with roadmaps of at most a quarter and weekly shipping; make it cheap to say yes, then learn from and sunset weak ideas. The speaker argues a bad idea in production can teach in a week, while a roadmap idea may teach nothing for a quarter.
- Reconsider buy-versus-build: Product School replaced most tools with custom solutions despite added tech debt; the speaker says this saved millions, enabled its best-selling membership product, and let sales staff spend over 80% of their time selling. He attributed a 31% year-to-date rise in revenue per employee to the five principles.
a16z
- OpenAI adds specialized healthcare data across training stages of its general models rather than building a smaller healthcare-only model, aiming to combine frontier-model capabilities with healthcare expertise and avoid a specialist model falling behind as general models improve.
- OpenAI frames healthcare product execution around model quality, a suitable product “harness,” and deployment through partnerships; it says product work should lower activation energy by addressing adoption barriers such as health-system security, privacy, and compliance. Its Epic integration supports use of Epic through ChatGPT and ChatGPT within Epic workflows, while OpenAI describes its role as enabling care-delivery partners rather than providing all medical care itself.
- OpenAI says its evaluations and training account for different user personas and draw on a global network of hundreds of physicians; safety should take priority over reassuring a user when a situation calls for care, and evaluations also test whether models acknowledge uncertainty.
Product School
- Miro CPTO Jeff argues that AI has eased execution, but building the right thing remains the bottleneck: customers he spoke with had largely solved execution yet still faced chaos and uncertainty about impact. Product managers’ leverage is problem-solving, decision-making, alignment, and pace-setting—not simply moderating agent loops.
- At AI speed, PMs should make decisions faster and more often, take bigger bets, maintain continuous team alignment, and use time freed from producing artifacts for deeper collaborative thinking about the problem and ambition.
- Miro’s demonstrated workflow uses AI to scaffold project briefs, user stories, diagrams, prototypes, and stakeholder materials during a cross-functional kickoff. The artifacts stay intentionally low-fidelity so the team can align on the problem and approach before implementation, while shared context is made available to agents.
- Jeff cautions that agent activity without a strategy, narrative, or synthesis still creates chaos; prototype collaboration should align the team on the experience and codify decisions and their rationale for both people and agents.
Product Management
An 8-person transportation product team using Claude Code and GitHub Copilot reported faster individual work but unchanged time-to-ship, with a QA backlog and missing context or unclear requirements causing further back-and-forth. A useful product-management response is to diagnose flow from intake through shipping rather than equating faster coding with faster delivery; the discussion points to QA/testing capacity and requirements gaps as possible constraints, with test automation suggested as one intervention.
Outcomes varied: a commenter at an organization with about 1,000 employees and 500+ engineers reported shipping roughly twice as much as two years earlier with about flat headcount growth. Another reported faster bug fixes, but said discovery, alignment, and stakeholder conversations remained the longest, harder-to-quantify steps for new features.
Product School
- YouTube’s Sunday Ticket team began with 129 P0 features but lacked ownership of 80% of the engineering needed; it distinguished launch blockers from work that could be staged, starting installment billing with pay-in-four and later expanding payment options, including 8- and 12-part plans and monthly cancel-anytime plans.
- AI speeds prototyping and code production, but decision-making, cross-team execution and readiness remain key bottlenecks; identifying dependencies early and reusing YouTube Gaming’s esports loot-drop infrastructure helped deliver account linking faster, while AI could not secure partner teams’ commitment to change roadmaps.
- Treat a launch as a business operation, not just a feature release: YouTube put pricing, marketing, distribution, operations and support alongside engineering in a shared sprint and decision cadence. It called a July code freeze, then tested features with live traffic and users and rehearsed human processes; the speaker says these checks matter even when AI can generate test cases.
- After launch, weekly reviews of sign-up data, playback quality and support issues fed mini-sprints; location verification was an early weakness on the main YouTube app. The cross-functional process became a blueprint for later major YouTube sports launches.
