We can't find the internet
Attempting to reconnect
Something went wrong!
Hang in there while we get back on track
Big Ideas
Consumer AI may compete less on model identity than on usefulness and access. Tony Fadell argues that models are already good enough for most consumer needs, and that users will want AI to be useful, easy to reach, and free or bundled with something they already pay for. Paul Graham offers a complementary choice for builders: work close to the technology by making LLMs, or close to customers by using AI to give them what they want. For PMs, the implication is to build a real edge in capability or in solving a customer job—not rely on model novelty alone.
Shipping may be cheaper; maintenance and user attention are not. A former startup employee says CEO-led weekend AI coding hackathons produced features with near-zero adoption; another PM reported roughly 30 unused features that remained in the product and added maintenance and testing burden. Commenters also point to ownership and support tickets, and warn that features outside the product’s job-to-be-done tax users’ attention and obscure valuable functionality.
Tactical Playbook
Turn “launch and see” into a bounded experiment. One commenter recommends agreeing before an AI coding sprint on a single 30-day adoption threshold and removing the feature if it misses; ship off by default behind a flag to a subset of accounts so removal is a toggle, not a fight. Track repeat tickets per feature alongside adoption: usage alone can hide the maintenance cost.
Design agent permissions around the task and its consequences. A Muse user had to approve sending a message after already instructing the agent to send it; the article also says Claude Code users approve about 93% of prompts, a pattern Anthropic calls approval fatigue. Start with read-only access and expand only when needed; distinguish drafting from sending and viewing production from changing it. For hard limits, make them architectural: Replit separated development and production databases so its Agent cannot change production during development.
Case Studies & Lessons
A product-operations leader described roadmap planning that consumed two months of every quarter making slides, while inconsistent Jira definitions and the lack of a shared account of what teams planned to do—and why—made the roadmap hard to use. Standardizing the work hierarchy proved easier than getting thousands of people to adopt it. The organization now links initiatives to expected value and spend, and the leader said a Jira-backed app was intended to replace the planning slides. The lesson: fix the underlying work data and adoption problem before polishing the roadmap presentation.
The same leader’s PM capability framework used 12 skills across four themes, with employee self-assessment and manager feedback to prompt development conversations. After six months spent aligning the language, 150 people completed the assessment; engineering, data, and UX later adapted discipline-specific versions. He says the shared framework also made promotion decisions more consistent and transparent. Keep the skill intent consistent, but let teams define how it applies to their work.
Career Corner
For a Founding PM role that drew hundreds of applications, Deb Liu advises making fit unmistakable: connect your experience to the company’s actual needs, show one finished product or prototype, and seek a reference from someone who knows your work. She also reports that direct outreach from an unconnected candidate led to a meeting.
A PM offer-negotiation guide reports that five coached candidates won increases without an offer being pulled, including two who were unemployed after layoffs. Its method is to calculate effective annual compensation over expected tenure, including cash, equity likely to vest, and sign-on; discount private equity for payout risk and time to liquidity. For a two-to-three-year stay, it recommends prioritizing sign-on and front-loaded vesting; for four or more years, base and equity.
A frontend-designer launch teaser said only that a product would “solve the pain problem,” without explaining the pain or the solution . Readers called the pitch vague/low-effort and asked for more detail; one warned it had created a bad impression of the product .
- The interviewee describes product ops as connective support for both product and engineering: it should help teams decide what and why to build and make delivery possible, rather than simply add process. Diagnose organizational blind spots and sources of friction, then solve one problem at a time; he suggests investing some capacity in ways of working above roughly 30 PMs or when teams are geographically or culturally distributed, though around 10 teams may not need dedicated headcount.
- In his company, quarterly roadmap preparation once took two months of slide-making, with no shared document for people outside planning meetings to understand or comment on the what and why; inconsistent Jira usage also lacked a shared hierarchy for initiatives and features. Standardizing Jira exposed that adoption—not designing the solution—was the harder challenge across roughly 3,000 people. He reports that Jira data now supports initiatives tied to expected value and spend; product and finance work on translating product metrics into value, and an app using the data is intended to replace planning slides with a source of truth.
- To clarify PM expectations and support development, he built a 12-skill framework across four themes, drawing on Reforge, CPO input, his experience, and market observations; it covers areas including execution, influence, strategy, storytelling, prioritization, and data. The process pairs self-assessment with manager feedback to prompt career conversations, and keeps skill intent consistent while allowing application to vary by team and domain. After six months of alignment, 150 people completed the assessment; the framework also supported more consistent and transparent promotion decisions. Engineering, Data, and UX adapted the model into discipline-specific frameworks, reaching about 3,000 people. At his company, product adoption was made an explicit PM skill because some PMs saw their job as ending at feature delivery; he says teams should track adoption and impact, with value delivery or realization as possible broader framings. He argues AI does not remove the need for core PM skills such as storytelling, understanding data, and prioritization.
- Anchor creative-tech adoption in audience value, not the tool: Katzenberg says Disney focused on whether audiences believed in a character, then co-developed CAPS with Pixar to replace hand-painted cels; he says the new process enabled visual storytelling the old one could not. The transition can carry real workforce costs: DreamWorks ended hand-drawn animation, and some artists lost their place in the industry while others adapted to CGI.
- For creative AI, build with creators and establish fair terms: Katzenberg argues for involving storytellers with credit, consent, and compensation; he expects lower production barriers and costs to enable more films, greater risk-taking, and new forms of storytelling. Kevin Weil endorsed the argument as a reason for optimism about AI and creativity.
- Don’t assume you need a competing offer to negotiate: the author says PMs commonly have only one offer in the 2026 job market and reports five coached negotiations that improved compensation without an offer being pulled, including two candidates who were unemployed.
- Evaluate the offer by its components—base, stock, bonus, and sign-on—and compare estimated Effective Compensation rather than headline total compensation. The suggested annual calculation uses cash, equity realistically expected to vest during your expected tenure, and sign-on spread across that tenure; keep this estimate internal to assess what to negotiate.
- Match the ask to expected tenure: for a planned 2–3-year stay, prioritize sign-on and front-loaded vesting; for 4+ years, prioritize base and equity. The guide describes sign-on as one of the easiest offer components to negotiate.
- Discount private-company RSUs/PPUs for payout likelihood and illiquidity rather than accepting quoted value at face value: the guide proposes quoted equity × payout probability ÷ (1 + 15%)^years to liquidity, with different payout assumptions by company stage. For private equity, request valuation, shares outstanding, how the valuation was set, four-year projections, and leaver terms; the author advises assigning little value when data is unavailable.
- Treat equity terms as negotiable risk, not just headline value: for ISOs, model the strike-price exercise cost and the usual 90-day post-termination exercise window, and ask for a longer window. The guide also says seniority and hard-to-replace expertise can increase leverage.
- For PM offer negotiations, compare effective compensation (EC) rather than headline total compensation (TC): annualize cash, equity that will vest during your expected tenure, and sign-on; prioritize sign-on and front-loaded vesting for a 2–3-year stay, versus base and equity for 4+ years. One Series C example puts a recruiter-quoted $370K offer at about $270K/year EC for a two-year stay.
- Value equity based on its instrument and liquidity: the guide values public-company RSUs at face value but discounts private equity for payout probability and time to liquidity, using a 15% rate; its examples value a $400K grant at about $80K for a Series C company and about $216K for a late-stage company with annual tenders. For ISOs, a typical 90-day post-termination exercise window can require a large cash outlay—the example is $350K—so the guide recommends asking for a longer exercise window.
- Gupta reports that five coached PMs negotiated better offers without competing offers, and that none lost the offer; he says two were unemployed after layoffs.
- Gupta describes PM work as a tangle rather than a clean linear process, emphasizing resilience, stakeholder management, discovery, and strategy.
- Product guidance attributed to Paul Graham: use less-sophisticated customers to spot where products need simplification and more-sophisticated customers to identify needed depth; go beyond acquisition to make users happy, and consider difficult-to-copy technical advantages when the impact justifies the effort.
- AI product operating model: Prioritize developer productivity and run building, selling, and iterating in parallel rather than sequentially; build what differentiates the product and buy infrastructure or building blocks that do not.
- AI pricing: Match pricing to variable customer value and costs. Replit moved from flat subscriptions to subscriptions plus credits as AI became central to its product, combining predictable subscriptions with usage-based value capture. Implement this by choosing units customers associate with value (such as tokens for developers or seats/consumption for enterprises), showing usage before billing to prevent surprises and churn, and selling credits so customers focus on value rather than each use’s dollar cost.
- Global product readiness: AI companies in the talk reached 42 countries in year one and 120 by year three; top AI companies earned 48% of revenue outside their home market, compared with 33% three years earlier. Localize prices, offer local payment methods, automate tax collection, and track revenue and conversion by country. The speaker cites 18% higher cross-border revenue from localized pricing and more than 7% uplift from adding at least one local payment method.
- Product and GTM design: Treat adding enterprise sales, channels, or agent buyers as product and business-model changes, not just sales changes: onboarding, pricing, and support differ by motion. Define when self-serve customers graduate to enterprise and how pricing changes; use one customer object, product catalog, and data model across routes; and enable agents to discover, evaluate, and activate the product without a human.
- Design agent permissions around the task and its consequences: start with read-only access, expand only when needed, distinguish drafting from sending and inspecting from changing production, and use scoped “Allow” rules to remove repetitive prompts without opening everything.
- Make boundaries enforceable in the product architecture, not just the model’s instructions: after an Agent deleted app data, Replit separated development and production databases by default so Agent could not change production during development; Muse runs agents in an isolated runtime, keeps credentials outside it, and uses Sentinel to evaluate actions and network access.
- Approval prompts alone can become routine: the article reports that Claude Code users approve about 93% of prompts, and argues for pairing human decisions on consequential actions with automated review and containment. Match the fix to the failure: scoped permissions for repetitive interruptions, containment for risky actions, and access boundaries for systems the agent should not reach.
- Avoid blanket always-ask or always-allow permissions: Muse’s repeated approval request after a user had already directed it to send a message created redundant work, while visible prompts can also serve as trust checkpoints. Design permissions around how long approval lasts and which actions it covers. Claude Code users approve about 93% of permission prompts, a pattern Anthropic calls approval fatigue; routine approvals can weaken the value of a confirmation prompt.
- Start with read-only access when it is enough, then add permissions as the task requires; distinguish drafting from sending, inspecting production from changing it, and preparing a purchase from spending money.
- Enforce consequential boundaries in the system rather than relying on the model to remember instructions: after Replit Agent deleted data from Jason Lemkin’s app database during development, Replit separated development and production databases by default and prevented Agent from changing production during development. For agents that can access customer systems, isolation, credential handling, permission enforcement, and network controls are part of the product’s security obligation, not just demo polish.
Sam Julien says a course by Hamel Husain and Shreya fundamentally changed how he builds AI products and platforms, and he cites them in his O’Reilly book’s evaluations chapter.
Consumer founders and builders should regularly leave Silicon Valley and act as ethnographers to understand behaviors and attitudes beyond their own bubble . The Walmart example shows why: its app guides shoppers to items by aisle, and in-stock items can be delivered within an hour—experiences the quoted speaker says tech insiders may not appreciate .
- A PM hired to modernize a legacy HRM product reported one new customer in five years and a 75–80% customer loss over 10–15 years; a couple of GET endpoints took seven months in a COBOL, SQL stored-procedure, and PowerBuilder environment with little API experience, while leadership expected API and web modernization despite capability and staffing gaps.
- A practical response is to shift from optimistic planning to evidence-based accountability: track engineering commitments and actual time, effort, and cost; reforecast; and report missed commitments using data rather than assigning motives. This gives management a basis to reassess roadblocks, while making clear that it may instead blame product for delays.
- Capability-building options raised include using AI to extract business logic only with a verification suite of test cases, evals, or datasets; training current staff; and making a case for architecture, DevOps, or cloud expertise using security/compliance risks and long-term efficiency. Separately, a PM in a similar situation said that presenting a CTO with evidence of skill gaps and their costs eventually contributed to top-down pressure for upskilling and hiring.
- Andrew Chen praised the rise of startups focused on local/“sovereign” AI and GPU capacity, and congratulated GhostAI.
- The linked product thesis: personal AI can differentiate through deeply individualized context rather than network scale, but privacy and trust concerns can limit what users share with hosted agents. Local ownership could ease that barrier and support continuous, proactive processing without per-token provider charges. The adoption challenge is to make local AI useful and simple enough to become the default—not a privacy option that requires worse UX or self-hosting; the article claims local models are already sufficient for 90% of day-to-day tasks.
- Treat cheaper AI-assisted builds as no substitute for product judgment: discovery, compliance, support and other launch work can remain bottlenecks, while unused features still create maintenance/testing costs and compete for user attention. Vet ideas against use cases, priorities, ROI, JTBD fit and usage evidence rather than shipping solely because implementation is cheap.
- Before a hackathon or launch, agree on one 30-day adoption threshold and what happens if the feature misses it; ship behind a flag, off by default for a subset of accounts, so removal is a toggle rather than a post-launch deletion fight.
- To make the costs visible to leadership, track repeat support tickets per shipped feature alongside adoption; a commenter also suggests recording the sponsor, team hours and adoption, then comparing sponsor-weighted adoption.
- A PM’s post-leadership update found senior leaders had not known product and engineering teams were struggling with machine-written PRs; engineers had trouble understanding them, with tight deadlines and integration of acquired and parent systems cited as a prevalent explanation. The PM secured authority for PMs to request rewrites or reject indefensible AI-written documentation and to promote sensible AI use and open discussion; engineering planned to review code-review practices, but took no immediate action.
- For AI-heavy development, one practitioner contrasted legacy codebases lacking AI-oriented context with greenfield products documented before coding: expectations, requirements, code style, architecture decisions and rationale, product direction, and planning. Their sequence was objectives → requirements → roadmap → PRs → code review; for existing systems, they recommended backfilling undocumented team context.
- Measure AI adoption by customer and business outcomes, not coding throughput alone: a commenter cautioned that 10x coding velocity does not mean 10x revenue and urged focus on customers, users, and business results. Reports on economics and quality were mixed: one global SaaS practitioner said scaling output via tokens was similar in cost to headcount and was working so far with business and architecture expertise plus senior security and scalability audits; another said token costs were below additional FTEs but still required human quality attention and guardrails.
- In a high-volume Founding PM search, make role fit unmistakable: connect your experience directly to the company’s needs instead of sending a generic biography. For Ember’s role, sought signals included AI-native experience, building from zero, founder-like operating, and consistently high performance.
- Demonstrate capability with a finished product, prototype, portfolio, or side project; one small, working example can show how you think under constraints better than broad claims. Seek a credible reference from someone who has worked with you, and consider direct outreach if you lack a connection: the post says an unconnected candidate who reached out was invited to meet.
- The FDE/PM boundary is unsettled: the opening post describes FDE job descriptions as overlapping product work while also requiring system-design and AI-stack knowledge; commenters see the strongest overlap in technically capable PMs or engineers with product and customer skills, while warning that technically oriented FDEs may lack user and business focus.
- One commenter reports that trials with pure-development FDEs who had little domain expertise were not going well, and says some FDEs produce MVP/POC-shaped code for handoff to product teams—work that calls for systems fluency and customer-experience judgment, not coding alone. Another flags developer lock-in and unclear maintenance ownership; FDE roles may also be post-sales, sales-engineering-adjacent, or integration-focused, so candidates should clarify the role’s mandate and who will maintain or extend what is built.
Muse, a consumer AI agent, exposes outbound-connection controls for SSH, SMTP, IMAP/POP3, database connections, FTP, DNS, TCP and UDP; users can block a protocol entirely or have Muse ask before each connection, providing a concrete example of permission controls for AI products.
- An internal-products PM at a large company with about a year of PM experience said they were being publicly criticized at least weekly and felt burned out and demotivated. Another PM described an unsupported 0→1 project with conflicting feedback from their manager and head of product.
- For stakeholder management, commenters recommend treating some friction as tension between departments or the PM role and not necessarily as a personal attack; adapt communication to the audience and conversation, and look for a shared problem. If communication feedback keeps recurring, seek specific individual feedback, since communication is central to the PM role.
- For senior-leader disagreements, one commenter advises against opening an SVP message with “to be clear”; another suggests being firm and factual when challenged publicly, while giving a senior leader a private opportunity to revise their message when approached privately.
- To widen an India PM job-search funnel, one commenter recommends contacting hiring managers and recruiters on LinkedIn; keeping active profiles on Naukri, Instahyre, IIM Jobs, Wellfound, Indeed, Weekday, and LinkedIn and applying regularly; and building LinkedIn visibility through relevant comments and posts, with the caveat that this may take time rather than produce immediate results.
- An experienced B2B PM searching in NCR said PM hiring had slowed and recommended targeting Bengaluru, Hyderabad, and Pune over NCR; they also said seniority made their own search harder.
- A commenter who said they had secured six offers in two years argued that an industry/domain tag on a CV helps and that generic PM positioning may not be enough. In this thread, AI experience alone did not ensure progress: a five-year PM reported recruiter calls but no interviews while learning more AI, and a PM with nine years of domain/PM experience and AI build bullets said their search had not moved; their suggestion that metric-moving experience may be valued over delivery-heavy experience was explicitly a hypothesis.
- For early product or venture assessment, do not treat a polished pitch or demo as proof of viability: look for deployments, paying customers, technical milestones, and evidence that the economics work.
- In a discussion of YC’s chemistry-AI entrant, a commenter said it had pivoted from drug development to industrial chemicals, possibly because large pharma had developed models internally; they pointed to Cusp.ai’s reported $650M raise and industrial-partner data access as competitive advantages. The commenter argued that customers seeking R&D savings may pay a premium for the best solution, leaving a less data-rich product needing aggressive pricing that may still not be enough to compete.