We can't find the internet
Attempting to reconnect
Something went wrong!
Hang in there while we get back on track
Big Ideas
Depth beats AI model FOMO. Sachin Rekhi argues that social media rewards hype about frontier models more than guidance on making existing tools work. His recommendation for most PMs is to choose an established tool such as Claude Code or Codex, then go deep: automate workflows with skills, make company context machine-readable through MCPs, build design systems, and add a semantic layer for data analysis. The practical implication is that durable advantage comes from compounding workflow and context integration—not from repeatedly switching tools.
Discovery is extrapolation, not transcription. Teresa Torres highlights a familiar trap: customers describe the problem directly in front of them, not their “wildest dreams.” Use the literal request as evidence about the customer’s job, then reason from the persona and adjacent workflow to predict what they will need next before they can articulate it.
Tactical Playbook
Use progressive refinement so AI speed does not harden bad assumptions. A useful process from this period’s requirements discussion is:
- State the product thesis, desired outcome, and constraints; test the thesis with the target persona.
- Prototype early. A user story is a conversation prompt and hypothesis, not proof that users want the feature; only customer testing can establish that.
- Once the flow holds up, add functional requirements, acceptance criteria, and edge cases. Keep early artifacts loose enough to change.
- Keep one backlog and a short engineering review. Product owns the user problem and desired experience; a tech lead or engineer decomposes the technical work and reviews feasibility.
This preserves the speed of AI-assisted prototyping without turning cheap, premature requirements into expensive rework.
Case Studies & Lessons
SaaStr reports that agentic go-to-market execution can scale a very small team—but not by removing humans from the loop. The company says three humans now operate 21 agents and that sponsorship revenue doubled in 12 months; it attributes a 60% increase in new business to inbound agents. The inbound system handled almost 3 million website sessions, 17,000 conversations, about 600 meetings, and influenced a couple million dollars of pipeline.
The design choices matter more than the headline: visitors can choose AI chat or self-serve; the system uses first-party signals and behavior data to generate a tailored pitch, waits ten minutes to observe engagement, and routes the opportunity using similar-account context. On outbound, agents send only one to three initial emails; a human then sends the customized deck and follow-up. SaaStr also says it built internally because third-party tools could not use enough proprietary context, and recommends stair-stepping the system rather than attempting everything at once. The transferable lesson: automate coverage, context gathering, and routine follow-up; retain human judgment where messaging and commitment affect the customer relationship.
Career Corner
Build an agentic-workflow portfolio piece, not another model demo. One B2B SaaS PM with eight years of IT experience reports that basic AI-PM training did not prepare them for the agent, multi-agent, and agentic-workflow experience appearing in the listings they see. A stronger project brief is to choose one B2B process with handoffs, map failure points, build a small agent with human approval and an evaluation set, and publish baseline versus post-automation time, error rate, and intervention rate. That makes product judgment—and not just familiarity with models—visible to hiring managers.
- SMB-focused products face a scale and unit-economics challenge in VC contexts: the discussion associates this segment with more linear sales and marketing, small contract sizes, churn, and customer-acquisition costs that may not fit SMB pricing.
- Before committing to an SMB segment, product teams should quantify churn, CAC, time to close, willingness to pay, cross-sell and upsell potential, reachable market size, competition, and regulatory constraints.
- Potential product-strategy responses include linking monetization to transaction volume or customer revenue rather than seats through payments, payroll, collections, or other fintech models, and targeting freelancers, sole proprietors, or a narrow high-growth or stable vertical.
- Product-led growth must match implementation complexity: bookkeeping may be difficult to scale through organic PLG when account and ledger setup requires implementation and specialization, while SMB products generally benefit from simplicity.
- VC fit should be evaluated separately from product viability: commenters describe successful, funded SMB companies and argue that many strong businesses simply do not fit VC return requirements. One founder also describes moving from SMB toward enterprise and eventually raising several additional VC rounds.
- Use progressive refinement for requirements: start with the problem/outcome and constraints, move to the proposed flow, then add functional acceptance criteria and edge cases once the flow is understood. Keep early stories high-level, but make them testable before committing to build; maintain one backlog/source of truth and conduct a short engineering review to prevent duplicate stories. This aligns with treating user stories as a high-level view of intended functionality, then adding functional requirements and acceptance criteria once the solution is more graspable.
- Teams can draft high-level stories in parallel with design and hand the finalized design and stories to engineering, but detailed requirements written before the idea is tested can lock in decisions and require rework when the solution changes.
- Validate the product thesis before treating stories as truth: state the hypothesis, speak with the target persona, prototype early, and test the prototype with customers. In an AI-heavy workflow, use Claude after prototyping to interrogate unresolved engineering decisions and convert the answers into stories, while expecting engineering to uncover remaining gaps.
- Translate product decisions into “money stories.” When working with budget-controlling executives and go-to-market leaders who may not care about product operating models, tech debt, or workflows, frame prioritization around how the work will make money and express trade-offs in financial outcomes rather than staffing or process terms.
- Treat AI speed as a throughput input, not a product outcome. Code generation may become dramatically faster, but commercially viable products still require security, usability, architectural fit, reliability, and enterprise readiness; the interview notes there is not yet evidence of a comparable increase in workable, tested products. In established markets, faster development does not automatically expand customer budgets; more entrants and features can intensify competition, reduce prices, and depress total category spending.
- Preserve product judgment under AI-enabled discovery. In a 100-feature-per-month scenario, users may not discover 98 features and may give little attention or feedback to most of what they do see, making user attention the scarce resource. A good two-thirds of incoming requests may be bad ideas, harmful, illegal, incoherent, or damaging to the product, so teams should deliberately select the few features worth promoting rather than wire every request directly to code generation. A practical boundary is to automate obvious bug triage and fixes, while requiring product judgment for larger changes involving customer impact, legality, compliance, economics, and market need.
- Use a barbell-shaped PM role. The proposed allocation shrinks engineering coordination from roughly 60% of PM time to about 20%, leaving roughly 40% for front-end discovery—customer research, market and competitive analysis, economics, money stories, and legal checks—and 40% for commercialization through customer and sales calls, marketing collaboration, and sales-enablement materials.
- Make go-to-market teams co-accountable for roadmap value. Product and engineering can ask sales and marketing to commit to higher quotas, lead-generation results, target markets, marketing plans, and sales targets for new products; if those commitments are not credible, the product may not be worth building. Reward systems also shape PM behavior: when companies threaten to remove PMs who do not use AI tools, PMs rationally shift toward building prototypes and code even when that may not be the best long-term organizational strategy.
- Assess platform-absorption risk, not just buildability. HTML authoring tools were undermined when Microsoft Word added “save as HTML,” and major security vendors had already announced or shipped similar AI intrusion-detection capabilities; PMs therefore need to test whether an idea is differentiated and defensible before treating it as a standalone product.
- SaaStr reports a three-person team operating 21 AI agents and doubling sponsorship revenue in 12 months. Its inbound agents were credited with a 60% increase in new business, while renewal revenue was 60% ahead of the prior year year-to-date, which the team attributed partly to contacting every account and maintaining richer, ongoing customer context. The inbound agent handled nearly 3 million website sessions, 17,000 conversations, about 600 meetings, and influenced several million dollars of pipeline.
- The inbound design pattern preserves user choice rather than forcing an AI interface: users can either chat with an AI that answers questions, qualifies budget and intent, and books meetings instantly, or use a self-serve path. The self-serve workflow uses first-party signals before third-party data, including prior site activity, event attendance, newsletter status, ads, and existing conversations, then adds competitor context. It instruments behavior with heat mapping, creates a company-specific living prospectus, waits 10 minutes to observe engagement, generates a tailored pitch, updates the prospect's link, and tracks follow-up in the dashboard, Slack, and Salesforce. Similar-account knowledge is then used to route the meeting to the salesperson most likely to add context.
- The operating model is deliberately human-in-the-loop: outbound agents are limited to roughly one to three initial emails, after which a human sends a customized deck and follow-up rather than an automatic calendar link. SaaStr built its own agent because third-party tools could not use enough proprietary customer, community, partner, and historical-performance data to produce the desired level of personalization. The recommended implementation lesson is to build incrementally—start with a narrow workflow and stair-step capabilities rather than attempting the full system at once; the team also found that reducing excessive data/API complexity improved the agent's recommendations.
- A recurring operating model is for product to own the user-facing problem, desired experience, scope, timing, and rationale, while engineering owns the technical design and implementation breakdown. PM-written PRDs or stories are reviewed and decomposed with tech leads or engineers, who provide feedback on sizing, ticket boundaries, testing, and technical dependencies.
- User stories work best as lightweight statements of the problem and desired outcome—an invitation to conversation—rather than prescriptive implementation documents. Teams can capture intent first, then use refinement with engineering, design, data, and QA to agree on scope, acceptance criteria, and testability close to build time.
- AI is being used to draft technical stories and acceptance criteria from PRDs and codebase context, while product still refines scope and sequencing. One practitioner recommends using an LLM to ask high-impact clarification questions rather than blindly generating requirements, and reports that agentic workflows still require careful human review.
- Collaborative refinement and upfront conversations take time, but practitioners report that they expose incorrect assumptions and prevent downstream problems that could cost two or three times more; the preventive value can be difficult to express through management KPIs.
Trust-first framework for recurring AI monitoring: Before assigning a bot a weekly competitor-monitoring job, define how it can fail and write the evaluation criteria before running it. Shah tested two Grok Bots on the same task: one passed all three criteria, while the other found useful information but was not trusted with the recurring assignment. Require checkable evidence and a clear reason each finding matters; when nothing has changed, silence is the correct output.
- Customers typically describe the immediate problem in front of them, not their “wildest dreams”; treating the stated request as the full opportunity is a discovery trap.
- During discovery, start with the customer’s literal ask, then extrapolate outward using the customer persona to predict what they will need next—even before they can articulate it.
- Operationalize enterprise AI around organizational context, not just model capability. Databricks’ approach is to digitize meetings and other organizational content, define an ontology connecting goals, departments, people, projects, and resources, then compile it into a permission-aware, continuously computed index for agents. Databricks says its internal ontology contains millions of nodes and lets AI perform analyses, answer questions without follow-up meetings, and disseminate decisions; employees now routinely query Genie for organizational answers.
- Make AI cost control a product capability once usage scales. Databricks introduced per-person and per-group budgets, threshold warnings, cost forecasting, smart routing to cheaper models, and harness multiplexing; the same model can cost nearly 2x more under a different harness, while the company’s token usage rose without a corresponding increase in total AI cost.
- Match model ownership to task specificity and evaluation capacity. Startups with a narrow, repetitive product can post-train a strong open model with reinforcement learning to reduce cost, improve speed, and retain control of their IP. Large enterprises may rationally stay with frontier models because creating reliable evaluations and baselines is difficult; even automatically generated evals were ignored when they added process overhead.
- Design for agents as a distinct product persona. Neon/Lakebase focused on agent workflows rather than competing primarily for DBA or application-developer preference: databases start and clone in well under a second, support lightweight branching and recovery, and use pricing that does not penalize experimentation. The result reported in the discussion is that more than 90% of databases created on Neon and Lakebase are created by agents rather than humans.
A 22-year-old software-engineering graduate reports that six months building a startup provided broad cross-functional experience: developing mobile, admin, and partner applications; coordinating developers; designing workflows around business needs; onboarding and negotiating with brands; and prioritizing work for user and partner value. They are considering a master’s in international business/management in Shanghai as a route into technology product management, while weighing which skills and credentials would best support the transition.
A prospective buyer reported that an AI PM Accelerator’s advertised “live” webinar appeared prerecorded: only two attendees were present, the chat was empty while comments from absent participants were read, and page inspection revealed a video element loading an earlier MP4 recording, leaving no opportunity for live questions. The attendee further said roughly half the session promoted the accelerator and that it did not explain how to become an AI PM in 90 days beyond encouraging viewers to buy the program.
- A startup founder is considering stealth as a product-launch strategy despite existing traction: the product has about 5,000 registered users after one year, adds roughly 200 registered and 800 unregistered users organically each month, and recently received $400,000 in funding.
- The rationale is to protect a domain-specific ViMoE trained on roughly 6 billion images, already integrated into the web app and described as producing extremely high retention. The founder worries that revealing the technology shift would give competitors time to adapt and build around it before the product is finished.
- The proposed sequencing is to stay relatively quiet until the technology is fully integrated, mobile apps are built, and retention improves, then deploy the funding heavily into marketing during the stronger spring/summer season. The unresolved product-strategy trade-off is competitive secrecy versus incremental user growth when paid acquisition can later accelerate demand.
- For PMs building agentic AI products, frame the work around measurable workflow outcomes rather than model demos: choose a B2B process with handoffs such as support triage or account research, map its failure points, build a small agent with human approval and an evaluation set, then publish baseline and post-automation time, error rate, and intervention rate so hiring managers can assess product judgment.
- An internal-tools PM described shifting a mixed IT, infrastructure, systems, and hardware function from project-centric SaaS deployments, process transformations, and integrations toward product management by hiring software engineers and treating internal products as products. The team’s reorganization raises whether the PM role should sit with product-oriented engineering partners or under project management, while the PM reports working most closely with developers, IT support, DevOps, and systems.
- Internal-product teams may need to measure value beyond user satisfaction: one practitioner distinguishes employee users from the paying customers they support, while another says an enterprise internal team focuses on saving the business time and money and otherwise operates like a standard product/engineering organization.
A product-management community member is seeking to split or share the $429 lifetime-access Product Alliance “Full Library Access Pass.” Another member offered to share an account.
- An entry-level candidate reports submitting more than 150 applications for associate/junior Product Management and Product Owner roles but receiving only one interview; that interview was for a mid-level role and did not progress. Their application approach included product teardowns, cover letters, and product analysis, and they were willing to relocate within the EU/EEA and learn a local language.
- The candidate also applied to strategy & operations, founder’s associate, and BizOps roles, identifying product, operations, and funnel optimization as strengths and sales as a weakness. They questioned whether their CV or positioning, lack of formal internal-stakeholder experience, English-only language ability, or ATS filtering was limiting responses; they found most roles through LinkedIn.
- For a pre-product AI SaaS, customer discovery should precede major commitment: the founders planned to work with potential customers to understand their needs, then pivot or build toward validated demand. Commenters recommended validating part-time for 8–12 weeks and looking for paying customers or a credible waitlist before making the leap.
- Use explicit validation gates: speak with roughly 20 potential customers, test whether at least one will pay for a beta, and assess customer need, product direction, and the GTM path. Treat initial problem validation separately from scalable PMF: a few customers may confirm the problem, but repeatable acquisition and retention require a credible path to repeat traction.
A reported Ramp business-case interview involved relatively light pre-work, but candidates were expected to know the fintech space inside-out; the panel tested segmentation logic and prioritization of customer personas for a hypothetical launch.
Early-stage PM operating model: The author argues that founding PMs should work beyond conventional ticket ownership: move quickly with small teams, speak directly with users, identify the problem and what to build, collaborate closely with engineering, prototype when needed, contribute to GTM, operations, and growth, and ultimately own product outcomes.
- PMM certification ROI appears to depend on career stage and employer: PMA’s core certification is commonly recommended for people breaking into product marketing, while some job descriptions favor Pragmatic.
- The payoff is not universal: one Pragmatic-certified practitioner said interviewers rarely ask about it and that it had not materially changed interview outcomes; a director-level user found certification somewhat helpful but not worth self-funding, particularly beyond junior roles. Program pricing was reported at roughly $700–$1,300 per module, with higher costs for the full stack, so candidates should weigh the target role, seniority, and employer sponsorship before paying personally.
An 8-year IT professional with approximately 3 years as a B2B SaaS PM reports that, after taking an intentional career break in 2025, they secured two offers but faced aggressive compensation lowballing that they attribute to the employment gap. They also report that a basic AI PM program covering definitions and simple RAG did not prepare them for job listings requesting experience with AI agents, multi-agent systems, and agentic workflows; they are seeking non-coding learning resources and practical portfolio projects to demonstrate that capability.