We can't find the internet
Attempting to reconnect
Something went wrong!
Hang in there while we get back on track
Big Ideas
The harness around the model is becoming the product. Stanford’s Open Jarvis work decomposes a personal-AI stack into five primitives—interface, agent logic, model, inference engine, and tools/learning—and reports that optimizing the whole stack improved cost, latency, and quality; the talk claims roughly 800× lower inference cost while acknowledging that local models still fail on some tasks. YC’s QM experience shows the operating consequence: after managing 50-plus individually configured agents became unwieldy, the team centralized conversations, made sandboxes on-demand resources, kept the core harness thin, and retained human review for database writes. For PMs, an AI product spec now needs context, permissions, recovery, and review paths—not just a model choice.
Adoption fails at workflow friction before it fails at capability. Teams report that Slack agents are ignored when they create “another place to check”; the ones that persist solve one narrow job in the channel where the work already happens. A credible trust baseline is individual credentials, a read/draft/act split, visible sources, explicit approval before writes, and an audit trail that records which agent acted and what prompted it.
Tactical Playbook
Use a lightweight AI-assisted delivery loop:
- Ask the agent to challenge the idea or propose two or three directions; produce an interactive prototype.
- Refine the JTBD, users, desired behavior, scenarios, constraints, and UX decisions; skip this only for genuinely small changes.
- Let the agent inspect the codebase and produce the architecture, files, sequence, tests, and risks; planning can be lighter for small or medium changes.
- Have AI build and unit-test, then manually walk the main scenarios because dynamic loading and micro-interactions can escape automation.
For adoption work, diagnose belief as well as behavior and benefit: Nir Eyal’s motivation triangle says sustained action requires all three, and he argues that people who see AI as a threat or burden are less likely to engage with it. Pair rollout instructions with a small, credible win that builds confidence.
Case Studies & Lessons
Make a B2B pilot a commercial experiment, not an open-ended trial. A founder preparing a two-week AI document-processing pilot is explicitly trying to define success, capture honest user feedback, and establish the route to payment before launch. The most useful operating advice is to measure problem offload rather than “they liked it,” set a realistic coverage target such as 70%, track adoption, retention, and core-feature use, observe users directly, and interview affected decision-makers. Put the success metrics and conversion terms in the contract before the pilot: automatic annual conversion if the criteria are met, termination if they are not, and simple pricing with few unnecessary options.
Career Corner
Present AI as evidence inside a normal PM profile. Current community advice is to tailor accomplishments to the role, show model deployment and the concrete cost-versus-latency trade-offs managed, and avoid generic AI buzzwords or a special “AI PM” label.
Tools & Resources
Aakash Gupta’s current framework shortlist gives each tool a distinct job: Opportunity Solution Trees for tracking hypotheses and learning from failed experiments; Working Backwards for defining the MVP and launch requirements before coding; JTBD for behavior change; North Star for multi-team alignment; Four Big Risks for value, usability, feasibility, and viability; and LNO for reserving Grade-A effort for high-leverage work. Use them as decision checklists, not substitutes for judgment.
Separate product judgment from project administration. A former Capcom employee contrasted Western studios’ emphasis on Jira, burn-downs, data tracking, and task management with Capcom’s producer role: providing creative oversight alongside a director, challenging whether work will resonate with players and fit the timeline and budget, while the director retains final say. The PM lesson is to make delivery tooling serve product decisions and customer value rather than let charts and task completion define progress.
Make process earn renewal. One commenter argues that meetings and required fields accumulate because adding them spreads the cost across the organization, while removing them creates personal accountability. Their proposed countermeasure is to give every recurring meeting and required field a default expiry date, renewing it only when someone can identify a decision it changed during the prior quarter—not merely informed.
Test governance against decisions and outcomes. Community examples include being asked to create governance, a workback plan, and an operating rhythm for a single strategy paper, alongside extensive recurring status meetings and reports. Another commenter says reporting still consumes 40% of their week after automation, with three reporting layers and large volumes of Confluence documentation. A useful review question is what decision each reporting ritual enables; if no one can answer, the activity may be organizational theater rather than transparency.
AI-assisted delivery is creating a new operating-model problem. One commenter reported shipping a feature built entirely by coding agents in three weeks with two engineers and an unlimited token budget, despite story points representing roughly six months of work; the next challenge was creating business processes to scale AI development. Another said a read-only AI tool still required CAB approval despite having no QE testing, with its read-only nature helping justify the exception, while a VP pushed to treat vibe coding as the answer to everything. This points toward risk-tiered governance: preserve stronger approval and testing controls for higher-impact changes rather than generalizing from low-risk, read-only tools.
- AI-native PM workflow: PMs do not need to code, but developing an understanding of engineering with AI can strengthen their profile. The recommended lightweight lifecycle is: (1) use AI to question the idea or propose 2–3 directions with pros and cons, producing an interactive prototype; (2) refine the problem/JTBD, users, desired behavior, scenarios, constraints, and UX decisions, using technical spikes when needed and skipping this step for small changes; (3) have the agent inspect the codebase and define architecture, files, implementation sequence, tests, and risks, while skipping detailed planning for small or medium changes; and (4) let AI build and unit-test, then manually verify the main scenarios because automation may miss dynamic loading and micro-interactions.
- Entitlement and role design: AskOne moved from user-level to organization-level billing after the need for moderators exposed that users cannot contain additional users. Its plans gate organization capabilities through feature keys rather than hard-coded plan names—for example, Free supports one active room and 100 participants, while Premium supports up to 10 active rooms and 1,000 participants with monthly or annual billing—while individual permissions remain role-based; the default Member role was renamed Moderator with key
org:moderator. The moderation experience defaults rooms to moderated but allows that setting to be disabled when no moderator exists; submitted questions remain pending until the host approves, rejects, or bans them, and approved questions become visible to everyone. - Production release and measurement practices: AskOne separated development from production with a production GitHub branch and a separate Supabase project; code and database migrations move together, but data does not, and changes or test data remain out of production until explicitly pushed. For early product analytics, the author recommends cookie-disabled Microsoft Clarity: this avoids a cookie banner and reduces consent-related risk, but sacrifices returning-user tracking while retaining landing-page analysis, heatmaps, and session recordings.
- Nir Eyal’s “motivation triangle” says sustained motivation requires three elements: knowing the behavior, wanting the benefit, and believing in the benefit or one’s ability to perform it; belief holds the behavior–benefit link together. For PM change initiatives, this points to pairing requested actions and expected outcomes with deliberate work on team or user confidence.
- Eyal defines a limiting belief as one that decreases motivation and increases suffering, while a liberating belief does the opposite; he treats beliefs as tools for decision-making rather than immutable truths. His inquiry-based stress-reduction process is: identify an area where progress is stuck, write down the belief being treated as the reason, use four questions to generate a “turnaround” portfolio of alternative perspectives, temporarily adopt one perspective, and test it through daily behavior—trying another if it does not work.
- For AI adoption, Eyal argues that beliefs about AI shape usage: people who see it as a job threat or burden are less likely to engage, while the way they approach and use the tool—and the larger purpose behind it—determines what they get from it. He also characterizes consuming business or productivity advice without applying it as “pseudo work” that reinforces listening without action, making behavior change—not additional information—the relevant measure of learning.
- A practical B2B JTBD discovery pattern is to reconstruct a recent event across situation → decision → current process → friction → consequence → workaround → budget/owner, then compare interviews for recurring jobs rather than feature requests.
- Map the customer’s process, goals, and current steps first; identify major blockers to goal attainment before smaller UX pain points, and observe people performing the workflow because normalized, flawed steps may be difficult for them to identify proactively.
- Test whether the job matters enough to buy by asking what solutions people have tried, whether they paid, and how much time the process takes; look for existing workarounds, concrete failure consequences, and evidence that money or time is already moving instead of relying on frequency alone. Identify who feels the consequence and who controls the budget.
- Reduce discovery bias with open, event-based questions such as where and when the customer realized there was a problem, and check that a preselected solution is not creating a solution-in-search-of-a-problem situation.
- In digital health and medtech, include an incumbent-risk check—whether Epic already offers similar functionality or could release it for free—and distinguish relatively lower-value time savings from patient-outcome improvements, which may be more valuable but harder to prove.
- Treat an MVP as a test of one risky assumption rather than a smaller version of the entire product: define one user outcome, select a single happy-path workflow that delivers it end to end, and validate it with 5–10 target users through a clickable mockup or manual concierge experience before coding. Measure whether users return or pay, not merely whether they say they like the idea.
- Build personas and test product-market fit before investing heavily in development; structure the feature roadmap by “Core,” “Comprehensive,” and “Full” completion levels, then choose the required level for each feature. Sequence work around order of operations, future extensibility, and feature blockers.
- AI-assisted or “vibe” coding can accelerate early prototypes, but it carries risks of maintainability problems, security issues, an unsuitable tech stack, and later rewrites; use it to amplify existing technical skills rather than fill technical gaps. A sales workaround that was demonstrated to a customer before the underlying telemetry was ready produced a feature far from the customer’s expectations, and the customer dropped the product.
- Design AI-native workflows as closed loops: A coding loop can turn a bug report into a fix and low-risk production release in five minutes. The same pattern can extend to growth experiments, sales demos, legal, and support; the key implementation step is giving the agent the context it lacks to complete the loop.
- Treat moats as something product usage can reveal: Cursor is presented as having started with high engagement, then turning captured reasoning traces into its own models. Product teams do not need a fully formed moat on day one if they build momentum, craft, and engagement; network effects, scale, brand, and proprietary data can emerge from decisions made after launch.
- Keep humans responsible for choosing the next opportunity: Agents are effective at hill-climbing toward a local maximum but plateau when deciding which direction to pursue next, so the operating model is agent optimization followed by human direction-setting, repeated over time.
- For consumer AI, design beyond productivity and chat: The opportunity identified is to build for connection, entertainment, and happiness, with interfaces between conventional chat and TikTok-like experiences. Falling model costs, better interfaces, and broader use cases are described as removing three constraints that have held consumer AI back.
- Use premium willingness-to-pay as a product exercise: Ask what the $1,000- or $10,000-per-month “Birkin bag” version of a consumer product would need to do to justify its price; the post frames price as a signal of product-market fit and argues that consumer discretionary spend is available for exceptional products.
- Build model fluency through frequent shipping: Different models are suited to different types of work; a practical method is to build with every release, use one or two low-stakes projects as recurring test beds, and ship at least weekly.
- The AI “permanent underclass” and job-loss narrative is challenged by a counter-signal: radiologist demand reportedly kept rising despite 20 years of predictions that the profession was “cooked,” open engineering roles are at all-time highs, and every AI-stack layer has roughly 20 strong competitors rather than a mobile-era winner-take-all structure.
- Product-strategy prompts from the discussion include looking for AI’s “/loop make me happier” opportunity, viewing companies as series of loops, treating moats as discovered rather than designed, and identifying the “Birkin bag version” of a product.
- YC evolved QM from observed internal usage and operational pain. The initial one-size-fits-all “general agent” gained Slack access, scheduled jobs, and more tools as usage expanded; the team then moved to QM after operating 50+ individually configured Hermes agents became difficult to manage. QM was subsequently positioned as a customizable assistant for every employee, available in Slack and a web UI, supporting email triage, legal and finance workflows, document editing, internal-data retrieval, and lightweight app creation.
- The product architecture prioritizes flexibility while keeping the core narrow. QM centralizes conversations in Postgres, treats sandboxes as on-demand resources rather than permanent homes, and lets the agent choose sandbox capacity and model provider based on the task. The team deliberately kept the harness thin around three core capabilities—remote execution, object-storage access, and internal-app publishing—while treating other tools as temporary solutions for rough edges.
- YC used guardrails and human review where automation was not reliable. Automated hill-climbing over agent traces produced mixed results because agents judged only their local change, so human involvement remained important. QM keeps database access mostly read-only and requires human review of proposed bulk writes, while fine-grained permissions are treated as a prerequisite for preventing sensitive information from leaking across shared contexts. The team also introduced minimum time or token budgets to stop agents from giving up early, improving research and reporting outputs.
- Open Jarvis illustrates a product strategy for local AI: optimize the whole user-facing stack rather than only the model. The project targets cloud AI’s cost and privacy drawbacks with five primitives—UI, agent logic, model, inference engine, and tools/learning—and uses cloud models during development to optimize local configurations before deployment. The team reports lower cost, latency improvements, and quality gains, including an approximately 800× reduction in inference cost, while acknowledging that local models still cannot handle every task.
- Early-stage trade-off: Participants describe Supabase as a fast way to obtain authentication, row-level security (RLS), infrastructure, and tooling so an early startup can focus on the product and iterate; one team reports using it across millions of rows and dozens of tables, while another recommends starting with direct integrations and adding a backend when scale or business-logic complexity requires it.
- Key product risk: One team’s production experience included cumbersome RLS policies that duplicated business logic, difficult-to-debug triggers and functions, expensive storage egress, frequent outages, and an authentication migration constrained by the prospect of forcing a broad password reset. These are reported implementation experiences rather than universal evidence about Supabase.
- Portability pattern: A commenter recommends treating Supabase primarily as standard Postgres, keeping complex logic behind a backend, avoiding Supabase Edge Functions, and storing only authentication data in auth tables while maintaining application user data separately; this is intended to reduce dependence on Supabase-specific schemas and ease a later auth or database migration. RLS is not universally viewed as a liability: another startup says session-enforced RLS provides a cross-tenant data-breach safety net and lets app developers iterate without reimplementing access controls.
- A Senior UI/UX Designer transitioned internally into an Associate Product Manager role, with the company citing accumulated domain and product knowledge as the main rationale.
- The transition highlights a career-portability concern: while working remotely in India for a US-based company and seeing global opportunities, the PM is uncertain whether a UI/UX-to-APM background will translate into Indian PM roles and is seeking a 1–2-year development focus to improve employability.
- Product strategy principle: “Moats are discovered, not designed,” framing defensibility as something PMs should uncover through product and market learning rather than treat solely as an upfront planning exercise.
An aspiring PM transitioning from six years in finance operations, where they led 13 people, is preparing for a PM career after completing a master’s in project management. They are seeking guidance on the expected breadth and depth for entry-level PM interviews, listing SQL, Figma, Jira/Scrum/Agile, Six Sigma, Power BI, product thinking, A/B testing, analytics, APIs, roadmapping, user research, Python, PRD writing, and competitive analysis.
Andrew Chen contrasts two product priorities: use AI to eliminate drudgery, workflow friction, and costs, while preserving more human attention for connection, entertainment, and humanity—areas characterized by novelty-seeking and outcomes that are harder to verify.
Product managers are exploring an AI-assisted PRD-to-engineering workflow: interactive prototypes created through “vibe coding” may reduce the amount of descriptive and behavioral detail needed in PRDs, while AI tools could translate the PRD and prototype into comprehensive Jira stories and tickets with clear descriptions and acceptance criteria.
- Treat an AI PM resume as a role-targeted PM CV: emphasize prior experience and accomplishments, tailor the content to the specific job, and describe AI work alongside other relevant product experience rather than relying on a separate “AI PM” format or label.
- For AI PM roles, make model deployment and the concrete cost-versus-latency trade-offs you managed explicit. Avoid generic AI buzzwords; strengthen the resume with measurable impact and evidence against core PM competencies.
- Discovery and matching friction: Users report that Co-Founder Match offers only broad filters such as science, business, and distance, with no keyword search, making relevant profiles difficult to find. Other feedback describes the experience as overly algorithmic and suggests freer browsing or an AI-assisted matching conversation.
- Trust and marketplace-quality problems: Anecdotal reports mention bots, consultant/contractor profiles, generic pitches, and a technical-founder profile receiving many idea-stage requests; one commenter estimated roughly five idea-focused users per builder. A suggested screening workflow is to ask what a candidate shipped, sold, or personally funded in the last six months, invite candidates with concrete evidence to a 30-minute call, and skip generic first messages.
- Mixed outcomes: Despite the negative feedback, commenters also reported legitimate cofounder matches, including one match that became a company and another company described as growing fast.
A professional with 10 years of management experience is nearing completion of a product management Weiterbildung and is seeking guidance on which PM roles and seniority levels to target when applying for jobs.
- Define pilot success around problem reduction, not subjective satisfaction: set a realistic target rather than expecting 100% coverage (the commenter suggests roughly 70%), then track adoption such as sessions per day, session length where relevant, retention, and usage of core features. Review product-session recordings manually when available.
- Combine behavioral and qualitative feedback: hold both structured and open-ended one-to-one discussions, observe users working in the product, and interview the different decision-makers affected by it.
- Design the conversion path before the pilot begins: sign an agreement that defines success metrics and automatically converts to an annual subscription if they are met, while allowing termination if they are not; this is intended to prevent pilots from stalling without a commercial outcome.
- Keep B2B pricing simple: base pricing on margins and competitive context, but minimize unnecessary plan choices because simpler pricing can accelerate deal closure.
A Reddit user is offering referrals for APM roles targeting candidates with 1–3 years of product experience, including at least one year in healthcare SaaS; interested candidates are asked to send a direct message.
A Northwestern University master’s student graduating in December is seeking a full-time U.S. product manager role and asks the community for referrals or introductions. Their background includes three years as a software engineer, an internal transition to APM at a U.S.-based payments startup, and a Bay Area startup PM internship; they report struggling to find a job.