We can't find the internet
Attempting to reconnect
Something went wrong!
Hang in there while we get back on track
Big Ideas
Agents are forcing a better definition of engagement. Scott Belsky argues that a person who gets value from a service every day through an agent is a DAU even if they never open the digital product; the interface can change, while the goal is an indispensable underlying resource. Apply: make the core engagement metric reflect recurring value delivered—such as a job completed or a decision advanced—and retain interface visits as a separate diagnostic for UX health and distribution.
Future-proof positioning must still sell today. April Dunford frames positioning as how a product best delivers value for a clearly defined customer, not as a marketing label. In one example, repositioning a desktop spreadsheet/SQL tool as an embeddable mobile database changed the target market, sales model, pricing, roadmap, and synchronization requirements. For an AI transition, first align executives on differentiated value, then explain why it matters in the future and offer a staged adoption path: map processes; start with low-risk, human-checked work; automate after repeated success; add exception handling; and retain humans for the hardest cases. Avoid promising a distant autonomous future that gives customers a reason to wait. Recheck competitive alternatives, differentiated capabilities, value themes, and changes in customer buying behavior every six months, using advisory boards, executive account calls, or systematic sales feedback.
Use AI to remove recontextualization tax, not to flatten reality. The Beautiful Mess describes the cost of translating complex operational reality into simplified reports for powerful or time-poor audiences: companies either spend heavily on the translation or wing it at the last minute. With reasonably fresh raw context, AI can produce audience-specific views while teams continue working in their own tools. Preserve the underlying context and create deliberate translation layers for each stakeholder instead of forcing one roadmap format or abstracting the product around every client workflow.
Tactical Playbook
Validate an unfamiliar domain before writing software. A practical community sequence is:
- Cold-DM practitioners, offer to pay for roughly 20 minutes, and ask them to walk through one recent workflow; permit redacted screen sharing where useful.
- Ask what arrived late, which spreadsheet they reopened, what they copied between tools, and where something nearly got missed.
- After five conversations, choose one repeated headache and handle it manually for a practitioner before building the first version.
- Start with one ICP, about 50 verified contacts, and one concrete reason to reply; scale outreach only after the first conversations.
This converts a vague market thesis into observed behavior and a low-cost test. Established competitors and their one-star reviews become sharper interview prompts, not reasons to abandon discovery.
Case Studies & Lessons
Payelle simplified payment choice by moving into the wallet. The team started with a recurring problem: choosing among cards with different rewards at checkout. It shifted from a physical-card concept to mobile wallets, aiming to surface the right existing card at payment time rather than make users open a separate app, search for a merchant, inspect rewards, and return to checkout. Eighteen months later it had built the technology, filed IP, launched, and entered discussions with large companies and financial institutions—but still identified distribution as an unresolved risk. The lesson is to move into the moment where friction occurs before adding another destination, then treat distribution as a separate post-launch hypothesis.
Know when to stop shipping. Paul Graham reports telling a startup that its product was already good enough and that it should stop writing code to focus entirely on acquiring customers; the team listened. PMs can make this handoff explicit: once quality is acceptable for the target user, shift capacity to activation, sales, or retention experiments rather than polishing another feature.
Career Corner
For senior-PM interviews, slow down and compress the answer. Advice from the PM community is to breathe, identify what is actually being asked, clarify when useful, lead with the important point, let it land, and stop before rambling. A simple response structure is three beats: situation, call, what changed. Practice saying that structure once before the next interview loop; it makes judgment easier to hear than speed does.
- Continuous discovery as hypothesis testing. Torres separates discovery (deciding what to build) from delivery (building it) and recommends treating each idea as a hypothesis with fast feedback loops; use qualitative and quantitative methods to learn before excessive build effort. Design feedback to disconfirm rather than confirm the idea, and treat never discarding or evolving ideas as a warning sign of weak discovery.
- Story-based customer interviews. Interview people who actually experience the target problem; ask for a specific recent story, such as “tell me about the last time…,” rather than an opinion on your idea or a reaction to a demo. To collect reliable behavioral evidence, situate the person in the moment, build the timeline with “what happened first/next,” and redirect generalizations back to the specific instance; this reveals context, environment, and actual behavior rather than generic or aspirational answers.
- Opportunity Solution Tree and assumption testing. Start with a desired outcome, populate the opportunity space from interviews, then design solutions tied to those opportunities; the tree is a synthesis exercise for finding the best path to the outcome, not an artifact whose existence is valuable by itself. Align on which opportunity matters most before debating solutions, or teams can work from different scopes and waste effort arguing in the solution space. For evaluative discovery, story-map the customer’s step-by-step path to value and identify desirability, willingness, usability, feasibility, viability, ethical, and sustainability assumptions; test specific assumptions, often within a day or two, instead of testing the whole idea after building everything.
- Cross-functional discovery. Bring engineers, PMs, and designers into the same discovery process: engineers contribute what technology makes newly possible, PMs business needs, and designers what is usable, desirable, and delightful. Torres encourages including engineers in discovery as teams increasingly expect every function to be product-minded.
- AI synthesis needs human research judgment. Dumping mixed transcripts into an LLM without explicit research goals, research design, and decision context can produce shallow, ungrounded, or irrelevant insights. Claude was a useful teammate for identifying opportunities but both missed opportunities Torres found and surfaced ones she missed; it can also preserve a product symptom such as “too many Slack notifications” instead of the broader human need of avoiding irrelevant interruptions, so teams must frame needs around customer experience and keep the solution space open.
- AI-enabled skill-building product case. Because learners struggled to develop interviewing mindset and technique—and many avoided practicing with colleagues out of embarrassment—Torres paired an AI interview coach that gives transcript-level feedback with an AI participant for private practice, enabling repeated practice with expert feedback and tracking whether scores rise across rounds. She kept the beginner flagship course cohort-based but moved advanced curriculum on demand because the AI tools could provide personalized feedback; showing the AI’s work was also intended to teach the underlying skill.
- Evidence quality and evaluation operations. In a Vistily beta, 500 teams uploaded three interviews but Torres estimated only eight were story-based, so the product expanded to general interviews while distinguishing stronger from weaker evidence; team meetings and sales calls were not supported initially, and usability sessions were reserved for evaluating assumptions rather than generating opportunities. The system classified transcripts, extracted key moments and opportunities, generated a first tree from three interviews, and updated trees while preserving human edits through traceable change sets linking nodes to source interviews. In a failure investigation, a missed opportunity grouping interacted with upstream framing errors; four eval variants over three weeks showed a prompt-only fix was insufficient, while putting evals into an agentic loop as guardrails let the system correct itself on a second pass.
- B2B product leaders are under pressure to ship monetizable agentic value. The panel characterizes the CPO role as increasingly focused on delivering AI agents that generate revenue, not AI “for fun,” contrasting this with the earlier practice of deferring roadmap items to future quarters.
- Use controlled execution for high-stakes agents. Rubric’s cyber-recovery product aims to reduce service-management work toward zero, but incorrect recommendations or actions could affect production applications and destroy customer trust. Its target pattern is to use an LLM to generate a plan, keep recovery procedures deterministic and explainable, let the customer edit or approve the plan, and execute only within guardrails; the team treats evaluation design as part of the platform work.
- Build reusable agent infrastructure and roll out autonomy progressively. Rubric chose a generative platform spanning onboarding, troubleshooting, and planning instead of custom-building every anticipated workflow, with the goal of enabling every PM and engineering team to work from an agent-first mindset. Glean’s sales example covers roughly 300–800 Gong calls per day and models a path from testing one call, to departmental autopilot that recommends Salesforce updates, to full autonomy; feedback is persisted to improve later runs, while agent identity and rich traces are treated as scale-level product challenges.
- Treat organizational context as a product layer before automating work. Glean argues that AI must progress from retrieving information to performing work, and that performance depends on company-specific decisions, patterns, tested knowledge, and unwritten conventions. It provides that context through its own assistant or as a single MCP-based system of intelligence for other assistants, combining runtime retrieval with offline processing across teams, projects, subsidiaries, and acquired organizations.
- Encode expertise at both organizational and individual levels, then pair the product with domain experts. Harvey’s agent builder supports natural-language workflows based on selected skills and data sets as well as deterministic workflows with exact steps; these modes are used to encode firm or GC best practices and automate repeatable personal routines. Law-firm knowledge and innovation teams build shared agents, while Harvey says it has 180 legal engineers—mostly lawyers with 8–10 years of experience—and uses bespoke pods containing an agent PM, lawyer, and software engineers for customers needing deeper customization. Legal users’ questions have moved beyond safe usage and citations toward verifying agent plans and collaborating, coaching, and performance-managing around AI work.
- Front-load customer discovery in product leadership. A newly joined product leader described conducting a listening tour with 60 customers during her first six weeks and called talking to customers the number-one requirement for a head of product.
- Match discovery rigor to scope. Teresa recommends treating assumptions differently at different layers: at the business-model level, align on the riskiest assumptions and invest in deeper discussion and testing; at the solution level, use a story map to connect assumptions to individual customer-journey steps, then run fast tests rather than letting debate delay learning. Risk can be extracted from a canvas, PRD, roadmap, or executive one-pager, so teams do not need to start with a canvas.
- Show the work behind product decisions. Presenting only conclusions makes stakeholders treat them as one idea among many; sharing the underlying customer research and reasoning makes disagreement inspectable and moves the conversation from competing conclusions to the evidence and assumptions beneath them, strengthening influence without authority.
- Treat AI quality as an explicit product measurement loop. An eval is a metric for how often a defined failure occurs: inspect input/output pairs, identify a concrete error, encode a deterministic check or an LLM-as-judge measure, and iterate on prompts, context, or orchestration to reduce the error rate. PMs contribute domain expertise by defining the quality bar and acceptance criteria; generic golden datasets assume predictable customer behavior and require ongoing maintenance, while product-specific evals should measure value-creation moments unique to the product. Teresa’s interview coach illustrates the loop: a nine-year-refined interview rubric supported a useful first version built in three weeks; it enabled unlimited practice and personalized feedback, while four scores per interview made learner improvement and course gaps visible.
Scope AI product opportunities as concrete recurring jobs. Shah contrasts vague roles such as “Chief of Staff” and “research assistant” with specific instructions like checking a child’s school inbox nightly or reporting daily market changes while saving the research; his conclusion is that “the job explains the Bot.” For discovery, define one recurring job, its inputs and cadence, and the expected output or handoff before expanding the assistant’s scope.
Productize the method around the model. Useful Bots encode what evidence counts, what to ignore, and what a finished result should look like:
last30daysspecifies sources and a time window, Site Audit cannot invent unmeasured metrics, and Critiquito must select one highest-impact fix. A practical PM specification should therefore include evidence rules, explicit exclusions, and concrete output-quality criteria—not just a general request for AI assistance.Make memory an artifact-based product feature. Thoth files and indexes completed research so later questions can start from the prior answer, while Inbot uses a processed ledger to avoid losing track of what a previous sweep handled. Recurring research and operations workflows should persist outputs in searchable records rather than leaving useful work buried in chat history.
Bound autonomy with explicit human handoffs. Copay Compass prepares a cancer-drug assistance application or appeal but does not submit it; eligibility decisions remain with the program and sensitive-information limits are explicit. Table Money similarly drafts but does not send, illustrating the broader rule that “prepare this and bring it back for approval” is more trustworthy than an undefined “handle this.” For consequential workflows, specify permitted actions, the approval point, and data boundaries in the product design.
Add supervisory tooling as agent fleets grow. Loops converts a repository goal into a testable outcome, launches coding agents, reviews their work, and keeps the outer loop moving toward a merge; Shah argues that a fleet also creates the need to inspect, tune, and retire agents. This suggests treating orchestration, quality review, drift correction, and retirement as first-class product capabilities rather than relying only on individual specialist agents.
Product opportunity signal: personal, highly specific workflows. In Shah’s sample of 407 public Bots, personal use was the largest category with 120 Bots, ahead of operations with 68 and engineering with 53; recurring household, paperwork, travel, and other person-specific jobs appear repeatedly. PMs should consider repeatable one-person or household problems as viable AI product opportunities even when they are too narrow to justify conventional standalone software.
- Tradbot is highlighted as a favorite AI bot; its described output is a daily “newspaper” combining the family’s plans with kid-friendly neighborhood news.
- The broader bot lineup covers discrete workflows including chief-of-staff support, family assistance, PR closing, SOC 2 control monitoring, customer support, money saving, and personal shopping.
- Frame AI products around a concrete job, not a broad role. A useful job is specific enough to describe as an action the user wants done repeatedly; this can justify software even when the market is too narrow for a conventional standalone product. Define the job by its trigger or input, the expected output, and the point where the user reviews or approves the result.
- Encode the working method, not just model access. Strong Bots specify what evidence counts, which sources and time windows to use, and what a finished result should contain; examples include refusing to invent unmeasured metrics and selecting one highest-impact interface fix instead of producing an unfocused list. Persist completed research in dossiers, files, or indexes so future work starts from prior artifacts rather than repeating the same investigation.
- Design agent workflows as managed loops with explicit boundaries. For complex outcomes, convert the goal into something testable, launch specialist agents, review their outputs, and keep an outer loop moving toward completion; separate the coordinating role from the execution role. Once multiple agents are deployed, add processes for inspecting, tuning, and retiring agents whose output drifts or no longer earns its keep. Trust improves when the product clearly states what it prepares versus what the human must submit, send, or decide, especially for sensitive work.
- Market signal: In the review of 407 public Grok Bots, personal use was the largest category at 120 Bots, ahead of Ops at 68 and Engineering at 53, suggesting substantial opportunity in highly tailored household and individual workflows.
- Problem → product thesis. The interview cites published phase-3 checkpoint data in which about 60% of people were disease-free five years after treatment, leaving 40% without benefit; it also says checkpoint therapy can cause serious immune-related diseases. The mRNA approach adds a different mechanism by sequencing each tumor against a healthy cell, selecting 34 mutations with an algorithm, and stitching them into an individualized vaccine that teaches T cells the cancer signature the immune system missed. Its phase-3 melanoma study met both recurrence-free-survival and distant-metastasis-free-survival endpoints at the first interim analysis; regulatory work was underway with hoped availability in 2027.
- Execution and scale. The process is built around an information handoff rather than removing and reprogramming patient immune cells: the lab sends tumor/healthy-cell sequence files, and the factory uses synthetic, enzymatic, aqueous production to make DNA/RNA and add lipid, with much smaller reactors than the cell-based process described. The team deliberately optimized the first clinical machine for quality, not efficiency, to avoid a faulty device producing a false-negative trial; after efficacy data arrived, it shifted to automation and robotics, reducing needle-to-needle time, currently about 42 days, machine footprint, and fixed cost while increasing throughput.
- Regulatory design and iteration. Because every dose differs, the company pursued a process BLA/IND and engaged the FDA for years on study design and manufacturing; the key reproducibility test is that the same tumor/blood input yields the same patient-ready output. The algorithm remained version 1.0 across phases 1–3; the next loop is to mine phase-3 samples from responders and nonresponders, then make a tightly controlled 2.0 change only if the data supplies a scientific rationale and efficacy is not lost.
- Roadmap strategy. The expansion plan tests three mechanism-led use cases: combine with checkpoint inhibitors where they already work, use mRNA alone earlier in disease where checkpoint toxicity limits treatment, and explore checkpoint-resistant pancreatic and gastric cancers where the different mechanism may create a signal; the speaker explicitly says effect size must be established experimentally.
- Treat positioning as a cross-functional product decision, not just messaging: define how the product is best at delivering a value that a clearly defined customer set cares about, while clarifying what it is, who it is for, what to compare it with, and why it deserves attention. Repositioning can change the whole business: moving from a desktop productivity tool—a spreadsheet with SQL queries—to an embeddable database for mobile devices changed the target market, sales model, bulk pricing, roadmap, and required sync capabilities.
- In periods of major market change, align the executive team on the product’s core differentiated value, then articulate a point of view on how that value matters in the future and use it to explain current roadmap bets and why customers should invest now. To turn an ambitious AI future into an adoption path, use a maturity model: map processes, select low-risk opportunities, begin with a human checking outputs, automate after repeated successful execution, add exception handling, and retain humans for the hardest cases before expanding automation.
- Keep positioning current through a disciplined six-month checkpoint: reassess competitive alternatives, differentiated capabilities, value themes, and market category, then adjust positioning if competitors catch up, the product changes, or the comparison set shifts. Pair this with systematic customer and field feedback—customer advisory boards or quarterly executive-account calls can reveal changes in budgets and purchase processes, while structured sales-team input can surface new competitors on shortlists before they start affecting deals.
- Use product dependence as a qualitative product test. OpenAI’s internal “mainlining” meme asks whether team members use the product all day, depend on it, and apply their own taste to judge whether people actually want it. Tara Seshan said the recent shift in internal sentiment toward Codex came from people noticing its value, not from a deliberate internal change.
- Build for the near-term model frontier. Tara Seshan’s rule for products built on frontier models is to target where the models will be in 2–3 months; building for today’s capabilities or a year ahead both fails.
- PMs as ambition multipliers. The discussion frames PMs as responsible for elevating everyone’s ambition and describes the future of knowledge work as “steering, not rowing.” It also characterizes OpenAI as “founders-led,” rather than founder-led, with no secret strategy room.
- Lenny states that ChatGPT Work equals Codex, clarifying the relationship between the product names.
- Anthropic recently formalized forward-deployed engineering (FDE) as a function serving customer and internal initiatives, focused on applying AI to real workflows and processes. Unlike time-for-money professional services, FDE teams align with customers on a business outcome and share ownership of delivering it, while feeding engagement learnings back into product and, at Anthropic, research. Each first-of-a-kind engagement is expected to produce a reusable blueprint or playbook that can later be productized, given to customers, or scaled through partners.
- Anthropic decides whether to pursue an FDE engagement using three filters: alignment with its mission to bring AI safely to the world, first-of-a-kind potential that could open new use cases or verticals, and the product signal the work will generate; commercial value is explicitly not the sole lens.
- A career-growth alternative to management progression is a deliberate return to hands-on IC work to learn an unfamiliar domain: Amandep Kurana moved into an IC product-manager role in 2023 after consulting people who had made similar transitions, viewing the move as a way to gain domain expertise with potential future leadership upside. FDE work particularly rewards mission alignment, hands-on building, customer guidance in complex environments, high agency, ambiguity resolution, and maintaining customer trust.
- Evals are an essential product practice for AI workflows and products—including AI-generated PRDs, customer-feedback analysis, and customer-facing AI—because traditional one-time testing is insufficient for variable LLM outputs. Teams should define what “right” means for their specific product and measure how often the AI achieves it.
- A practical eval workflow is to analyze errors and identify which mistakes matter most, select the appropriate method—golden datasets, code assertions, LLM-as-a-Judge, or customer feedback—then run experiments to determine whether changes improve results.
- OpenAI’s “Are you mainlining it yet?” meme functions as a dogfooding test: PMs should ask whether they use the product all day, depend on it, and apply their own judgment to whether people genuinely want it. Product lead Tara Seshan attributed the shift in internal sentiment toward Codex to people starting to notice its value rather than to a deliberate internal change.
- For products built on frontier models, Seshan’s planning rule is to build for where the models will be in roughly 2–3 months—building for today fails, while building for a year ahead also fails. The discussion also frames PMs as responsible for elevating organizational ambition and increasingly “steering” knowledge work rather than doing all the execution themselves.
Recent podcast guests repeatedly advised: “Be more ambitious.”
Design principle — make repeated use cumulative. Hiten Shah argues that software that starts from zero each time feels broken, and that personal software should improve the longer it is used by retaining context. Andy Madrick’s coffee companion demonstrates the pattern: collect session inputs and notes such as beans, recipes, tasting notes, drawdown time, and what worked or failed; persist them in a Notion database; then use the history to recommend adjustments to future sessions, including ratio, flow rate, grind size, and temperature. The approach is most applicable when each interaction generates information that can improve the next one: capture, persist, retrieve, and recommend.
Enterprise product adoption can carry significant internal political risk: when someone introduces a tool into their organization, they are spending political capital and vouching for it internally. Teams should therefore treat internal champions as trust-based relationships, not merely steps in a sales process.
- Define AI product scope around a specific recurring job, not a broad role or presumed market. Shah contrasts vague roles such as “Chief of Staff” or “research assistant” with concrete instructions like checking a child’s school inbox nightly or reporting daily market changes; narrow tools can still be valuable when one person repeatedly has the problem, even without a large standalone market.
- Encode a method, not just a model. Specify what evidence counts, what to ignore, source and time boundaries, and what a finished result should contain; examples include a research Bot with a defined corpus and time window, an audit Bot prohibited from inventing unmeasured metrics, and an interface reviewer required to choose one highest-impact fix.
- Design the operating loop and trust boundary explicitly. Persist research in files and indexes so future work can reuse it, keep sensitive or irreversible actions behind human approval, and add inspection, tuning, and retirement processes when managing a fleet of agents.
- The recontextualization tax is the organizational cost of translating complex, varied operational reality into simplified views for stakeholders with limited time or appetite for detail; teams either invest heavily in flattening reality or resort to last-minute judgment calls, while high-level meetings try to manage by exception under cognitive-load constraints.
- Use AI when teams need to preserve flexible, emergent ways of working while serving stakeholders with different information needs: provide reasonably current raw context and create audience-specific skills that translate the same underlying work into each audience’s vocabulary and format. This avoids either persuading everyone to use one view or manually producing many versions, including roadmap representations such as swimlanes and deliverables or outcome- and metric-oriented views.
- Product implication: do not force clients into the team’s workflow or over-abstract the product to support every possible workflow; retain the team’s preferred way of working and translate it into language that empowers each client. AI’s practical value is making previously worthwhile but too-time-consuming practices feasible.
- AI prototyping practice: Start with the problem and “WHY” before specifying the artifact or “WHAT.” In a regulated-data B2B SaaS team, the author reports that poorly defined prompts caused frustration, wasted tokens, and outputs that were not close to usable; they propose RCCF—role, context, constraints, format—to front-load context instead of discovering it through trial and error.
- Implementation: One practitioner uses a five-line brief before any prototyping prompt: who has the problem, what they do today, what decision the output must enable, what is out of scope, and what “good” looks like. They describe this as discovery written down; framing RCCF as a product brief rather than prompt technique reportedly reduced PM pushback.
- Potential product opportunity: The author is looking for B2B tooling that catches vague asks before a build cycle and coaches the human side of AI interaction, rather than focusing only on routing, cost, or model benchmarks.
- Hiten Shah built “I Said I Would,” a Grok bot that watches Slack and GitHub for clear commitments made to other people, maintains a commitment ledger, automatically closes items when it finds strong evidence of follow-through, and surfaces only important commitments that remain open or uncertain.
- A BA/PO-to-PM transition can involve expanding from delivery responsibilities—roadmaps, requirements, workflows, KPIs, and stakeholder alignment—to strategic ownership of the product’s “why,” including discovery, user conversations, and outcomes.
- First distinguish a genuine strategy-skill gap from a capability-presentation problem; the development path differs depending on whether the issue is what the person can do or what the organization allows them to exercise and demonstrate.
- Target roles where PMs own the “why,” inspect job descriptions for strategic ownership, and learn from internal stakeholders by asking how they reached the “why,” reviewing research, and joining future initiatives.
- Make strategic judgment visible in the current role: before reviewing client requirements, document the problem each request solves and the evidence supporting it, then push back on one weak request. In B2B SaaS, arbitrating feature requests and killing low-value work is presented as core PM practice.
- Build discovery evidence through a recurring cadence of speaking face-to-face with one customer or user each week to understand why they use the product and what would make it better.