We can't find the internet
Attempting to reconnect
Something went wrong!
Hang in there while we get back on track
Big Ideas
AI makes building cheap; PM judgment is the scarce layer. Sachin Rekhi says specs still sharpen thinking, but prototyping is a stronger forcing function because building surfaces implementation trade-offs faster. Run the Business sees the operating risk: AI-heavy teams that measure prototypes and features rather than outcomes create UX clutter and feature bloat; meaningful reps are evidence-based changes that move the product toward PMF, measured by how quickly the team moves from uncertainty to confidence. Aha’s Builder team makes the same shift: building the right thing is harder, so strategy and customer understanding increasingly determine PM value. Use AI to prune obvious ideas cheaply, then spend the saved capacity on deeper discovery—not on shipping every prototype.
Tactical Playbook
Put an agent through a task-level gate. Decompose a workflow into tasks and label each deterministic, AI-assisted, or agentic; compare the human cognitive load with the engineering, evaluation, and failure-handling cost. One PM estimates that roughly 70% of their workflows should remain deterministic. For structured manipulation, use ordinary logic; reserve AI for large volumes of unstructured data, pattern extraction, or transformation, and inspect where users export data or continue working outside the product to find higher-value opportunities.
Use evidence gates before a new product. Aha’s five-part process is: spark, picture-based concept validation, proof of concept, invite-only early access, and general availability. The concept test targets at least 30 significant customers in no more than 20 slides and asks about willingness to pay and adoption timing; early-access customers commit to usage and recurring meetings. For AI-enabled products, prototype the experience before designing the schema and back end: Aha reports that this phased order produces better outcomes than an open-ended prompt and can still complete in five or six minutes.
Case Studies & Lessons
PMF before sales scale. A pre-seed B2B founder reports paying customers after eight months of redevelopment but says PMF is unproven; advisers are urging heavy sales, while the founder fears acquiring customers whose staff will not use the product. The thread’s proposed operating plan is to model the current team, a sales hire, and sales plus a fractional CMO against runway and milestones such as retention, usage, expansion, and repeatable acquisition. Stage spend in batches: watch activation, retention, and feedback before increasing acquisition, or risk proving only that leads can be bought.
For marketplaces, seed the constrained side first. Five days after launch, Coloca had organic demand from room seekers but no available-room listings, no ad budget, and a strategy focused on existing renters rather than landlords. An experienced marketplace operator recommends one-city focus, manual seeding of the hard side, then marketing to fill the easier side; founder, family, friends, or multi-room units may be needed to create the first supply. Supply acquisition should therefore be an explicit product milestone, not an assumption behind the launch.
Career Corner
Move from PO throughput to PM judgment. A nearly 13-year PO already uses AI agents and Claude prototypes but asks how to progress into leadership. The recommended skill stack is stakeholder influence and negotiation, “context engineering” for product/user/problem/strategy documentation, and rapid discovery through personas, hypotheses, and prototypes; the AI-era differentiator is connecting people, process, and product while deciding what should happen, why, and when.
For a portfolio, show the product as a story rather than a static case study: user lens for the problem, founder lens for why and how to build, and the research–iteration–testing loop. A dual view—a four-to-five-minute skim plus a detailed build journal—serves both hiring managers and deep readers.
Tools & Resources
A lightweight bot-evaluation worksheet. Hiten Shah suggests starting with work completed this week that will recur; promising jobs include monitoring changes, assembling customer evidence, and turning signals into a brief. Before delegating, write down failure modes and the success bar, then give competing bots the same job and input for one attempt and score pass/fail. Useful-looking output is not enough to justify autonomous operation.
- Use a problem-first, task-level filter. Decompose a workflow into individual tasks and classify each as deterministic, AI-assisted, or agentic; compare the user’s cognitive load with the engineering effort, evaluation burden, and failure-handling complexity before choosing an agent. In the post’s domain, roughly 70% of workflows were judged likely to remain deterministic, with only a smaller subset genuinely needing agents.
- Match the technique to the data and workflow. Use conventional logic for structured data manipulation; reserve AI for high-volume unstructured data, pattern derivation, or data transformation, and find opportunities by asking users what they export from the product and where they continue working afterward. For intake flows, one practitioner recommends using an off-the-shelf parser first and AI only for missed cases, reporting that Amazon Textract was cheaper and more accurate in that example.
- Treat AI as an adoption and cost decision, not just a capability. Make LLM or agent features optional where possible so they do not disrupt users or inflate marginal costs; one commenter says agents often add little advantage in B2B workflows despite executive and marketing demand. Another practitioner reports that some AI launches succeeded while others drew negative feedback or were dead on arrival when ease of use, reliability, utility, and predictability were deprioritized.
- Protect product strategy from AI-mandate pressure. Searching for places to use agents can displace product strategy and strategic thinking. A useful review asks whether AI fits the existing use case and whether it enables a different workflow or outcome; if neither answer is yes, the existing approach can remain unchanged.
Discovery-to-launch method: Aha! describes a five-part new-product process that starts with a spark or insight and picture-based concept validation, then moves through a first version or working proof of concept, internal-use validation, invite-only early access, and general availability. Concept testing targets at least 30 significant customers, uses no more than 20 slides, and asks hard commercial questions such as willingness to pay, price, and adoption timing. Early-access customers commit to a defined amount of usage and recurring meetings.
Use behavior as a product signal, then expand the problem: Aha! saw strong uptake when its AI assistant began generating simple prototypes: product managers created them repeatedly, replaced some wireframing activity, and changed how the internal team practiced product management. Users then wanted to move from prototypes to applications with integrations and real functionality, motivating the broader Builder product. The discovery lesson is to treat a customer’s immediate problem as a starting point, extrapolate the broader workflow and needs, and then validate that customers agree with the expanded solution. Keeping this capability inside the existing product-management workflow preserves access to roadmap, feedback, and other product context.
Scaffold AI with the product process: Builder asks product managers to establish vision, goals, personas, problems, and background context before coding, combining open-ended AI interaction with structured guidance. Its multi-phase flow interviews the user, generates a prototype first, and only then develops the schema and back end; the team reports that this sequence produces better outcomes than a single unstructured chat prompt and can complete in roughly five or six minutes.
PM value shifts toward judgment and product-system integration: The interview argues that AI makes building easier but makes knowing what to build harder, increasing the importance of strategy, customer understanding, prioritization, and deciding what not to invest in. Builder is intentionally aimed at prototypes, proofs of concept, and non-core business applications such as system integrations, dashboards, and beta-tracking tools—not a company’s primary line-of-business application. The boundary reflects the need for human teams to handle change management, process, deployment, and ongoing operations; PMs can initiate code generation, but the coding agent remains inside the engineering team’s existing review and deployment process.
Enterprise governance is a product requirement, not an AI guess: Builder uses deterministic platform components for authentication, user and role management, email, APIs, and related capabilities instead of having the model recreate security-sensitive code for each application. Administrators can require a specific organizational authentication method, while hosted deployments provide one-click release for PMs with guardrails such as blocking public deployment.
- AI changes discovery tactics more than its fundamentals: product teams should start with outcomes, understand the humans they serve, enumerate assumptions, and test those assumptions; sound product decisions still balance customer desirability, business viability, and feasibility. AI can automate transcripts, identify customers at risk or likely to need a feature, generate insights, and create interactive prototypes quickly, but it does not replace judgment or validation with customers and the business.
- Customer research remains a core PM practice because “customer interview” is often used for inconsistent activities, including story-based interviews, generic questioning, sales demos, stakeholder meetings, and interface-preference prompts. An AI interviewer may improve consistency and model good technique, but should augment rather than replace PMs’ firsthand conversations about customer goals, usage context, outcomes, pain, and friction; synthetic-user and digital-twin approaches are not yet predictive of human behavior. For synthesis, teams should use domain-specific guidance rather than simply dumping transcripts into an LLM, and should test individual assumptions instead of validating an entire solution at once.
- For AI products, define “good” as a cross-functional product decision spanning customer needs, business value, and feasibility; translate those rules into metrics, treating evaluations as closer to acceptance criteria than unit tests. Reviewing AI traces can improve product quality, but teams should be transparent that AI-human interactions may be inspected; synthetic-data alternatives also have limitations. Teams that reach market successfully are blurring functional boundaries—PMs and designers learn enough code to run evaluations, data scientists partner with designers, and engineers engage with business questions. For broader adoption, create bright-spot pilots with motivated individuals and take small, continuous steps rather than relying on organization-wide transformation programs.
- Lenny shared 25 PM openings spanning business technology, payments/connect, Google Photos, growth platforms, AI safeguards and post-training, fintech, partner integrations, IT, manufacturing software, and AI infrastructure.
- The curated set shows AI-focused PM opportunities across safeguards, post-training, public-sector agent development, AI CI/CD, AI infrastructure networking, agentic payments, and AI growth.
- Career levels range from Staff and Principal PM to Director and VP roles. Listed compensation examples include $385K–$460K for Anthropic’s Business Technology PM, $350K–$450K for Thinking Machines’ Post-Training PM, $340K–$380K for Handshake AI’s VP of Product, and $345K–$385K for Crusoe’s VP of Product Management.
- Discovery framework: Aha! applies a five-step process to every new product, including Builder: spark → paper prototypes → proof of concept → early access → general availability.
- AI product-building trade-offs: Aha!’s initial containerized Ruby on Rails approach was too wasteful to scale, so the team rebuilt Builder on a single-instance, multi-tenant architecture using V8 isolates. The product uses deterministic, pre-built components for authentication, SSO, databases, and email to reduce token costs and provide reliability that AI-generated code cannot guarantee. Its multi-phase, multi-agent pipeline generates a design system, then a prototype, then a working application, rather than relying on one open-ended prompt.
- Scope and governance: Aha! is optimizing Builder for prototypes, proofs of concept, and internal “meta applications,” not primary line-of-business applications; the product also incorporates authentication policies, deployment guardrails, and PII/PHI considerations for enterprise use.
- PM implication: As building becomes easier, Aha! argues that the product manager’s differentiator will increasingly be knowing what to build rather than how to build it.
- Token-market-fit framework: Fal defines “token market fit” by asking whether a single person can productively spend roughly $10,000 in tokens per month. It applies this lens to generative media and coding-agent products, where daily users may spend thousands of dollars and compute efficiency can unlock more usage under industry-wide capacity constraints.
- Launch and discovery loop: Before emphasizing H3 Max’s performance, the team waited three to four days for external evaluations because its internal results seemed “too good to be true.” After release, an engineer’s Twitch stream, an external influencer’s streaming site, and the ML team’s continuous-memory version emerged independently; the three efforts went viral and became products or experiences over the following days. The case supports a two-stage launch pattern: validate headline claims, then leave room for rapid internal and user-led experimentation to reveal unexpected use cases.
- Speed-versus-control roadmap: After achieving major speed and cost improvements, the team shifted its priority from further latency reduction toward quality and controllability. H3 Max Turbo can generate a five-second video in about 1.5 seconds at roughly half the cost, but with a small quality trade-off, giving users a speed/quality choice. The control roadmap moved from text-to-video and image-to-video to reference inputs, character voices, structured camera trajectories, lighting controls, lip synchronization, and motion control; the team reported roughly 80–90% reliability with basic prompting while targeting 99.9% reliability for professional outputs.
- Professional-segment discovery: Hollywood became the platform’s fastest-growing segment, with customers seeking targeted capabilities such as extending footage or changing camera controls and lighting rather than generating entire productions from scratch. The product response was to build reusable post-training toolkits around professional workflows, support customer-owned IP, and provide US hosting to address legal and data-residency blockers.
- Frame AI opportunities around outcomes, not tools: After delegating tedious digital tasks to AI, use the recovered time for creative, high-agency experiences rather than focusing only on which model or tool to optimize. The essay groups leisure-oriented opportunities into four buckets: Hobbies++, what-if explorations, future doses of delight, and one-of-a-kind gifts.
- Use existing interests as a discovery starting point: Begin with something users already enjoy, then explore how AI can push it into a richer or more creative form—for example, turning a hobby into an interactive game, simulation, or personalized wardrobe experience.
- Practical AI prototyping loop: Start with a person, activity, or recurring idea; complete “It would make me happy if ___”; make the desired result specific enough to visualize; ask AI to help create it; identify where the result matches or misses the vision; and iterate, potentially involving other people in the exploration.
- Case study—personalized memory product: Seeking something richer than standard “on this day” posts, the author built a daily loop that combines old photos, videos, and journal entries into a story from the same month in the past, then sends it to her and her husband via WhatsApp each morning; both enjoy reading the resulting memory prompts.
- Design AI products around completed jobs, not point solutions. YC speakers report that companies handling full end-to-end tasks grew from 10% to more than 25% of the batch, while median monthly revenue by the end of the batch rose from about $8K to $20K; they connect the growth to software that performs the work rather than merely records it.
- Juicebox illustrates the product expansion path. It began as LLM-powered candidate search, which still required recruiters to contact candidates; its newer agent contacts candidates, schedules interviews, and handles additional workflow steps. The speakers said this could double or triple revenue per customer, while recruiters retain higher-value judgment such as assessing culture fit.
- Systems of record increasingly need to become AI execution harnesses. The speakers argue that products should be usable by agents as well as humans; simply exposing data through an MCP may make the data easier to leave and switching easier, whereas becoming the place where users and agents read, write, and perform work is the stronger product position.
- AI lowers the building barrier but raises the value of product judgment. The discussion frames knowing what to build, having domain “taste,” and directing coding-agent teams as increasingly important; experienced engineering managers may have an advantage because managing agent teams can resemble managing human engineering teams.
The post suggests a repeatability-based test for automating knowledge work: start with something finished this week that you already expect to do again, then assess whether the job is ready to hand off to a bot. It identifies monitoring changes, assembling customer evidence, turning signals into a brief, and making the next thing as strong recurring candidates, based on a review of 921 public Bots.
- Domain experience appears to be a major hiring filter for PMs in this discussion: an 8-year professional with five years in product management reports receiving interviews only for PM/SPM roles aligned with prior industries and remaining unemployed for six months after a March layoff. The thread also reports only four company interviews, with processes reaching rounds 4–6 before rejection.
- Networking and focused positioning may be necessary for an industry switch: one commenter describes the market as “stay in your lane” and believes out-of-domain candidates may need an internal contact to advocate for them; another says securing interviews remained difficult even with a referral and strong credentials.
- Anecdotal application tactic: a commenter who changed fields 2.5 years earlier recommends prioritizing local hybrid or in-office roles and applying within 24 hours of posting; they report getting no responses from full-remote applications but immediate results from local roles, while noting the experience may not generalize.
- Switching industries can require a temporary compensation trade-off: one commenter lowered salary expectations and later caught up after several years. Another reports taking a $40,000 base-pay cut, exceeding prior total compensation after a year through promotion and bonus, while base pay remained lower.
- An actionable AI-assisted prototyping loop is to start with a specific person, activity, or unusual idea; define a concrete desired outcome and visualize it; make a single AI request; then identify where the result matched or missed the vision and iterate, optionally involving others in the exploration.
- Constraint-led personalization can turn an existing product into a shared experience: because Geometry Dash does not offer multiplayer, Mike built a multiplayer version for his 10-year-old son’s birthday, adding characters and levels themed around the son’s interests plus AI-assisted songs containing family jokes.
- A recurring product experience can be built from user-owned data: the author combined old photos, videos, and journal entries into a daily story about the same month in the past, then delivered it to herself and her husband through WhatsApp each morning; both enjoyed reading it.
- Hiten Shah describes a multi-agent workflow in which one bot monitors inboxes, calendars, and work chat; identifies what needs attention; passes context to a task-generating bot; and routes suitable work to specialist bots for a first pass. The human remains responsible for judgment when needed.
- For deciding which work is ready for automation, Shah compares bots head-to-head on the same input, defines evaluation criteria before testing, and scores each result pass/fail.
- His team built an internal lead-review tool in two weeks using roughly 10 hours of actual build time; Shah reported record-high lead-review rates after rollout.
- Before testing a bot, write down its possible failure modes and the success bar in advance; this avoids judging a polished response favorably only after seeing it.
- For a controlled bot comparison, keep the job, input, and number of attempts identical across each pair, then assess outputs against the prewritten bar. In the Grok Bots test, some responses looked useful but were still not good enough to leave running autonomously.
- Frontier-model pacing is becoming a roadmap risk: Anthropic CEO Dario Amodei has argued that frontier labs should deliberately hold back capability gains by roughly one to two years so safety and alignment work can catch up; OpenAI CEO Sam Altman and Elon Musk publicly endorsed the need to “pace the frontier.” Product teams should add slack to plans that assume the next model will arrive within weeks or months, or will automatically be faster, cheaper, and more capable.
- Stress-test dependence on capabilities you do not control: Teams building on frontier models should examine whether their next-year roadmap requires meaningful model improvements every few months, then build product value around assets they own—data, workflows, and context—instead of relying purely on a lab’s future capability gains.
- AI assurance may become a vendor-selection criterion: Enterprise buyers may soon ask whether a model provider gives independent evaluators employee-level access and lets them publish findings without vendor approval, alongside existing questions about security, data residency, and uptime. For products shipping AI, practical responsible-AI controls include evaluations, quality disclosures, human-in-the-loop safeguards, user choice, transparency, and controls aligned with users’ interests.
- Treat public pacing commitments as signals to verify, not roadmap facts: The proposal has unresolved measurement and governance issues—“pacing” lacks an agreed definition, limiting one capability path could push development toward another, and standards written by the largest labs could become an incumbent moat rather than an industry-wide baseline. PMs should monitor actual release pace and capability changes rather than relying on executive statements alone.
- AI is making prototyping, feedback synthesis, roadmap generation, and metric inspection faster, but teams that measure output—prototypes shipped or features delivered—risk UX clutter, feature bloat, and feature-factory behavior.
- A stronger operating model uses AI to prototype rapidly, eliminate obvious or weak ideas before exposing them to customers, and reinvest the saved runway in deeper exploration of non-obvious opportunities. The goal is disciplined, targeted iteration rather than random shipping.
- Measure iteration quality by meaningful learning reps: changes made from evidence that move the product closer to product-market fit. The practical north star is shortening the path from uncertainty about direction to confidence in the right direction—not maximizing feature count or delivery speed.
- AI shifts the PM constraint upstream from delivery to discovery: teams must question whether they are testing the right hypotheses, why they are shipping, and whether their iteration loop is sound. The failure mode varies by stage—learning-speed confusion in early teams, local-maxima optimization in scaling organizations, and defensive shipping in mature products.
- Shift from delivery execution to product outcomes: Community responses distinguish PO work as primarily sprint/implementation focused, while PM work is broader and more strategic. One framing is that POs release capabilities, whereas senior product leaders connect those capabilities to customer and company outcomes rather than outputs.
- Build the skills that enable that transition: Recommended development areas include stakeholder management (relationships, influence, and negotiation), “context engineering” to document the product, users, problems, and strategy, and rapid discovery through problem/persona exploration, hypotheses, and rapid prototyping. A practical career tactic is to review Technical PM job requirements and use them to identify skill gaps.
- Use AI for leverage while strengthening judgment: A nearly 13-year PO reports already building AI skills/agents for the PO pipeline and using Claude to prototype and validate solutions. The accompanying career advice emphasizes that AI increases the value of a person who connects people, process, and product and makes decisions about what should happen, why, and when.
Early-adopter enthusiasm can make mediocre product positioning look strong because early adopters already understand the underlying problem; PMs should not treat their response alone as definitive positioning validation.
- NILO is a B2B SaaS product for industrial sites that digitizes visitor and contractor access control. Its workflow validates identity and company data against government registries, logs approvals and entry/exit times, creates an audit trail, and is designed for guards, security managers, and visitors to use with minimal training. It charges per location, raised pricing from $500 to $1,000 per month, offers $10,000 annual prepayment, and positions the product as replacing roughly five security staff.
- The product had two customers since July 2025: a single-location customer renewed for a second year, while a five-location customer that prepaid annually chose to extend for only five months while building internally. Users nevertheless reported faster gate processing, less paperwork chasing, and elimination of shadow spreadsheets. The founder reported no marketing or inbound motion; prospects typically went silent, deferred the decision, or faded after positive meetings, suggesting strong user appreciation but weak perceived necessity.
- Community feedback separated two product signals: the pain was real enough to generate purchases but not necessarily sticky enough to overcome an enterprise preference for owning the workflow and audit infrastructure. Suggested PM/GTM actions were to conduct post-use interviews to identify the specific value customers experienced and reuse that evidence in sales, position the product around urgency triggers such as insurance renewals, safety regulations, incidents, or failed audits, and work through insurance brokers or industry associations that already surface those consequences. To test scalability, the founder was advised to win a third, unconnected plant through a repeatable partner, association, or narrow-ICP outbound motion, and to ask the departing customer who owns the rebuild, its deadline, and the operational consequences if it slips.
- Build visibility through evidence-based product thinking: Aspiring PMs without formal PM experience can publish analyses of common user problems, product explainers, and informed opinions; research the problem, support the perspective with data, propose a solution, and share it on platforms such as Medium, Substack, or LinkedIn.
- Make the portfolio a product story, not just a case study: Present the problem through the user lens and the build rationale through the founder lens, covering research, competitive analysis, development, iteration, and testing as an ongoing loop.
- Serve both skimmers and deep readers: A proposed portfolio format uses a short 4–5 minute overview alongside a detailed version covering each stage; a startup-journal format can document the problems encountered, iterations made, and product updates.
- Mercury launched Mercury Books, a QuickBooks Online-like bookkeeping tool embedded in its banking platform; the post estimates that it is currently free and may cost about $35/month in 2027, close to QBO’s $38/month Simple plan.
- The product’s main differentiation is direct bank-to-accounting integration, but migration requires customers to redo their books, reset rules and categorizations, and retrain teams or accountants. The discussion questions whether integration is enough to displace an incumbent that accountants prefer when Mercury offers no clear pricing advantage.
- One commenter hypothesized that bookkeeping is primarily a retention strategy rather than a standalone revenue product: storing books inside Mercury could make switching to Brex or Ramp harder because customers would have to untangle accounting data while moving their bank account, protecting the higher-value deposits and lending relationship.
- The discussion points to small existing Mercury customers with limited bookkeeping needs as an initial segment: users cited QuickBooks’ cost and dated user experience, and said a free integrated tool could be preferable to adopting another paid system.
- Automation remains a product risk: the discussion characterizes the current offering as mainly a general ledger with auto-categorization, while noting that bookkeeping requires contextual judgment and that changing transaction descriptions can confuse AI systems.
- A commenter identified Mercury’s distribution advantage as roughly 300,000 businesses and strong presence among startups choosing their first bank, but another warned that success depends on adoption by both clients and vendors.